From bclaise@cisco.com Fri Sep 2 06:39:01 2011 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 D559821F8B0F for ; Fri, 2 Sep 2011 06:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_50=0.001, 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 3IKaRgOW8Y-b for ; Fri, 2 Sep 2011 06:39:00 -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 6690A21F8B0A for ; Fri, 2 Sep 2011 06:39:00 -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 p82DeZYe025074; Fri, 2 Sep 2011 15:40:35 +0200 (CEST) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p82DeY2g015326; Fri, 2 Sep 2011 15:40:34 +0200 (CEST) Message-ID: <4E60DCD2.8060308@cisco.com> Date: Fri, 02 Sep 2011 15:40:34 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000603000208020600050701" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] proposal for IPFIX charter update 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: Fri, 02 Sep 2011 13:39:01 -0000 This is a multi-part message in MIME format. --------------000603000208020600050701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Juergen, Double-checking with my meeting minutes, I found some more issues. See below. > Dear all, > > At our session in Quebec we discussed candidates > for new IPFIX work items. Based on this discussion, > Nevil and I drafted an update of our charter that > you can find below. > > Please have a look at it and send us your comments. > > Thanks, > > Juergen > > > IP Flow Information Export (ipfix) > > > Description of Working Group > > > The IPFIX working group has specified the information model (to describe > IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX > exporters to collectors). Several implementers have already built > applications using the IPFIX protocol. As a result of a series of IPFIX > interoperability testing events the WG has produced guidelines for IPFIX > implementation and testing as well as recommendations for handling > special cases such as bidirectional flow reporting and reducing > redundancy in flow records. > > The IPFIX WG has developed a mediation framework, that defines IPFIX > mediators for processing flow records for various purposes including > aggregation, anonymization, etc. For configuring IPFIX devices, a YANG > module has been developed. > > 1. Having a solid standardized base for IPFIX deployment and operation > and several exiting implementations, the IPFIX WG will revisit the IPFIX > protocol specifications (RFC 5101) and the IPFIX information element > specification (RFC 5102) in order to advance them to draft standard. > > 2. For giving guidelines to developers of new IPFIX information > elements and for better defining the process of registering new > information elements at IANA the IPFIX WG will create an information > element developers guideline document. > > 3. The export of IPFIX flow records from IPFIX mediators introduces a > set of potential issues at the protocol level, such as the loss of > information on the original exporter, loss of base time information, > loss of original options template information, etc. The IPFIX WG will > define common ways to deal with these issues, by specifying guidelines > for the use of the IPFIX protocol on IPFIX mediators. > > 4. For supporting the aggregation of flow records at IPFIX mediators > the IPFIX WG will define how to export aggregated flow information using > IPFIX. An aggregated flow is essentially an IPFIX flow representing > packets from multiple original Flows sharing some set of common properties. > > 5. The IPFIX WG will investigate the use of the IPFIX protocol for > exporting > MIB objects, avoiding the need to define new IPFIX information elements > for existing management information base objects that are already fully > specified. This method requires the specification of new template set > and options template sets to allow the export of MIB objects along > with IPFIX information elements. > > 6. The IPFIX MIB module (RFC 5815) defined a way to register packet > selector functions at IANA. The WG agreed that another method would > be preferable that requires a minor change of RFC 5815. The IPFIX WG > will produce a new version of RFC 5815 with small modifications of > the IANA actions and DESCRIPTION clauses in the the MIB modules. Even if obvious, I believe that a sentence explaining that all new deliverables should be based on RFC5102bis and RFC5101bis > > Oct 2011 Publish draft on guidelines for IE doctors > Oct 2011 Publish draft on IPFIX use at mediators > Oct 2011 Publish draft on intermediate aggregation > Oct 2011 Publish draft on exporting MIB objects > Oct 2011 Publish draft on data link IEs I guess you want to mention the IPFIX MIB module > Dec 2011 Publish draft revising RFC 5101 > Dec 2011 Publish draft revising RFC 5102 > > Apr 2012 Submit guidelines for IE doctors for publication as > Informational BCP RFC > Apr 2012 Submit draft on IPFIX use at mediators for publication as > Standards track RFC > Apr 2012 Submit draft on intermediate aggregation for publication as > Standards track RFC > Apr 2012 Submit draft on data link IEs for publication as Standards > track RFC I guess you want to mention the IPFIX MIB module Regards, Benoit. > Apr 2012 Submit draft revising RFC 5101 for publication as Standards > track RFC > Apr 2012 Submit draft revising RFC 5102 for publication as Standards > track RFC > Sep 2012 Submit draft on exporting MIB objects for publication as > Standards track RFC > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------000603000208020600050701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Juergen,

Double-checking with my meeting minutes, I found some more issues.
See below.
Dear all,

At our session in Quebec we discussed candidates
for new IPFIX work items. Based on this discussion,
Nevil and I drafted an update of our charter that
you can find below.

Please have a look at it and send us your comments.

Thanks,

    Juergen


IP Flow Information Export (ipfix)


Description of Working Group


The IPFIX working group has specified the information model (to describe
IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX
exporters to collectors). Several implementers have already built
applications using the IPFIX protocol. As a result of a series of IPFIX
interoperability testing events the WG has produced guidelines for IPFIX
implementation and testing as well as recommendations for handling
special cases such as bidirectional flow reporting and reducing
redundancy in flow records.

The IPFIX WG has developed a mediation framework, that defines IPFIX
mediators for processing flow records for various purposes including
aggregation, anonymization, etc. For configuring IPFIX devices, a YANG
module has been developed.

1. Having a solid standardized base for IPFIX deployment and operation
and several exiting implementations, the IPFIX WG will revisit the IPFIX
protocol specifications (RFC 5101) and the IPFIX information element
specification (RFC 5102) in order to advance them to draft standard.

2. For giving guidelines to developers of new IPFIX information
elements and for better defining the process of registering new
information elements at IANA the IPFIX WG will create an information
element developers guideline document.

3. The export of IPFIX flow records from IPFIX mediators introduces a
set of potential issues at the protocol level, such as the loss of
information on the original exporter, loss of base time information,
loss of original options template information, etc. The IPFIX WG will
define common ways to deal with these issues, by specifying guidelines
for the use of the IPFIX protocol on IPFIX mediators.

4. For supporting the aggregation of flow records at IPFIX mediators
the IPFIX WG will define how to export aggregated flow information using
IPFIX. An aggregated flow is essentially an IPFIX flow representing
packets from multiple original Flows sharing some set of common properties.

5. The IPFIX WG will investigate the use of the IPFIX protocol for
exporting
MIB objects, avoiding the need to define new IPFIX information elements
for existing management information base objects that are already fully
specified. This method requires the specification of new template set
and options template sets to allow the export of MIB objects along
with IPFIX information elements.

6. The IPFIX MIB module (RFC 5815) defined a way to register packet
selector functions at IANA. The WG agreed that another method would
be preferable that requires a minor change of RFC 5815. The IPFIX WG
will produce a new version of RFC 5815 with small modifications of
the IANA actions and DESCRIPTION clauses in the the MIB modules.
Even if obvious, I believe that a sentence explaining that all new deliverables should be based on RFC5102bis and RFC5101bis 

Oct 2011    Publish draft on guidelines for IE doctors
Oct 2011    Publish draft on IPFIX use at mediators
Oct 2011    Publish draft on intermediate aggregation
Oct 2011    Publish draft on exporting MIB objects
Oct 2011    Publish draft on data link IEs
I guess you want to mention the IPFIX MIB module
Dec 2011    Publish draft revising RFC 5101
Dec 2011    Publish draft revising RFC 5102

Apr 2012    Submit guidelines for IE doctors for publication as
Informational BCP RFC
Apr 2012    Submit draft on IPFIX use at mediators for publication as
Standards track RFC
Apr 2012    Submit draft on intermediate aggregation for publication as
Standards track RFC
Apr 2012    Submit draft on data link IEs for publication as Standards
track RFC
I guess you want to mention the IPFIX MIB module

Regards, Benoit.
Apr 2012    Submit draft revising RFC 5101 for publication as Standards
track RFC
Apr 2012    Submit draft revising RFC 5102 for publication as Standards
track RFC
Sep 2012    Submit draft on exporting MIB objects for publication as
Standards track RFC


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

--------------000603000208020600050701-- From bclaise@cisco.com Fri Sep 2 07:33:02 2011 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 0CE9D21F8B2C for ; Fri, 2 Sep 2011 07:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 37q+Lb-C-oL4 for ; Fri, 2 Sep 2011 07:33:01 -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 10AFA21F8888 for ; Fri, 2 Sep 2011 07:33:00 -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 p82DOECq023138; Fri, 2 Sep 2011 15:24:14 +0200 (CEST) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p82DODZC027857; Fri, 2 Sep 2011 15:24:13 +0200 (CEST) Message-ID: <4E60D8FC.9040907@cisco.com> Date: Fri, 02 Sep 2011 15:24:12 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] proposal for IPFIX charter update 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: Fri, 02 Sep 2011 14:33:02 -0000 Hi Juergen, Next to Dan's editorial comments, I have some more. See in line. > Dear all, > > At our session in Quebec we discussed candidates > for new IPFIX work items. Based on this discussion, > Nevil and I drafted an update of our charter that > you can find below. > > Please have a look at it and send us your comments. > > Thanks, > > Juergen > > > IP Flow Information Export (ipfix) > > > Description of Working Group > > > The IPFIX working group has specified the information model (to describe > IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX > exporters to collectors). Several implementers have already built > applications using the IPFIX protocol. As a result of a series of IPFIX > interoperability testing events the WG has produced guidelines for IPFIX > implementation and testing as well as recommendations for handling > special cases such as bidirectional flow reporting and reducing > redundancy in flow records. > > The IPFIX WG has developed a mediation framework, that defines IPFIX > mediators for processing flow records for various purposes including > aggregation, anonymization, etc. For configuring IPFIX devices, a YANG > module has been developed. > > 1. Having a solid standardized base for IPFIX deployment and operation > and several exiting implementations, the IPFIX WG will revisit the IPFIX > protocol specifications (RFC 5101) and the IPFIX information element > specification (RFC 5102) in order to advance them to draft standard. > > 2. For giving guidelines to developers of new IPFIX information > elements and for better defining the process of registering new > information elements at IANA the IPFIX WG will create an information > element developers guideline document. There are actually two different audiences. See section 1.1 http://tools.ietf.org/html/draft-trammell-ipfix-ie-doctors-02 NEW: For giving guidelines to developers of new IPFIX information elements, for helping the IPFIX experts appointed as IE-Doctors, and for better defining the process of registering new information elements at IANA, the IPFIX WG will create an information element developers guideline document. > > 3. The export of IPFIX flow records from IPFIX mediators introduces a > set of potential issues at the protocol level, such as the loss of > information on the original exporter, loss of base time information, > loss of original options template information, etc. The IPFIX WG will > define common ways to deal with these issues, by specifying guidelines > for the use of the IPFIX protocol on IPFIX mediators. "common ways", "specifying guidelines for the use of the IPFIX protocol": actually it's a real protocol specification, which will be standard track. Should we be more specific? Note that http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-04 title is: Specification of the Protocol for IPFIX Mediations For example: 3. The export of IPFIX flow records from IPFIX mediators introduces a set of potential issues at the protocol level, such as the loss of information on the original exporter, loss of base time information, loss of original options template information, etc. The IPFIX WG will produce the protocol specifications in order to solve these IPFIX mediation specific problems. > > 4. For supporting the aggregation of flow records at IPFIX mediators > the IPFIX WG will define how to export aggregated flow information using s/define/specify > IPFIX. An aggregated flow is essentially an IPFIX flow representing > packets from multiple original Flows sharing some set of common properties. s/Flow/flow Regards, Benoit. > > 5. The IPFIX WG will investigate the use of the IPFIX protocol for > exporting > MIB objects, avoiding the need to define new IPFIX information elements > for existing management information base objects that are already fully > specified. This method requires the specification of new template set > and options template sets to allow the export of MIB objects along > with IPFIX information elements. > > 6. The IPFIX MIB module (RFC 5815) defined a way to register packet > selector functions at IANA. The WG agreed that another method would > be preferable that requires a minor change of RFC 5815. The IPFIX WG > will produce a new version of RFC 5815 with small modifications of > the IANA actions and DESCRIPTION clauses in the the MIB modules. > > Oct 2011 Publish draft on guidelines for IE doctors > Oct 2011 Publish draft on IPFIX use at mediators > Oct 2011 Publish draft on intermediate aggregation > Oct 2011 Publish draft on exporting MIB objects > Oct 2011 Publish draft on data link IEs > Dec 2011 Publish draft revising RFC 5101 > Dec 2011 Publish draft revising RFC 5102 > > Apr 2012 Submit guidelines for IE doctors for publication as > Informational BCP RFC > Apr 2012 Submit draft on IPFIX use at mediators for publication as > Standards track RFC > Apr 2012 Submit draft on intermediate aggregation for publication as > Standards track RFC > Apr 2012 Submit draft on data link IEs for publication as Standards > track RFC > Apr 2012 Submit draft revising RFC 5101 for publication as Standards > track RFC > Apr 2012 Submit draft revising RFC 5102 for publication as Standards > track RFC > Sep 2012 Submit draft on exporting MIB objects for publication as > Standards track RFC > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Fri Sep 2 08:17:07 2011 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 431F521F8ACC for ; Fri, 2 Sep 2011 08:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 bmH1v74k-IGU for ; Fri, 2 Sep 2011 08:17: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 57C9621F8745 for ; Fri, 2 Sep 2011 08:17: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 p82FIfDG005974; Fri, 2 Sep 2011 17:18:41 +0200 (CEST) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p82FIfjI012374; Fri, 2 Sep 2011 17:18:41 +0200 (CEST) Message-ID: <4E60F3D0.7040501@cisco.com> Date: Fri, 02 Sep 2011 17:18:40 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Brian Trammell References: <4E4CDC92.5000003@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] template lifetime 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: Fri, 02 Sep 2011 15:17:07 -0000 Brian, > Hi, Paul, > > My personal opinion is that, if we're not going to deprecate UDP with prejudice (which I realize to my sorrow we cannot do), we should jettison all this template lifetime nonsense. We spent an inordinate amount of time on 5101/5102 the first time around trying to come up with sensible guidance, then gave up and basically said "template lifetimes are configured out of band according to operational environment and application constraints", which is essentially RFCese for "here, you make this work." Which is actually sensible: there is no default that covers edge-network, core-network, and IPFIX-as-SNMP-replacement-on-the-moon use cases. > > Half a decade later, there has never been a successful interop test to my knowledge demonstrating the template management (expiry, withdrawal, reissue) features in IPFIX. Sure. It's only when you exhausted the number of Template ID than you need "reiusse", when then need "withdrawal". Note: I know of such use case/implementation. "Expiry" is a different problem. Regards, Benoit. > > Most export applications use one, two, twenty, thirty templates, and that's all they'll ever use, because those templates reflect the core data model in use by the application, and the export app wants to waste as little effort in export transcoding as possible. Sure, collectors in the wild have to handle more templates than that, but it doesn't take long as a collector operator (or even implementor) to realize that practically speaking, nobody is ever going to reuse an ID on you without dropping a session, and just setting your template expiry time to something practically infinite . You interpret templates as they come in, you replace old with new, and everything works unless you find yourself in an insanely rare corner case -- and if you do, you write something to the log and wake up the human. > > Trying to export template lifetime information from EP to CP adds complexity while pretending that the system as specified works better than an infinite-lifetime-at-collector with silent replacement, which IMO is not the case. > > I'd propose we use the RFC5655 File Reader template rules (accept anything that would be legal on any transport in any combination), but I don't know the right way to do this in 5101bis: perhaps filing technical errata on all the "MUST drop the session" language on the grounds that 1. a receiver cannot always reliably signal session failure to a transmitter and 2. it violates the "be liberal in what you accept" principle of protocol design. > > Cheers, > > Brian > > On Aug 18, 2011, at 11:34 AM, Paul Aitken wrote: > >> Dear IPFIX experts, >> >> >> RFC5102, section 10.3.7 ("Collecting Process") says: >> >> The Collecting Process MUST associate a lifetime with each Template >> (or another definition of an identifier considered unique within the >> Transport Session) received via UDP. Templates (and similar >> definitions) not refreshed by the Exporting Process within the >> lifetime are expired at the Collecting Process. >> >> ... >> >> The Template lifetime at the Collecting Process MUST be at least 3 >> times higher than the Template refresh timeout configured on the >> Exporting Process. >> >> >> >> How does a collector determine the correct lifetime to associate with each Template, and how does it know "the Template refresh timeout configured on the Exporting Process." ? >> >> What are the default and acceptable range of lifetime values? >> >> Should we have a mechanism which allows an Exporting Process to report Template lifetimes to the Collecting Process? >> eg, by exporting an option of { scope = templateId, lifetime = lifeTimeUnits }, where lifeTimeUnits = u32 milliseconds - which allows 1ms to 49.7 days, with 0 = infinite? >> >> Thanks, >> P. >> _______________________________________________ >> 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 Fri Sep 2 08:17:46 2011 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 CA36121F8AD9 for ; Fri, 2 Sep 2011 08:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 v9PbgUebXKR4 for ; Fri, 2 Sep 2011 08:17:46 -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 EB88E21F8ACE for ; Fri, 2 Sep 2011 08:17:43 -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 p82FJJs8006037; Fri, 2 Sep 2011 17:19:19 +0200 (CEST) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p82FJDw5012753; Fri, 2 Sep 2011 17:19:14 +0200 (CEST) Message-ID: <4E60F3F1.5040900@cisco.com> Date: Fri, 02 Sep 2011 17:19:13 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Paul Aitken References: <4E4CDC92.5000003@cisco.com> <4E4D64DA.1080601@net.in.tum.de> <4E4D69C4.5080107@cisco.com> In-Reply-To: <4E4D69C4.5080107@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] template lifetime 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: Fri, 02 Sep 2011 15:17:46 -0000 Paul, > Brian, Gerhard, > > Thanks for your replies. I know it's an old problem, but someone asked > what the default refresh interval should be. > > So it seems we should either define a mechanism for Exporters to > inform Collectors what their default refresh interval is (eg, define a > new standard options template), or re-work (or even remove?) the > template timeout sections. > > Currently this is a gap which allows an Exporting Process and a > Collecting Process to both claim to be IPFIX compliant, while being > quite un-interoperable. Can you please clarify the un-interoperable aspect. I don't get it. Regards, Benoit. > > P. > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Fri Sep 2 08:32:52 2011 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 B5D4D21F8B4E for ; Fri, 2 Sep 2011 08:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 CYlmMhae6oXq for ; Fri, 2 Sep 2011 08:32: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 C746C21F84DB for ; Fri, 2 Sep 2011 08:32: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 p82FFoQt005672 for ; Fri, 2 Sep 2011 17:15:50 +0200 (CEST) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p82FFoGX010596; Fri, 2 Sep 2011 17:15:50 +0200 (CEST) Message-ID: <4E60F325.5090602@cisco.com> Date: Fri, 02 Sep 2011 17:15:49 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Paul Aitken References: <4E4CDC92.5000003@cisco.com> In-Reply-To: <4E4CDC92.5000003@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] template lifetime 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: Fri, 02 Sep 2011 15:32:52 -0000 On 18/08/2011 11:34, Paul Aitken wrote: > Dear IPFIX experts, > > > RFC5102, section 10.3.7 ("Collecting Process") says: > > The Collecting Process MUST associate a lifetime with each Template > (or another definition of an identifier considered unique within the > Transport Session) received via UDP. Templates (and similar > definitions) not refreshed by the Exporting Process within the > lifetime are expired at the Collecting Process. > > ... > > The Template lifetime at the Collecting Process MUST be at least 3 > times higher than the Template refresh timeout configured on the > Exporting Process. > > > > How does a collector determine the correct lifetime to associate with > each Template, and how does it know "the Template refresh timeout > configured on the Exporting Process." ? Solution 1. Out of band configuration with http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10. Note: I still envision that IPFIX caches might be configured for a short period of time on IPFIX exporters, for troubleshooting reasons. Solution 2. CP observes 10 (or 20, or whatever number) template refresh and conclude the right value Solution 3: the CP doesn't bother and take a very high value > > What are the default and acceptable range of lifetime values? > > Should we have a mechanism which allows an Exporting Process to report > Template lifetimes to the Collecting Process? > eg, by exporting an option of { scope = templateId, lifetime = > lifeTimeUnits }, where lifeTimeUnits = u32 milliseconds - which allows > 1ms to 49.7 days, with 0 = infinite? This is solution 4. Regards, Benoit. > > Thanks, > P. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From fontas@tik.ee.ethz.ch Fri Sep 2 05:30:31 2011 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 21DE321F8DE2 for ; Fri, 2 Sep 2011 05:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 kpMzs6rKW2i6 for ; Fri, 2 Sep 2011 05:30:30 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B8B5821F8DE0 for ; Fri, 2 Sep 2011 05:30:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 12FDED930F for ; Fri, 2 Sep 2011 14:32:05 +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 b32rRoLv8DUe for ; Fri, 2 Sep 2011 14:32:04 +0200 (MEST) Received: from [82.130.103.55] (nb-10218.ethz.ch [82.130.103.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dimitroc) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id CD1FFD9309 for ; Fri, 2 Sep 2011 14:32:04 +0200 (MEST) Message-ID: <4E60CCC5.10103@tik.ee.ethz.ch> Date: Fri, 02 Sep 2011 14:32:05 +0200 From: Xenofontas Dimitropoulos User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 02 Sep 2011 15:12:12 -0700 Subject: [IPFIX] Traffic Monitoring and Analysis (TMA) 2012 CFP 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: Fri, 02 Sep 2011 12:30:31 -0000 [Our apologies if you receive multiple copies of this CFP] -------------------------------- TMA 2012 --- Call for Papers -------------------------------- 4th COST TMA International Workshop on Traffic Monitoring and Analysis Vienna, Austria, March 12, 2012 Co-located with Passive and Active Measurement (PAM) Conference 2012 http://tma2012.ftw.at/TMA/index.html After three successful editions of the TMA Workshop organized by the Traffic Monitoring and Analysis (TMA) COST Action, we are excited to announce the 4th edition that will be held in Vienna (Austria), co-located with the Passive and Active Measurement Conference. **** Scope of the Workshop We are soliciting network-measurement papers with an emphasis on experimental work that relate to the following topics: Traffic analysis, characterization, and classification New and improved measurement and monitoring methods and techniques Measurement-based applications Measurement-based network management Large scale monitoring and measurement Validation and benchmarking of measurement tools Measurement-based experiments: repeatability tests, data sharing, collaborative platforms Internet topologies Bandwidth estimation Software tools for analyzing and visualizing high-volume Internet-related datasets Distributed monitoring architectures Privacy-preserving network measurement and analysis Inter-domain and intra-domain routing Anomaly detection Measurement-related to data centers and cloud-based services Measurement-related to Virtualized systems Home networks measurements **** Paper Submission Submissions must not exceed 14 pages (8.5”x11”), including figures, tables, and references, using the LNCS format. We recommend using the LNCS users' guide to format your paper. Papers that exceed the 14 pages limitation will not be reviewed. Accepted papers will be published in a volume of the Lecture Notes in Computer Science (LNCS) series by Springer Verlag. **** Important Dates Abstract Registration: September 25, 2011 Paper Submission: October 9, 2011 Notification of Decision: December 20, 2011 Camera Ready: January 8, 2012 Workshop: March 12, 2012 **** Program Chairs Antonio Pescapè University of Napoli, Federico II Xenofontas Dimitropoulos ETH Zurich Luca Salgarelli University of Brescia **** Local Arrangements Chair Philipp Svoboda TU Wien **** Program Committee Olivier Bonaventure, Université Catholique de Louvain Ernst Biersack, Eurecom Pere Barlet-Ros, Technical University of Catalunya Kenjiro Cho, IIJ Konstantina Papagiannaki, Telefonica Alberto Dainotti, University of Napoli Federico II Nick Feamster, Georgia Tech KC Claffy, CAIDA Pietro Michiardi, Eurecom Brian Trammell, ETH Zurich Georgios Lioudakis, National Technical University of Athens Felipe Huici, NEC Labs Europe Joseph Gasparakis, Intel Maurizio Dusi, NEC labs Europe Grenville Armitage, CAIA Wenke Lee, Georgia Tech Maria Papadopouli, FORTH Gianluca Iannaccone, Intel Labs Berkeley Marco Mellia, Politecnico di Torino Steve Uhlig, TU Berlin / T-Labs Yuval Shavitt, Tel Aviv University Dario Rossi, TELECOM ParisTech Fabio Ricciato, FTW and University of Salento Francesco Gringoli, University of Brescia Philippe Owezarski, CNRS Alessio Botta, University of Napoli Federico II Aiko Pras, University of Twente Michela Meo, Politecnico di Torino Louis Plissonneau, Orange Labs Pierre Borgnat, ENS Lyon Hyun-chul Kim, Seoul National University Georgios Smaragdakis, Deutsche Telekom Labs and TU Berlin Andreas Kind, IBM Research Marcin Pietrzyk, Swisscom -- ETH Zurich Dr. Xenofontas Dimitropoulos Lecturer& Senior Researcher Computer Engineering and Networks Laboratory (TIK) ETZ G95, Gloriastrasse 35, CH-8092 Zurich. http://www.fontas.net +41 44 632 7004 (phone) From paitken@cisco.com Sun Sep 4 15:08:47 2011 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 35BD921F8A64 for ; Sun, 4 Sep 2011 15:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.481 X-Spam-Level: X-Spam-Status: No, score=-10.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 LbGI2aIKT5dn for ; Sun, 4 Sep 2011 15:08: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 EBFB521F8906 for ; Sun, 4 Sep 2011 15:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=2422; q=dns/txt; s=iport; t=1315174228; x=1316383828; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=EN+8zp+glgMcGqDQ9GEDZ05CCzWhwsELYlwVN1JXsII=; b=W2c3OYQD9QyDh+3wtLnnWIc2BCq07xV87Q9ThvWkqKFYehZqQZCIjaQt zSJiJ7Z1lbe/wfLfLuVxZ1+ZuLULZmHQPnfPKTVXfJWQLjZH1DoYT7/xz IOWP6X+oXAV7HdHwTEBk55J0JeUkEJyQI6BFWbK5vLnA6nrfHmBBG1HBK U=; X-IronPort-AV: E=Sophos;i="4.68,330,1312156800"; d="scan'208";a="113865439" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 04 Sep 2011 22:10:26 +0000 Received: from [10.55.92.151] (dhcp-10-55-92-151.cisco.com [10.55.92.151]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p84MAQWw002767; Sun, 4 Sep 2011 22:10:26 GMT Message-ID: <4E63F748.8010508@cisco.com> Date: Sun, 04 Sep 2011 23:10:16 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Benoit Claise References: <4E4CDC92.5000003@cisco.com> <4E4D64DA.1080601@net.in.tum.de> <4E4D69C4.5080107@cisco.com> <4E60F3F1.5040900@cisco.com> In-Reply-To: <4E60F3F1.5040900@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] template lifetime 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, 04 Sep 2011 22:08:47 -0000 Benoit, > Paul, >> Brian, Gerhard, >> >> Thanks for your replies. I know it's an old problem, but someone >> asked what the default refresh interval should be. >> >> So it seems we should either define a mechanism for Exporters to >> inform Collectors what their default refresh interval is (eg, define >> a new standard options template), or re-work (or even remove?) the >> template timeout sections. >> >> Currently this is a gap which allows an Exporting Process and a >> Collecting Process to both claim to be IPFIX compliant, while being >> quite un-interoperable. > Can you please clarify the un-interoperable aspect. I don't get it. An Exporting Process has a template refresh time in order to satisfy RFC 5101 / 10.3.6 : 10.3.6. Template Management When IPFIX uses UDP as the transport protocol, Template Sets and Option Template Sets MUST be re-sent at regular intervals. The frequency of the (Options) Template transmission MUST be configurable. The default value for the frequency of the (Options) Template transmission is 10 minutes. Meanwhile the Collecting Process follows RFC 5101 / 10.3.7 : 10.3.7. Collecting Process The Collecting Process MUST associate a lifetime with each Template (or another definition of an identifier considered unique within the Transport Session) received via UDP. Templates (and similar definitions) not refreshed by the Exporting Process within the lifetime are expired at the Collecting Process. If the Template (or other definition) is not refreshed before that lifetime has expired, the Collecting Process MUST discard that definition and any current and future associated Data Records. Since the CP doesn't know what the EP's template refresh time is, perhaps it assumes to follow the "10 minutes" advice in 10.3.6 - and for good measure, it allows three times as much - so, it associates a 30 minute lifetime with each template. However, the EP actually refreshes templates hourly. Or every 90 minutes. Or daily. Whatever you like, > 30 mins (since, "The frequency of the (Options) Template transmission MUST be configurable."). So both are quite RFC5101 compliant, but fail to interoperate properly - because for some period, the CP will have discarded the template and won't be able to decode further data until the P. From paitken@cisco.com Sun Sep 4 15:08:59 2011 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 0BCC921F8ACC for ; Sun, 4 Sep 2011 15:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 b-mCyvvw0P5U for ; Sun, 4 Sep 2011 15:08:58 -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 4E2CC21F8906 for ; Sun, 4 Sep 2011 15:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1355; q=dns/txt; s=iport; t=1315174241; x=1316383841; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6BPRmzQIsFNNDPFHR0FTtbpQrTVQHVVapZHIu2NTfUw=; b=aD2DWbfHZm/tbN7wRlLe0iykmknM4C04ZqpWdft0PLn5JQudI3lD+Xr0 8L9Y6lyp8NvKDQuryBFky+XV/YNC/80WwSD2ztYTxbbkfebwYdripIETP pbKSGo3Q1ml3S5Oew9sReugve3A40vVkyzQ4fq+gupB4UAWJUCnKtT1hf k=; X-IronPort-AV: E=Sophos;i="4.68,330,1312156800"; d="scan'208";a="113865454" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 04 Sep 2011 22:10:40 +0000 Received: from [10.55.92.151] (dhcp-10-55-92-151.cisco.com [10.55.92.151]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p84MAdYm002857; Sun, 4 Sep 2011 22:10:40 GMT Message-ID: <4E63F756.1040802@cisco.com> Date: Sun, 04 Sep 2011 23:10:30 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Benoit Claise References: <4E4CDC92.5000003@cisco.com> <4E60F325.5090602@cisco.com> In-Reply-To: <4E60F325.5090602@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] template lifetime 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, 04 Sep 2011 22:08:59 -0000 Benoit, >> How does a collector determine the correct lifetime to associate with >> each Template, and how does it know "the Template refresh timeout >> configured on the Exporting Process." ? > Solution 1. Out of band configuration with > http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10. > Note: I still envision that IPFIX caches might be configured for a > short period of time on IPFIX exporters, for troubleshooting reasons. This is not mentioned anywhere in IPFIX. It's a hole. > Solution 2. CP observes 10 (or 20, or whatever number) template > refresh and conclude the right value Packet loss and network jitter make this problematic. > Solution 3: the CP doesn't bother and take a very high value That seems reasonable. Why not specify this as the default behaviour? >> >> What are the default and acceptable range of lifetime values? >> >> Should we have a mechanism which allows an Exporting Process to >> report Template lifetimes to the Collecting Process? >> eg, by exporting an option of { scope = templateId, lifetime = >> lifeTimeUnits }, where lifeTimeUnits = u32 milliseconds - which >> allows 1ms to 49.7 days, with 0 = infinite? > This is solution 4. Then it needs to be written in the protocol so EPs export it and CPs expect and action it correctly. P. From trammell@tik.ee.ethz.ch Sun Sep 4 23:32:36 2011 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 CC6C321F874B for ; Sun, 4 Sep 2011 23:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 y+yXSFuaWbgC for ; Sun, 4 Sep 2011 23:32: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 2C77821F8744 for ; Sun, 4 Sep 2011 23:32:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B6189D9310; Mon, 5 Sep 2011 08:34:16 +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 A7580qodH2cY; Mon, 5 Sep 2011 08:34:16 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (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 58627D930C; Mon, 5 Sep 2011 08:34:16 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4E63F756.1040802@cisco.com> Date: Mon, 5 Sep 2011 08:34:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <425A3F76-D7D9-4EF8-ADF1-ACC2E2ED886A@tik.ee.ethz.ch> References: <4E4CDC92.5000003@cisco.com> <4E60F325.5090602@cisco.com> <4E63F756.1040802@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1084) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] template lifetime 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, 05 Sep 2011 06:32:36 -0000 hi Paul, all,=20 Comments on the running discussion inline... Cheers, Brian On Sep 5, 2011, at 12:10 AM, Paul Aitken wrote: > Benoit, >=20 >>> How does a collector determine the correct lifetime to associate = with each Template, and how does it know "the Template refresh timeout = configured on the Exporting Process." ? >> Solution 1. Out of band configuration with = http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10. = Note: I still envision that IPFIX caches might be configured for a short = period of time on IPFIX exporters, for troubleshooting reasons. >=20 > This is not mentioned anywhere in IPFIX. It's a hole. Is the intention to plug this in 5101bis? The questionable (or at least, = not yet demonstrated) interoperability of the existing spec may give us = an opening to do so... >> Solution 2. CP observes 10 (or 20, or whatever number) template = refresh and conclude the right value >=20 > Packet loss and network jitter make this problematic. Indeed, but assuming a network that is working _well enough_ that the = human in charge doesn't reprovision it due to unacceptable export = efficiency, the long term average of template refresh times should = approximate an upper bound reasonably well...=20 >=20 >> Solution 3: the CP doesn't bother and take a very high value >=20 > That seems reasonable. Why not specify this as the default behaviour? Infinity seems high enough. :) Coupled with automatic replacement on = receipt of a different template with the same ID (keyed by template = validity tied to the export time in the message in which it was = received), it would seem to solve the synchronization problem. >>> What are the default and acceptable range of lifetime values? >>>=20 >>> Should we have a mechanism which allows an Exporting Process to = report Template lifetimes to the Collecting Process? >>> eg, by exporting an option of { scope =3D templateId, lifetime =3D = lifeTimeUnits }, where lifeTimeUnits =3D u32 milliseconds - which allows = 1ms to 49.7 days, with 0 =3D infinite? >> This is solution 4. >=20 > Then it needs to be written in the protocol so EPs export it and CPs = expect and action it correctly. If we go with option 4 (unsurprisingly, I'm not a fan), then I would = suggest _explicitly_ tying these timeouts to the export time in the = message header, not any-old-random-clock the CP happens to have hanging = around. From paitken@cisco.com Mon Sep 5 01:51:56 2011 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 9CF9321F8A55 for ; Mon, 5 Sep 2011 01:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 zv4TDdI1vq7K for ; Mon, 5 Sep 2011 01:51:55 -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 891D421F8A23 for ; Mon, 5 Sep 2011 01:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=3193; q=dns/txt; s=iport; t=1315212819; x=1316422419; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VW3lrDReLNCsbJgiUdGNpAzRHuPwApZ9LPFSClGuZEU=; b=BzubQFfCeCdX6SMysdHUpO9UkOYc7iMMkntCiV1aRl0T0IoCsI+XZxwc +vPZF2RAT8eLSKAWzLDZLr8351/LSe0TDa2rMXFfisjiBV3wvBEdYVLdl VjmWvp/Eo7fQhRh+Lq9luK15cVpyMvMSWhx7sigbTha5t7f3VLey14QSX w=; X-IronPort-AV: E=Sophos;i="4.68,332,1312156800"; d="scan'208";a="113936732" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 05 Sep 2011 08:53:34 +0000 Received: from [144.254.153.24] (dhcp-144-254-153-24.cisco.com [144.254.153.24]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p858rY8C032215; Mon, 5 Sep 2011 08:53:34 GMT Message-ID: <4E648E0D.5080508@cisco.com> Date: Mon, 05 Sep 2011 09:53:33 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Brian Trammell References: <4E4CDC92.5000003@cisco.com> <4E60F325.5090602@cisco.com> <4E63F756.1040802@cisco.com> <425A3F76-D7D9-4EF8-ADF1-ACC2E2ED886A@tik.ee.ethz.ch> In-Reply-To: <425A3F76-D7D9-4EF8-ADF1-ACC2E2ED886A@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] template lifetime 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, 05 Sep 2011 08:51:56 -0000 Brian, >>>> How does a collector determine the correct lifetime to associate with each Template, and how does it know "the Template refresh timeout configured on the Exporting Process." ? >>> Solution 1. Out of band configuration with http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10. Note: I still envision that IPFIX caches might be configured for a short period of time on IPFIX exporters, for troubleshooting reasons. >> This is not mentioned anywhere in IPFIX. It's a hole. > Is the intention to plug this in 5101bis? The questionable (or at least, not yet demonstrated) interoperability of the existing spec may give us an opening to do so... That's rather the point of this thread. >>> Solution 2. CP observes 10 (or 20, or whatever number) template refresh and conclude the right value >> Packet loss and network jitter make this problematic. > Indeed, but assuming a network that is working _well enough_ that the human in charge doesn't reprovision it due to unacceptable export efficiency, the long term average of template refresh times should approximate an upper bound reasonably well... There may not be any such thing as a "long term" average, since templates may come and go at unpredictable times. It may be especially difficult to make any predication about the lifetime of short-lived templates or frequently redefined templates. Also, when a template is redefined (ie, same template ID, but different fields or different field order), the lifetime calculation has to be re-started. Clearly a full discussion is missing and is needed if this method is expected to be used. >>> Solution 3: the CP doesn't bother and take a very high value >> That seems reasonable. Why not specify this as the default behaviour? > Infinity seems high enough. :) Coupled with automatic replacement on receipt of a different template with the same ID (keyed by template validity tied to the export time in the message in which it was received), it would seem to solve the synchronization problem. This could work. However, we have to recognise the disadvantage of possibly incorrectly decoding some data records where a template redefinition has been missed. A finite lifetime would ensure the records had to be discarded. >>>> What are the default and acceptable range of lifetime values? >>>> >>>> Should we have a mechanism which allows an Exporting Process to report Template lifetimes to the Collecting Process? >>>> eg, by exporting an option of { scope = templateId, lifetime = lifeTimeUnits }, where lifeTimeUnits = u32 milliseconds - which allows 1ms to 49.7 days, with 0 = infinite? >>> This is solution 4. >> Then it needs to be written in the protocol so EPs export it and CPs expect and action it correctly. > If we go with option 4 (unsurprisingly, I'm not a fan), then I would suggest _explicitly_ tying these timeouts to the export time in the message header, not any-old-random-clock the CP happens to have hanging around. Clearly there are several ways of solving the problem. I don't really mind which method is used, as long as it fills what seems to be a hole in IPFIX. Thanks, P. From trammell@tik.ee.ethz.ch Mon Sep 5 03:52:12 2011 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 2855221F8B13 for ; Mon, 5 Sep 2011 03:52:12 -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 DbeuSoNXsmEZ for ; Mon, 5 Sep 2011 03:52:11 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3C621F8AE6 for ; Mon, 5 Sep 2011 03:52:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A20D7D9304; Mon, 5 Sep 2011 12:53:54 +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 4kCYbOme6X9S; Mon, 5 Sep 2011 12:53:54 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (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 3334CD9300; Mon, 5 Sep 2011 12:53:54 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4E648E0D.5080508@cisco.com> Date: Mon, 5 Sep 2011 12:53:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1AC60ED2-8798-4DA1-9A99-9B42699C1C78@tik.ee.ethz.ch> References: <4E4CDC92.5000003@cisco.com> <4E60F325.5090602@cisco.com> <4E63F756.1040802@cisco.com> <425A3F76-D7D9-4EF8-ADF1-ACC2E2ED886A@tik.ee.ethz.ch> <4E648E0D.5080508@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1084) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] template lifetime 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, 05 Sep 2011 10:52:12 -0000 hi, Paul, all, On Sep 5, 2011, at 10:53 AM, Paul Aitken wrote: > Brian, >=20 >>>>> How does a collector determine the correct lifetime to associate = with each Template, and how does it know "the Template refresh timeout = configured on the Exporting Process." ? >>>> Solution 1. Out of band configuration with = http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10. = Note: I still envision that IPFIX caches might be configured for a short = period of time on IPFIX exporters, for troubleshooting reasons. >>> This is not mentioned anywhere in IPFIX. It's a hole. >> Is the intention to plug this in 5101bis? The questionable (or at = least, not yet demonstrated) interoperability of the existing spec may = give us an opening to do so... >=20 > That's rather the point of this thread. Good. Now I'm caught up. :) >>>> Solution 2. CP observes 10 (or 20, or whatever number) template = refresh and conclude the right value >>> Packet loss and network jitter make this problematic. >> Indeed, but assuming a network that is working _well enough_ that the = human in charge doesn't reprovision it due to unacceptable export = efficiency, the long term average of template refresh times should = approximate an upper bound reasonably well... >=20 > There may not be any such thing as a "long term" average, since = templates may come and go at unpredictable times. It may be especially = difficult to make any predication about the lifetime of short-lived = templates or frequently redefined templates. >=20 > Also, when a template is redefined (ie, same template ID, but = different fields or different field order), the lifetime calculation has = to be re-started. Clearly a full discussion is missing and is needed if = this method is expected to be used. Ah. Good point... So let's move this down the list for now on account of = "effort required to do it right" (indeed, it seems on the face of it = that it is harder to do right than the current method, which IMO is = impossible to do right, so...) >=20 >>>> Solution 3: the CP doesn't bother and take a very high value >>> That seems reasonable. Why not specify this as the default = behaviour? >> Infinity seems high enough. :) Coupled with automatic replacement on = receipt of a different template with the same ID (keyed by template = validity tied to the export time in the message in which it was = received), it would seem to solve the synchronization problem. >=20 > This could work. However, we have to recognise the disadvantage of = possibly incorrectly decoding some data records where a template = redefinition has been missed. A finite lifetime would ensure the records = had to be discarded. I'm still a fan of not even _trying_ to pretend that UDP over a MAC = layer that isn't doing some sort of congestion control (even implicit = congestion control through "being dedicated and insanely = overdimensioned") is reliable enough for every template management = corner case (this, indeed, is why IESG pushback put a MUST on IPFIX over = SCTP)... If you are going to flow export over UDP, you need to have = administrators on _both_ sides of the IPFIX session who know what = they're doing, because in limited circumstances things _will_ break, = full stop. If you need it to work, don't use the optional protocol, use = the mandatory one, where these problems are solved. >=20 >>>>> What are the default and acceptable range of lifetime values? >>>>>=20 >>>>> Should we have a mechanism which allows an Exporting Process to = report Template lifetimes to the Collecting Process? >>>>> eg, by exporting an option of { scope =3D templateId, lifetime =3D = lifeTimeUnits }, where lifeTimeUnits =3D u32 milliseconds - which allows = 1ms to 49.7 days, with 0 =3D infinite? >>>> This is solution 4. >>> Then it needs to be written in the protocol so EPs export it and CPs = expect and action it correctly. >> If we go with option 4 (unsurprisingly, I'm not a fan), then I would = suggest _explicitly_ tying these timeouts to the export time in the = message header, not any-old-random-clock the CP happens to have hanging = around. >=20 > Clearly there are several ways of solving the problem. I don't really = mind which method is used, as long as it fills what seems to be a hole = in IPFIX. On that point we are emphatically in agreement. Cheers, Brian= From paitken@cisco.com Mon Sep 5 12:33:38 2011 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 3173221F8B88 for ; Mon, 5 Sep 2011 12:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.501 X-Spam-Level: X-Spam-Status: No, score=-11.501 tagged_above=-999 required=5 tests=[AWL=1.098, BAYES_00=-2.599, GB_I_LETTER=-2, 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 lUByVgigWqpZ for ; Mon, 5 Sep 2011 12:33:34 -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 A0B6E21F8AE6 for ; Mon, 5 Sep 2011 12:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=62156; q=dns/txt; s=iport; t=1315251318; x=1316460918; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lp32DwRQkwcjST1I8sxmCkD4JmpXV6MyFFIDP/ZQ9Ek=; b=AVQS3jAHgtAxSd4LdHEUbPKd1QAVK6G/TcRicqHgVdm0YPtNiUdeMbOa eICuOe9yrPWaA22Kep9O3timRvu5Dd8L7PRF1MPG5PL7vsjBv/bV0+apv KpccCtgPg+TI9FfHzmZ5sSyHQmggCYDs5z87AwTViQj1lmT5H/oeRbAF9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMsjZU6Q/khN/2dsb2JhbABDDqgMeIFGAQEBAQIBEgEHAR0wBAgCAgEFCQILDgQPFg8JAwIBAgEJLg4GCgMBBQIBARUJh1EEmWEBnl8ChmgEky6FD4tGOQ X-IronPort-AV: E=Sophos;i="4.68,335,1312156800"; d="scan'208";a="53296971" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 05 Sep 2011 19:35:13 +0000 Received: from [10.55.92.139] (dhcp-10-55-92-139.cisco.com [10.55.92.139]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p85JZCPO027840; Mon, 5 Sep 2011 19:35:12 GMT Message-ID: <4E65246F.5070406@cisco.com> Date: Mon, 05 Sep 2011 20:35:11 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Nevil Brownlee References: <4E558AE2.9000308@auckland.ac.nz> In-Reply-To: <4E558AE2.9000308@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org, IPFIX Working Group Subject: Re: [IPFIX] Any last comments on draft-ietf-ipfix-flow-selection-tech-07 ??? 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, 05 Sep 2011 19:33:38 -0000 Nevil, All, > There hasn't been any comment on the selection draft for nearly a > month - as long as I don't hear any by next Monday, I'll declare > its WG Last Call finished and send its write-up to Dan. Sorry for the late response. Please find many comments inline. I'd like to see a new version of this draft. Thanks, P. > > Internet Engineering Task Force S. D'Antonio > Internet-Draft University of Napoli > Intended status: Standards Track "Parthenope" > Expires: January 12, 2012 T. Zseby > Fraunhofer Institute FOKUS > C. Henke > Technische Universitat Berlin > L. Peluso > University of Napoli > July 11, 2011 > > > Flow Selection Techniques > draft-ietf-ipfix-flow-selection-tech-07.txt > > Abstract > > Flow selection is the process of selecting a subset of flows from all > flows observed at an observation point. Flow selection reduces the Is just one OP allowed, or can they be observed at multiple observation points? eg, consider flow selection in a mediation device. > effort of post-processing flow data and transferring Flow Records. > This document describes motivations for flow selection and presents > flow selection techniques. It provides an information model for > configuring flow selection techniques and discusses what information > about a flow selection process should be exported. > > Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on January 12, 2012. > > > > > D'Antonio, et al. Expires January 12, 2012 [Page 1] > > Internet-Draft Flow Selection Techniques July 2011 > > > Copyright Notice > > Copyright (c) 2011 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > This document may contain material from IETF Documents or IETF > Contributions published or made publicly available before November > 10, 2008. The person(s) controlling the copyright in some of this > material may not have granted the IETF Trust the right to allow > modifications of such material outside the IETF Standards Process. > Without obtaining an adequate license from the person(s) controlling > the copyright in such materials, this document may not be modified > outside the IETF Standards Process, and derivative works of it may > not be created outside the IETF Standards Process, except to format > it for publication as an RFC or to translate it into languages other > than English. > > > > > > > > > > > > > > > > > > > > > > > > > > D'Antonio, et al. Expires January 12, 2012 [Page 2] > > Internet-Draft Flow Selection Techniques July 2011 > > > Table of Contents > > 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Difference between Flow Selection and Packet Selection . . . . 7 > 4. Flow selection as a Function in the IPFIX Architecture . . . . 8 > 4.1. Flow selection during the Metering Process . . . . . . . . 10 > 4.2. Flow selection during the Exporting Process . . . . . . . 10 > 4.3. Flow selection as a function of the IPFIX Mediator . . . . 10 > 5. Flow Selection Techniques . . . . . . . . . . . . . . . . . . 11 > 5.1. Flow Filtering . . . . . . . . . . . . . . . . . . . . . . 11 > 5.1.1. Property Match Filtering . . . . . . . . . . . . . . . 11 > 5.1.2. Hash-based Flow Filtering . . . . . . . . . . . . . . 11 > 5.2. Flow Sampling . . . . . . . . . . . . . . . . . . . . . . 12 > 5.2.1. Systematic sampling . . . . . . . . . . . . . . . . . 12 > 5.2.2. Random sampling . . . . . . . . . . . . . . . . . . . 12 > 5.3. Flow-state Dependent Flow Selection . . . . . . . . . . . 13 > 5.4. Flow-state Dependent Packet Selection . . . . . . . . . . 13 > 6. Configuration of Flow Selection Techniques . . . . . . . . . . 14 > 6.1. Description of Flow Selection Techniques . . . . . . . . . 15 > 6.2. Description of Flow-state Dependent Packet Selection . . . 17 > 7. Information Model for Flow Selection Reporting . . . . . . . . 17 > 7.1. fsFlowRecordTotalCount . . . . . . . . . . . . . . . . . . 18 > 7.2. fsFlowRecordSelectedCount . . . . . . . . . . . . . . . . 19 > 7.3. fsPacketTotalCount . . . . . . . . . . . . . . . . . . . . 19 > 7.4. fsPacketSelectedCount . . . . . . . . . . . . . . . . . . 19 > 7.5. fsOctetTotalCount . . . . . . . . . . . . . . . . . . . . 19 > 7.6. fsOctetSelectedCount . . . . . . . . . . . . . . . . . . . 20 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 > 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 > 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 > 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 > > > > > > > > > > > > > > > > > > D'Antonio, et al. Expires January 12, 2012 [Page 3] > > Internet-Draft Flow Selection Techniques July 2011 > > > 1. Scope > > This document describes flow selection techniques for network traffic > measurements. A flow is defined as a set of packets with common > properties as described in [RFC5101]. Flow selection can be done to > limit the resource demands for capturing, storing, exporting and > post-processing of Flow Records. It also can be used to select a > particular set of flows that are of interest to a specific > application. This document provides a categorization of flow > selection techniques and describes configuration and reporting > parameters for them. In order to be compliant with this document, at > least one of the flow selection schemes MUST be implemented. That > means that the configuration parameters as well as the reporting > Information Elements for this particular scheme MUST be supported. > > This document also addresses configuration and reporting parameters > for flow-state dependent packet selection as described in [RFC5475], > although this technique is categorized as packet selection. The > reason is, that flow-state dependent packet selection techniques > often aim at the reduction of resources for flow capturing and flow > processing. Furthermore, they were only briefly discussed in > [RFC5475]. Therefore we included configuration and reporting > considerations for such techniques in this document. > > > 2. Terminology > > This document is consistent with the terminology introduced in > [RFC5101], [RFC5470], [RFC5475] and [RFC3917]. As in [RFC5101] and > [RFC5476], the first letter of each IPFIX-specific and PSAMP-specific > term is capitalized along with the flow selection specific terms > defined here. > > * Packet Classification > > Packet Classification is a process by which packets are mapped to > specific Flow Records based on packet properties or external > properties (e.g. interface). The properties make up the Flow Key > (e.g. header information, packet content, AS number). In case a "The properties (e.g. header information, packet content, AS number) make up the Flow Key." > Flow Record for a specific Flow Key already exists the Flow Record > is updated, otherwise a new Flow Record is created. > > * Packet Aggregation Process > > In the IPFIX Metering Process the Packet Aggregation Process > aggregates packet data into flow data and forms the Flow Records. > After the aggregation step only the aggregated flow information is > available. Information about individual packets is lost. > > > > D'Antonio, et al. Expires January 12, 2012 [Page 4] > > Internet-Draft Flow Selection Techniques July 2011 > > > * Flow Selection Process > > A Flow Selection Process takes Flow Records as its input and > selects a subset of this set as its output. A Flow Selection > Process MAY run on several instances within the IPFIX s/on several instances/in several places/ > architecture. A Flow Selection Process MAY be part of an IPFIX > Metering Process, Exporting Process or as an Intermediate > Selection Process as defined for the IPFIX Mediator [RFC6183]. > > * Flow Selection State > > A Flow Selection Process SHOULD maintain state information for use > by the Flow Selector. At a given time, the Flow Selection State > may depend on flows and packets observed at and before that time, > as well as other variables. Examples include: > > (i) sequence number of packets and accounted Flow Records; > > (ii) number of selected flows; > > (iii) number of observed flows; > > (iv) current flow cache occupancy; > > (v) flow specific counters, lower und upper bounds s/und/and/ > (vi) flow selection timeout intervals Some of the list items end with ";" while others do not. > * Flow Selector > > A Flow Selector defines the action of a Flow Selection Process on > a single flow of its input. The Flow Selector can make use of the > following information in order to establish whether a flow has to > be selected or not: > > (i) the content of the Flow Record; > > (ii) any state information related to the Metering Process or > Exporting Process; > > (iii) any Flow Selection State that may be maintained by the > Flow Selection Process. > > * Complete Flow > > A Complete Flow consists of all packets within the flow time-out > interval that enter the Flow Selection Process and belong to the "A Complete Flow consists of all the packets that enter the Flow Selection Process within the flow time-out interval, and which belong to the ..." > same flow as defined by the flow definition in [RFC5470]. For > > > > D'Antonio, et al. Expires January 12, 2012 [Page 5] > > Internet-Draft Flow Selection Techniques July 2011 > > > this definition only packets that arrive at the Flow Selection > Process are considered. That means, packets that are not observed > at the Flow Selection Process because of prior packet selection or > packet loss are not considered as belonging to the Complete Flow. > > * Flow Filtering > > Flow Filtering selects flows based on a deterministic function on > the Flow Record content, flow state, external properties (e.g. Does "flow state" mean "flow selection state"? ie referring to the list just above, is it (ii), (iii), or both? > ingress interface) or external events (e.g violated Access Control > List). If the relevant parts of the Flow Record content can be > already observed at packet level (e.g. Flow Keys from packet s/can be already/can already be/ > header fields) Flow Filtering can be performed at packet level by > Property Match Filtering as described in [RFC5475]. > > * Hash-based Flow Filtering > > Hash-based Flow Filtering is a deterministic flow filter function > that selects flows based on a Hash Function which is calculated > over parts of the Flow Record content or external properties. If > the hash value falls into a predefined Hash Selection Range the > flow is selected. Is there a way to control which fields from the Flow Record go in to the hash? Else, if two devices implement the same hash, are fed the same packets, and implement the same flow records - except that the fields are in a different order - then they may produce different output. > * Flow-state Dependent Flow Selection > > Flow-state Dependent Flow Selection is a selection function that > selects or drops flows based on the current flow state. The > selection can be either deterministic, random or non-uniform > random. Again, please clarify exactly what the flow state is. It seems worth defining the "Flow-state" term. eg, one could assume flow state = active, expired, exported... > * Flow-state Dependent Packet Selection > > Flow-state Dependent Packet Selection is a selection function that > selects or drops packets based on the current flow state. The > selection can be either deterministic, random or non-uniform > random. Flow-state Dependent Packet Selection can be used to > prefer the selection of packets belonging to specific flows (e.g. > large or small flows). Are those real examples? Surely preferring packets for small flows gives lots of details without giving the big picture and may quickly fill the cache (not withstanding that everything starts as a small flow anyway...), while preferring packets for large flows may grow whatever flows are initially observed into "large" flows while discarding individual packets which would eventually make a truely "large" flow. Unless this is something you want to develop, I'd just remove the "(e.g. ...)" section. [Later] I see that you mention "large" flows several times. Does this require foreknowledge of what may constitute a large flow? Else, how can you correctly select packets which pertain to the "large" flows? > * Flow Sampling > > Flow Sampling selects flows based on Flow Record sequence or > arrival times (e.g. entry in flow cache, arrival time at Exporter > or Mediator). The selection can be systematic (e.g. every n-th > flow) or based on a random function (e.g. select each Flow Record > with probability p, or randomly select n out of N Flow Records). I'm hoping that a discussion of the pros and cons of each method and recommendations as to when to use each method will follow. [Later] It may be worth saying "Discussion of these methods appears in section 5 below". > > > > > D'Antonio, et al. Expires January 12, 2012 [Page 6] > > Internet-Draft Flow Selection Techniques July 2011 > > > 3. Difference between Flow Selection and Packet Selection > > Flow selection differs from packet selection described in [RFC5475]. This seems obvious. > Packet selection techniques consider packets as basic element and the "as *the" basic element" ? > parent population consists of all packets observed at an observation > point. In contrast to this the basic elements in flow selection are Just one observation point? Therefore the techniques can't be used when traffic has been aggregated from multiple OPs? > the flows. The parent population consists of all observed flows and > the selection process operates on the flows. The major > characteristics of flow selection are the following: > > - Flow selection takes flows as basic elements. For packet > selection, packets are considered as basic elements. > > - Flow selection can only take place after Packet > Classification, because the classification rules determine to > which flow a packet belongs. Packet selection can be applied > before and after Packet Classification. > > - Flow selection operates on Complete Flows. That means that > after the Flow Selection Process either all packets of the > flow are kept or all packets of the flow are discarded. All When you say "flow" here, I think you mean "Complete Flow". So consider, "either the complete flow is kept or the complete flow is discarded". > packets of the flow here means all packets that enter the > Flow Selection Process. That means that if the flow Packets don't enter the flow selection process, since the flow selection process operates on complete flows (per the definition above). > selection is preceded by a packet selection process the > Complete Flow consists only of the packets that were not > discarded during the packet selection. > > There are some techniques that are difficult to unambiguously > categorize into one of the categories. Here we give some guidance > how to categorize such techniques: > > - Techniques that can be considered as both packet and flow > selection: some packet selection techniques result in the > selection of Complete Flows and therefore can be considered > as packet or as flow selection at the same time. An example > is Property Match Filtering of all packets to a specific > destination address. If flows are defined based on > destination addresses, such a packet selection also results > in a flow selection and can be considered as packet or flow > selection. > > - Flow-state Dependent Packet Selection (as described in > [RFC5475]): there exist techniques that select packets based s/there exist technique/techniques exist/ > on the flow state, e.g. based on the number of already > observed packets belonging to the flow. Examples of these > techniques from the literature are "Sample and Hold" [EsVa01] > "Fast Filtered Sampling" [MSZC10] or the "Sticky Sampling" > algorithm presented in [MaMo02]. Such techniques can be used > > > > D'Antonio, et al. Expires January 12, 2012 [Page 7] > > Internet-Draft Flow Selection Techniques July 2011 > > > to influence which flows are captured (e.g. increase the > selection of packets belonging to large flows) and reduce the > number of flows that need to be stored in the flow cache. > Nevertheless, such techniques do not necessarily select > Complete Flows, because they do not ensure that all packets > of a selected flow are captured. Therefore Flow-state > Dependent Packet Selection methods that do not ensure that > either all or no packets of a flow are selected strictly > speaking have to be considered as packet selection techniques > and not as flow selection techniques. > > > 4. Flow selection as a Function in the IPFIX Architecture > > Figure 1 shows the IPFIX reference model as defined in [RFC5470] and > shows the Packet Classification and Packet Aggregation Process in the > Metering Process. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > D'Antonio, et al. Expires January 12, 2012 [Page 8] > > Internet-Draft Flow Selection Techniques July 2011 > > > Packet(s) coming in to Observation Point(s) > | | > v v > +----------------+---------------------------+ +-----+-------+ > | Metering Process | | | > | | | | > | packet header capturing | | | > | | |...| Metering | > | timestamping | | Process N | > | | | | | > | packet sampling | | | > | | | | | > | (packet classification) | | | The bounding boxes need to be fixed. > | | | | | > | packet filtering* | | | > | | | | | > | (packet aggregation)* | | | > | | | | | > +--------|-----------------------------------+ +-----|-------+ > Flow Records Flow Records > | | > +----------------------+----------------------+ > | > +----------------------|-----------------+ > | Exporting Process* | > +----------------------+-----------------+ > | IPFIX (Flow Records) > v > +-------------------------|-----------------------+ > | IPFIX Mediator | | > | v | > | Collecting Process(es) | > | | | > | Intermediate Flow Selection Process (*) | > | | | > | Exporting Process(es) | Flow selection is possible in this EP too. eg, after the IFSP, the EP may need to perform selection to throttle the export bandwith. > +-------------------------|-----------------------+ > v > IPFIX > > (*) indicates where flow selection can take place. > > Figure 1: Flow selection in the IPFIX Architecture > > In contrast to packet selection, flow selection is always applied > after the packets are classified into flows. Flows can be selected > at different stages of the measurement chain: > > > > > D'Antonio, et al. Expires January 12, 2012 [Page 9] > > Internet-Draft Flow Selection Techniques July 2011 > > > 1. during the Metering Process > > 2. during Exporting Process > > 3. during an Intermediate Selection Process on a Mediator > > 4.1. Flow selection during the Metering Process > > In the Packet Aggregation Process the packet information is used to > update the Flow Records in the flow cache. Flow selection that is > applied before aggregation equals a packet selection process. The > flow still consists of individual packets. Those are then selected > based on the classification information, i.e. based on the flow they > belong to. Flow selection before aggregation can be based on the > fields of the Flow Key (also on a hash value over these fields), but So the hash cannot be on non-key fields? I didn't see that specified anywhere. > not based on characteristics that are only available after packet > aggregation (e.g. flow size, flow duration). Flow selection during > the Metering Process is applied to reduce resources for all > succeeding processes or to select specific flows of interest in case > such flow characteristics are already observable at packet level > (e.g. flows to specific IP addresses). In contrast, Flow-state > Dependent Packet Selection is a packet selection method, because it > does not necessarily select Complete Flows. > > 4.2. Flow selection during the Exporting Process > > The Flow Selection Process at the Exporter is similar to an > Intermediate Selection Process as described in [RFC6183] and works on > Flow records. Flow selection during the Exporting Process can > therefore also depend on flow characteristics that are only visible > after the aggregation of packets, such as flow size and flow > duration. The Exporting Process may implement policies for exporting > only a subset of the Flow Records which have been stored in the > system memory in order to unload flow export and flow postprocessing. Consider "post-processing". > Flow selection during the Exporting Process may select only the > subset of Flow Records which are of interest to the users > application, or select only as many Flow Records as can be handled by > the available resources (e.g. limited flow cache size and export link > capacity). Surely flow cache size would be of interest at the metering process rather than at the exporting process? > 4.3. Flow selection as a function of the IPFIX Mediator > > As shown in Figure 1, flow selection can be performed as an > Intermediate Process within an IPFIX Mediator [RFC6183]. The > Intermediate Selection Process takes Flow Record stream as its input > and selects a flow record stream. The Intermediate Selection Process > can again apply a flow selection technique to obtain flows of > interest to the application. Further the Intermediate Selection "Further," > > > D'Antonio, et al. Expires January 12, 2012 [Page 10] > > Internet-Draft Flow Selection Techniques July 2011 > > > Process can base its selection decision on the correlation of data > from different observation points, e.g. by only selecting flows that > were at least recorded on two observation points. So earlier discussion of "an Observation Point" wasn't exclusive? Good. > > 5. Flow Selection Techniques > > A flow selection technique selects either all or none of the packets > of a flow, otherwise the technique has to be considered as packet > selection. We distinguish between Flow Filtering and Flow Sampling. This is such a simple definition, I wish it had been said earlier! > 5.1. Flow Filtering > > Flow Filtering is a deterministic function on the IPFIX Flow Record > content. In case that the relevant flow characteristics are already s/In case that/If/ > observable at packet level (e.g. Flow Keys) Flow Filtering can be Add a comma after the ")". > applied before aggregation at packet level. > > 5.1.1. Property Match Filtering > > Flow Filtering can be done similarly to Property Match Filtering for s/done/performed/ ? > packet selection described in [RFC5475]. The difference is that, > instead of packet fields, Flow Record fields are here used to derive > the selection decision. Property Match Filtering is typically used > to select a specific subset of the flows that are of interest to a > particular application (e.g. all flows to a specific destination, all > large flows, etc.). Properties on which the filtering is based can > be for example Flow Keys, the flow size in bytes, the number of > packets in the flow, the observation time of the first or last > packet, or the maximum packet length. The selection criteria can be > a specific value or an interval. Property Match Filtering can be > applied during the Metering Process if the properties are already > observable at the packet level (e.g. Flow Key fields). > > There are content-based Property Match Filtering techniques that > require a computation on the current flow cache. An example is the > selection of the k largest flows or a percentage of flows with the Although I'm sure you intend 'k' as a variable, it looks like a typo. Can't it just be "N" - or just not named at all since it's not used below? > longest lifetime. This type of Property Match Filtering is also used > in flow selection techniques that react to external events (e.g. > resource constraint). For example in case the flow cache is full, s/in case/when/ > the Flow Record with the lowest flow volume per current flow life > time is deleted. s/is/may be/ (From an implementation point of view, I wouldn't do this since "per" involves division which I don't have time for when the cache is full...) > 5.1.2. Hash-based Flow Filtering > > Hash-based Flow Filtering uses a Hash Function h to map the Flow Key > c onto a Hash Range R. A flow is selected if the hash value h(c) is > within the Hash Selection Range S, which is a subset of R. Hash-based Do it like 'h', 'c', 'R' and 'S' so it doesn't look like typos. > > > D'Antonio, et al. Expires January 12, 2012 [Page 11] > > Internet-Draft Flow Selection Techniques July 2011 > > > Flow Filtering can be used to emulate a random sampling process but > still enable the correlation between selected flow subset at "subsets"? > different observation points. Hash-based Flow Filtering is similar > to Hash-based Packet Selection, and in fact is identical when Hash- > based Packet Selection uses the Flow Key that defines the flow as the > hash input. Nevertheless there MAY be the incentive to apply Hash- > based Flow Filtering not on the packet level during the Metering > Process, for example when the size of the selection range and > therefore the sampling probability is dependent on the number of > observed flows. > > 5.2. Flow Sampling > > Flow Sampling operates on Flow Record sequence or arrival times. It > can use either a systematic or a random function for the selection > process. Flow Sampling usually aims at the selection of a > representative subset of all flows in order to estimate > characteristics of the whole set (e.g. mean flow size in the > network). > > 5.2.1. Systematic sampling > > Systematic sampling is a deterministic selection function. > Systematic sampling may be a periodic selection of the k-th Flow Why k-th? In my experience, most engineers understand "Nth". > Record which arrives at the Exporting or Intermediate Selection > Process. Systematic sampling can also be applied during the Metering > Process. An example would be to use an additional data structure > that saves the Flow Keys of the non-selected flows. I don't follow the example, because a regular MP doesn't meter flows; it meters packets - so this would be systematic *packet* sampling rather than systematic *flow* sampling. Also, the example sounds like a filter: flows f were sampled, while flows f' were not. > Systematic sampling can also be time-based. Systematic sampling is s/Systematic sampling/Time based systematic sampling/ > applied by only creating flows that are observed between time-based > start and stop triggers. The time interval may be applied at packet > level during the Metering Process or after aggregation on flow level, > e.g. by selecting a flow arriving at the Exporting Process every k > seconds. > > 5.2.2. Random sampling > > Random flow sampling is based on a random process which requires the > calculation of random numbers. One can differentiate between n-out-N Random numbers are required for random sampling? This seems... obvious. > and probabilistic flow sampling. The sampling probability of It would bee good to explain the difference between n-out-N and probabilistic flow sampling. > individual Flows Records MAY be adjusted according to the Flow Record s/Flows/Flow/ > content or external events like the available export resources. Non- If the sampling rate is adjusted per individual flow record, how do you propose to report the sampling rate(s) correctly to allow normalisation and the correct interpretation of the data? > uniform random sampling approaches can be applied similar to the ones > defined in [RFC5475]. An example would be to increase the selection > probability of large volume flows over small volume flows as > described in the Smart Sampling technique [DuLT01]. Random flow > sampling can also be applied before the Packet Aggregation Process > > > > D'Antonio, et al. Expires January 12, 2012 [Page 12] > > Internet-Draft Flow Selection Techniques July 2011 > > > when additional flow state about non selected flows is kept. Why keep info about non-selected flows? What will be done with it? If the point of selection is to get rid of uninteresting flows, keeping the stuff that wasn't selected is just wasteful. > 5.3. Flow-state Dependent Flow Selection > > Flow-state Dependent Flow Selection can be a deterministic or random > flow selection process based on the Flow Record content and the flow > state which may be kept additionally for each of the flows. External > processes may update counters, bounds and timers for each of the Flow > Records and the Flow Selection Process utilises this information for > the selection decision. A review of Flow-state Dependent Flow > Selection techniques that aim at the selection of the most frequent > items by keeping additional flow state information can be found in > [CoHa08]. Flow-state Dependent Flow Selection can only be applied > after packet aggregation, when a packet has been assigned to a flow. > The selection process then decides based upon the flow state for each > flow if it is kept in the flow cache or not. Two Flow State > Dependent Flow Selection are here described: s/Selection are/Selection algorithms are/ > The frequent algorithm [KaPS03] is a technique that aims at the > selection of all flows that at least exceed a 1/k fraction of the > observed packet stream. The algorithm has only a flow cache of size OPS should be capitalised per RFC5476. > k-1 and each flow in the cache has an additional counter. The > counter is incremented each time a packet belonging to the flow in > the flow cache is observed. In case the observed packet does not > belong to any flow all counters are decremented and if any of the > flow counters has a value of zero the flow is replaced with a flow > formed from the new packet. > > Lossy counting is a selection technique that identifies all flows > whose packet count exceeds a certain percentage of the whole observed > packet stream (e.g. 5% of all packets) with a certain estimation > error e. Lossy counting separates the observed packet stream in 'e' > windows of size N=1/e, where N is an amount of consecutive packets. > For each observed flow an additional counter will be held in the flow > state. The counter is incremented each time a packet belonging to > the flow is observed and all counters are decremented at the end of > each window and all flows with a counter of zero will be removed from > the flow cache. s/will be/are/ > 5.4. Flow-state Dependent Packet Selection > > Flow-state Dependent Packet Selection is not a flow selection > technique but a packet selection technique. Nevertheless we will > describe configuration and reporting parameters for this technique in > this document. An example is the "Sample and Hold" algorithm > [EsVa01] that tries to prefer large volume flows in the selection. > When a packet arrives it is selected when a Flow Record for this > packet already exists. In case there is no Flow Record, the packet > > > > D'Antonio, et al. Expires January 12, 2012 [Page 13] > > Internet-Draft Flow Selection Techniques July 2011 > > > is selected by a certain probability that is dependent on the packet > size. > > > 6. Configuration of Flow Selection Techniques > > This section describes the configuration parameters of the flow > selection techniques presented above. It provides the basis of an > information model to be adopted in order to configure the Flow > Selection Process within an IPFIX Device. The following table gives > an overview of the defined selection techniques, where they can be > applied and what their input parameters are. Dependent on where the > flow selection techniques are applied different input parameters can > be configured. > > Overview of Flow Selection Techniques: > > +------------------+-----------------+------------------------------+ > | Location | Selection | Selection Input | > | | Method | | > +------------------+-----------------+------------------------------+ > | During the | Flow-state | packet sampling | > | Metering Process | Dependent | probabilities, flow state, | > | based on Packets | Packet | packet properties | > | | Selection | | > +------------------+-----------------+------------------------------+ > | | Property Match | Flow Key fields, filter | > | | Flow Filtering | function | > +------------------+-----------------+------------------------------+ > | | Hash-based Flow | selection range, Hash | > | | Filtering | Function, Flow Key | > +------------------+-----------------+------------------------------+ > | | Time-based | flow position (derived from | > | | Systematic Flow | arrival time of packets), | > | | Sampling | flow state | > +------------------+-----------------+------------------------------+ > | | Sequence-based | flow position (derived from | > | | Systematic Flow | packet position), flow state | > | | Sampling | | > +------------------+-----------------+------------------------------+ > | | Random Flow | random number generator or | > | | Sampling | list and packet position, | > | | | flow state | > +------------------+-----------------+------------------------------+ > | Exporting / | Property Match | Flow Record content, filter | > | Intermediate | Flow Filtering | function | > | Selection | | | > | Process | | | > > > > D'Antonio, et al. Expires January 12, 2012 [Page 14] > > Internet-Draft Flow Selection Techniques July 2011 > > > | | Hash-based Flow | selection range, Hash | > | | Filtering | Function, hash input (Flow | > | | | Keys and other flow | > | | | properties) | > +------------------+-----------------+------------------------------+ > | | Flow-state | flow state parameters, | > | | Dependent Flow | random number generator or | > | | Selection | list | > +------------------+-----------------+------------------------------+ > | | Time-based | flow arrival time, flow | > | | Systematic Flow | state | > | | Sampling | | > +------------------+-----------------+------------------------------+ > | | Sequence-based | flow position, flow state | > | | Systematic Flow | | > | | Sampling | | > +------------------+-----------------+------------------------------+ > | | Random Flow | random number generator or | > | | Sampling | list and flow position, flow | > | | | state | > +------------------+-----------------+------------------------------+ > > 6.1. Description of Flow Selection Techniques > > In this section, we define what parameters are required to describe > the most common Flow Selection techniques. Consider moving this paragraph to the top of section 6. > Flow Selection Parameters: > Flow state dependent packet selection is missing here. [Later] OK, it's below. See below. > For Property Match Filtering: > > - Information Element (from [RFC5102]): > Specifies the Information Element which is used as the property > in the filter expression. Can there be more than one IE? Don't use RFC5102 as the reference, use IANA - since there are now many more IEs in IANA than in 5102, you're adding an unintentional limitation. > - Selection Value or Value Interval: > Specifies the value or interval of the filter expression. > Packets and Flow Record that have a value equal to the Selection > Value or within the Interval will be selected. Are there other possibilities, eg not-equal, less-than, greater-than, regexp? The table above says "Flow Key fields, filter function" (for the relevant "Selection Input"). Is the text here supposed to align with or relate to the table in any way? > For Hash-based Flow Filtering: > > - Hash Domain: > Specifies the bits from packet (IPv4 or IPv6) which are taken as Why say "IPv4 or IPv6" ? > the hash input to the Hash Function. > > > > > > > D'Antonio, et al. Expires January 12, 2012 [Page 15] > > Internet-Draft Flow Selection Techniques July 2011 > > > - Hash Function: > Specifies the name of the Hash Function that is used to calculate > the hash value. Possible Hash Functions are BOB, IPSX, CRC-32 > > - Hash Selection Range: > Flows that have a hash value within the Hash Selection Range are > selected. The Hash Selection Range can be a value interval or > arbitrary hash values within the Hash Range of the Hash Function. > > - Random Seed or Initializer Value: > Some Hash Functions require an initializing value. In order to > make the selection decision more secure one can choose a random > seed that configures the hash function. Again, the table above says, "selection range, Hash Function, Flow Key" - so there's some similarity between the text and the table, but they don't align. > For Flow-state Dependent Flow Selection: It'd be good to maintain a consistent order of selection methods. > - frequency threshold: > Specifies the frequency threshold s for flow state dependent flow Is 's' the name of the threshold? It's not an obvious choice and looks like a typo. Consider: Specifies the frequency threshold 's' for flow state Specifies the frequency threshold, 's', for flow state > selection techniques that try to find the most frequent items > within a dataset. All flows which exceed the defined threshold > will be selected. > > - accuracy parameter: > specifies the accuracy parameter e for techniques that deal with Is 'e' a variable? Again, it looks like a typo. > the frequent items problems. The accuracy paramter defines the s/paramter/parameter/ > maximum error, i.e. no flows that have a true frequency less than > (s- e) N is selected, where s is the frequency threshold and N is "(s - e) N", with equal spacing. > the total number of packets. > > The above list of parameters for Flow-state Dependent Flow Selection > techniques is suitable for the presented frequent item and lossy > counting algorithm. Nevertheless there exist a variety of techniques s/there exist a variety of techniques/a variety of techniques exist/ > with very specific parameters which are not defined here. > > For Systematic time-based Flow Sampling: > > - Interval length (in usec) > Defines the length of the sampling interval during which flows > are selected. > > - Spacing (in usec) > The spacing parameter defines the spacing in usec between the end > of one sampling interval and the start of the next succeeding > interval. > > For Systematic count-based Flow Sampling: > > > > > > D'Antonio, et al. Expires January 12, 2012 [Page 16] > > Internet-Draft Flow Selection Techniques July 2011 > > > - Interval length > Defines the number of flows that are selected within the sampling > interval. > > - Spacing > The spacing parameter defines the spacing in number of observed > flows between the end of one sampling interval and the start of > the next succeeding interval. Can these methods be used together? eg, observe 10 flows, then wait 10 seconds? > For random n-out-of-N Flow Sampling: > > - Population Size N > The Population Size N is the number of all flows in the > Population from which the sample is drawn. > > - Sample size n > The sample size n is the number of flows that are randomly drawn > from the population N. > > For probabilistic Flow Sampling: > > - Sampling probability p > The sampling probability p defines the probability by which each > of the observed flows is selected. Again, the same point about N, n and p - it's not immediately clear that these are variables rather than typos. However, since they're not used anywhere, why name them at all? > 6.2. Description of Flow-state Dependent Packet Selection > > The configuration of Flow-state Dependent Packet Selection has not > been described in [RFC5475] therefore the parameters are defined > here: > > For Flow-state Dependent Packet Selection: > > - packet selection probability per possible flow state interval > Defines multiple [flow interval, packet selection probability] It'd be better to use { } for this, since [ ] usually delineate citations. > value pairs that configure the sampling probability dependent on > the current flow state. > > - additional parameters > For the configuration of flow state dependent packet selection > additional parameters or packet properties may be required for > the configuration, e.g. the packet size ([EsVa01]) > > > 7. Information Model for Flow Selection Reporting > > In this section we describe Information Elements (IEs) that SHOULD be > exported by a flow selection process in order to support the > > > > D'Antonio, et al. Expires January 12, 2012 [Page 17] > > Internet-Draft Flow Selection Techniques July 2011 > > > interpretation of measurement results from flow measurements where > only some flows are selected. The information is mainly used to > report how many packets and flows have been observed in total and how > many of them were selected. This helps for instance to calculate the > Attained Selection Fraction, which is an important parameter to Insert xref for ASF [RFC5476]. > provide an accuracy statement. The IEs can provide reporting > information about Flow Records, packets or bytes. The reported > metrics are number of total and the number of selected elements. s/number of total/total number of elements,/ > From this the number of dropped elements can be derived. All - provided appropriate total and selected pairs are exported. > counters SHOULD be exported and reset when a new measurement interval > starts. Additional IEs may be useful for future flow selection > techniques. Those can be defined additionally if needed. > > List of additional Flow Selection Information Elements: > > +------+---------------------------+ > | ID | Name | > +------+---------------------------+ > | TBD1 | fsFlowRecordTotalCount | > +------+---------------------------+ > | TBD2 | fsFlowRecordSelectedCount | > +------+---------------------------+ > | TBD3 | fsPacketTotalCount | > +------+---------------------------+ > | TBD4 | fsPacketSelectedCount | > +------+---------------------------+ > | TBD5 | fsOctetTotalCount | > +------+---------------------------+ > | TBD6 | fsOctetSelectedCount | > +------+---------------------------+ > Curiously, TBD1, TBD2, TBD7, TBD8, TBD9 and TBD10 are used below. Did none of the other reviewers notice this? :-( > 7.1. fsFlowRecordTotalCount > > Description: > > This Information Element specifies the current number of all Flow > Records that form the parent population as input to the Flow > Selection Process. > > Abstract Data Type: unsigned64 > > ElementId: TBD1 > > Units: Flows > > > > > > > > D'Antonio, et al. Expires January 12, 2012 [Page 18] > > Internet-Draft Flow Selection Techniques July 2011 > > > 7.2. fsFlowRecordSelectedCount > > Description: > > This Information Element specifies the current number of Flow > Records that were selected during the Flow Selection Process. > > Abstract Data Type: unsigned64 > > ElementId: TBD2 > > Units: Flows > > 7.3. fsPacketTotalCount > > Description: > > This Information Element specifies the current number of packets > in all flows that form the parent population as input to the Flow > Selection Process. > > Abstract Data Type: unsigned64 NB u64 might not be sufficient for this. See below. > ElementId: TBD7 This is TBD3 in the list above. > Units: Packets > > 7.4. fsPacketSelectedCount > > Description: > > This Information Element specifies the current number packets in > all flows that were selected during the Flow Selection Process. > > Abstract Data Type: unsigned64 > > ElementId: TBD8 This is TBD4. You get the idea. > Units: Packets > > 7.5. fsOctetTotalCount > > Description: > > This Information Element specifies the current number of all bytes > in all flows that form the parent population as input to the Flow > Selection Process. > > > > > D'Antonio, et al. Expires January 12, 2012 [Page 19] > > Internet-Draft Flow Selection Techniques July 2011 > > > Abstract Data Type: unsigned64 NB u64 may be insufficient for this since all bytes in all flows = all traffic entering the selection process. eg, monitoring 1000 x 10g interfaces, this allows for < 2^24 seconds of traffic, which is about 170 days. Perhaps this is enough today... though perhaps not so next year. > ElementId: TBD9 > > Units: Octets > > 7.6. fsOctetSelectedCount > > Description: > > This Information Element specifies the current number of bytes in > all flows that were selected during the Flow Selection Process. > > Abstract Data Type: unsigned64 > > ElementId: TBD10 > > Units: Octets > > > 8. IANA Considerations > > This document introduces several new Information Elements as an > extension to the IPFIX information model. Values TBD1-TBD10 in > section 7 of this document should be replaced with the assigned > numbers by IANA. > > > 9. Security Considerations > > In this section security issues concerning an IPFIX Device performing > flow selection are pointed out. In case the flow selection function > is activated an IPFIX Device might be exposed to security threats. "activated," > Since flow selection implies analysing flow packets, associating them > to a specific traffic flow and selecting Flow Records, a malicious "associate ... with" - so s/to/with/ > user who was able to gain control of an IPFIX Device might access > both packet and flow data, thus violating their confidentiality. > > Furthermore, the intruder might be attracted by the possibility of > altering the Flow Selection Process by modifying the criteria used to > select Flow Records. In this case, the IPFIX Device would export > flow data which are different from the ones that the Collector > expects to receive. > > It is apparent that these security threats can be mitigated by > authenticating entities that interact with the IPFIX Device and > keeping information for flow selection configuration confidential. In short, if you can gain control of the box then you can do bad things. This is well known. Does this document expose any new security considerations for the reader / implementer? If not, then consider stating that explicitly (copy the "no new security implications" text from other IPFIX RFCs) in order to avoid creating a negative impression (ie, that implementing this draft exposes security risks). > > > > D'Antonio, et al. Expires January 12, 2012 [Page 20] > > Internet-Draft Flow Selection Techniques July 2011 > > > 10. References > > 10.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > 10.2. Informative References > > [CoHa08] Cormode, G. and M. Hadjieleftheriou, "Finding frequent > items in data streams", Journal, Proceedings of the Very > Large DataBase Endowment VLDB Endowment, Volume 1 Issue 2, > August 2008, August 2008. > > [DuLT01] Duffield, N., Lund, C., and M. Thorup, "Charging from > Sampled Network Usage", ACM Internet Measurement Workshop > IMW 2001, San Francisco, USA, November 2001. > > [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. > > [KaPS03] Karp, R., Papadimitriou, C., and S. S. Shenker, "A simple > algorithm for finding frequent elements in sets and > bags.", ACM Transactions on Database Systems, Volume 28, > 51-55, 2003, March 2003. > > [MSZC10] Mai, J., Sridharan, A., Zang, H., and C. Chuah, "Fast > Filtered Sampling", Computer Networks Volume 54, Issue 11, > Pages 1885-1898, ISSN 1389-1286, January 2010. > > [MaMo02] Manku, G. and R. Motwani, "Approximate Frequency Counts > over Data Streams", Proceedings of the Internation s/Internation/International/ > Conference on Very large DataBases (VLDB) pages 346--357, > 2002, Hong Kong, China, 2002. > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export (IPFIX)", > RFC 3917, October 2004. > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", RFC 5101, January 2008. > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > RFC 5102, January 2008. > > > > D'Antonio, et al. Expires January 12, 2012 [Page 21] > > Internet-Draft Flow Selection Techniques July 2011 > > > [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, > "Architecture for IP Flow Information Export", RFC 5470, > March 2009. > > [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. > Raspall, "Sampling and Filtering Techniques for IP Packet > Selection", RFC 5475, March 2009. > > [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling > (PSAMP) Protocol Specifications", RFC 5476, March 2009. > > [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, > "IP Flow Information Export (IPFIX) Mediation: Framework", > RFC 6183, April 2011. > > > Authors' Addresses > > Salvatore D'Antonio > University of Napoli "Parthenope" > Centro Direzionale di Napoli Is. C4 > Naples 80143 > Italy > > Phone: +39 081 5476766 > Email: salvatore.dantonio@uniparthenope.it > > > Tanja Zseby > Fraunhofer Institute FOKUS > Kaiserin-Augusta-Allee 31 > Berlin 10589 > Germany > > Phone: +49 30 3463 7153 > Email: tanja.zseby@fokus.fraunhofer.de > > > Christian Henke > Technische Universitat Berlin > Strasse des 17. Juni 135 > Berlin 10623 > Germany > > Phone: +49 30 3463 7366 > Email: c.henke@tu-berlin.de > > > > > > D'Antonio, et al. Expires January 12, 2012 [Page 22] > > Internet-Draft Flow Selection Techniques July 2011 > > > Lorenzo Peluso > University of Napoli > Via Claudio 21 > Napoli 80125 > Italy > > Phone: +39 081 7683821 > Email: lorenzo.peluso@unina.it > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > D'Antonio, et al. Expires January 12, 2012 [Page 23] > From paitken@cisco.com Tue Sep 6 04:06:56 2011 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 E148921F85B9 for ; Tue, 6 Sep 2011 04:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 LHMyBlIStfgF for ; Tue, 6 Sep 2011 04:06:56 -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 B8F0A21F866A for ; Tue, 6 Sep 2011 04:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=665; q=dns/txt; s=iport; t=1315307322; x=1316516922; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=q+C/OYJBRcCry6jWIaJ7Oxzg38chGxoCdz8S33YRPyw=; b=C1a2Pqmce21LBhlf8hE8bxW9KHalFR+1w5vsVGIS8btPy7Yg+enjsSxx 71HxAv7KLO/GsQjX4drdDmWo0sriki+iwKryZoUJVYae5bWKNcDRm2xJY +RzkVsqwKDMIZ9j+FqbNLvkg4qRmt/wAaDkx9zPIX4PGpW6qwGsUFxZix Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAO7+ZU6Q/khR/2dsb2JhbABCqCJ4gUYBAQEBAxIBJUABEAshFg8JAwIBAgFFBg0BBwEBHqMcAZ59hmoEky6FD4t/ X-IronPort-AV: E=Sophos;i="4.68,338,1312156800"; d="scan'208";a="53393439" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 06 Sep 2011 11:08:37 +0000 Received: from [10.55.92.139] (dhcp-10-55-92-139.cisco.com [10.55.92.139]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p86B8bwq003867; Tue, 6 Sep 2011 11:08:37 GMT Message-ID: <4E65FF30.5070504@cisco.com> Date: Tue, 06 Sep 2011 12:08:32 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: IPFIX Working Group References: <4E558AE2.9000308@auckland.ac.nz> <4E65246F.5070406@cisco.com> In-Reply-To: <4E65246F.5070406@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee , draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Subject: Re: [IPFIX] Any last comments on draft-ietf-ipfix-flow-selection-tech-07 ??? 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, 06 Sep 2011 11:06:57 -0000 Dear all, Considering the draft some more... A standards track document should specify and contain everything that needs to be known and understood in order to implement the specified methods. However, this draft reads more as an overview of the methods, rather than a specification of them. While reading it gave an idea of the available methods, what actually needs done to correctly implement each method is not spelled out. eg, there are only two MUSTs in the document, both in the first paragraph of section 1. The average over all the IPFIX drafts is over 15 MUSTs. In short, it seems more Informational than Standards track. P. From bclaise@cisco.com Tue Sep 6 06:37:01 2011 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 A6F8C21F85AB for ; Tue, 6 Sep 2011 06:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=1.138, BAYES_00=-2.599, GB_I_LETTER=-2] 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 9tAVWmZi8QS9 for ; Tue, 6 Sep 2011 06:36:57 -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 213D021F85B1 for ; Tue, 6 Sep 2011 06:36:56 -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 p86DcZ52008402; Tue, 6 Sep 2011 15:38:35 +0200 (CEST) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p86DcXdh026506; Tue, 6 Sep 2011 15:38:33 +0200 (CEST) Message-ID: <4E662259.2000708@cisco.com> Date: Tue, 06 Sep 2011 15:38:33 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Paul Aitken References: <4E558AE2.9000308@auckland.ac.nz> <4E65246F.5070406@cisco.com> In-Reply-To: <4E65246F.5070406@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee , IPFIX Working Group , draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Subject: Re: [IPFIX] Any last comments on draft-ietf-ipfix-flow-selection-tech-07 ??? 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, 06 Sep 2011 13:37:01 -0000 Dear all, After speaking with Paul, I reviewed this draft. Next to Paul's comments below, I have some more. See in line. I have a couple of important concerns: - the lack of integration with the other mediation related RFC & drafts * for the terminology (example: Flow Selection Process is used instead of the Intermediate Flow Selection Process) * for the figure - I just took one example "Random Flow Sampling" and looked at what I should implement to be compliant. And I don't know the answer, and there is not a single example. If I compare with the PSAMP protocol specification for Random (packet) sampling, http://tools.ietf.org/html/rfc5476#section-6.5.2.3, this is clear. Therefore, I haven't read the entire draft, as there were blocking factors already. Regards, Benoit. > Nevil, All, > >> There hasn't been any comment on the selection draft for nearly a >> month - as long as I don't hear any by next Monday, I'll declare >> its WG Last Call finished and send its write-up to Dan. > > Sorry for the late response. > > Please find many comments inline. I'd like to see a new version of > this draft. > > Thanks, > P. > > >> >> Internet Engineering Task Force S. D'Antonio >> Internet-Draft University of Napoli >> Intended status: Standards Track "Parthenope" >> Expires: January 12, 2012 T. Zseby >> Fraunhofer Institute >> FOKUS >> C. >> Henke >> Technische Universitat >> Berlin >> L. >> Peluso >> University of >> Napoli >> July 11, >> 2011 >> >> >> Flow Selection Techniques >> draft-ietf-ipfix-flow-selection-tech-07.txt >> >> Abstract >> >> Flow selection is the process of selecting a subset of flows from >> all >> flows observed at an observation point. Flow selection reduces the > > Is just one OP allowed, or can they be observed at multiple > observation points? > eg, consider flow selection in a mediation device. Right. "a subset from all flows observed at an observation point, into a cache, or in mediatior" > > >> effort of post-processing flow data and transferring Flow Records. Capitalization in the abstract? >> This document describes motivations for flow selection and presents >> flow selection techniques. It provides an information model for >> configuring flow selection techniques and discusses what information >> about a flow selection process should be exported. >> >> Requirements Language >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in RFC 2119 [RFC2119]. >> >> Status of this Memo >> >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF). Note that other groups may also distribute >> working documents as Internet-Drafts. The list of current Internet- >> Drafts is at http://datatracker.ietf.org/drafts/current/. >> >> Internet-Drafts are draft documents valid for a maximum of six >> months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> This Internet-Draft will expire on January 12, 2012. >> >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 1] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> Copyright Notice >> >> Copyright (c) 2011 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions with >> respect >> to this document. Code Components extracted from this document must >> include Simplified BSD License text as described in Section 4.e of >> the Trust Legal Provisions and are provided without warranty as >> described in the Simplified BSD License. >> >> This document may contain material from IETF Documents or IETF >> Contributions published or made publicly available before November >> 10, 2008. The person(s) controlling the copyright in some of this >> material may not have granted the IETF Trust the right to allow >> modifications of such material outside the IETF Standards Process. >> Without obtaining an adequate license from the person(s) controlling >> the copyright in such materials, this document may not be modified >> outside the IETF Standards Process, and derivative works of it may >> not be created outside the IETF Standards Process, except to format >> it for publication as an RFC or to translate it into languages other >> than English. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 2] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> Table of Contents >> >> 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . >> . 4 >> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . >> . 4 >> 3. Difference between Flow Selection and Packet Selection . . . >> . 7 >> 4. Flow selection as a Function in the IPFIX Architecture . . . >> . 8 >> 4.1. Flow selection during the Metering Process . . . . . . . >> . 10 >> 4.2. Flow selection during the Exporting Process . . . . . . >> . 10 >> 4.3. Flow selection as a function of the IPFIX Mediator . . . >> . 10 >> 5. Flow Selection Techniques . . . . . . . . . . . . . . . . . >> . 11 >> 5.1. Flow Filtering . . . . . . . . . . . . . . . . . . . . . >> . 11 >> 5.1.1. Property Match Filtering . . . . . . . . . . . . . . >> . 11 >> 5.1.2. Hash-based Flow Filtering . . . . . . . . . . . . . >> . 11 >> 5.2. Flow Sampling . . . . . . . . . . . . . . . . . . . . . >> . 12 >> 5.2.1. Systematic sampling . . . . . . . . . . . . . . . . >> . 12 >> 5.2.2. Random sampling . . . . . . . . . . . . . . . . . . >> . 12 >> 5.3. Flow-state Dependent Flow Selection . . . . . . . . . . >> . 13 >> 5.4. Flow-state Dependent Packet Selection . . . . . . . . . >> . 13 >> 6. Configuration of Flow Selection Techniques . . . . . . . . . >> . 14 >> 6.1. Description of Flow Selection Techniques . . . . . . . . >> . 15 >> 6.2. Description of Flow-state Dependent Packet Selection . . >> . 17 >> 7. Information Model for Flow Selection Reporting . . . . . . . >> . 17 >> 7.1. fsFlowRecordTotalCount . . . . . . . . . . . . . . . . . >> . 18 >> 7.2. fsFlowRecordSelectedCount . . . . . . . . . . . . . . . >> . 19 >> 7.3. fsPacketTotalCount . . . . . . . . . . . . . . . . . . . >> . 19 >> 7.4. fsPacketSelectedCount . . . . . . . . . . . . . . . . . >> . 19 >> 7.5. fsOctetTotalCount . . . . . . . . . . . . . . . . . . . >> . 19 >> 7.6. fsOctetSelectedCount . . . . . . . . . . . . . . . . . . >> . 20 >> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . >> . 20 >> 9. Security Considerations . . . . . . . . . . . . . . . . . . >> . 20 >> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . >> . 21 >> 10.1. Normative References . . . . . . . . . . . . . . . . . . >> . 21 >> 10.2. Informative References . . . . . . . . . . . . . . . . . >> . 21 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . >> . 22 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 3] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> 1. Scope >> >> This document describes flow selection techniques for network >> traffic >> measurements. A flow is defined as a set of packets with common >> properties as described in [RFC5101]. Flow selection can be done to >> limit the resource demands for capturing, storing, exporting and >> post-processing of Flow Records. It also can be used to select a >> particular set of flows that are of interest to a specific >> application. This is where you should expand on the different cases: 1. selected flows observed at an observation point, 2. selected flow from a cache, 3 .selected flow in a mediator >> This document provides a categorization of flow >> selection techniques and describes configuration and reporting >> parameters for them. In order to be compliant with this >> document, at >> least one of the flow selection schemes MUST be implemented. That >> means that the configuration parameters as well as the reporting >> Information Elements for this particular scheme MUST be supported. >> >> This document also addresses configuration and reporting parameters >> for flow-state dependent packet selection as described in [RFC5475], >> although this technique is categorized as packet selection. The >> reason is, that flow-state dependent packet selection techniques >> often aim at the reduction of resources for flow capturing and flow >> processing. Furthermore, they were only briefly discussed in >> [RFC5475]. Therefore we included configuration and reporting >> considerations for such techniques in this document. >> Please add section such as http://tools.ietf.org/html/rfc6235#section-1.2, to be consistent between all the different mediation drafts. Note: this should be done as for http://tools.ietf.org/html/draft-trammell-ipfix-a9n-03 >> >> 2. Terminology >> >> This document is consistent with the terminology introduced in >> [RFC5101], [RFC5470], [RFC5475] and [RFC3917]. Please mention which terms are used in this draft. For example, when I read the definition of Packet Aggregation Process or Flow Selection Process, I was wondering they were not similar to terms defined in other RFCs >> As in [RFC5101] and >> [RFC5476], the first letter of each IPFIX-specific and >> PSAMP-specific >> term is capitalized along with the flow selection specific terms >> defined here. I hope the terminology is also in line with http://tools.ietf.org/html/rfc6183 and http://tools.ietf.org/html/rfc5982 If this is the case, please mention it. >> >> * Packet Classification >> >> Packet Classification is a process by which packets are mapped to >> specific Flow Records based on packet properties or external >> properties (e.g. interface). The properties make up the Flow Key >> (e.g. header information, packet content, AS number). In case a > > "The properties (e.g. header information, packet content, AS number) > make up the Flow Key." > > >> Flow Record for a specific Flow Key already exists the Flow >> Record >> is updated, otherwise a new Flow Record is created. How is this different from the IPFIX Metering Process? * Metering Process The Metering Process generates Flow Records. Inputs to the process are packet headers and characteristics observed at an Observation Point, and packet treatment at the Observation Point (for example, the selected output interface). The Metering Process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining Flow Records. The maintenance of Flow Records may include creating new records, updating existing ones, computing Flow statistics, deriving further Flow properties, detecting Flow expiration, passing Flow Records to the Exporting Process, and deleting Flow Records. >> >> * Packet Aggregation Process >> >> In the IPFIX Metering Process the Packet Aggregation Process >> aggregates packet data into flow data and forms the Flow Records. >> After the aggregation step only the aggregated flow >> information is >> available. Information about individual packets is lost. What is packet data? Again, how is this different from the Metering Process? >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 4] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> * Flow Selection Process >> >> A Flow Selection Process takes Flow Records as its input and >> selects a subset of this set as its output. A Flow Selection >> Process MAY run on several instances within the IPFIX > > s/on several instances/in several places/ > > >> architecture. A Flow Selection Process MAY be part of an IPFIX >> Metering Process, Exporting Process or as an Intermediate >> Selection Process as defined for the IPFIX Mediator [RFC6183]. I really confused by "A Flow Selection Process MAY be part of ... an Intermediate Selection Process as defined for the IPFIX Mediator [RFC6183]." Why don't you reuse the Intermediate Selection Process An Intermediate Selection Process is an Intermediate Process that selects records from a sequence based upon criteria-evaluated record values and passes only those records that match the criteria (e.g., filtering only records from a given network to a given Collector). Your Flow Selection Process term should be replaced by the Intermediate Selection Process. >> >> * Flow Selection State >> >> A Flow Selection Process SHOULD maintain state information for >> use It's the second time that I see RFC 2119 keywords in definition. If I recall correctly, this is not welcome. >> by the Flow Selector. At a given time, the Flow Selection State >> may depend on flows and packets observed at and before that time, >> as well as other variables. Examples include: >> >> (i) sequence number of packets and accounted Flow Records; >> >> (ii) number of selected flows; >> >> (iii) number of observed flows; >> >> (iv) current flow cache occupancy; >> >> (v) flow specific counters, lower und upper bounds > > s/und/and/ > > >> (vi) flow selection timeout intervals > > Some of the list items end with ";" while others do not. > > >> * Flow Selector >> >> A Flow Selector defines the action of a Flow Selection Process on >> a single flow of its input. The Flow Selector can make use of >> the >> following information in order to establish whether a flow has to >> be selected or not: I'm confused by the "on a single flow". If I do flow based random sampling, do I use a Flow Selector? I mean, I will look at all the flows in the caches, not individual flows >> >> (i) the content of the Flow Record; >> >> (ii) any state information related to the Metering Process or >> Exporting Process; >> >> (iii) any Flow Selection State that may be maintained by the >> Flow Selection Process. >> >> * Complete Flow >> >> A Complete Flow consists of all packets within the flow time-out >> interval that enter the Flow Selection Process and belong to the > > "A Complete Flow consists of all the packets that enter the > Flow Selection Process within the flow time-out interval, and which > belong to the ..." > > >> same flow as defined by the flow definition in [RFC5470]. For >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 5] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> this definition only packets that arrive at the Flow Selection >> Process are considered. That means, packets that are not >> observed >> at the Flow Selection Process because of prior packet >> selection or >> packet loss are not considered as belonging to the Complete Flow. >> >> * Flow Filtering >> >> Flow Filtering selects flows based on a deterministic function on >> the Flow Record content, flow state, external properties (e.g. > > Does "flow state" mean "flow selection state"? > ie referring to the list just above, is it (ii), (iii), or both? > > >> ingress interface) or external events (e.g violated Access >> Control >> List). If the relevant parts of the Flow Record content can be >> already observed at packet level (e.g. Flow Keys from packet > > s/can be already/can already be/ > > >> header fields) Flow Filtering can be performed at packet level by >> Property Match Filtering as described in [RFC5475]. >> >> * Hash-based Flow Filtering >> >> Hash-based Flow Filtering is a deterministic flow filter function >> that selects flows based on a Hash Function which is calculated >> over parts of the Flow Record content or external properties. If >> the hash value falls into a predefined Hash Selection Range the >> flow is selected. > > Is there a way to control which fields from the Flow Record go in to > the hash? > > Else, if two devices implement the same hash, are fed the same > packets, and implement the same flow records - except that the fields > are in a different order - then they may produce different output. > > >> * Flow-state Dependent Flow Selection >> >> Flow-state Dependent Flow Selection is a selection function that >> selects or drops flows based on the current flow state. The >> selection can be either deterministic, random or non-uniform >> random. > > Again, please clarify exactly what the flow state is. It seems worth > defining the "Flow-state" term. > > eg, one could assume flow state = active, expired, exported... > > >> * Flow-state Dependent Packet Selection >> >> Flow-state Dependent Packet Selection is a selection function >> that >> selects or drops packets based on the current flow state. The >> selection can be either deterministic, random or non-uniform >> random. Flow-state Dependent Packet Selection can be used to >> prefer the selection of packets belonging to specific flows (e.g. >> large or small flows). > > Are those real examples? Surely preferring packets for small flows > gives lots of details without giving the big picture and may quickly > fill the cache (not withstanding that everything starts as a small > flow anyway...), while preferring packets for large flows may grow > whatever flows are initially observed into "large" flows while > discarding individual packets which would eventually make a truely > "large" flow. > > Unless this is something you want to develop, I'd just remove the > "(e.g. ...)" section. > > [Later] I see that you mention "large" flows several times. Does this > require foreknowledge of what may constitute a large flow? Else, how > can you correctly select packets which pertain to the "large" flows? > > >> * Flow Sampling >> >> Flow Sampling selects flows based on Flow Record sequence or >> arrival times (e.g. entry in flow cache, arrival time at Exporter >> or Mediator). The selection can be systematic (e.g. every n-th >> flow) or based on a random function (e.g. select each Flow Record >> with probability p, or randomly select n out of N Flow Records). > > I'm hoping that a discussion of the pros and cons of each method and > recommendations as to when to use each method will follow. > > [Later] It may be worth saying "Discussion of these methods appears in > section 5 below". > > >> >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 6] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> 3. Difference between Flow Selection and Packet Selection >> >> Flow selection differs from packet selection described in [RFC5475]. > > This seems obvious. > > >> Packet selection techniques consider packets as basic element and >> the > > "as *the" basic element" ? > > >> parent population consists of all packets observed at an observation >> point. In contrast to this the basic elements in flow selection are > > Just one observation point? Therefore the techniques can't be used > when traffic has been aggregated from multiple OPs? > > >> the flows. The parent population consists of all observed flows and >> the selection process operates on the flows. The major >> characteristics of flow selection are the following: >> >> - Flow selection takes flows as basic elements. For packet >> selection, packets are considered as basic elements. >> >> - Flow selection can only take place after Packet >> Classification, because the classification rules >> determine to >> which flow a packet belongs. Packet selection can be >> applied >> before and after Packet Classification. >> >> - Flow selection operates on Complete Flows. That means that >> after the Flow Selection Process either all packets of the >> flow are kept or all packets of the flow are discarded. All > > When you say "flow" here, I think you mean "Complete Flow". > So consider, "either the complete flow is kept or the complete flow is > discarded". > > >> packets of the flow here means all packets that enter the >> Flow Selection Process. That means that if the flow > > Packets don't enter the flow selection process, since the flow > selection process operates on complete flows (per the definition above). > > >> selection is preceded by a packet selection process the >> Complete Flow consists only of the packets that were not >> discarded during the packet selection. >> >> There are some techniques that are difficult to unambiguously >> categorize into one of the categories. Here we give some guidance >> how to categorize such techniques: >> >> - Techniques that can be considered as both packet and flow >> selection: some packet selection techniques result in the >> selection of Complete Flows and therefore can be considered >> as packet or as flow selection at the same time. An example >> is Property Match Filtering of all packets to a specific >> destination address. If flows are defined based on >> destination addresses, such a packet selection also results >> in a flow selection and can be considered as packet or flow >> selection. >> >> - Flow-state Dependent Packet Selection (as described in >> [RFC5475]): there exist techniques that select packets based > > s/there exist technique/techniques exist/ > > >> on the flow state, e.g. based on the number of already >> observed packets belonging to the flow. Examples of these >> techniques from the literature are "Sample and Hold" >> [EsVa01] >> "Fast Filtered Sampling" [MSZC10] or the "Sticky Sampling" >> algorithm presented in [MaMo02]. Such techniques can be >> used >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 7] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> to influence which flows are captured (e.g. increase the >> selection of packets belonging to large flows) and reduce >> the >> number of flows that need to be stored in the flow cache. >> Nevertheless, such techniques do not necessarily select >> Complete Flows, because they do not ensure that all packets >> of a selected flow are captured. Therefore Flow-state >> Dependent Packet Selection methods that do not ensure that >> either all or no packets of a flow are selected strictly >> speaking have to be considered as packet selection >> techniques >> and not as flow selection techniques. >> >> >> 4. Flow selection as a Function in the IPFIX Architecture >> >> Figure 1 shows the IPFIX reference model as defined in [RFC5470] and >> shows the Packet Classification and Packet Aggregation Process in >> the >> Metering Process. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 8] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> Packet(s) coming in to Observation Point(s) >> | | >> v v >> +----------------+---------------------------+ +-----+-------+ >> | Metering Process | | | >> | | | | >> | packet header capturing | | | >> | | |...| Metering | >> | timestamping | | Process N | >> | | | | | >> | packet sampling | | | >> | | | | | >> | (packet classification) | >> | | > > The bounding boxes need to be fixed. > > >> | | | | | >> | packet filtering* | | | >> | | | | | >> | (packet aggregation)* | | | >> | | | | | >> +--------|-----------------------------------+ +-----|-------+ >> Flow Records Flow Records >> | | >> +----------------------+----------------------+ >> | >> +----------------------|-----------------+ >> | Exporting Process* | >> +----------------------+-----------------+ >> | IPFIX (Flow Records) >> v >> +-------------------------|-----------------------+ >> | IPFIX Mediator | | >> | v | >> | Collecting Process(es) | >> | | | >> | Intermediate Flow Selection Process (*) | >> | | | >> | Exporting Process(es) | > > Flow selection is possible in this EP too. > eg, after the IFSP, the EP may need to perform selection to throttle > the export bandwith. In other words, we could have a IPFIX Mediation on the Original Exporter. Using a * to "indicate where flow selection can take place." is confusing > > >> +-------------------------|-----------------------+ >> v >> IPFIX >> >> (*) indicates where flow selection can take place. There is a big confusion between packet and flow. A flow selection happens where there are flows, and you mention that flow selection can take place in "packet filtering", "packet aggregation". It doesn't make sense. This figure should be redrawn according to the figure A at http://tools.ietf.org/html/rfc6183#section-4, with Intermediate Flow Selection Process >> >> Figure 1: Flow selection in the IPFIX Architecture >> >> In contrast to packet selection, flow selection is always applied >> after the packets are classified into flows. Exactly. See my previous remark >> Flows can be selected >> at different stages of the measurement chain: >> >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 9] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> 1. during the Metering Process >> >> 2. during Exporting Process >> >> 3. during an Intermediate Selection Process on a Mediator >> >> 4.1. Flow selection during the Metering Process >> >> In the Packet Aggregation Process the packet information is used to >> update the Flow Records in the flow cache. Flow selection that is >> applied before aggregation equals a packet selection process. The >> flow still consists of individual packets. Those are then selected >> based on the classification information, i.e. based on the flow they >> belong to. Flow selection before aggregation can be based on the >> fields of the Flow Key (also on a hash value over these fields), but > > So the hash cannot be on non-key fields? I didn't see that specified > anywhere. > > >> not based on characteristics that are only available after packet >> aggregation (e.g. flow size, flow duration). Flow selection during >> the Metering Process is applied to reduce resources for all >> succeeding processes or to select specific flows of interest in case >> such flow characteristics are already observable at packet level >> (e.g. flows to specific IP addresses). In contrast, Flow-state >> Dependent Packet Selection is a packet selection method, because it >> does not necessarily select Complete Flows. >> >> 4.2. Flow selection during the Exporting Process >> >> The Flow Selection Process at the Exporter is similar to an >> Intermediate Selection Process as described in [RFC6183] and >> works on >> Flow records. Flow selection during the Exporting Process can >> therefore also depend on flow characteristics that are only visible >> after the aggregation of packets, such as flow size and flow >> duration. The Exporting Process may implement policies for >> exporting >> only a subset of the Flow Records which have been stored in the >> system memory in order to unload flow export and flow >> postprocessing. > > Consider "post-processing". > > >> Flow selection during the Exporting Process may select only the >> subset of Flow Records which are of interest to the users >> application, or select only as many Flow Records as can be >> handled by >> the available resources (e.g. limited flow cache size and export >> link >> capacity). > > Surely flow cache size would be of interest at the metering process > rather than at the exporting process? > > >> 4.3. Flow selection as a function of the IPFIX Mediator >> >> As shown in Figure 1, flow selection can be performed as an >> Intermediate Process within an IPFIX Mediator [RFC6183]. The >> Intermediate Selection Process takes Flow Record stream as its input >> and selects a flow record stream. The Intermediate Selection >> Process >> can again apply a flow selection technique to obtain flows of >> interest to the application. Further the Intermediate Selection > > "Further," > > >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 10] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> Process can base its selection decision on the correlation of data >> from different observation points, e.g. by only selecting flows that >> were at least recorded on two observation points. > > So earlier discussion of "an Observation Point" wasn't exclusive? Good. > > >> >> 5. Flow Selection Techniques >> >> A flow selection technique selects either all or none of the packets >> of a flow, otherwise the technique has to be considered as packet >> selection. We distinguish between Flow Filtering and Flow Sampling. > > This is such a simple definition, I wish it had been said earlier! > > >> 5.1. Flow Filtering >> >> Flow Filtering is a deterministic function on the IPFIX Flow Record >> content. In case that the relevant flow characteristics are already > > s/In case that/If/ > > >> observable at packet level (e.g. Flow Keys) Flow Filtering can be > > Add a comma after the ")". > > >> applied before aggregation at packet level. >> >> 5.1.1. Property Match Filtering >> >> Flow Filtering can be done similarly to Property Match Filtering for > > s/done/performed/ ? > > >> packet selection described in [RFC5475]. The difference is that, >> instead of packet fields, Flow Record fields are here used to derive >> the selection decision. Property Match Filtering is typically used >> to select a specific subset of the flows that are of interest to a >> particular application (e.g. all flows to a specific destination, >> all >> large flows, etc.). Properties on which the filtering is based can >> be for example Flow Keys, the flow size in bytes, the number of >> packets in the flow, the observation time of the first or last >> packet, or the maximum packet length. The selection criteria can be >> a specific value or an interval. Property Match Filtering can be >> applied during the Metering Process if the properties are already >> observable at the packet level (e.g. Flow Key fields). >> >> There are content-based Property Match Filtering techniques that >> require a computation on the current flow cache. An example is the >> selection of the k largest flows or a percentage of flows with the > > Although I'm sure you intend 'k' as a variable, it looks like a typo. > > Can't it just be "N" - or just not named at all since it's not used > below? > > >> longest lifetime. This type of Property Match Filtering is also >> used >> in flow selection techniques that react to external events (e.g. >> resource constraint). For example in case the flow cache is full, > > s/in case/when/ > > >> the Flow Record with the lowest flow volume per current flow life >> time is deleted. > > s/is/may be/ > > (From an implementation point of view, I wouldn't do this since "per" > involves division which I don't have time for when the cache is full...) > > >> 5.1.2. Hash-based Flow Filtering >> >> Hash-based Flow Filtering uses a Hash Function h to map the Flow Key >> c onto a Hash Range R. A flow is selected if the hash value h(c) is >> within the Hash Selection Range S, which is a subset of R. >> Hash-based > > Do it like 'h', 'c', 'R' and 'S' so it doesn't look like typos. > > >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 11] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> Flow Filtering can be used to emulate a random sampling process but >> still enable the correlation between selected flow subset at > > "subsets"? > > >> different observation points. Hash-based Flow Filtering is similar >> to Hash-based Packet Selection, and in fact is identical when Hash- >> based Packet Selection uses the Flow Key that defines the flow as >> the >> hash input. Nevertheless there MAY be the incentive to apply Hash- >> based Flow Filtering not on the packet level during the Metering >> Process, for example when the size of the selection range and >> therefore the sampling probability is dependent on the number of >> observed flows. >> >> 5.2. Flow Sampling >> >> Flow Sampling operates on Flow Record sequence or arrival times. It >> can use either a systematic or a random function for the selection >> process. Flow Sampling usually aims at the selection of a >> representative subset of all flows in order to estimate >> characteristics of the whole set (e.g. mean flow size in the >> network). >> >> 5.2.1. Systematic sampling >> >> Systematic sampling is a deterministic selection function. >> Systematic sampling may be a periodic selection of the k-th Flow > > Why k-th? In my experience, most engineers understand "Nth". > > >> Record which arrives at the Exporting or Intermediate Selection >> Process. Systematic sampling can also be applied during the >> Metering >> Process. An example would be to use an additional data structure >> that saves the Flow Keys of the non-selected flows. > > I don't follow the example, because a regular MP doesn't meter flows; > it meters packets - so this would be systematic *packet* sampling > rather than systematic *flow* sampling. > > Also, the example sounds like a filter: flows f were sampled, while > flows f' were not. > > >> Systematic sampling can also be time-based. Systematic sampling is > > s/Systematic sampling/Time based systematic sampling/ > > >> applied by only creating flows that are observed between time-based >> start and stop triggers. The time interval may be applied at packet >> level during the Metering Process or after aggregation on flow >> level, >> e.g. by selecting a flow arriving at the Exporting Process every k >> seconds. >> >> 5.2.2. Random sampling >> >> Random flow sampling is based on a random process which requires the >> calculation of random numbers. One can differentiate between >> n-out-N > > Random numbers are required for random sampling? This seems... obvious. > > >> and probabilistic flow sampling. The sampling probability of > > It would bee good to explain the difference between n-out-N and > probabilistic flow sampling. > > >> individual Flows Records MAY be adjusted according to the Flow >> Record > > s/Flows/Flow/ > > >> content or external events like the available export resources. >> Non- > > If the sampling rate is adjusted per individual flow record, how do > you propose to report the sampling rate(s) correctly to allow > normalisation and the correct interpretation of the data? > > >> uniform random sampling approaches can be applied similar to the >> ones >> defined in [RFC5475]. An example would be to increase the selection >> probability of large volume flows over small volume flows as >> described in the Smart Sampling technique [DuLT01]. Random flow >> sampling can also be applied before the Packet Aggregation Process >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 12] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> when additional flow state about non selected flows is kept. > > Why keep info about non-selected flows? What will be done with it? If > the point of selection is to get rid of uninteresting flows, keeping > the stuff that wasn't selected is just wasteful. > > >> 5.3. Flow-state Dependent Flow Selection >> >> Flow-state Dependent Flow Selection can be a deterministic or random >> flow selection process based on the Flow Record content and the flow >> state which may be kept additionally for each of the flows. >> External >> processes may update counters, bounds and timers for each of the >> Flow >> Records and the Flow Selection Process utilises this information for >> the selection decision. A review of Flow-state Dependent Flow >> Selection techniques that aim at the selection of the most frequent >> items by keeping additional flow state information can be found in >> [CoHa08]. Flow-state Dependent Flow Selection can only be applied >> after packet aggregation, when a packet has been assigned to a flow. >> The selection process then decides based upon the flow state for >> each >> flow if it is kept in the flow cache or not. Two Flow State >> Dependent Flow Selection are here described: > > s/Selection are/Selection algorithms are/ > > >> The frequent algorithm [KaPS03] is a technique that aims at the >> selection of all flows that at least exceed a 1/k fraction of the >> observed packet stream. The algorithm has only a flow cache of size > > OPS should be capitalised per RFC5476. > > >> k-1 and each flow in the cache has an additional counter. The >> counter is incremented each time a packet belonging to the flow in >> the flow cache is observed. In case the observed packet does not >> belong to any flow all counters are decremented and if any of the >> flow counters has a value of zero the flow is replaced with a flow >> formed from the new packet. >> >> Lossy counting is a selection technique that identifies all flows >> whose packet count exceeds a certain percentage of the whole >> observed >> packet stream (e.g. 5% of all packets) with a certain estimation >> error e. Lossy counting separates the observed packet stream in > > 'e' > > >> windows of size N=1/e, where N is an amount of consecutive packets. >> For each observed flow an additional counter will be held in the >> flow >> state. The counter is incremented each time a packet belonging to >> the flow is observed and all counters are decremented at the end of >> each window and all flows with a counter of zero will be removed >> from >> the flow cache. > > s/will be/are/ > > >> 5.4. Flow-state Dependent Packet Selection >> >> Flow-state Dependent Packet Selection is not a flow selection >> technique but a packet selection technique. Nevertheless we will >> describe configuration and reporting parameters for this >> technique in >> this document. An example is the "Sample and Hold" algorithm >> [EsVa01] that tries to prefer large volume flows in the selection. >> When a packet arrives it is selected when a Flow Record for this >> packet already exists. In case there is no Flow Record, the packet >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 13] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> is selected by a certain probability that is dependent on the packet >> size. >> >> >> 6. Configuration of Flow Selection Techniques >> >> This section describes the configuration parameters of the flow >> selection techniques presented above. It provides the basis of an >> information model to be adopted in order to configure the Flow >> Selection Process within an IPFIX Device. The following table gives >> an overview of the defined selection techniques, where they can be >> applied and what their input parameters are. Dependent on where the >> flow selection techniques are applied different input parameters can >> be configured. >> >> Overview of Flow Selection Techniques: >> >> >> +------------------+-----------------+------------------------------+ >> | Location | Selection | Selection >> Input | >> | | Method >> | | >> >> +------------------+-----------------+------------------------------+ >> | During the | Flow-state | packet >> sampling | >> | Metering Process | Dependent | probabilities, flow >> state, | >> | based on Packets | Packet | packet >> properties | >> | | Selection >> | | >> >> +------------------+-----------------+------------------------------+ >> | | Property Match | Flow Key fields, >> filter | >> | | Flow Filtering | >> function | >> >> +------------------+-----------------+------------------------------+ >> | | Hash-based Flow | selection range, >> Hash | >> | | Filtering | Function, Flow >> Key | >> >> +------------------+-----------------+------------------------------+ >> | | Time-based | flow position (derived >> from | >> | | Systematic Flow | arrival time of >> packets), | >> | | Sampling | flow >> state | >> >> +------------------+-----------------+------------------------------+ >> | | Sequence-based | flow position (derived >> from | >> | | Systematic Flow | packet position), flow >> state | >> | | Sampling >> | | >> >> +------------------+-----------------+------------------------------+ >> | | Random Flow | random number generator >> or | >> | | Sampling | list and packet >> position, | >> | | | flow >> state | >> >> +------------------+-----------------+------------------------------+ >> | Exporting / | Property Match | Flow Record content, >> filter | >> | Intermediate | Flow Filtering | >> function | >> | Selection | >> | | >> | Process | >> | | >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 14] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> | | Hash-based Flow | selection range, >> Hash | >> | | Filtering | Function, hash input >> (Flow | >> | | | Keys and other >> flow | >> | | | >> properties) | >> >> +------------------+-----------------+------------------------------+ >> | | Flow-state | flow state >> parameters, | >> | | Dependent Flow | random number generator >> or | >> | | Selection | >> list | >> >> +------------------+-----------------+------------------------------+ >> | | Time-based | flow arrival time, >> flow | >> | | Systematic Flow | >> state | >> | | Sampling >> | | >> >> +------------------+-----------------+------------------------------+ >> | | Sequence-based | flow position, flow >> state | >> | | Systematic Flow >> | | >> | | Sampling >> | | >> >> +------------------+-----------------+------------------------------+ >> | | Random Flow | random number generator >> or | >> | | Sampling | list and flow position, >> flow | >> | | | >> state | >> >> +------------------+-----------------+------------------------------+ >> >> 6.1. Description of Flow Selection Techniques >> >> In this section, we define what parameters are required to describe >> the most common Flow Selection techniques. > > Consider moving this paragraph to the top of section 6. > > >> Flow Selection Parameters: >> > > Flow state dependent packet selection is missing here. > > [Later] OK, it's below. See below. > > >> For Property Match Filtering: >> >> - Information Element (from [RFC5102]): >> Specifies the Information Element which is used as the property >> in the filter expression. > > Can there be more than one IE? > > Don't use RFC5102 as the reference, use IANA - since there are now > many more IEs in IANA than in 5102, you're adding an unintentional > limitation. > > >> - Selection Value or Value Interval: >> Specifies the value or interval of the filter expression. >> Packets and Flow Record that have a value equal to the Selection >> Value or within the Interval will be selected. > > Are there other possibilities, eg not-equal, less-than, greater-than, > regexp? > > The table above says "Flow Key fields, filter function" (for the > relevant "Selection Input"). Is the text here supposed to align with > or relate to the table in any way? > > >> For Hash-based Flow Filtering: >> >> - Hash Domain: >> Specifies the bits from packet (IPv4 or IPv6) which are taken as > > Why say "IPv4 or IPv6" ? > > >> the hash input to the Hash Function. >> >> >> >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 15] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> - Hash Function: >> Specifies the name of the Hash Function that is used to >> calculate >> the hash value. Possible Hash Functions are BOB, IPSX, CRC-32 >> >> - Hash Selection Range: >> Flows that have a hash value within the Hash Selection Range are >> selected. The Hash Selection Range can be a value interval or >> arbitrary hash values within the Hash Range of the Hash >> Function. >> >> - Random Seed or Initializer Value: >> Some Hash Functions require an initializing value. In order to >> make the selection decision more secure one can choose a random >> seed that configures the hash function. > > Again, the table above says, "selection range, Hash Function, Flow > Key" - so there's some similarity between the text and the table, but > they don't align. > > >> For Flow-state Dependent Flow Selection: > > It'd be good to maintain a consistent order of selection methods. > > >> - frequency threshold: >> Specifies the frequency threshold s for flow state dependent >> flow > > Is 's' the name of the threshold? It's not an obvious choice and looks > like a typo. > > Consider: > > Specifies the frequency threshold 's' for flow state > > Specifies the frequency threshold, 's', for flow state > > > > >> selection techniques that try to find the most frequent items >> within a dataset. All flows which exceed the defined threshold >> will be selected. >> >> - accuracy parameter: >> specifies the accuracy parameter e for techniques that deal with > > Is 'e' a variable? Again, it looks like a typo. > > >> the frequent items problems. The accuracy paramter defines the > > s/paramter/parameter/ > > >> maximum error, i.e. no flows that have a true frequency less >> than >> (s- e) N is selected, where s is the frequency threshold and >> N is > > "(s - e) N", with equal spacing. > > >> the total number of packets. >> >> The above list of parameters for Flow-state Dependent Flow Selection >> techniques is suitable for the presented frequent item and lossy >> counting algorithm. Nevertheless there exist a variety of >> techniques > > s/there exist a variety of techniques/a variety of techniques exist/ > > >> with very specific parameters which are not defined here. >> >> For Systematic time-based Flow Sampling: >> >> - Interval length (in usec) >> Defines the length of the sampling interval during which flows >> are selected. >> >> - Spacing (in usec) >> The spacing parameter defines the spacing in usec between the >> end >> of one sampling interval and the start of the next succeeding >> interval. >> >> For Systematic count-based Flow Sampling: >> >> >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 16] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> - Interval length >> Defines the number of flows that are selected within the >> sampling >> interval. >> >> - Spacing >> The spacing parameter defines the spacing in number of observed >> flows between the end of one sampling interval and the start of >> the next succeeding interval. > > Can these methods be used together? eg, observe 10 flows, then wait 10 > seconds? > > >> For random n-out-of-N Flow Sampling: >> >> - Population Size N >> The Population Size N is the number of all flows in the >> Population from which the sample is drawn. >> >> - Sample size n >> The sample size n is the number of flows that are randomly drawn >> from the population N. >> >> For probabilistic Flow Sampling: >> >> - Sampling probability p >> The sampling probability p defines the probability by which each >> of the observed flows is selected. > > Again, the same point about N, n and p - it's not immediately clear > that these are variables rather than typos. > However, since they're not used anywhere, why name them at all? > >> 6.2. Description of Flow-state Dependent Packet Selection >> >> The configuration of Flow-state Dependent Packet Selection has not >> been described in [RFC5475] therefore the parameters are defined >> here: >> >> For Flow-state Dependent Packet Selection: >> >> - packet selection probability per possible flow state interval >> Defines multiple [flow interval, packet selection probability] > > It'd be better to use { } for this, since [ ] usually delineate > citations. > > >> value pairs that configure the sampling probability dependent on >> the current flow state. >> >> - additional parameters >> For the configuration of flow state dependent packet selection >> additional parameters or packet properties may be required for >> the configuration, e.g. the packet size ([EsVa01]) >> >> >> 7. Information Model for Flow Selection Reporting >> >> In this section we describe Information Elements (IEs) that >> SHOULD be >> exported by a flow selection process in order to support the >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 17] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> interpretation of measurement results from flow measurements where >> only some flows are selected. The information is mainly used to >> report how many packets and flows have been observed in total and >> how >> many of them were selected. This helps for instance to calculate >> the >> Attained Selection Fraction, which is an important parameter to > > Insert xref for ASF [RFC5476]. > > >> provide an accuracy statement. The IEs can provide reporting >> information about Flow Records, packets or bytes. The reported >> metrics are number of total and the number of selected elements. > > s/number of total/total number of elements,/ > > >> From this the number of dropped elements can be derived. All > > - provided appropriate total and selected pairs are exported. > > >> counters SHOULD be exported and reset when a new measurement >> interval >> starts. Additional IEs may be useful for future flow selection >> techniques. Those can be defined additionally if needed. >> >> List of additional Flow Selection Information Elements: >> >> +------+---------------------------+ >> | ID | Name | >> +------+---------------------------+ >> | TBD1 | fsFlowRecordTotalCount | >> +------+---------------------------+ >> | TBD2 | fsFlowRecordSelectedCount | >> +------+---------------------------+ >> | TBD3 | fsPacketTotalCount | >> +------+---------------------------+ >> | TBD4 | fsPacketSelectedCount | >> +------+---------------------------+ >> | TBD5 | fsOctetTotalCount | >> +------+---------------------------+ >> | TBD6 | fsOctetSelectedCount | >> +------+---------------------------+ >> > > Curiously, TBD1, TBD2, TBD7, TBD8, TBD9 and TBD10 are used below. > Did none of the other reviewers notice this? :-( > > >> 7.1. fsFlowRecordTotalCount >> >> Description: >> >> This Information Element specifies the current number of all Flow >> Records that form the parent population as input to the Flow >> Selection Process. >> >> Abstract Data Type: unsigned64 >> >> ElementId: TBD1 >> >> Units: Flows >> >> >> >> >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 18] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> 7.2. fsFlowRecordSelectedCount >> >> Description: >> >> This Information Element specifies the current number of Flow >> Records that were selected during the Flow Selection Process. >> >> Abstract Data Type: unsigned64 >> >> ElementId: TBD2 >> >> Units: Flows >> >> 7.3. fsPacketTotalCount >> >> Description: >> >> This Information Element specifies the current number of packets >> in all flows that form the parent population as input to the Flow >> Selection Process. >> >> Abstract Data Type: unsigned64 > > NB u64 might not be sufficient for this. See below. > > >> ElementId: TBD7 > > This is TBD3 in the list above. > > >> Units: Packets >> >> 7.4. fsPacketSelectedCount >> >> Description: >> >> This Information Element specifies the current number packets in >> all flows that were selected during the Flow Selection Process. >> >> Abstract Data Type: unsigned64 >> >> ElementId: TBD8 > > This is TBD4. You get the idea. > > >> Units: Packets >> >> 7.5. fsOctetTotalCount >> >> Description: >> >> This Information Element specifies the current number of all >> bytes >> in all flows that form the parent population as input to the Flow >> Selection Process. >> >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 19] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> Abstract Data Type: unsigned64 > > NB u64 may be insufficient for this since all bytes in all flows = all > traffic entering the selection process. > > eg, monitoring 1000 x 10g interfaces, this allows for < 2^24 seconds > of traffic, which is about 170 days. Perhaps this is enough today... > though perhaps not so next year. > > >> ElementId: TBD9 >> >> Units: Octets >> >> 7.6. fsOctetSelectedCount >> >> Description: >> >> This Information Element specifies the current number of bytes in >> all flows that were selected during the Flow Selection Process. >> >> Abstract Data Type: unsigned64 >> >> ElementId: TBD10 >> >> Units: Octets >> >> >> 8. IANA Considerations >> >> This document introduces several new Information Elements as an >> extension to the IPFIX information model. Values TBD1-TBD10 in >> section 7 of this document should be replaced with the assigned >> numbers by IANA. >> >> >> 9. Security Considerations >> >> In this section security issues concerning an IPFIX Device >> performing >> flow selection are pointed out. In case the flow selection function >> is activated an IPFIX Device might be exposed to security threats. > > "activated," > > >> Since flow selection implies analysing flow packets, associating >> them >> to a specific traffic flow and selecting Flow Records, a malicious > > "associate ... with" - so s/to/with/ > > >> user who was able to gain control of an IPFIX Device might access >> both packet and flow data, thus violating their confidentiality. >> >> Furthermore, the intruder might be attracted by the possibility of >> altering the Flow Selection Process by modifying the criteria >> used to >> select Flow Records. In this case, the IPFIX Device would export >> flow data which are different from the ones that the Collector >> expects to receive. >> >> It is apparent that these security threats can be mitigated by >> authenticating entities that interact with the IPFIX Device and >> keeping information for flow selection configuration confidential. > > In short, if you can gain control of the box then you can do bad > things. This is well known. > > Does this document expose any new security considerations for the > reader / implementer? > If not, then consider stating that explicitly (copy the "no new > security implications" text from other IPFIX RFCs) in order to avoid > creating a negative impression (ie, that implementing this draft > exposes security risks). > > >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 20] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> 10. References >> >> 10.1. Normative References >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> 10.2. Informative References >> >> [CoHa08] Cormode, G. and M. Hadjieleftheriou, "Finding frequent >> items in data streams", Journal, Proceedings of the Very >> Large DataBase Endowment VLDB Endowment, Volume 1 >> Issue 2, >> August 2008, August 2008. >> >> [DuLT01] Duffield, N., Lund, C., and M. Thorup, "Charging from >> Sampled Network Usage", ACM Internet Measurement Workshop >> IMW 2001, San Francisco, USA, November 2001. >> >> [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. >> >> [KaPS03] Karp, R., Papadimitriou, C., and S. S. Shenker, "A simple >> algorithm for finding frequent elements in sets and >> bags.", ACM Transactions on Database Systems, Volume 28, >> 51-55, 2003, March 2003. >> >> [MSZC10] Mai, J., Sridharan, A., Zang, H., and C. Chuah, "Fast >> Filtered Sampling", Computer Networks Volume 54, Issue >> 11, >> Pages 1885-1898, ISSN 1389-1286, January 2010. >> >> [MaMo02] Manku, G. and R. Motwani, "Approximate Frequency Counts >> over Data Streams", Proceedings of the Internation > > s/Internation/International/ > > >> Conference on Very large DataBases (VLDB) pages 346--357, >> 2002, Hong Kong, China, 2002. >> >> [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, >> "Requirements for IP Flow Information Export (IPFIX)", >> RFC 3917, October 2004. >> >> [RFC5101] Claise, B., "Specification of the IP Flow Information >> Export (IPFIX) Protocol for the Exchange of IP Traffic >> Flow Information", RFC 5101, January 2008. >> >> [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. >> Meyer, "Information Model for IP Flow Information >> Export", >> RFC 5102, January 2008. >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 21] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, >> "Architecture for IP Flow Information Export", RFC 5470, >> March 2009. >> >> [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., >> and F. >> Raspall, "Sampling and Filtering Techniques for IP Packet >> Selection", RFC 5475, March 2009. >> >> [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling >> (PSAMP) Protocol Specifications", RFC 5476, March 2009. >> >> [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, >> "IP Flow Information Export (IPFIX) Mediation: >> Framework", >> RFC 6183, April 2011. >> >> >> Authors' Addresses >> >> Salvatore D'Antonio >> University of Napoli "Parthenope" >> Centro Direzionale di Napoli Is. C4 >> Naples 80143 >> Italy >> >> Phone: +39 081 5476766 >> Email: salvatore.dantonio@uniparthenope.it >> >> >> Tanja Zseby >> Fraunhofer Institute FOKUS >> Kaiserin-Augusta-Allee 31 >> Berlin 10589 >> Germany >> >> Phone: +49 30 3463 7153 >> Email: tanja.zseby@fokus.fraunhofer.de >> >> >> Christian Henke >> Technische Universitat Berlin >> Strasse des 17. Juni 135 >> Berlin 10623 >> Germany >> >> Phone: +49 30 3463 7366 >> Email: c.henke@tu-berlin.de >> >> >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 22] >> >> Internet-Draft Flow Selection Techniques July 2011 >> >> >> Lorenzo Peluso >> University of Napoli >> Via Claudio 21 >> Napoli 80125 >> Italy >> >> Phone: +39 081 7683821 >> Email: lorenzo.peluso@unina.it >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> D'Antonio, et al. Expires January 12, 2012 [Page 23] >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Tue Sep 6 07:13:45 2011 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 E35D521F8841 for ; Tue, 6 Sep 2011 07:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.127, 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 6BtBza2faz9v for ; Tue, 6 Sep 2011 07:13:45 -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 D063A21F87FC for ; Tue, 6 Sep 2011 07:13:44 -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 p86EFTKo012538 for ; Tue, 6 Sep 2011 16:15:29 +0200 (CEST) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p86EFSJ3025244; Tue, 6 Sep 2011 16:15:29 +0200 (CEST) Message-ID: <4E662B00.8010609@cisco.com> Date: Tue, 06 Sep 2011 16:15:28 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Paul Aitken References: <4E4CDC92.5000003@cisco.com> <4E60F325.5090602@cisco.com> <4E63F756.1040802@cisco.com> In-Reply-To: <4E63F756.1040802@cisco.com> Content-Type: multipart/alternative; boundary="------------090008000701000107000504" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] template lifetime - proposal 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, 06 Sep 2011 14:13:46 -0000 This is a multi-part message in MIME format. --------------090008000701000107000504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/09/2011 00:10, Paul Aitken wrote: > Benoit, > >>> How does a collector determine the correct lifetime to associate >>> with each Template, and how does it know "the Template refresh >>> timeout configured on the Exporting Process." ? >> Solution 1. Out of band configuration with >> http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10. >> Note: I still envision that IPFIX caches might be configured for a >> short period of time on IPFIX exporters, for troubleshooting reasons. > > This is not mentioned anywhere in IPFIX. It's a hole. Since http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10 mentions it 4.4.2. UdpExporter Class +-------------------------------------+ | UdpExporter | +-------------------------------------+ 0..1 +------------------+ | ipfixVersion = 10 |<>------| TransportLayer- | | sourceIPAddress[0..1] | | Security | | destinationIPAddress | +------------------+ | destinationPort = 4739|4740 | | ifName/ifIndex[0..1] | 0..1 +------------------+ | sendBufferSize {opt.} |<>------| TransportSession | | rateLimit[0..1] | +------------------+ | maxPacketSize {opt.} | | templateRefreshTimeout = 600 | | optionsTemplateRefreshTimeout = 600 | | templateRefreshPacket[0..1] | | optionsTemplateRefreshPacket[0..1] | +-------------------------------------+ We could at least add a sentence in RFC5101bis, referring to the configuration in draft-ietf-ipfix-configuration-model-10 Something such as: OLD: 10.3.6. Template Management When IPFIX uses UDP as the transport protocol, Template Sets and Option Template Sets MUST be re-sent at regular intervals. The frequency of the (Options) Template transmission MUST be configurable. The default value for the frequency of the (Options) Template transmission is 10 minutes. NEW: 10.3.6. Template Management When IPFIX uses UDP as the transport protocol, Template Sets and Option Template Sets MUST be re-sent at regular intervals. The frequency of the (Options) Template transmission MUST be configurable. The default value for the frequency of the (Options) Template transmission is 10 minutes. Note that the frequency of the (Options) Template transmission can be monitored and configured with thetemplateRefreshTimeout and optionsTemplateRefreshTimeout in [IPFIX-CONF]. I believe this change should be allowed from proposed to draft, as it doesn't change the specifications. The advantage is that it makes an implicit reference to the out of the band solution. Disclaimer: I know it doesn't solve the entire issue, but I'm trying to work in the limits imposed by the proposed to draft transition. Regards, Benoit. > >> Solution 2. CP observes 10 (or 20, or whatever number) template >> refresh and conclude the right value > > Packet loss and network jitter make this problematic. > > >> Solution 3: the CP doesn't bother and take a very high value > > That seems reasonable. Why not specify this as the default behaviour? > > >>> >>> What are the default and acceptable range of lifetime values? >>> >>> Should we have a mechanism which allows an Exporting Process to >>> report Template lifetimes to the Collecting Process? >>> eg, by exporting an option of { scope = templateId, lifetime = >>> lifeTimeUnits }, where lifeTimeUnits = u32 milliseconds - which >>> allows 1ms to 49.7 days, with 0 = infinite? >> This is solution 4. > > Then it needs to be written in the protocol so EPs export it and CPs > expect and action it correctly. > > P. --------------090008000701000107000504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/09/2011 00:10, Paul Aitken wrote:
Benoit,

How does a collector determine the correct lifetime to associate with each Template, and how does it know "the Template refresh timeout configured on the Exporting Process." ?
Solution 1. Out of band configuration with http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10. Note: I still envision that IPFIX caches might be configured for a short period of time on IPFIX exporters, for troubleshooting reasons.

This is not mentioned anywhere in IPFIX. It's a hole.

Since http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10 mentions it
4.4.2.  UdpExporter Class

    +-------------------------------------+
    | UdpExporter                         |
    +-------------------------------------+   0..1 +------------------+
    | ipfixVersion = 10                   |<>------| TransportLayer-  |
    | sourceIPAddress[0..1]               |        | Security         |
    | destinationIPAddress                |        +------------------+
    | destinationPort = 4739|4740         |
    | ifName/ifIndex[0..1]                |   0..1 +------------------+
    | sendBufferSize {opt.}               |<>------| TransportSession |
    | rateLimit[0..1]                     |        +------------------+
    | maxPacketSize {opt.}                |
    | templateRefreshTimeout = 600        |
    | optionsTemplateRefreshTimeout = 600 |
    | templateRefreshPacket[0..1]         |
    | optionsTemplateRefreshPacket[0..1]  |
    +-------------------------------------+
We could at least add a sentence in RFC5101bis, referring to the configuration in draft-ietf-ipfix-configuration-model-10
Something such as:

OLD:
10.3.6.  Template Management

   When IPFIX uses UDP as the transport protocol, Template Sets and
   Option Template Sets MUST be re-sent at regular intervals.  The
   frequency of the (Options) Template transmission MUST be
   configurable.  The default value for the frequency of the (Options)
   Template transmission is 10 minutes.

NEW:
10.3.6.  Template Management

   When IPFIX uses UDP as the transport protocol, Template Sets and
   Option Template Sets MUST be re-sent at regular intervals.  The
   frequency of the (Options) Template transmission MUST be
   configurable.  The default value for the frequency of the (Options)
   Template transmission is 10 minutes. Note that the frequency of the
    (Options) Template transmission can be monitored and configured
    with the templateRefreshTimeout and optionsTemplateRefreshTimeout
    in [IPFIX-CONF].

I believe this change should be allowed from proposed to draft, as it doesn't change the specifications.
The advantage is that it makes an implicit reference to the out of the band solution.
Disclaimer: I know it doesn't solve the entire issue, but I'm trying to work in the limits imposed by the proposed to draft transition.

Regards, Benoit.


Solution 2. CP observes 10 (or 20, or whatever number) template refresh and conclude the right value

Packet loss and network jitter make this problematic.


Solution 3: the CP doesn't bother and take a very high value

That seems reasonable. Why not specify this as the default behaviour?



What are the default and acceptable range of lifetime values?

Should we have a mechanism which allows an Exporting Process to report Template lifetimes to the Collecting Process?
eg, by exporting an option of { scope = templateId, lifetime = lifeTimeUnits }, where lifeTimeUnits = u32 milliseconds - which allows 1ms to 49.7 days, with 0 = infinite?
This is solution 4.

Then it needs to be written in the protocol so EPs export it and CPs expect and action it correctly.

P.

--------------090008000701000107000504-- From trammell@tik.ee.ethz.ch Wed Sep 7 04:23:37 2011 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 CDF3B21F8B3D for ; Wed, 7 Sep 2011 04:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.495 X-Spam-Level: X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[AWL=1.105, BAYES_00=-2.599, GB_I_LETTER=-2, 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 ZVyS42h+rAOl for ; Wed, 7 Sep 2011 04:23:33 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 192E621F8B38 for ; Wed, 7 Sep 2011 04:23:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 08DC9D9308; Wed, 7 Sep 2011 13:25:15 +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 6shMwE3nmd00; Wed, 7 Sep 2011 13:25:14 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (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 9B008D9304; Wed, 7 Sep 2011 13:25:13 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4E662259.2000708@cisco.com> Date: Wed, 7 Sep 2011 13:25:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <40D39AEE-0F7B-40F4-9544-EEE59A01E747@tik.ee.ethz.ch> References: <4E558AE2.9000308@auckland.ac.nz> <4E65246F.5070406@cisco.com> <4E662259.2000708@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1084) Cc: Nevil Brownlee , IPFIX Working Group , draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Subject: Re: [IPFIX] Any last comments on draft-ietf-ipfix-flow-selection-tech-07 ??? 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, 07 Sep 2011 11:23:37 -0000 Greetings, all, On review of Benoit's and Paul's comments, I would like to reiterate = that my review primarily concerned the diffs between -06 and -07, and = whether those addressed the pending last call comments, and was not an = extensive review. On reading the comments of Paul and Benoit, I find = myself in agreement. Therefore, I agree with that the editorial changes suggested by Paul = should be folded into a revised -08. The questions posed by Benoit and = Paul with respect to content should also be answered with the -08 = revision. That said, I refer back to my first LC review of this document of 1 = March 2011 = (http://www.ietf.org/mail-archive/web/ipfix/current/msg05775.html) -- = and I have to say that the draft still falls a bit short of the scope as = I understood it to be at the time it was added to the working group = charter. Specifically (note that these comments are quoted from that = message and refer to the -04 revision of the document): > Third, the selection of flow keys for key-based selection in the = subsections of section 7 seems arbitrary. Specifically, why can't I = select flows based on protocolIdentifier? It is also unclear how to = apply this flow selection system for selecting the set of flows for any = but a very simplistic set of keys. A good example: all flows involving a = given set of networks: "All flows which belong to Organization Foo", = where Foo controls the netblocks 130.229.0.0/16, 199.38.128.0/17, and = 199.57.198.0/23. Also, keep in mind that _any_ IE, basically, may be a = Flow Key field. What if I only want to select 3-packet TCP flows (i.e., = zero content complete handshakes)? >=20 > I would submit that this case -- arbitrary key space subsets -- must = be handled by any flow selection draft that comes out of the WG; it's = fairly common especially at the mediator level. If, instead, the scope = of this document really is intended only to handle flow sampling use = cases for resource constraint avoidance, that is certainly useful, but I = would suggest in that case that it should be made Informational, and = that an updated working group charter reflect a need to handle = generalized flow selection in a separate document. The state of the document today does acknowledge all these potential = corner cases (mainly through "flow property match filtering"), but as = noted by Paul provides no specification of a method for configuring this = property match filtering, or reporting anything about it other than flow = counts. I don't really blame the authors of the document for this: it is = a very hard problem, and somewhat out of scope from the original work = they intended to bring into the working group. But we do seem to be far = from WG consensus on whether this document fits the charter. I think, given this, that we may want to consider Paul's suggestion and, = in the upcoming recharter, change the intended status of this document = to Informational, and reduce its scope to more or less the present scope = of the document. Best regards, Brian On Sep 6, 2011, at 3:38 PM, Benoit Claise wrote: > Dear all, >=20 > After speaking with Paul, I reviewed this draft. > Next to Paul's comments below, I have some more. See in line. >=20 > I have a couple of important concerns: > - the lack of integration with the other mediation related RFC & = drafts > * for the terminology (example: Flow Selection Process is used = instead of the Intermediate Flow Selection Process) > * for the figure > - I just took one example "Random Flow Sampling" and looked at what I = should implement to be compliant. And I don't know the answer, and there = is not a single example. > If I compare with the PSAMP protocol specification for Random (packet) = sampling, http://tools.ietf.org/html/rfc5476#section-6.5.2.3, this is = clear. >=20 > Therefore, I haven't read the entire draft, as there were blocking = factors already. >=20 > Regards, Benoit. >=20 >> Nevil, All, >>=20 >>> There hasn't been any comment on the selection draft for nearly a >>> month - as long as I don't hear any by next Monday, I'll declare >>> its WG Last Call finished and send its write-up to Dan. >>=20 >> Sorry for the late response. >>=20 >> Please find many comments inline. I'd like to see a new version of = this draft. >>=20 >> Thanks, >> P. >>=20 >>=20 >>>=20 >>> Internet Engineering Task Force S. = D'Antonio >>> Internet-Draft University of = Napoli >>> Intended status: Standards Track = "Parthenope" >>> Expires: January 12, 2012 T. = Zseby >>> Fraunhofer Institute = FOKUS >>> C. = Henke >>> Technische Universitat = Berlin >>> L. = Peluso >>> University of = Napoli >>> July 11, = 2011 >>>=20 >>>=20 >>> Flow Selection Techniques >>> draft-ietf-ipfix-flow-selection-tech-07.txt >>>=20 >>> Abstract >>>=20 >>> Flow selection is the process of selecting a subset of flows from = all >>> flows observed at an observation point. Flow selection reduces = the >>=20 >> Is just one OP allowed, or can they be observed at multiple = observation points? >> eg, consider flow selection in a mediation device. > Right. > "a subset from all flows observed at an observation point, into a = cache, or in mediatior" >>=20 >>=20 >>> effort of post-processing flow data and transferring Flow = Records. > Capitalization in the abstract? >>> This document describes motivations for flow selection and = presents >>> flow selection techniques. It provides an information model for >>> configuring flow selection techniques and discusses what = information >>> about a flow selection process should be exported. >>>=20 >>> Requirements Language >>>=20 >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this >>> document are to be interpreted as described in RFC 2119 = [RFC2119]. >>>=20 >>> Status of this Memo >>>=20 >>> This Internet-Draft is submitted in full conformance with the >>> provisions of BCP 78 and BCP 79. >>>=20 >>> Internet-Drafts are working documents of the Internet Engineering >>> Task Force (IETF). Note that other groups may also distribute >>> working documents as Internet-Drafts. The list of current = Internet- >>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>>=20 >>> Internet-Drafts are draft documents valid for a maximum of six = months >>> and may be updated, replaced, or obsoleted by other documents at = any >>> time. It is inappropriate to use Internet-Drafts as reference >>> material or to cite them other than as "work in progress." >>>=20 >>> This Internet-Draft will expire on January 12, 2012. >>>=20 >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 = [Page 1] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> Copyright Notice >>>=20 >>> Copyright (c) 2011 IETF Trust and the persons identified as the >>> document authors. All rights reserved. >>>=20 >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> (http://trustee.ietf.org/license-info) in effect on the date of >>> publication of this document. Please review these documents >>> carefully, as they describe your rights and restrictions with = respect >>> to this document. Code Components extracted from this document = must >>> include Simplified BSD License text as described in Section 4.e = of >>> the Trust Legal Provisions and are provided without warranty as >>> described in the Simplified BSD License. >>>=20 >>> This document may contain material from IETF Documents or IETF >>> Contributions published or made publicly available before = November >>> 10, 2008. The person(s) controlling the copyright in some of = this >>> material may not have granted the IETF Trust the right to allow >>> modifications of such material outside the IETF Standards = Process. >>> Without obtaining an adequate license from the person(s) = controlling >>> the copyright in such materials, this document may not be = modified >>> outside the IETF Standards Process, and derivative works of it = may >>> not be created outside the IETF Standards Process, except to = format >>> it for publication as an RFC or to translate it into languages = other >>> than English. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 = [Page 2] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> Table of Contents >>>=20 >>> 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . = . 4 >>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . = . 4 >>> 3. Difference between Flow Selection and Packet Selection . . . = . 7 >>> 4. Flow selection as a Function in the IPFIX Architecture . . . = . 8 >>> 4.1. Flow selection during the Metering Process . . . . . . . = . 10 >>> 4.2. Flow selection during the Exporting Process . . . . . . = . 10 >>> 4.3. Flow selection as a function of the IPFIX Mediator . . . = . 10 >>> 5. Flow Selection Techniques . . . . . . . . . . . . . . . . . = . 11 >>> 5.1. Flow Filtering . . . . . . . . . . . . . . . . . . . . . = . 11 >>> 5.1.1. Property Match Filtering . . . . . . . . . . . . . . = . 11 >>> 5.1.2. Hash-based Flow Filtering . . . . . . . . . . . . . = . 11 >>> 5.2. Flow Sampling . . . . . . . . . . . . . . . . . . . . . = . 12 >>> 5.2.1. Systematic sampling . . . . . . . . . . . . . . . . = . 12 >>> 5.2.2. Random sampling . . . . . . . . . . . . . . . . . . = . 12 >>> 5.3. Flow-state Dependent Flow Selection . . . . . . . . . . = . 13 >>> 5.4. Flow-state Dependent Packet Selection . . . . . . . . . = . 13 >>> 6. Configuration of Flow Selection Techniques . . . . . . . . . = . 14 >>> 6.1. Description of Flow Selection Techniques . . . . . . . . = . 15 >>> 6.2. Description of Flow-state Dependent Packet Selection . . = . 17 >>> 7. Information Model for Flow Selection Reporting . . . . . . . = . 17 >>> 7.1. fsFlowRecordTotalCount . . . . . . . . . . . . . . . . . = . 18 >>> 7.2. fsFlowRecordSelectedCount . . . . . . . . . . . . . . . = . 19 >>> 7.3. fsPacketTotalCount . . . . . . . . . . . . . . . . . . . = . 19 >>> 7.4. fsPacketSelectedCount . . . . . . . . . . . . . . . . . = . 19 >>> 7.5. fsOctetTotalCount . . . . . . . . . . . . . . . . . . . = . 19 >>> 7.6. fsOctetSelectedCount . . . . . . . . . . . . . . . . . . = . 20 >>> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . = . 20 >>> 9. Security Considerations . . . . . . . . . . . . . . . . . . = . 20 >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . = . 21 >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . = . 21 >>> 10.2. Informative References . . . . . . . . . . . . . . . . . = . 21 >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . = . 22 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 = [Page 3] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> 1. Scope >>>=20 >>> This document describes flow selection techniques for network = traffic >>> measurements. A flow is defined as a set of packets with common >>> properties as described in [RFC5101]. Flow selection can be done = to >>> limit the resource demands for capturing, storing, exporting and >>> post-processing of Flow Records. It also can be used to select a >>> particular set of flows that are of interest to a specific >>> application.=20 > This is where you should expand on the different cases: > 1. selected flows observed at an observation point, > 2. selected flow from a cache, > 3 .selected flow in a mediator >>> This document provides a categorization of flow >>> selection techniques and describes configuration and reporting >>> parameters for them. In order to be compliant with this = document, at >>> least one of the flow selection schemes MUST be implemented. = That >>> means that the configuration parameters as well as the reporting >>> Information Elements for this particular scheme MUST be = supported. >>>=20 >>> This document also addresses configuration and reporting = parameters >>> for flow-state dependent packet selection as described in = [RFC5475], >>> although this technique is categorized as packet selection. The >>> reason is, that flow-state dependent packet selection techniques >>> often aim at the reduction of resources for flow capturing and = flow >>> processing. Furthermore, they were only briefly discussed in >>> [RFC5475]. Therefore we included configuration and reporting >>> considerations for such techniques in this document. >>>=20 > Please add section such as = http://tools.ietf.org/html/rfc6235#section-1.2, to be consistent between = all the different mediation drafts. > Note: this should be done as for = http://tools.ietf.org/html/draft-trammell-ipfix-a9n-03 >>>=20 >>> 2. Terminology >>>=20 >>> This document is consistent with the terminology introduced in >>> [RFC5101], [RFC5470], [RFC5475] and [RFC3917].=20 > Please mention which terms are used in this draft. > For example, when I read the definition of Packet Aggregation Process = or Flow Selection Process, I was wondering they were not similar to = terms defined in other RFCs >>> As in [RFC5101] and >>> [RFC5476], the first letter of each IPFIX-specific and = PSAMP-specific >>> term is capitalized along with the flow selection specific terms >>> defined here. > I hope the terminology is also in line with = http://tools.ietf.org/html/rfc6183 and = http://tools.ietf.org/html/rfc5982 > If this is the case, please mention it. >>>=20 >>> * Packet Classification >>>=20 >>> Packet Classification is a process by which packets are mapped = to >>> specific Flow Records based on packet properties or external >>> properties (e.g. interface). The properties make up the Flow = Key >>> (e.g. header information, packet content, AS number). In case = a >>=20 >> "The properties (e.g. header information, packet content, AS number) = make up the Flow Key." >>=20 >>=20 >>> Flow Record for a specific Flow Key already exists the Flow = Record >>> is updated, otherwise a new Flow Record is created. > How is this different from the IPFIX Metering Process? >=20 > * Metering Process >=20 > The Metering Process generates Flow Records. Inputs to the > process are packet headers and characteristics observed at an > Observation Point, and packet treatment at the Observation Point > (for example, the selected output interface). >=20 > The Metering Process consists of a set of functions that includes > packet header capturing, timestamping, sampling, classifying, and > maintaining Flow Records. >=20 > The maintenance of Flow Records may include creating new records, > updating existing ones, computing Flow statistics, deriving > further Flow properties, detecting Flow expiration, passing Flow > Records to the Exporting Process, and deleting Flow Records. >=20 >=20 >>>=20 >>> * Packet Aggregation Process >>>=20 >>> In the IPFIX Metering Process the Packet Aggregation Process >>> aggregates packet data into flow data and forms the Flow = Records. >>> After the aggregation step only the aggregated flow = information is >>> available. Information about individual packets is lost. > What is packet data? > Again, how is this different from the Metering Process? >=20 >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 = [Page 4] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> * Flow Selection Process >>>=20 >>> A Flow Selection Process takes Flow Records as its input and >>> selects a subset of this set as its output. A Flow Selection >>> Process MAY run on several instances within the IPFIX >>=20 >> s/on several instances/in several places/ >>=20 >>=20 >>> architecture. A Flow Selection Process MAY be part of an = IPFIX >>> Metering Process, Exporting Process or as an Intermediate >>> Selection Process as defined for the IPFIX Mediator [RFC6183]. > I really confused by "A Flow Selection Process MAY be part of ... an = Intermediate > Selection Process as defined for the IPFIX Mediator [RFC6183]." > Why don't you reuse the >=20 > Intermediate Selection Process >=20 > An Intermediate Selection Process is an Intermediate Process that > selects records from a sequence based upon criteria-evaluated > record values and passes only those records that match the > criteria (e.g., filtering only records from a given network to a > given Collector). >=20 > Your Flow Selection Process term should be replaced by the = Intermediate Selection Process. >>>=20 >>> * Flow Selection State >>>=20 >>> A Flow Selection Process SHOULD maintain state information for = use > It's the second time that I see RFC 2119 keywords in definition. > If I recall correctly, this is not welcome. >>> by the Flow Selector. At a given time, the Flow Selection = State >>> may depend on flows and packets observed at and before that = time, >>> as well as other variables. Examples include: >>>=20 >>> (i) sequence number of packets and accounted Flow Records; >>>=20 >>> (ii) number of selected flows; >>>=20 >>> (iii) number of observed flows; >>>=20 >>> (iv) current flow cache occupancy; >>>=20 >>> (v) flow specific counters, lower und upper bounds >>=20 >> s/und/and/ >>=20 >>=20 >>> (vi) flow selection timeout intervals >>=20 >> Some of the list items end with ";" while others do not. >>=20 >>=20 >>> * Flow Selector >>>=20 >>> A Flow Selector defines the action of a Flow Selection Process = on >>> a single flow of its input. The Flow Selector can make use of = the >>> following information in order to establish whether a flow has = to >>> be selected or not: > I'm confused by the "on a single flow". > If I do flow based random sampling, do I use a Flow Selector? I mean, = I will look at all the flows in the caches, not individual flows >>>=20 >>> (i) the content of the Flow Record; >>>=20 >>> (ii) any state information related to the Metering Process = or >>> Exporting Process; >>>=20 >>> (iii) any Flow Selection State that may be maintained by the >>> Flow Selection Process. >>>=20 >>> * Complete Flow >>>=20 >>> A Complete Flow consists of all packets within the flow = time-out >>> interval that enter the Flow Selection Process and belong to = the >>=20 >> "A Complete Flow consists of all the packets that enter the >> Flow Selection Process within the flow time-out interval, and which = belong to the ..." >>=20 >>=20 >>> same flow as defined by the flow definition in [RFC5470]. For >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 = [Page 5] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> this definition only packets that arrive at the Flow Selection >>> Process are considered. That means, packets that are not = observed >>> at the Flow Selection Process because of prior packet = selection or >>> packet loss are not considered as belonging to the Complete = Flow. >>>=20 >>> * Flow Filtering >>>=20 >>> Flow Filtering selects flows based on a deterministic function = on >>> the Flow Record content, flow state, external properties (e.g. >>=20 >> Does "flow state" mean "flow selection state"? >> ie referring to the list just above, is it (ii), (iii), or both? >>=20 >>=20 >>> ingress interface) or external events (e.g violated Access = Control >>> List). If the relevant parts of the Flow Record content can = be >>> already observed at packet level (e.g. Flow Keys from packet >>=20 >> s/can be already/can already be/ >>=20 >>=20 >>> header fields) Flow Filtering can be performed at packet level = by >>> Property Match Filtering as described in [RFC5475]. >>>=20 >>> * Hash-based Flow Filtering >>>=20 >>> Hash-based Flow Filtering is a deterministic flow filter = function >>> that selects flows based on a Hash Function which is = calculated >>> over parts of the Flow Record content or external properties. = If >>> the hash value falls into a predefined Hash Selection Range = the >>> flow is selected. >>=20 >> Is there a way to control which fields from the Flow Record go in to = the hash? >>=20 >> Else, if two devices implement the same hash, are fed the same = packets, and implement the same flow records - except that the fields = are in a different order - then they may produce different output. >>=20 >>=20 >>> * Flow-state Dependent Flow Selection >>>=20 >>> Flow-state Dependent Flow Selection is a selection function = that >>> selects or drops flows based on the current flow state. The >>> selection can be either deterministic, random or non-uniform >>> random. >>=20 >> Again, please clarify exactly what the flow state is. It seems worth = defining the "Flow-state" term. >>=20 >> eg, one could assume flow state =3D active, expired, exported... >>=20 >>=20 >>> * Flow-state Dependent Packet Selection >>>=20 >>> Flow-state Dependent Packet Selection is a selection function = that >>> selects or drops packets based on the current flow state. The >>> selection can be either deterministic, random or non-uniform >>> random. Flow-state Dependent Packet Selection can be used to >>> prefer the selection of packets belonging to specific flows = (e.g. >>> large or small flows). >>=20 >> Are those real examples? Surely preferring packets for small flows = gives lots of details without giving the big picture and may quickly = fill the cache (not withstanding that everything starts as a small flow = anyway...), while preferring packets for large flows may grow whatever = flows are initially observed into "large" flows while discarding = individual packets which would eventually make a truely "large" flow. >>=20 >> Unless this is something you want to develop, I'd just remove the = "(e.g. ...)" section. >>=20 >> [Later] I see that you mention "large" flows several times. Does this = require foreknowledge of what may constitute a large flow? Else, how can = you correctly select packets which pertain to the "large" flows? >>=20 >>=20 >>> * Flow Sampling >>>=20 >>> Flow Sampling selects flows based on Flow Record sequence or >>> arrival times (e.g. entry in flow cache, arrival time at = Exporter >>> or Mediator). The selection can be systematic (e.g. every = n-th >>> flow) or based on a random function (e.g. select each Flow = Record >>> with probability p, or randomly select n out of N Flow = Records). >>=20 >> I'm hoping that a discussion of the pros and cons of each method and = recommendations as to when to use each method will follow. >>=20 >> [Later] It may be worth saying "Discussion of these methods appears = in section 5 below". >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 = [Page 6] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> 3. Difference between Flow Selection and Packet Selection >>>=20 >>> Flow selection differs from packet selection described in = [RFC5475]. >>=20 >> This seems obvious. >>=20 >>=20 >>> Packet selection techniques consider packets as basic element and = the >>=20 >> "as *the" basic element" ? >>=20 >>=20 >>> parent population consists of all packets observed at an = observation >>> point. In contrast to this the basic elements in flow selection = are >>=20 >> Just one observation point? Therefore the techniques can't be used = when traffic has been aggregated from multiple OPs? >>=20 >>=20 >>> the flows. The parent population consists of all observed flows = and >>> the selection process operates on the flows. The major >>> characteristics of flow selection are the following: >>>=20 >>> - Flow selection takes flows as basic elements. For packet >>> selection, packets are considered as basic elements. >>>=20 >>> - Flow selection can only take place after Packet >>> Classification, because the classification rules = determine to >>> which flow a packet belongs. Packet selection can be = applied >>> before and after Packet Classification. >>>=20 >>> - Flow selection operates on Complete Flows. That means = that >>> after the Flow Selection Process either all packets of = the >>> flow are kept or all packets of the flow are discarded. = All >>=20 >> When you say "flow" here, I think you mean "Complete Flow". >> So consider, "either the complete flow is kept or the complete flow = is discarded". >>=20 >>=20 >>> packets of the flow here means all packets that enter the >>> Flow Selection Process. That means that if the flow >>=20 >> Packets don't enter the flow selection process, since the flow = selection process operates on complete flows (per the definition above). >>=20 >>=20 >>> selection is preceded by a packet selection process the >>> Complete Flow consists only of the packets that were not >>> discarded during the packet selection. >>>=20 >>> There are some techniques that are difficult to unambiguously >>> categorize into one of the categories. Here we give some = guidance >>> how to categorize such techniques: >>>=20 >>> - Techniques that can be considered as both packet and flow >>> selection: some packet selection techniques result in the >>> selection of Complete Flows and therefore can be = considered >>> as packet or as flow selection at the same time. An = example >>> is Property Match Filtering of all packets to a specific >>> destination address. If flows are defined based on >>> destination addresses, such a packet selection also = results >>> in a flow selection and can be considered as packet or = flow >>> selection. >>>=20 >>> - Flow-state Dependent Packet Selection (as described in >>> [RFC5475]): there exist techniques that select packets = based >>=20 >> s/there exist technique/techniques exist/ >>=20 >>=20 >>> on the flow state, e.g. based on the number of already >>> observed packets belonging to the flow. Examples of = these >>> techniques from the literature are "Sample and Hold" = [EsVa01] >>> "Fast Filtered Sampling" [MSZC10] or the "Sticky = Sampling" >>> algorithm presented in [MaMo02]. Such techniques can be = used >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 = [Page 7] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> to influence which flows are captured (e.g. increase the >>> selection of packets belonging to large flows) and reduce = the >>> number of flows that need to be stored in the flow cache. >>> Nevertheless, such techniques do not necessarily select >>> Complete Flows, because they do not ensure that all = packets >>> of a selected flow are captured. Therefore Flow-state >>> Dependent Packet Selection methods that do not ensure = that >>> either all or no packets of a flow are selected strictly >>> speaking have to be considered as packet selection = techniques >>> and not as flow selection techniques. >>>=20 >>>=20 >>> 4. Flow selection as a Function in the IPFIX Architecture >>>=20 >>> Figure 1 shows the IPFIX reference model as defined in [RFC5470] = and >>> shows the Packet Classification and Packet Aggregation Process in = the >>> Metering Process. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 = [Page 8] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> Packet(s) coming in to Observation Point(s) >>> | | >>> v v >>> +----------------+---------------------------+ = +-----+-------+ >>> | Metering Process | | = | >>> | | | = | >>> | packet header capturing | | = | >>> | | |...| Metering = | >>> | timestamping | | Process N = | >>> | | | | = | >>> | packet sampling | | = | >>> | | | | = | >>> | (packet classification) | | = | >>=20 >> The bounding boxes need to be fixed. >>=20 >>=20 >>> | | | | = | >>> | packet filtering* | | = | >>> | | | | = | >>> | (packet aggregation)* | | = | >>> | | | | = | >>> +--------|-----------------------------------+ = +-----|-------+ >>> Flow Records Flow = Records >>> | | >>> +----------------------+----------------------+ >>> | >>> +----------------------|-----------------+ >>> | Exporting Process* | >>> +----------------------+-----------------+ >>> | IPFIX (Flow Records) >>> v >>> +-------------------------|-----------------------+ >>> | IPFIX Mediator | | >>> | v | >>> | Collecting Process(es) | >>> | | | >>> | Intermediate Flow Selection Process (*) | >>> | | | >>> | Exporting Process(es) | >>=20 >> Flow selection is possible in this EP too. >> eg, after the IFSP, the EP may need to perform selection to throttle = the export bandwith. > In other words, we could have a IPFIX Mediation on the Original = Exporter. > Using a * to "indicate where flow selection can take place." is = confusing >>=20 >>=20 >>> +-------------------------|-----------------------+ >>> v >>> IPFIX >>>=20 >>> (*) indicates where flow selection can take place. > There is a big confusion between packet and flow. > A flow selection happens where there are flows, and you mention that = flow selection can take place in "packet filtering", "packet = aggregation". It doesn't make sense. > This figure should be redrawn according to the figure A at = http://tools.ietf.org/html/rfc6183#section-4, with Intermediate Flow = Selection Process >>>=20 >>> Figure 1: Flow selection in the IPFIX Architecture >=20 >>>=20 >>> In contrast to packet selection, flow selection is always applied >>> after the packets are classified into flows.=20 > Exactly. See my previous remark >>> Flows can be selected >>> at different stages of the measurement chain: >>>=20 >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 = [Page 9] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> 1. during the Metering Process >>>=20 >>> 2. during Exporting Process >>>=20 >>> 3. during an Intermediate Selection Process on a Mediator >>>=20 >>> 4.1. Flow selection during the Metering Process >>>=20 >>> In the Packet Aggregation Process the packet information is used = to >>> update the Flow Records in the flow cache. Flow selection that = is >>> applied before aggregation equals a packet selection process. = The >>> flow still consists of individual packets. Those are then = selected >>> based on the classification information, i.e. based on the flow = they >>> belong to. Flow selection before aggregation can be based on the >>> fields of the Flow Key (also on a hash value over these fields), = but >>=20 >> So the hash cannot be on non-key fields? I didn't see that specified = anywhere. >>=20 >>=20 >>> not based on characteristics that are only available after packet >>> aggregation (e.g. flow size, flow duration). Flow selection = during >>> the Metering Process is applied to reduce resources for all >>> succeeding processes or to select specific flows of interest in = case >>> such flow characteristics are already observable at packet level >>> (e.g. flows to specific IP addresses). In contrast, Flow-state >>> Dependent Packet Selection is a packet selection method, because = it >>> does not necessarily select Complete Flows. >>>=20 >>> 4.2. Flow selection during the Exporting Process >>>=20 >>> The Flow Selection Process at the Exporter is similar to an >>> Intermediate Selection Process as described in [RFC6183] and = works on >>> Flow records. Flow selection during the Exporting Process can >>> therefore also depend on flow characteristics that are only = visible >>> after the aggregation of packets, such as flow size and flow >>> duration. The Exporting Process may implement policies for = exporting >>> only a subset of the Flow Records which have been stored in the >>> system memory in order to unload flow export and flow = postprocessing. >>=20 >> Consider "post-processing". >>=20 >>=20 >>> Flow selection during the Exporting Process may select only the >>> subset of Flow Records which are of interest to the users >>> application, or select only as many Flow Records as can be = handled by >>> the available resources (e.g. limited flow cache size and export = link >>> capacity). >>=20 >> Surely flow cache size would be of interest at the metering process = rather than at the exporting process? >>=20 >>=20 >>> 4.3. Flow selection as a function of the IPFIX Mediator >>>=20 >>> As shown in Figure 1, flow selection can be performed as an >>> Intermediate Process within an IPFIX Mediator [RFC6183]. The >>> Intermediate Selection Process takes Flow Record stream as its = input >>> and selects a flow record stream. The Intermediate Selection = Process >>> can again apply a flow selection technique to obtain flows of >>> interest to the application. Further the Intermediate Selection >>=20 >> "Further," >>=20 >>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 [Page = 10] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> Process can base its selection decision on the correlation of = data >>> from different observation points, e.g. by only selecting flows = that >>> were at least recorded on two observation points. >>=20 >> So earlier discussion of "an Observation Point" wasn't exclusive? = Good. >>=20 >>=20 >>>=20 >>> 5. Flow Selection Techniques >>>=20 >>> A flow selection technique selects either all or none of the = packets >>> of a flow, otherwise the technique has to be considered as packet >>> selection. We distinguish between Flow Filtering and Flow = Sampling. >>=20 >> This is such a simple definition, I wish it had been said earlier! >>=20 >>=20 >>> 5.1. Flow Filtering >>>=20 >>> Flow Filtering is a deterministic function on the IPFIX Flow = Record >>> content. In case that the relevant flow characteristics are = already >>=20 >> s/In case that/If/ >>=20 >>=20 >>> observable at packet level (e.g. Flow Keys) Flow Filtering can = be >>=20 >> Add a comma after the ")". >>=20 >>=20 >>> applied before aggregation at packet level. >>>=20 >>> 5.1.1. Property Match Filtering >>>=20 >>> Flow Filtering can be done similarly to Property Match Filtering = for >>=20 >> s/done/performed/ ? >>=20 >>=20 >>> packet selection described in [RFC5475]. The difference is that, >>> instead of packet fields, Flow Record fields are here used to = derive >>> the selection decision. Property Match Filtering is typically = used >>> to select a specific subset of the flows that are of interest to = a >>> particular application (e.g. all flows to a specific destination, = all >>> large flows, etc.). Properties on which the filtering is based = can >>> be for example Flow Keys, the flow size in bytes, the number of >>> packets in the flow, the observation time of the first or last >>> packet, or the maximum packet length. The selection criteria can = be >>> a specific value or an interval. Property Match Filtering can be >>> applied during the Metering Process if the properties are already >>> observable at the packet level (e.g. Flow Key fields). >>>=20 >>> There are content-based Property Match Filtering techniques that >>> require a computation on the current flow cache. An example is = the >>> selection of the k largest flows or a percentage of flows with = the >>=20 >> Although I'm sure you intend 'k' as a variable, it looks like a typo. >>=20 >> Can't it just be "N" - or just not named at all since it's not used = below? >>=20 >>=20 >>> longest lifetime. This type of Property Match Filtering is also = used >>> in flow selection techniques that react to external events (e.g. >>> resource constraint). For example in case the flow cache is = full, >>=20 >> s/in case/when/ >>=20 >>=20 >>> the Flow Record with the lowest flow volume per current flow life >>> time is deleted. >>=20 >> s/is/may be/ >>=20 >> (=46rom an implementation point of view, I wouldn't do this since = "per" involves division which I don't have time for when the cache is = full...) >>=20 >>=20 >>> 5.1.2. Hash-based Flow Filtering >>>=20 >>> Hash-based Flow Filtering uses a Hash Function h to map the Flow = Key >>> c onto a Hash Range R. A flow is selected if the hash value h(c) = is >>> within the Hash Selection Range S, which is a subset of R. = Hash-based >>=20 >> Do it like 'h', 'c', 'R' and 'S' so it doesn't look like typos. >>=20 >>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 [Page = 11] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> Flow Filtering can be used to emulate a random sampling process = but >>> still enable the correlation between selected flow subset at >>=20 >> "subsets"? >>=20 >>=20 >>> different observation points. Hash-based Flow Filtering is = similar >>> to Hash-based Packet Selection, and in fact is identical when = Hash- >>> based Packet Selection uses the Flow Key that defines the flow as = the >>> hash input. Nevertheless there MAY be the incentive to apply = Hash- >>> based Flow Filtering not on the packet level during the Metering >>> Process, for example when the size of the selection range and >>> therefore the sampling probability is dependent on the number of >>> observed flows. >>>=20 >>> 5.2. Flow Sampling >>>=20 >>> Flow Sampling operates on Flow Record sequence or arrival times. = It >>> can use either a systematic or a random function for the = selection >>> process. Flow Sampling usually aims at the selection of a >>> representative subset of all flows in order to estimate >>> characteristics of the whole set (e.g. mean flow size in the >>> network). >>>=20 >>> 5.2.1. Systematic sampling >>>=20 >>> Systematic sampling is a deterministic selection function. >>> Systematic sampling may be a periodic selection of the k-th Flow >>=20 >> Why k-th? In my experience, most engineers understand "Nth". >>=20 >>=20 >>> Record which arrives at the Exporting or Intermediate Selection >>> Process. Systematic sampling can also be applied during the = Metering >>> Process. An example would be to use an additional data structure >>> that saves the Flow Keys of the non-selected flows. >>=20 >> I don't follow the example, because a regular MP doesn't meter flows; = it meters packets - so this would be systematic *packet* sampling rather = than systematic *flow* sampling. >>=20 >> Also, the example sounds like a filter: flows f were sampled, while = flows f' were not. >>=20 >>=20 >>> Systematic sampling can also be time-based. Systematic sampling = is >>=20 >> s/Systematic sampling/Time based systematic sampling/ >>=20 >>=20 >>> applied by only creating flows that are observed between = time-based >>> start and stop triggers. The time interval may be applied at = packet >>> level during the Metering Process or after aggregation on flow = level, >>> e.g. by selecting a flow arriving at the Exporting Process every = k >>> seconds. >>>=20 >>> 5.2.2. Random sampling >>>=20 >>> Random flow sampling is based on a random process which requires = the >>> calculation of random numbers. One can differentiate between = n-out-N >>=20 >> Random numbers are required for random sampling? This seems... = obvious. >>=20 >>=20 >>> and probabilistic flow sampling. The sampling probability of >>=20 >> It would bee good to explain the difference between n-out-N and = probabilistic flow sampling. >>=20 >>=20 >>> individual Flows Records MAY be adjusted according to the Flow = Record >>=20 >> s/Flows/Flow/ >>=20 >>=20 >>> content or external events like the available export resources. = Non- >>=20 >> If the sampling rate is adjusted per individual flow record, how do = you propose to report the sampling rate(s) correctly to allow = normalisation and the correct interpretation of the data? >>=20 >>=20 >>> uniform random sampling approaches can be applied similar to the = ones >>> defined in [RFC5475]. An example would be to increase the = selection >>> probability of large volume flows over small volume flows as >>> described in the Smart Sampling technique [DuLT01]. Random flow >>> sampling can also be applied before the Packet Aggregation = Process >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 [Page = 12] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> when additional flow state about non selected flows is kept. >>=20 >> Why keep info about non-selected flows? What will be done with it? If = the point of selection is to get rid of uninteresting flows, keeping the = stuff that wasn't selected is just wasteful. >>=20 >>=20 >>> 5.3. Flow-state Dependent Flow Selection >>>=20 >>> Flow-state Dependent Flow Selection can be a deterministic or = random >>> flow selection process based on the Flow Record content and the = flow >>> state which may be kept additionally for each of the flows. = External >>> processes may update counters, bounds and timers for each of the = Flow >>> Records and the Flow Selection Process utilises this information = for >>> the selection decision. A review of Flow-state Dependent Flow >>> Selection techniques that aim at the selection of the most = frequent >>> items by keeping additional flow state information can be found = in >>> [CoHa08]. Flow-state Dependent Flow Selection can only be = applied >>> after packet aggregation, when a packet has been assigned to a = flow. >>> The selection process then decides based upon the flow state for = each >>> flow if it is kept in the flow cache or not. Two Flow State >>> Dependent Flow Selection are here described: >>=20 >> s/Selection are/Selection algorithms are/ >>=20 >>=20 >>> The frequent algorithm [KaPS03] is a technique that aims at the >>> selection of all flows that at least exceed a 1/k fraction of the >>> observed packet stream. The algorithm has only a flow cache of = size >>=20 >> OPS should be capitalised per RFC5476. >>=20 >>=20 >>> k-1 and each flow in the cache has an additional counter. The >>> counter is incremented each time a packet belonging to the flow = in >>> the flow cache is observed. In case the observed packet does not >>> belong to any flow all counters are decremented and if any of the >>> flow counters has a value of zero the flow is replaced with a = flow >>> formed from the new packet. >>>=20 >>> Lossy counting is a selection technique that identifies all flows >>> whose packet count exceeds a certain percentage of the whole = observed >>> packet stream (e.g. 5% of all packets) with a certain estimation >>> error e. Lossy counting separates the observed packet stream in >>=20 >> 'e' >>=20 >>=20 >>> windows of size N=3D1/e, where N is an amount of consecutive = packets. >>> For each observed flow an additional counter will be held in the = flow >>> state. The counter is incremented each time a packet belonging = to >>> the flow is observed and all counters are decremented at the end = of >>> each window and all flows with a counter of zero will be removed = from >>> the flow cache. >>=20 >> s/will be/are/ >>=20 >>=20 >>> 5.4. Flow-state Dependent Packet Selection >>>=20 >>> Flow-state Dependent Packet Selection is not a flow selection >>> technique but a packet selection technique. Nevertheless we will >>> describe configuration and reporting parameters for this = technique in >>> this document. An example is the "Sample and Hold" algorithm >>> [EsVa01] that tries to prefer large volume flows in the = selection. >>> When a packet arrives it is selected when a Flow Record for this >>> packet already exists. In case there is no Flow Record, the = packet >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 [Page = 13] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> is selected by a certain probability that is dependent on the = packet >>> size. >>>=20 >>>=20 >>> 6. Configuration of Flow Selection Techniques >>>=20 >>> This section describes the configuration parameters of the flow >>> selection techniques presented above. It provides the basis of = an >>> information model to be adopted in order to configure the Flow >>> Selection Process within an IPFIX Device. The following table = gives >>> an overview of the defined selection techniques, where they can = be >>> applied and what their input parameters are. Dependent on where = the >>> flow selection techniques are applied different input parameters = can >>> be configured. >>>=20 >>> Overview of Flow Selection Techniques: >>>=20 >>> = +------------------+-----------------+------------------------------+ >>> | Location | Selection | Selection Input = | >>> | | Method | = | >>> = +------------------+-----------------+------------------------------+ >>> | During the | Flow-state | packet sampling = | >>> | Metering Process | Dependent | probabilities, flow state, = | >>> | based on Packets | Packet | packet properties = | >>> | | Selection | = | >>> = +------------------+-----------------+------------------------------+ >>> | | Property Match | Flow Key fields, filter = | >>> | | Flow Filtering | function = | >>> = +------------------+-----------------+------------------------------+ >>> | | Hash-based Flow | selection range, Hash = | >>> | | Filtering | Function, Flow Key = | >>> = +------------------+-----------------+------------------------------+ >>> | | Time-based | flow position (derived = from | >>> | | Systematic Flow | arrival time of packets), = | >>> | | Sampling | flow state = | >>> = +------------------+-----------------+------------------------------+ >>> | | Sequence-based | flow position (derived = from | >>> | | Systematic Flow | packet position), flow = state | >>> | | Sampling | = | >>> = +------------------+-----------------+------------------------------+ >>> | | Random Flow | random number generator or = | >>> | | Sampling | list and packet position, = | >>> | | | flow state = | >>> = +------------------+-----------------+------------------------------+ >>> | Exporting / | Property Match | Flow Record content, = filter | >>> | Intermediate | Flow Filtering | function = | >>> | Selection | | = | >>> | Process | | = | >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 [Page = 14] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> | | Hash-based Flow | selection range, Hash = | >>> | | Filtering | Function, hash input (Flow = | >>> | | | Keys and other flow = | >>> | | | properties) = | >>> = +------------------+-----------------+------------------------------+ >>> | | Flow-state | flow state parameters, = | >>> | | Dependent Flow | random number generator or = | >>> | | Selection | list = | >>> = +------------------+-----------------+------------------------------+ >>> | | Time-based | flow arrival time, flow = | >>> | | Systematic Flow | state = | >>> | | Sampling | = | >>> = +------------------+-----------------+------------------------------+ >>> | | Sequence-based | flow position, flow state = | >>> | | Systematic Flow | = | >>> | | Sampling | = | >>> = +------------------+-----------------+------------------------------+ >>> | | Random Flow | random number generator or = | >>> | | Sampling | list and flow position, = flow | >>> | | | state = | >>> = +------------------+-----------------+------------------------------+ >>>=20 >>> 6.1. Description of Flow Selection Techniques >>>=20 >>> In this section, we define what parameters are required to = describe >>> the most common Flow Selection techniques. >>=20 >> Consider moving this paragraph to the top of section 6. >>=20 >>=20 >>> Flow Selection Parameters: >>>=20 >>=20 >> Flow state dependent packet selection is missing here. >>=20 >> [Later] OK, it's below. See below. >>=20 >>=20 >>> For Property Match Filtering: >>>=20 >>> - Information Element (from [RFC5102]): >>> Specifies the Information Element which is used as the = property >>> in the filter expression. >>=20 >> Can there be more than one IE? >>=20 >> Don't use RFC5102 as the reference, use IANA - since there are now = many more IEs in IANA than in 5102, you're adding an unintentional = limitation. >>=20 >>=20 >>> - Selection Value or Value Interval: >>> Specifies the value or interval of the filter expression. >>> Packets and Flow Record that have a value equal to the = Selection >>> Value or within the Interval will be selected. >>=20 >> Are there other possibilities, eg not-equal, less-than, greater-than, = regexp? >>=20 >> The table above says "Flow Key fields, filter function" (for the = relevant "Selection Input"). Is the text here supposed to align with or = relate to the table in any way? >>=20 >>=20 >>> For Hash-based Flow Filtering: >>>=20 >>> - Hash Domain: >>> Specifies the bits from packet (IPv4 or IPv6) which are taken = as >>=20 >> Why say "IPv4 or IPv6" ? >>=20 >>=20 >>> the hash input to the Hash Function. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 [Page = 15] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> - Hash Function: >>> Specifies the name of the Hash Function that is used to = calculate >>> the hash value. Possible Hash Functions are BOB, IPSX, = CRC-32 >>>=20 >>> - Hash Selection Range: >>> Flows that have a hash value within the Hash Selection Range = are >>> selected. The Hash Selection Range can be a value interval = or >>> arbitrary hash values within the Hash Range of the Hash = Function. >>>=20 >>> - Random Seed or Initializer Value: >>> Some Hash Functions require an initializing value. In order = to >>> make the selection decision more secure one can choose a = random >>> seed that configures the hash function. >>=20 >> Again, the table above says, "selection range, Hash Function, Flow = Key" - so there's some similarity between the text and the table, but = they don't align. >>=20 >>=20 >>> For Flow-state Dependent Flow Selection: >>=20 >> It'd be good to maintain a consistent order of selection methods. >>=20 >>=20 >>> - frequency threshold: >>> Specifies the frequency threshold s for flow state dependent = flow >>=20 >> Is 's' the name of the threshold? It's not an obvious choice and = looks like a typo. >>=20 >> Consider: >>=20 >> Specifies the frequency threshold 's' for flow state >>=20 >> Specifies the frequency threshold, 's', for flow state >>=20 >>=20 >>=20 >>=20 >>> selection techniques that try to find the most frequent items >>> within a dataset. All flows which exceed the defined = threshold >>> will be selected. >>>=20 >>> - accuracy parameter: >>> specifies the accuracy parameter e for techniques that deal = with >>=20 >> Is 'e' a variable? Again, it looks like a typo. >>=20 >>=20 >>> the frequent items problems. The accuracy paramter defines = the >>=20 >> s/paramter/parameter/ >>=20 >>=20 >>> maximum error, i.e. no flows that have a true frequency less = than >>> (s- e) N is selected, where s is the frequency threshold and = N is >>=20 >> "(s - e) N", with equal spacing. >>=20 >>=20 >>> the total number of packets. >>>=20 >>> The above list of parameters for Flow-state Dependent Flow = Selection >>> techniques is suitable for the presented frequent item and lossy >>> counting algorithm. Nevertheless there exist a variety of = techniques >>=20 >> s/there exist a variety of techniques/a variety of techniques exist/ >>=20 >>=20 >>> with very specific parameters which are not defined here. >>>=20 >>> For Systematic time-based Flow Sampling: >>>=20 >>> - Interval length (in usec) >>> Defines the length of the sampling interval during which = flows >>> are selected. >>>=20 >>> - Spacing (in usec) >>> The spacing parameter defines the spacing in usec between the = end >>> of one sampling interval and the start of the next succeeding >>> interval. >>>=20 >>> For Systematic count-based Flow Sampling: >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 [Page = 16] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> - Interval length >>> Defines the number of flows that are selected within the = sampling >>> interval. >>>=20 >>> - Spacing >>> The spacing parameter defines the spacing in number of = observed >>> flows between the end of one sampling interval and the start = of >>> the next succeeding interval. >>=20 >> Can these methods be used together? eg, observe 10 flows, then wait = 10 seconds? >>=20 >>=20 >>> For random n-out-of-N Flow Sampling: >>>=20 >>> - Population Size N >>> The Population Size N is the number of all flows in the >>> Population from which the sample is drawn. >>>=20 >>> - Sample size n >>> The sample size n is the number of flows that are randomly = drawn >>> from the population N. >>>=20 >>> For probabilistic Flow Sampling: >>>=20 >>> - Sampling probability p >>> The sampling probability p defines the probability by which = each >>> of the observed flows is selected. >>=20 >> Again, the same point about N, n and p - it's not immediately clear = that these are variables rather than typos. >> However, since they're not used anywhere, why name them at all? >>=20 >>> 6.2. Description of Flow-state Dependent Packet Selection >>>=20 >>> The configuration of Flow-state Dependent Packet Selection has = not >>> been described in [RFC5475] therefore the parameters are defined >>> here: >>>=20 >>> For Flow-state Dependent Packet Selection: >>>=20 >>> - packet selection probability per possible flow state interval >>> Defines multiple [flow interval, packet selection = probability] >>=20 >> It'd be better to use { } for this, since [ ] usually delineate = citations. >>=20 >>=20 >>> value pairs that configure the sampling probability dependent = on >>> the current flow state. >>>=20 >>> - additional parameters >>> For the configuration of flow state dependent packet = selection >>> additional parameters or packet properties may be required = for >>> the configuration, e.g. the packet size ([EsVa01]) >>>=20 >>>=20 >>> 7. Information Model for Flow Selection Reporting >>>=20 >>> In this section we describe Information Elements (IEs) that = SHOULD be >>> exported by a flow selection process in order to support the >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 [Page = 17] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> interpretation of measurement results from flow measurements = where >>> only some flows are selected. The information is mainly used to >>> report how many packets and flows have been observed in total and = how >>> many of them were selected. This helps for instance to calculate = the >>> Attained Selection Fraction, which is an important parameter to >>=20 >> Insert xref for ASF [RFC5476]. >>=20 >>=20 >>> provide an accuracy statement. The IEs can provide reporting >>> information about Flow Records, packets or bytes. The reported >>> metrics are number of total and the number of selected elements. >>=20 >> s/number of total/total number of elements,/ >>=20 >>=20 >>> =46rom this the number of dropped elements can be derived. All >>=20 >> - provided appropriate total and selected pairs are exported. >>=20 >>=20 >>> counters SHOULD be exported and reset when a new measurement = interval >>> starts. Additional IEs may be useful for future flow selection >>> techniques. Those can be defined additionally if needed. >>>=20 >>> List of additional Flow Selection Information Elements: >>>=20 >>> +------+---------------------------+ >>> | ID | Name | >>> +------+---------------------------+ >>> | TBD1 | fsFlowRecordTotalCount | >>> +------+---------------------------+ >>> | TBD2 | fsFlowRecordSelectedCount | >>> +------+---------------------------+ >>> | TBD3 | fsPacketTotalCount | >>> +------+---------------------------+ >>> | TBD4 | fsPacketSelectedCount | >>> +------+---------------------------+ >>> | TBD5 | fsOctetTotalCount | >>> +------+---------------------------+ >>> | TBD6 | fsOctetSelectedCount | >>> +------+---------------------------+ >>>=20 >>=20 >> Curiously, TBD1, TBD2, TBD7, TBD8, TBD9 and TBD10 are used below. >> Did none of the other reviewers notice this? :-( >>=20 >>=20 >>> 7.1. fsFlowRecordTotalCount >>>=20 >>> Description: >>>=20 >>> This Information Element specifies the current number of all = Flow >>> Records that form the parent population as input to the Flow >>> Selection Process. >>>=20 >>> Abstract Data Type: unsigned64 >>>=20 >>> ElementId: TBD1 >>>=20 >>> Units: Flows >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 [Page = 18] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> 7.2. fsFlowRecordSelectedCount >>>=20 >>> Description: >>>=20 >>> This Information Element specifies the current number of Flow >>> Records that were selected during the Flow Selection Process. >>>=20 >>> Abstract Data Type: unsigned64 >>>=20 >>> ElementId: TBD2 >>>=20 >>> Units: Flows >>>=20 >>> 7.3. fsPacketTotalCount >>>=20 >>> Description: >>>=20 >>> This Information Element specifies the current number of = packets >>> in all flows that form the parent population as input to the = Flow >>> Selection Process. >>>=20 >>> Abstract Data Type: unsigned64 >>=20 >> NB u64 might not be sufficient for this. See below. >>=20 >>=20 >>> ElementId: TBD7 >>=20 >> This is TBD3 in the list above. >>=20 >>=20 >>> Units: Packets >>>=20 >>> 7.4. fsPacketSelectedCount >>>=20 >>> Description: >>>=20 >>> This Information Element specifies the current number packets = in >>> all flows that were selected during the Flow Selection = Process. >>>=20 >>> Abstract Data Type: unsigned64 >>>=20 >>> ElementId: TBD8 >>=20 >> This is TBD4. You get the idea. >>=20 >>=20 >>> Units: Packets >>>=20 >>> 7.5. fsOctetTotalCount >>>=20 >>> Description: >>>=20 >>> This Information Element specifies the current number of all = bytes >>> in all flows that form the parent population as input to the = Flow >>> Selection Process. >>>=20 >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 [Page = 19] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> Abstract Data Type: unsigned64 >>=20 >> NB u64 may be insufficient for this since all bytes in all flows =3D = all traffic entering the selection process. >>=20 >> eg, monitoring 1000 x 10g interfaces, this allows for < 2^24 seconds = of traffic, which is about 170 days. Perhaps this is enough today... = though perhaps not so next year. >>=20 >>=20 >>> ElementId: TBD9 >>>=20 >>> Units: Octets >>>=20 >>> 7.6. fsOctetSelectedCount >>>=20 >>> Description: >>>=20 >>> This Information Element specifies the current number of bytes = in >>> all flows that were selected during the Flow Selection = Process. >>>=20 >>> Abstract Data Type: unsigned64 >>>=20 >>> ElementId: TBD10 >>>=20 >>> Units: Octets >>>=20 >>>=20 >>> 8. IANA Considerations >>>=20 >>> This document introduces several new Information Elements as an >>> extension to the IPFIX information model. Values TBD1-TBD10 in >>> section 7 of this document should be replaced with the assigned >>> numbers by IANA. >>>=20 >>>=20 >>> 9. Security Considerations >>>=20 >>> In this section security issues concerning an IPFIX Device = performing >>> flow selection are pointed out. In case the flow selection = function >>> is activated an IPFIX Device might be exposed to security = threats. >>=20 >> "activated," >>=20 >>=20 >>> Since flow selection implies analysing flow packets, associating = them >>> to a specific traffic flow and selecting Flow Records, a = malicious >>=20 >> "associate ... with" - so s/to/with/ >>=20 >>=20 >>> user who was able to gain control of an IPFIX Device might access >>> both packet and flow data, thus violating their confidentiality. >>>=20 >>> Furthermore, the intruder might be attracted by the possibility = of >>> altering the Flow Selection Process by modifying the criteria = used to >>> select Flow Records. In this case, the IPFIX Device would export >>> flow data which are different from the ones that the Collector >>> expects to receive. >>>=20 >>> It is apparent that these security threats can be mitigated by >>> authenticating entities that interact with the IPFIX Device and >>> keeping information for flow selection configuration = confidential. >>=20 >> In short, if you can gain control of the box then you can do bad = things. This is well known. >>=20 >> Does this document expose any new security considerations for the = reader / implementer? >> If not, then consider stating that explicitly (copy the "no new = security implications" text from other IPFIX RFCs) in order to avoid = creating a negative impression (ie, that implementing this draft exposes = security risks). >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 [Page = 20] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> 10. References >>>=20 >>> 10.1. Normative References >>>=20 >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>>=20 >>> 10.2. Informative References >>>=20 >>> [CoHa08] Cormode, G. and M. Hadjieleftheriou, "Finding frequent >>> items in data streams", Journal, Proceedings of the = Very >>> Large DataBase Endowment VLDB Endowment, Volume 1 = Issue 2, >>> August 2008, August 2008. >>>=20 >>> [DuLT01] Duffield, N., Lund, C., and M. Thorup, "Charging from >>> Sampled Network Usage", ACM Internet Measurement = Workshop >>> IMW 2001, San Francisco, USA, November 2001. >>>=20 >>> [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. >>>=20 >>> [KaPS03] Karp, R., Papadimitriou, C., and S. S. Shenker, "A = simple >>> algorithm for finding frequent elements in sets and >>> bags.", ACM Transactions on Database Systems, Volume = 28, >>> 51-55, 2003, March 2003. >>>=20 >>> [MSZC10] Mai, J., Sridharan, A., Zang, H., and C. Chuah, "Fast >>> Filtered Sampling", Computer Networks Volume 54, Issue = 11, >>> Pages 1885-1898, ISSN 1389-1286, January 2010. >>>=20 >>> [MaMo02] Manku, G. and R. Motwani, "Approximate Frequency = Counts >>> over Data Streams", Proceedings of the Internation >>=20 >> s/Internation/International/ >>=20 >>=20 >>> Conference on Very large DataBases (VLDB) pages = 346--357, >>> 2002, Hong Kong, China, 2002. >>>=20 >>> [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, >>> "Requirements for IP Flow Information Export (IPFIX)", >>> RFC 3917, October 2004. >>>=20 >>> [RFC5101] Claise, B., "Specification of the IP Flow Information >>> Export (IPFIX) Protocol for the Exchange of IP Traffic >>> Flow Information", RFC 5101, January 2008. >>>=20 >>> [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and = J. >>> Meyer, "Information Model for IP Flow Information = Export", >>> RFC 5102, January 2008. >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 [Page = 21] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. = Quittek, >>> "Architecture for IP Flow Information Export", RFC = 5470, >>> March 2009. >>>=20 >>> [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., = and F. >>> Raspall, "Sampling and Filtering Techniques for IP = Packet >>> Selection", RFC 5475, March 2009. >>>=20 >>> [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet = Sampling >>> (PSAMP) Protocol Specifications", RFC 5476, March = 2009. >>>=20 >>> [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. = Ishibashi, >>> "IP Flow Information Export (IPFIX) Mediation: = Framework", >>> RFC 6183, April 2011. >>>=20 >>>=20 >>> Authors' Addresses >>>=20 >>> Salvatore D'Antonio >>> University of Napoli "Parthenope" >>> Centro Direzionale di Napoli Is. C4 >>> Naples 80143 >>> Italy >>>=20 >>> Phone: +39 081 5476766 >>> Email: salvatore.dantonio@uniparthenope.it >>>=20 >>>=20 >>> Tanja Zseby >>> Fraunhofer Institute FOKUS >>> Kaiserin-Augusta-Allee 31 >>> Berlin 10589 >>> Germany >>>=20 >>> Phone: +49 30 3463 7153 >>> Email: tanja.zseby@fokus.fraunhofer.de >>>=20 >>>=20 >>> Christian Henke >>> Technische Universitat Berlin >>> Strasse des 17. Juni 135 >>> Berlin 10623 >>> Germany >>>=20 >>> Phone: +49 30 3463 7366 >>> Email: c.henke@tu-berlin.de >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 [Page = 22] >>>=20 >>> Internet-Draft Flow Selection Techniques July = 2011 >>>=20 >>>=20 >>> Lorenzo Peluso >>> University of Napoli >>> Via Claudio 21 >>> Napoli 80125 >>> Italy >>>=20 >>> Phone: +39 081 7683821 >>> Email: lorenzo.peluso@unina.it >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> D'Antonio, et al. Expires January 12, 2012 [Page = 23] >>>=20 >>=20 >> _______________________________________________ >> 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 muenz@net.in.tum.de Sun Sep 11 13:46:04 2011 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 2FADC21F8A97 for ; Sun, 11 Sep 2011 13:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 amcPR3B1C-qE for ; Sun, 11 Sep 2011 13:46:03 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6F921F84FB for ; Sun, 11 Sep 2011 13:46:03 -0700 (PDT) Received: from [192.168.2.26] (e181133096.adsl.alicedsl.de [85.181.133.96]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 3FA4F205783C; Sun, 11 Sep 2011 22:51:14 +0200 (CEST) Message-ID: <4E6D1E73.9@net.in.tum.de> Date: Sun, 11 Sep 2011 22:47:47 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] proposal for IPFIX charter update 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, 11 Sep 2011 20:46:04 -0000 Hi Juergen, The IPFIX configuration data model is pending because of the IPFIX and PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of highest priority, and a solution be published before any other new draft. (I already see IPFIX config being outdated by RFC5101/5102bis before it ever becomes RFC...) Regards, Gerhard On 29.08.2011 06:57, Juergen Quittek wrote: > Dear all, > > At our session in Quebec we discussed candidates > for new IPFIX work items. Based on this discussion, > Nevil and I drafted an update of our charter that > you can find below. > > Please have a look at it and send us your comments. > > Thanks, > > Juergen > > > IP Flow Information Export (ipfix) > > > Description of Working Group > > > The IPFIX working group has specified the information model (to describe > IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX > exporters to collectors). Several implementers have already built > applications using the IPFIX protocol. As a result of a series of IPFIX > interoperability testing events the WG has produced guidelines for IPFIX > implementation and testing as well as recommendations for handling > special cases such as bidirectional flow reporting and reducing > redundancy in flow records. > > The IPFIX WG has developed a mediation framework, that defines IPFIX > mediators for processing flow records for various purposes including > aggregation, anonymization, etc. For configuring IPFIX devices, a YANG > module has been developed. > > 1. Having a solid standardized base for IPFIX deployment and operation > and several exiting implementations, the IPFIX WG will revisit the IPFIX > protocol specifications (RFC 5101) and the IPFIX information element > specification (RFC 5102) in order to advance them to draft standard. > > 2. For giving guidelines to developers of new IPFIX information > elements and for better defining the process of registering new > information elements at IANA the IPFIX WG will create an information > element developers guideline document. > > 3. The export of IPFIX flow records from IPFIX mediators introduces a > set of potential issues at the protocol level, such as the loss of > information on the original exporter, loss of base time information, > loss of original options template information, etc. The IPFIX WG will > define common ways to deal with these issues, by specifying guidelines > for the use of the IPFIX protocol on IPFIX mediators. > > 4. For supporting the aggregation of flow records at IPFIX mediators > the IPFIX WG will define how to export aggregated flow information using > IPFIX. An aggregated flow is essentially an IPFIX flow representing > packets from multiple original Flows sharing some set of common properties. > > 5. The IPFIX WG will investigate the use of the IPFIX protocol for > exporting > MIB objects, avoiding the need to define new IPFIX information elements > for existing management information base objects that are already fully > specified. This method requires the specification of new template set > and options template sets to allow the export of MIB objects along > with IPFIX information elements. > > 6. The IPFIX MIB module (RFC 5815) defined a way to register packet > selector functions at IANA. The WG agreed that another method would > be preferable that requires a minor change of RFC 5815. The IPFIX WG > will produce a new version of RFC 5815 with small modifications of > the IANA actions and DESCRIPTION clauses in the the MIB modules. > > Oct 2011 Publish draft on guidelines for IE doctors > Oct 2011 Publish draft on IPFIX use at mediators > Oct 2011 Publish draft on intermediate aggregation > Oct 2011 Publish draft on exporting MIB objects > Oct 2011 Publish draft on data link IEs > Dec 2011 Publish draft revising RFC 5101 > Dec 2011 Publish draft revising RFC 5102 > > Apr 2012 Submit guidelines for IE doctors for publication as > Informational BCP RFC > Apr 2012 Submit draft on IPFIX use at mediators for publication as > Standards track RFC > Apr 2012 Submit draft on intermediate aggregation for publication as > Standards track RFC > Apr 2012 Submit draft on data link IEs for publication as Standards > track RFC > Apr 2012 Submit draft revising RFC 5101 for publication as Standards > track RFC > Apr 2012 Submit draft revising RFC 5102 for publication as Standards > track RFC > Sep 2012 Submit draft on exporting MIB objects for publication as > Standards track RFC > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From kashima@nttv6.net Mon Sep 12 09:25:03 2011 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 EAA1621F8B2D for ; Mon, 12 Sep 2011 09:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 LjUrbK2JmFaw for ; Mon, 12 Sep 2011 09:25:03 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id AAB2821F8B89 for ; Mon, 12 Sep 2011 09:25:02 -0700 (PDT) Received: from [10.60.227.219] (localhost.nttv6.net [IPv6:::1]) by leo.nttv6.net (8.14.4/8.14.4) with ESMTP id p8CGPX4D063743; Tue, 13 Sep 2011 01:25:34 +0900 (JST) (envelope-from kashima@nttv6.net) Date: Tue, 13 Sep 2011 01:25:40 +0900 From: Shingo KASHIMA To: Juergen Quittek In-Reply-To: References: Message-Id: <20110913012432.47B2.1AB7FA03@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.57.01 [ja] Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] proposal for IPFIX charter update 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, 12 Sep 2011 16:25:04 -0000 Hi Juergen, > Oct 2011 Publish draft on data link IEs > Apr 2012 Submit draft on data link IEs for publication as Standards > track RFC Has "Link Layer IEs" accepted as WG item ? IETF81's minutes is as follows: > We have one other draft that was presented in earlier meetings - "Link > Layer IEs." We discussed whether this could be a "trial run for the > IE Doctors," or a WG item. We reached consensus for it as a WG item, > with the proviso that it will need views from Layer 2 domain experts, > e.g. IEEE 802.1. Best regards, Shingo From bclaise@cisco.com Tue Sep 13 05:08:10 2011 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 6493621F87D3 for ; Tue, 13 Sep 2011 05:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 jEOeMIG7gAhe for ; Tue, 13 Sep 2011 05:08: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 F1E0A21F87C9 for ; Tue, 13 Sep 2011 05:08:05 -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 p8DCA2NQ003757; Tue, 13 Sep 2011 14:10:02 +0200 (CEST) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8DCA0i9026968; Tue, 13 Sep 2011 14:10:00 +0200 (CEST) Message-ID: <4E6F4818.2020501@cisco.com> Date: Tue, 13 Sep 2011 14:10:00 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Juergen Quittek , Nevil Brownlee , "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] proposal for IPFIX charter update -> Internet Standard 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, 13 Sep 2011 12:08:10 -0000 Juergen, Nevil, Dan, In light of http://tools.ietf.org/html/draft-housley-two-maturity-levels-08, which is in the RFC-editor queue, should we shoot for RFC5101bis and RFC5102bis as Internet Standard. Maybe a sentence in the charter such as. If draft-housley-two-maturity-levels-08 is published in time for the WG milestones, the revised RFC5101 and RFC5102 should target Internet Standard status" Regards, Benoit. > Dear all, > > At our session in Quebec we discussed candidates > for new IPFIX work items. Based on this discussion, > Nevil and I drafted an update of our charter that > you can find below. > > Please have a look at it and send us your comments. > > Thanks, > > Juergen > > > IP Flow Information Export (ipfix) > > > Description of Working Group > > > The IPFIX working group has specified the information model (to describe > IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX > exporters to collectors). Several implementers have already built > applications using the IPFIX protocol. As a result of a series of IPFIX > interoperability testing events the WG has produced guidelines for IPFIX > implementation and testing as well as recommendations for handling > special cases such as bidirectional flow reporting and reducing > redundancy in flow records. > > The IPFIX WG has developed a mediation framework, that defines IPFIX > mediators for processing flow records for various purposes including > aggregation, anonymization, etc. For configuring IPFIX devices, a YANG > module has been developed. > > 1. Having a solid standardized base for IPFIX deployment and operation > and several exiting implementations, the IPFIX WG will revisit the IPFIX > protocol specifications (RFC 5101) and the IPFIX information element > specification (RFC 5102) in order to advance them to draft standard. > > 2. For giving guidelines to developers of new IPFIX information > elements and for better defining the process of registering new > information elements at IANA the IPFIX WG will create an information > element developers guideline document. > > 3. The export of IPFIX flow records from IPFIX mediators introduces a > set of potential issues at the protocol level, such as the loss of > information on the original exporter, loss of base time information, > loss of original options template information, etc. The IPFIX WG will > define common ways to deal with these issues, by specifying guidelines > for the use of the IPFIX protocol on IPFIX mediators. > > 4. For supporting the aggregation of flow records at IPFIX mediators > the IPFIX WG will define how to export aggregated flow information using > IPFIX. An aggregated flow is essentially an IPFIX flow representing > packets from multiple original Flows sharing some set of common properties. > > 5. The IPFIX WG will investigate the use of the IPFIX protocol for > exporting > MIB objects, avoiding the need to define new IPFIX information elements > for existing management information base objects that are already fully > specified. This method requires the specification of new template set > and options template sets to allow the export of MIB objects along > with IPFIX information elements. > > 6. The IPFIX MIB module (RFC 5815) defined a way to register packet > selector functions at IANA. The WG agreed that another method would > be preferable that requires a minor change of RFC 5815. The IPFIX WG > will produce a new version of RFC 5815 with small modifications of > the IANA actions and DESCRIPTION clauses in the the MIB modules. > > Oct 2011 Publish draft on guidelines for IE doctors > Oct 2011 Publish draft on IPFIX use at mediators > Oct 2011 Publish draft on intermediate aggregation > Oct 2011 Publish draft on exporting MIB objects > Oct 2011 Publish draft on data link IEs > Dec 2011 Publish draft revising RFC 5101 > Dec 2011 Publish draft revising RFC 5102 > > Apr 2012 Submit guidelines for IE doctors for publication as > Informational BCP RFC > Apr 2012 Submit draft on IPFIX use at mediators for publication as > Standards track RFC > Apr 2012 Submit draft on intermediate aggregation for publication as > Standards track RFC > Apr 2012 Submit draft on data link IEs for publication as Standards > track RFC > Apr 2012 Submit draft revising RFC 5101 for publication as Standards > track RFC > Apr 2012 Submit draft revising RFC 5102 for publication as Standards > track RFC > Sep 2012 Submit draft on exporting MIB objects for publication as > Standards track RFC > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From dromasca@avaya.com Tue Sep 13 07:54:32 2011 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 379CC21F8B18 for ; Tue, 13 Sep 2011 07:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.891 X-Spam-Level: X-Spam-Status: No, score=-102.891 tagged_above=-999 required=5 tests=[AWL=-0.292, 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 IY0GIczG7GPZ for ; Tue, 13 Sep 2011 07:54:28 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4AB21F8B19 for ; Tue, 13 Sep 2011 07:54:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgAAK1ub06HCzI1/2dsb2JhbABDDphNjw54gVMBAQEBAgEBAQEPFQkKNAYFBQcEAgEIDQEDBAEBCwYMCwEGASYfCQgBAQQBCQkIGodVBJtpAptVhg5gBJh1izI6 X-IronPort-AV: E=Sophos;i="4.68,374,1312171200"; d="scan'208";a="207253751" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 13 Sep 2011 10:56:33 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Sep 2011 10:47:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Sep 2011 16:56:30 +0200 Message-ID: In-Reply-To: <4E6F4818.2020501@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] proposal for IPFIX charter update -> Internet Standard Thread-Index: AcxyDhp8QkGYGzcGQrqakskRjoM8awAFrhhQ References: <4E6F4818.2020501@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" , "Juergen Quittek" , "Nevil Brownlee" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] proposal for IPFIX charter update -> Internet Standard 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, 13 Sep 2011 14:54:32 -0000 Hi, I suggest to say 'advance RFC 5101 and RFC 5102 to the next stage of standardization on the standards track'.=20 The question that will be asked at some point is whether IPFIX reached the 'wide deployment' required by a Full Standard, but this is something we need to care about when and if we reach that phase and the process was already transitioned to two levels.=20 Regards, Dan > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Tuesday, September 13, 2011 3:10 PM > To: Juergen Quittek; Nevil Brownlee; Romascanu, Dan (Dan) > Cc: IETF IPFIX Working Group > Subject: Re: [IPFIX] proposal for IPFIX charter update -> Internet > Standard >=20 > Juergen, Nevil, Dan, >=20 > In light of > http://tools.ietf.org/html/draft-housley-two-maturity-levels-08, which > is in the RFC-editor queue, should we shoot for RFC5101bis and > RFC5102bis as Internet Standard. > Maybe a sentence in the charter such as. If > draft-housley-two-maturity-levels-08 is published in time for the WG > milestones, the revised RFC5101 and RFC5102 should target Internet > Standard status" >=20 > Regards, Benoit. > > Dear all, > > > > At our session in Quebec we discussed candidates > > for new IPFIX work items. Based on this discussion, > > Nevil and I drafted an update of our charter that > > you can find below. > > > > Please have a look at it and send us your comments. > > > > Thanks, > > > > Juergen > > > > > > IP Flow Information Export (ipfix) > > > > > > Description of Working Group > > > > > > The IPFIX working group has specified the information model (to > describe > > IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX > > exporters to collectors). Several implementers have already built > > applications using the IPFIX protocol. As a result of a series of > IPFIX > > interoperability testing events the WG has produced guidelines for > IPFIX > > implementation and testing as well as recommendations for handling > > special cases such as bidirectional flow reporting and reducing > > redundancy in flow records. > > > > The IPFIX WG has developed a mediation framework, that defines IPFIX > > mediators for processing flow records for various purposes including > > aggregation, anonymization, etc. For configuring IPFIX devices, a > YANG > > module has been developed. > > > > 1. Having a solid standardized base for IPFIX deployment and > operation > > and several exiting implementations, the IPFIX WG will revisit the > IPFIX > > protocol specifications (RFC 5101) and the IPFIX information element > > specification (RFC 5102) in order to advance them to draft standard. > > > > 2. For giving guidelines to developers of new IPFIX information > > elements and for better defining the process of registering new > > information elements at IANA the IPFIX WG will create an information > > element developers guideline document. > > > > 3. The export of IPFIX flow records from IPFIX mediators introduces a > > set of potential issues at the protocol level, such as the loss of > > information on the original exporter, loss of base time information, > > loss of original options template information, etc. The IPFIX WG will > > define common ways to deal with these issues, by specifying > guidelines > > for the use of the IPFIX protocol on IPFIX mediators. > > > > 4. For supporting the aggregation of flow records at IPFIX mediators > > the IPFIX WG will define how to export aggregated flow information > using > > IPFIX. An aggregated flow is essentially an IPFIX flow representing > > packets from multiple original Flows sharing some set of common > properties. > > > > 5. The IPFIX WG will investigate the use of the IPFIX protocol for > > exporting > > MIB objects, avoiding the need to define new IPFIX information > elements > > for existing management information base objects that are already > fully > > specified. This method requires the specification of new template set > > and options template sets to allow the export of MIB objects along > > with IPFIX information elements. > > > > 6. The IPFIX MIB module (RFC 5815) defined a way to register packet > > selector functions at IANA. The WG agreed that another method would > > be preferable that requires a minor change of RFC 5815. The IPFIX WG > > will produce a new version of RFC 5815 with small modifications of > > the IANA actions and DESCRIPTION clauses in the the MIB modules. > > > > Oct 2011 Publish draft on guidelines for IE doctors > > Oct 2011 Publish draft on IPFIX use at mediators > > Oct 2011 Publish draft on intermediate aggregation > > Oct 2011 Publish draft on exporting MIB objects > > Oct 2011 Publish draft on data link IEs > > Dec 2011 Publish draft revising RFC 5101 > > Dec 2011 Publish draft revising RFC 5102 > > > > Apr 2012 Submit guidelines for IE doctors for publication as > > Informational BCP RFC > > Apr 2012 Submit draft on IPFIX use at mediators for publication as > > Standards track RFC > > Apr 2012 Submit draft on intermediate aggregation for publication > as > > Standards track RFC > > Apr 2012 Submit draft on data link IEs for publication as > Standards > > track RFC > > Apr 2012 Submit draft revising RFC 5101 for publication as > Standards > > track RFC > > Apr 2012 Submit draft revising RFC 5102 for publication as > Standards > > track RFC > > Sep 2012 Submit draft on exporting MIB objects for publication as > > Standards track RFC > > > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Tue Sep 13 08:33:34 2011 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 ADAAF21F8B76 for ; Tue, 13 Sep 2011 08:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 bF1l+5Y+h7+K for ; Tue, 13 Sep 2011 08:33: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 2D11721F8B9B for ; Tue, 13 Sep 2011 08:33:30 -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 p8DFZOpK027708; Tue, 13 Sep 2011 17:35:24 +0200 (CEST) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8DFZLxn009371; Tue, 13 Sep 2011 17:35:22 +0200 (CEST) Message-ID: <4E6F7839.4080908@cisco.com> Date: Tue, 13 Sep 2011 17:35:21 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4E6F4818.2020501@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee , IETF IPFIX Working Group Subject: Re: [IPFIX] proposal for IPFIX charter update -> Internet Standard 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, 13 Sep 2011 15:33:34 -0000 Hi Dan, Good suggestion. Regards, Benoit. > Hi, > > I suggest to say 'advance RFC 5101 and RFC 5102 to the next stage of > standardization on the standards track'. > > The question that will be asked at some point is whether IPFIX reached > the 'wide deployment' required by a Full Standard, but this is something > we need to care about when and if we reach that phase and the process > was already transitioned to two levels. > > Regards, > > Dan > > > >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: Tuesday, September 13, 2011 3:10 PM >> To: Juergen Quittek; Nevil Brownlee; Romascanu, Dan (Dan) >> Cc: IETF IPFIX Working Group >> Subject: Re: [IPFIX] proposal for IPFIX charter update -> Internet >> Standard >> >> Juergen, Nevil, Dan, >> >> In light of >> http://tools.ietf.org/html/draft-housley-two-maturity-levels-08, which >> is in the RFC-editor queue, should we shoot for RFC5101bis and >> RFC5102bis as Internet Standard. >> Maybe a sentence in the charter such as. If >> draft-housley-two-maturity-levels-08 is published in time for the WG >> milestones, the revised RFC5101 and RFC5102 should target Internet >> Standard status" >> >> Regards, Benoit. >>> Dear all, >>> >>> At our session in Quebec we discussed candidates >>> for new IPFIX work items. Based on this discussion, >>> Nevil and I drafted an update of our charter that >>> you can find below. >>> >>> Please have a look at it and send us your comments. >>> >>> Thanks, >>> >>> Juergen >>> >>> >>> IP Flow Information Export (ipfix) >>> >>> >>> Description of Working Group >>> >>> >>> The IPFIX working group has specified the information model (to >> describe >>> IP flows) and the IPFIX protocol (to transfer IP flow data from > IPFIX >>> exporters to collectors). Several implementers have already built >>> applications using the IPFIX protocol. As a result of a series of >> IPFIX >>> interoperability testing events the WG has produced guidelines for >> IPFIX >>> implementation and testing as well as recommendations for handling >>> special cases such as bidirectional flow reporting and reducing >>> redundancy in flow records. >>> >>> The IPFIX WG has developed a mediation framework, that defines IPFIX >>> mediators for processing flow records for various purposes including >>> aggregation, anonymization, etc. For configuring IPFIX devices, a >> YANG >>> module has been developed. >>> >>> 1. Having a solid standardized base for IPFIX deployment and >> operation >>> and several exiting implementations, the IPFIX WG will revisit the >> IPFIX >>> protocol specifications (RFC 5101) and the IPFIX information element >>> specification (RFC 5102) in order to advance them to draft standard. >>> >>> 2. For giving guidelines to developers of new IPFIX information >>> elements and for better defining the process of registering new >>> information elements at IANA the IPFIX WG will create an information >>> element developers guideline document. >>> >>> 3. The export of IPFIX flow records from IPFIX mediators introduces > a >>> set of potential issues at the protocol level, such as the loss of >>> information on the original exporter, loss of base time information, >>> loss of original options template information, etc. The IPFIX WG > will >>> define common ways to deal with these issues, by specifying >> guidelines >>> for the use of the IPFIX protocol on IPFIX mediators. >>> >>> 4. For supporting the aggregation of flow records at IPFIX mediators >>> the IPFIX WG will define how to export aggregated flow information >> using >>> IPFIX. An aggregated flow is essentially an IPFIX flow representing >>> packets from multiple original Flows sharing some set of common >> properties. >>> 5. The IPFIX WG will investigate the use of the IPFIX protocol for >>> exporting >>> MIB objects, avoiding the need to define new IPFIX information >> elements >>> for existing management information base objects that are already >> fully >>> specified. This method requires the specification of new template > set >>> and options template sets to allow the export of MIB objects along >>> with IPFIX information elements. >>> >>> 6. The IPFIX MIB module (RFC 5815) defined a way to register packet >>> selector functions at IANA. The WG agreed that another method would >>> be preferable that requires a minor change of RFC 5815. The IPFIX WG >>> will produce a new version of RFC 5815 with small modifications of >>> the IANA actions and DESCRIPTION clauses in the the MIB modules. >>> >>> Oct 2011 Publish draft on guidelines for IE doctors >>> Oct 2011 Publish draft on IPFIX use at mediators >>> Oct 2011 Publish draft on intermediate aggregation >>> Oct 2011 Publish draft on exporting MIB objects >>> Oct 2011 Publish draft on data link IEs >>> Dec 2011 Publish draft revising RFC 5101 >>> Dec 2011 Publish draft revising RFC 5102 >>> >>> Apr 2012 Submit guidelines for IE doctors for publication as >>> Informational BCP RFC >>> Apr 2012 Submit draft on IPFIX use at mediators for publication > as >>> Standards track RFC >>> Apr 2012 Submit draft on intermediate aggregation for publication >> as >>> Standards track RFC >>> Apr 2012 Submit draft on data link IEs for publication as >> Standards >>> track RFC >>> Apr 2012 Submit draft revising RFC 5101 for publication as >> Standards >>> track RFC >>> Apr 2012 Submit draft revising RFC 5102 for publication as >> Standards >>> track RFC >>> Sep 2012 Submit draft on exporting MIB objects for publication as >>> Standards track RFC >>> >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Tue Sep 20 03:47:41 2011 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 84B2521F8C04 for ; Tue, 20 Sep 2011 03:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 RPqdETfJbvMH for ; Tue, 20 Sep 2011 03:47:41 -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 31A1321F8BF9 for ; Tue, 20 Sep 2011 03:47:39 -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 p8KAo3fB013154; Tue, 20 Sep 2011 12:50:03 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8KAnuE0001713; Tue, 20 Sep 2011 12:49:56 +0200 (CEST) Message-ID: <4E786FD4.2010901@cisco.com> Date: Tue, 20 Sep 2011 12:49:56 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20110920103441.5003.50588.idtracker@ietfa.amsl.com> In-Reply-To: <20110920103441.5003.50588.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110920103441.5003.50588.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------000706050905040209050406" Cc: Thomas Dietz , Simon Leinen Subject: [IPFIX] Fwd: New Version Notification for draft-claise-ipfix-protocol-rfc5101bis-00.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, 20 Sep 2011 10:47:41 -0000 This is a multi-part message in MIME format. --------------000706050905040209050406 Content-Type: multipart/alternative; boundary="------------080603090201010908080201" --------------080603090201010908080201 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is a new draft, to advance RFC 5101 to the next stage of standardization on the standards track, as foreseen by the future charter. DONE: Errata ID: 1655 (technical) Errata ID: 2791 (technical) Errata ID: 2814 (editorial) Errata ID: 1818 (editorial) Errata ID: 2792 (editorial) Errata ID: 2888 (editorial) Errata ID: 2889 (editorial) Errata ID: 2890 (editorial) Errata ID: 2891 (editorial) Errata ID: 2892 (editorial) Errata ID: 2903 (editorial) Errata ID: 2761 (editorial) Errata ID: 2762 (editorial) Errata ID: 2763 (editorial) Errata ID: 2764 (editorial) Errata ID: 2852 (editorial) Errata ID: 2857 (editorial) Section 8: "a new sampling rate" has been removed from the list of examples that requires a new Template. If the measurement parameters change such that a new Template is required, the Template MUST be withdrawn (using a Template Withdraw Message and a new Template definition) or an unused Template ID MUST be used. Examples of the measurement changes are: a new sampling rate, a new Flow expiration process, a new filtering definition, etc. Updated the references Updated the "Document overview" section. Template and UDP: included the proposal at http://www.ietf.org/mail-archive/web/ipfix/current/msg06051.html TO DO: "time first flow dropped" and "time last flow dropped" inconsistency. See the discussion on the list. Replace the RFC5102 by RFC5102bis, when the draft will be posted. Replace the RFC5815 by RFC5815bis, when the draft will be posted. NTP RFC 1305 is obsoleted by RFC5905. Check if the format is the similar before updating the reference. IDNA RFC 3490 is obsoleted by RFC5890 and RFC5891. Double-check Did I miss anything, which is within the boundary of what we can change for the next level of standardization? For your convenience, a diff between RFC5101 and this draft is included. Regards, Benoit. -------- Original Message -------- Subject: New Version Notification for draft-claise-ipfix-protocol-rfc5101bis-00.txt Date: Tue, 20 Sep 2011 03:34:41 -0700 From: internet-drafts@ietf.org To: bclaise@cisco.com CC: bclaise@cisco.com A new version of I-D, draft-claise-ipfix-protocol-rfc5101bis-00.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. Filename: draft-claise-ipfix-protocol-rfc5101bis Revision: 00 Title: Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Creation date: 2011-09-20 WG ID: Individual Submission Number of pages: 66 Abstract: This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and 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 IETF Secretariat --------------080603090201010908080201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear all,

Here is a new draft, to advance RFC 5101 to the next stage of standardization on the standards track, as foreseen by the future charter.

DONE:
      Errata ID: 1655 (technical)
      Errata ID: 2791 (technical)
      Errata ID: 2814 (editorial)
      Errata ID: 1818 (editorial)
      Errata ID: 2792 (editorial)
      Errata ID: 2888 (editorial)
      Errata ID: 2889 (editorial)
      Errata ID: 2890 (editorial)
      Errata ID: 2891 (editorial)
      Errata ID: 2892 (editorial)
      Errata ID: 2903 (editorial)
      Errata ID: 2761 (editorial)
      Errata ID: 2762 (editorial)
      Errata ID: 2763 (editorial)
      Errata ID: 2764 (editorial)
      Errata ID: 2852 (editorial)
      Errata ID: 2857 (editorial)

      Section 8: "a new sampling rate" has been removed from the list of
   examples that requires a new Template.

      If the measurement parameters change such that a new Template is 
   required, the Template MUST be withdrawn (using a Template Withdraw 
   Message and a new Template definition) or an unused Template ID MUST
    be used.  Examples of the measurement changes are: a new sampling 
   rate, a new Flow expiration process, a new filtering definition, etc.

      Updated the references

      Updated the "Document overview" section.

      Template and UDP: included the proposal at
   http://www.ietf.org/mail-archive/web/ipfix/current/msg06051.html


TO DO:
      "time first flow dropped" and "time last flow dropped" inconsistency. See the discussion on the list.
      Replace the RFC5102 by RFC5102bis, when the draft will be posted.
      Replace the RFC5815 by RFC5815bis, when the draft will be posted.
      NTP RFC 1305 is obsoleted by RFC5905. Check if the format is the similar before updating the reference.
      IDNA RFC 3490 is obsoleted by RFC5890 and RFC5891. Double-check

Did I miss anything, which is within the boundary of what we can change for the next level of standardization?

For your convenience, a diff between RFC5101 and this draft is included.

Regards, Benoit.

-------- Original Message --------
Subject: New Version Notification for draft-claise-ipfix-protocol-rfc5101bis-00.txt
Date: Tue, 20 Sep 2011 03:34:41 -0700
From: internet-drafts@ietf.org
To: bclaise@cisco.com
CC: bclaise@cisco.com 


A new version of I-D, draft-claise-ipfix-protocol-rfc5101bis-00.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-ipfix-protocol-rfc5101bis
Revision:	 00
Title:		 Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
Creation date:	 2011-09-20
WG ID:		 Individual Submission
Number of pages: 66

Abstract:
   This document specifies the IP Flow Information Export (IPFIX)
   protocol that serves for transmitting IP Traffic Flow information
   over the network.  In order to transmit IP Traffic Flow information
   from an Exporting Process to an information Collecting Process, a
   common representation of flow data and a standard means of
   communicating them is required.  This document describes how the
   IPFIX Data and 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 IETF Secretariat
--------------080603090201010908080201-- --------------000706050905040209050406 Content-Type: text/html; charset=ISO-8859-1; name="rfcdiff.pyht.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rfcdiff.pyht.htm" PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlv bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5z aXRpb25hbC5kdGQiPg0KPCEtLSBHZW5lcmF0ZWQgYnkgcmZjZGlmZiAxLjM5OiByZmNkaWZm ICAtLT4NCjwhLS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQu MDEgVHJhbnNpdGlvbmFsIiA+IC0tPg0KPCEtLSBTeXN0ZW06IExpbnV4IGlldGZhIDIuNi4y Ny40NS0wLjEteGVuICMxIFNNUCAyMDEwLTAyLTIyIDE2OjQ5OjQ3ICswMTAwIHg4Nl82NCB4 ODZfNjQgeDg2XzY0IEdOVS9MaW51eCAtLT4NCjwhLS0gVXNpbmcgYXdrOiAvYmluL2dhd2s6 IEdOVSBBd2sgMy4xLjYgLS0+DQo8IS0tIFVzaW5nIGRpZmY6IC91c3IvYmluL2RpZmY6IGRp ZmYgKEdOVSBkaWZmdXRpbHMpIDIuOC43LWN2cyAtLT4NCjwhLS0gVXNpbmcgd2RpZmY6IC91 c3IvYmluL3dkaWZmOiBHTlUgMC41LjIgTDMgLS0+DQo8aHRtbD48aGVhZD4gDQogIDxtZXRh IGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PUlTTy04ODU5LTEiPiANCiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1TdHlsZS1UeXBl IiBjb250ZW50PSJ0ZXh0L2NzcyI+IA0KICA8dGl0bGU+RGlmZjogcmZjNTEwMS50eHQgLSBk cmFmdC1jbGFpc2UtaXBmaXgtcHJvdG9jb2wtcmZjNTEwMWJpcy0wMC50eHQ8L3RpdGxlPiAN CiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4gDQogICAgYm9keSAgICB7IG1hcmdpbjogMC40 ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSANCiAgICB0ciAgICAgIHsgfSANCiAgICB0ZCAg ICAgIHsgd2hpdGUtc3BhY2U6IHByZTsgZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgdmVydGlj YWwtYWxpZ246IHRvcDsgZm9udC1zaXplOiAwLjg2ZW07fSANCiAgICB0aCAgICAgIHsgZm9u dC1zaXplOiAwLjg2ZW07IH0gDQogICAgLnNtYWxsICB7IGZvbnQtc2l6ZTogMC42ZW07IGZv bnQtc3R5bGU6IGl0YWxpYzsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEhlbHZldGljYSwgc2Fu cy1zZXJpZjsgfSANCiAgICAubGVmdCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAN CiAgICAucmlnaHQgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgfSANCiAgICAuZGlmZiAg IHsgYmFja2dyb3VuZC1jb2xvcjogI0NDRjsgfSANCiAgICAubGJsb2NrIHsgYmFja2dyb3Vu ZC1jb2xvcjogI0JGQjsgfSANCiAgICAucmJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZG ODsgfSANCiAgICAuaW5zZXJ0IHsgYmFja2dyb3VuZC1jb2xvcjogIzhGRjsgfSANCiAgICAu ZGVsZXRlIHsgYmFja2dyb3VuZC1jb2xvcjogI0FDRjsgfSANCiAgICAudm9pZCAgIHsgYmFj a2dyb3VuZC1jb2xvcjogI0ZGQjsgfSANCiAgICAuY29udCAgIHsgYmFja2dyb3VuZC1jb2xv cjogI0VFRTsgfSANCiAgICAubGluZWJyIHsgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAN CiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgZm9u dC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmlnaHQ7IHBhZGRpbmc6IDAgMnB4OyB9IA0K ICAgIC5lbGlwc2lzeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUFBOyB9IA0KICAgIC5sZWZ0IC5j b250IHsgYmFja2dyb3VuZC1jb2xvcjogI0RERDsgfSANCiAgICAucmlnaHQgLmNvbnQgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IA0KICAgIC5sYmxvY2sgLmNvbnQgeyBiYWNrZ3Jv dW5kLWNvbG9yOiAjOUQ5OyB9IA0KICAgIC5yYmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNv bG9yOiAjREQ2OyB9IA0KICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAj MEREOyB9IA0KICAgIC5kZWxldGUgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEFEOyB9 IA0KICAgIC5zdGF0cywgLnN0YXRzIHRkLCAuc3RhdHMgdGggeyBiYWNrZ3JvdW5kLWNvbG9y OiAjRUVFOyBwYWRkaW5nOiAycHggMDsgfSANCiAgPC9zdHlsZT4gDQo8L2hlYWQ+IA0KPGJv ZHk+IA0KICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjAiPiANCiAgPHRib2R5Pjx0ciBiZ2NvbG9yPSJvcmFuZ2UiPjx0aD48L3RoPjx0aD4mbmJz cDtyZmM1MTAxLnR4dCZuYnNwOzwvdGg+PHRoPiA8L3RoPjx0aD4mbmJzcDs8YSBocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL2h0bWwvZHJhZnQtY2xhaXNlLWlwZml4LXByb3RvY29sLXJm YzUxMDFiaXMtMDAudHh0IiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAxMzYpOyI+ZHJhZnQt Y2xhaXNlLWlwZml4LXByb3RvY29sLXJmYzUxMDFiaXMtMDAudHh0PC9hPiZuYnNwOzxhIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWNsYWlzZS1pcGZp eC1wcm90b2NvbC1yZmM1MTAxYmlzLTAwLnR4dCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MTM2KTsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+Jmd0OzwvYT48L3RoPjx0aD48L3RoPjwv dHI+IA0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEIuIENsYWlzZSwgRWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+TmV0 d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEIuIENsYWlzZSwgRWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDEiPjwvYT48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj5SZXF1ZXN0IGZvciBDb21t ZW50czogNTEwMTwvc3Bhbj4gICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbyBTeXN0 ZW1zLCBJbmMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPkludGVybmV0IERyYWZ0PC9zcGFuPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMsIEluYy48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+Q2F0ZWdvcnk6IFN0 YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+SmFudWFyeSAyMDA4PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij5PYnNvbGV0ZXM6IDUxMDEgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAsIDIwMTE8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj5DYXRlZ29y eTogU3RhbmRhcmRzIFRyYWNrPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij5FeHBpcmVzOiBNYXJjaCAyMywgMjAxMjwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDAyIj48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgU3BlY2lmaWNh dGlvbiBvZiB0aGUgSVAgRmxvdyBJbmZvcm1hdGlvbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5F eDwvc3Bhbj5wb3J0IChJUEZJWCkgUHJvdG9jb2w8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgU3BlY2lmaWNhdGlvbiBvZiB0aGUgSVAgRmxvdyBJbmZvcm1hdGlvbiA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5lWDwvc3Bhbj5wb3J0IChJUEZJWCkgUHJvdG9jb2w8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgIGZvciB0aGUgRXhjaGFuZ2Ugb2YgSVAgVHJhZmZpYyBGbG93IEluZm9y bWF0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgZm9y IHRoZSBFeGNoYW5nZSBvZiBJUCBUcmFmZmljIEZsb3cgSW5mb3JtYXRpb248L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48 YSBuYW1lPSJkaWZmMDAwMyI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAg ICAgICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5kcmFmdC1jbGFpc2UtaXBmaXgtcHJvdG9jb2wt cmZjNTEwMWJpcy0wMDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+U3RhdHVz IG9mIFRoaXMgTWVtbzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIFRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIGFuIEludGVybmV0IHN0YW5kYXJkcyB0cmFjayBwcm90b2NvbCBm b3IgdGhlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgSW50ZXJuZXQgY29tbXVuaXR5LCBhbmQgcmVxdWVz dHMgZGlzY3Vzc2lvbiBhbmQgc3VnZ2VzdGlvbnMgZm9yPC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgaW1w cm92ZW1lbnRzLiAgUGxlYXNlIHJlZmVyIHRvIHRoZSBjdXJyZW50IGVkaXRpb24gb2YgdGhl ICJJbnRlcm5ldDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIE9mZmljaWFsIFByb3RvY29sIFN0YW5kYXJk cyIgKFNURCAxKSBmb3IgdGhlIHN0YW5kYXJkaXphdGlvbiBzdGF0ZTwvc3Bhbj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUi PiAgIGFuZCBzdGF0dXMgb2YgdGhpcyBwcm90b2NvbC4gIERpc3RyaWJ1dGlvbiBvZiB0aGlz IG1lbW8gaXMgdW5saW1pdGVkLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkFic3Ry YWN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+QWJzdHJhY3Q8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBzcGVj aWZpZXMgdGhlIElQIEZsb3cgSW5mb3JtYXRpb24gRXhwb3J0IChJUEZJWCk8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUg SVAgRmxvdyBJbmZvcm1hdGlvbiBFeHBvcnQgKElQRklYKTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHJvdG9jb2wgdGhh dCBzZXJ2ZXMgZm9yIHRyYW5zbWl0dGluZyBJUCBUcmFmZmljIEZsb3cgaW5mb3JtYXRpb248 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwcm90b2NvbCB0aGF0IHNlcnZl cyBmb3IgdHJhbnNtaXR0aW5nIElQIFRyYWZmaWMgRmxvdyBpbmZvcm1hdGlvbjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg b3ZlciB0aGUgbmV0d29yay4gIEluIG9yZGVyIHRvIHRyYW5zbWl0IElQIFRyYWZmaWMgRmxv dyBpbmZvcm1hdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG92ZXIg dGhlIG5ldHdvcmsuICBJbiBvcmRlciB0byB0cmFuc21pdCBJUCBUcmFmZmljIEZsb3cgaW5m b3JtYXRpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGZyb20gYW4gRXhwb3J0aW5nIFByb2Nlc3MgdG8gYW4gaW5mb3Jt YXRpb24gQ29sbGVjdGluZyBQcm9jZXNzLCBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgZnJvbSBhbiBFeHBvcnRpbmcgUHJvY2VzcyB0byBhbiBpbmZvcm1hdGlvbiBD b2xsZWN0aW5nIFByb2Nlc3MsIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbW1vbiByZXByZXNlbnRhdGlvbiBvZiBm bG93IGRhdGEgYW5kIGEgc3RhbmRhcmQgbWVhbnMgb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBjb21tb24gcmVwcmVzZW50YXRpb24gb2YgZmxvdyBkYXRhIGFuZCBh IHN0YW5kYXJkIG1lYW5zIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb21tdW5pY2F0aW5nIHRoZW0gaXMgcmVxdWly ZWQuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgdGhlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgY29tbXVuaWNhdGluZyB0aGVtIGlzIHJlcXVpcmVkLiAgVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSVBGSVggRGF0YSBhbmQgVGVt cGxhdGUgUmVjb3JkcyBhcmUgY2FycmllZCBvdmVyIGEgbnVtYmVyIG9mPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSVBGSVggRGF0YSBhbmQgVGVtcGxhdGUgUmVjb3Jk cyBhcmUgY2FycmllZCBvdmVyIGEgbnVtYmVyIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0cmFuc3BvcnQgcHJvdG9j b2xzIGZyb20gYW4gSVBGSVggRXhwb3J0aW5nIFByb2Nlc3MgdG8gYW4gSVBGSVg8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0cmFuc3BvcnQgcHJvdG9jb2xzIGZyb20g YW4gSVBGSVggRXhwb3J0aW5nIFByb2Nlc3MgdG8gYW4gSVBGSVg8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1l PSJkaWZmMDAwNCI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIENvbGxlY3Rpbmcg UHJvY2Vzcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgQ29sbGVjdGlu ZyBQcm9jZXNzLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+VGhpcyBkb2N1bWVudCBvYnNvbGV0 ZXMgUkZDIDUxMDEuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+U3RhdHVzIG9mIFRo aXMgTWVtbzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFRoaXMgSW50ZXJuZXQt RHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGU8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5Ljwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgVGFz ayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry aWJ1dGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1E cmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LTwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg IERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJl bnQvLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIEludGVybmV0LURyYWZ0cyBh cmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29s ZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgdGltZS4g IEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVu Y2U8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhh biBhcyAid29yayBpbiBwcm9ncmVzcy4iPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBNYXJjaCAyMywgMjAxMi48 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij5Db3B5cmlnaHQgTm90aWNlPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgQ29weXJpZ2h0IChjKSAyMDExIElFVEYgVHJ1c3Qg YW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgZG9j dW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQg dGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFByb3Zpc2lvbnMgUmVs YXRpbmcgdG8gSUVURiBEb2N1bWVudHM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAoaHR0cDovL3RydXN0 ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2Y8L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4gICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJl dmlldyB0aGVzZSBkb2N1bWVudHM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBjYXJlZnVsbHksIGFzIHRo ZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3Q8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4 dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGluY2x1 ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9u IDQuZSBvZjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFu ZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhczwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGRl c2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS48L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPlRhYmxlIG9mIENvbnRlbnRzPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+VGFibGUgb2YgQ29udGVudHM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYw MDA1Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgMS4gSW50cm9kdWN0aW9uIDxz cGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4zPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICAxLiAgSW50cm9kdWN0aW9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDU8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgIDEuMS4gSVBGSVggRG9jdW1lbnRzIE92ZXJ2aWV3IDxzcGFuIGNsYXNzPSJk ZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNDwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAxLjEuICBJUEZJWCBEb2N1bWVu dHMgT3ZlcnZpZXcgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA1PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAyLiBUZXJtaW5vbG9neSA8c3BhbiBj bGFzcz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIDIuICBUZXJtaW5vbG9neSAgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNjwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgICAgMi4xLiBUZXJtaW5vbG9neSBTdW1tYXJ5IFRhYmxlIDxzcGFuIGNsYXNzPSJkZWxl dGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45PC9zcGFuPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDIuMS4gIFRlcm1pbm9sb2d5IFN1bW1h cnkgVGFibGUgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTE8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDMuIElQRklYIE1lc3NhZ2UgRm9ybWF0IDxz cGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4xMDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg My4gIElQRklYIE1lc3NhZ2UgRm9ybWF0IDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAg ICAzLjEuIE1lc3NhZ2UgSGVhZGVyIEZvcm1hdCA8c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTE8L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgMy4xLiAgTWVzc2FnZSBIZWFkZXIgRm9ybWF0 ICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxMzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgMy4yLiBGaWVsZCBTcGVjaWZpZXIgRm9ybWF0 IDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjEzPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDMu Mi4gIEZpZWxkIFNwZWNpZmllciBGb3JtYXQgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIDMu My4gU2V0IGFuZCBTZXQgSGVhZGVyIEZvcm1hdCA8c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgICAzLjMuICBTZXQgYW5kIFNldCBIZWFkZXIgRm9ybWF0 ICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDE1PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgIDMuMy4xLiBTZXQgRm9ybWF0IDxzcGFuIGNs YXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u MTQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAzLjMu MS4gIFNldCBGb3JtYXQgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAz LjMuMi4gU2V0IEhlYWRlciBGb3JtYXQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Li4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE1PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICAgICAgMy4zLjIuICBTZXQgSGVhZGVyIEZvcm1hdCAgPHNwYW4g Y2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTY8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgICAgIDMuNC4gUmVjb3JkIEZvcm1hdCA8c3BhbiBjbGFzcz0iZGVs ZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNjwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAzLjQuICAgUmVj b3JkIEZvcm1hdCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgIDMuNC4x LiBUZW1wbGF0ZSBSZWNvcmQgRm9ybWF0IDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMTY8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgICAgICAzLjQuMS4gIFRlbXBsYXRlIFJlY29yZCBGb3JtYXQgPHNwYW4g Y2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNzwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICAgICAgICAzLjQuMi4gT3B0aW9ucyBUZW1wbGF0ZSBSZWNvcmQgRm9y bWF0IDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE4PC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgMy40LjIuICBPcHRp b25zIFRlbXBsYXRlIFJlY29yZCBGb3JtYXQgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgICAgIDMu NC4yLjEuIFNjb3BlIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4xOTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgICAgICAgMy40LjIuMS4gIFNjb3BlICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4u IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICAgICAgICAgICAgICAgICAzLjQuMi4yLiBPcHRpb25zIFRlbXBsYXRlIFJlY29y ZCBGb3JtYXQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Li4uLi4uLi4uLi4uMjA8L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgIDMuNC4yLjIuICBPcHRp b25zIFRlbXBsYXRlIFJlY29yZCBGb3JtYXQgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4g LiAuIC4gLiAuIC4gLiAyMTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAzLjQuMy4gRGF0YSBS ZWNvcmQgRm9ybWF0IDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjIyPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICAgICAgMy40LjMuICBEYXRhIFJlY29yZCBGb3JtYXQgPHNwYW4gY2xhc3M9Imluc2Vy dCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjM8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIDQuIFNwZWNpZmljIFJlcG9ydGluZyBSZXF1aXJlbWVudHMgPHNwYW4gY2xhc3M9ImRl bGV0ZSI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMzwvc3Bhbj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgNC4gIFNwZWNpZmljIFJlcG9ydGluZyBS ZXF1aXJlbWVudHMgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDI0PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICA0LjEuIFRoZSBNZXRlcmluZyBQcm9j ZXNzIFN0YXRpc3RpY3MgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+T3B0aW9uPC9zcGFuPiBUZW1w bGF0ZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4uLi4uLi4uLjIzPC9zcGFuPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDQuMS4gIFRoZSBNZXRlcmluZyBQcm9j ZXNzIFN0YXRpc3RpY3MgPHNwYW4gY2xhc3M9Imluc2VydCI+T3B0aW9uczwvc3Bhbj4gVGVt cGxhdGUgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIDI0PC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICAgICA0LjIuIFRoZSBNZXRlcmluZyBQcm9jZXNzIFJlbGlhYmlsaXR5IFN0YXRpc3RpY3Mg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+T3B0aW9uPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICAgIDQuMi4gIFRoZSBNZXRlcmluZyBQcm9jZXNzIFJlbGlhYmls aXR5IFN0YXRpc3RpY3MgPHNwYW4gY2xhc3M9Imluc2VydCI+T3B0aW9uczwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgICAgICAgICBUZW1wbGF0ZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI0PC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgIFRlbXBsYXRlIDxzcGFu IGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMjU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIDQuMy4gVGhlIEV4cG9ydGluZyBQ cm9jZXNzIFJlbGlhYmlsaXR5IFN0YXRpc3RpY3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICA0LjMuICBUaGUgRXhwb3J0aW5nIFByb2Nlc3MgUmVsaWFiaWxpdHkg U3RhdGlzdGljcyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5PcHRpb25zPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICAgICAgICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPk9wdGlvbjwvc3Bhbj4gVGVtcGxhdGUg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjI1PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICAgICAgICAgIFRlbXBsYXRlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjY8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg ICAgIDQuNC4gVGhlIEZsb3cgS2V5cyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5PcHRpb248L3Nw YW4+IFRlbXBsYXRlIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMjY8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg ICAgNC40LiAgVGhlIEZsb3cgS2V5cyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5PcHRpb25zPC9z cGFuPiBUZW1wbGF0ZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMjc8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDUuIElQRklYIE1lc3NhZ2UgSGVhZGVyICJF eHBvcnQgVGltZSIgYW5kIEZsb3cgUmVjb3JkIFRpbWUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ Li4uLi4uLi4yNzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg NS4gIElQRklYIE1lc3NhZ2UgSGVhZGVyICJFeHBvcnQgVGltZSIgYW5kIEZsb3cgUmVjb3Jk IFRpbWUgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIDI4PC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA2 LiBMaW5rYWdlIHdpdGggdGhlIEluZm9ybWF0aW9uIE1vZGVsIDxzcGFuIGNsYXNzPSJkZWxl dGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjg8L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDYuICBMaW5rYWdlIHdpdGggdGhlIEluZm9ybWF0 aW9uIE1vZGVsIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyOTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgNi4xLiBFbmNvZGluZyBvZiBJUEZJWCBEYXRh IFR5cGVzIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjI4PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDYu MS4gIEVuY29kaW5nIG9mIElQRklYIERhdGEgVHlwZXMgPHNwYW4gY2xhc3M9Imluc2VydCI+ LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjk8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAg ICAgNi4xLjEuIEludGVncmFsIERhdGEgVHlwZXMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Li4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yODwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgICAgIDYuMS4xLiAgSW50ZWdyYWwgRGF0YSBUeXBlcyAg PHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDI5PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgIDYuMS4yLiBBZGRyZXNzIFR5cGVzIDxzcGFu IGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Mjg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICA2LjEu Mi4gIEFkZHJlc3MgVHlwZXMgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICA2 LjEuMy4gZmxvYXQzMiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI4PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICAgICAgNi4xLjMuICBmbG9hdDMyICA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjk8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgICAgICAgICAgNi4xLjQuIGZsb2F0NjQgPHNwYW4gY2xhc3M9ImRl bGV0ZSI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yODwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgIDYuMS40LiAg ZmxvYXQ2NCAgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI5PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgIDYuMS41 LiBib29sZWFuIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMjg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgICAgICA2LjEuNS4gIGJvb2xlYW4gIDxzcGFuIGNsYXNzPSJpbnNlcnQi Pi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOTwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICAgICAgICA2LjEuNi4gc3RyaW5nIGFuZCA8c3BhbiBjbGFzcz0iZGVs ZXRlIj5vY3RldGFycmF5IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI4PC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgNi4xLjYuICBzdHJp bmcgYW5kIDxzcGFuIGNsYXNzPSJpbnNlcnQiPm9jdGV0QXJyYXkgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMjk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgNi4xLjcuIGRh dGVUaW1lU2Vjb25kcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4yOTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgICAgIDYuMS43LiAgZGF0ZVRpbWVTZWNvbmRzICA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMwPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICAgICAgICAgIDYuMS44LiBkYXRlVGltZU1pbGxpc2Vjb25kcyA8c3BhbiBjbGFz cz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjk8L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICA2LjEuOC4gIGRhdGVUaW1l TWlsbGlzZWNvbmRzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAzMDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICA2LjEuOS4gZGF0ZVRp bWVNaWNyb3NlY29uZHMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Li4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjI5PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICAgICAgNi4xLjkuICBkYXRlVGltZU1pY3Jvc2Vjb25kcyA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzA8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAgNi4xLjEwLmRhdGVUaW1lTmFub3Nl Y29uZHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yOTwvc3Bhbj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAg IDYuMS4xMC4gIGRhdGVUaW1lTmFub3NlY29uZHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDMwPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICA2LjIuIFJlZHVjZWQgU2l6ZSBFbmNv ZGluZyBvZiBJbnRlZ2VyIGFuZCBGbG9hdCBUeXBlcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj4u Li4uLi4uLi4uMjk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg ICAgNi4yLiAgUmVkdWNlZCBTaXplIEVuY29kaW5nIG9mIEludGVnZXIgYW5kIEZsb2F0IFR5 cGVzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAzMDwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg Ny4gVmFyaWFibGUtTGVuZ3RoIEluZm9ybWF0aW9uIEVsZW1lbnQgPHNwYW4gY2xhc3M9ImRl bGV0ZSI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMwPC9zcGFuPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA3LiAgVmFyaWFibGUtTGVuZ3RoIEluZm9ybWF0 aW9uIEVsZW1lbnQgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMzE8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDguIFRlbXBsYXRlIE1hbmFnZW1lbnQgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4zMTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgOC4g IFRlbXBsYXRlIE1hbmFnZW1lbnQgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMyPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA5LiBU aGUgQ29sbGVjdGluZyBQcm9jZXNzJ3MgU2lkZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgIDkuICBUaGUgQ29sbGVjdGluZyBQcm9jZXNzJ3MgU2lk ZSAgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAzNTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgMTAuIFRyYW5zcG9ydCBQcm90b2NvbCA8c3BhbiBjbGFz cz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjM2PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAxMC4gIFRy YW5zcG9ydCBQcm90b2NvbCAgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzc8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIDEwLjEu IFRyYW5zcG9ydCBDb21wbGlhbmNlIGFuZCBUcmFuc3BvcnQgVXNhZ2UgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+Li4uLi4uLi4uLi4uLi4uLi4zNjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgICAxMC4xLiAgVHJhbnNwb3J0IENvbXBsaWFuY2UgYW5kIFRy YW5zcG9ydCBVc2FnZSAgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIDM3 PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICAgICAxMC4yLiBTQ1RQIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzc8 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgMTAuMi4gIFND VFAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzODwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAxMC4y LjEuIENvbmdlc3Rpb24gQXZvaWRhbmNlIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjM3PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICAgICAgMTAuMi4xLiAgQ29uZ2VzdGlvbiBBdm9pZGFuY2UgIDxzcGFu IGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzg8L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgICAgICAgICAgMTAuMi4yLiBSZWxpYWJpbGl0eSA8c3BhbiBjbGFzcz0i ZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zNzwvc3Bh bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgIDEwLjIuMi4gIFJl bGlhYmlsaXR5IDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDM4PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgIDEwLjIuMy4g TVRVIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMzc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgICAgICAxMC4yLjMuICBNVFUgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzODwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgICAgICAgICAxMC4yLjQuIEV4cG9ydGluZyBQcm9jZXNzIDxzcGFuIGNsYXNz PSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjM4PC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgMTAuMi40LiAgRXhwb3J0 aW5nIFByb2Nlc3MgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMzk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgICAgIDEwLjIu NC4xLiBBc3NvY2lhdGlvbiBFc3RhYmxpc2htZW50IDxzcGFuIGNsYXNzPSJkZWxldGUiPi4u Li4uLi4uLi4uLi4uLi4zODwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgICAgICAgMTAuMi40LjEuICBBc3NvY2lhdGlvbiBFc3RhYmxpc2htZW50IDxzcGFu IGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM5PC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICAgICAgICAgICAgICAgICAxMC4yLjQuMi4gQXNzb2NpYXRpb24gU2h1dGRvd24gPHNw YW4gY2xhc3M9ImRlbGV0ZSI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uMzg8L3NwYW4+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgIDEwLjIuNC4yLiAgIEFzc29j aWF0aW9uIFNodXRkb3duIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAzOTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgMTAuMi40LjMu IFN0cmVhbSA8c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjM4PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICAgICAgICAxMC4yLjQuMy4gIFN0cmVhbSAgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzk8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg ICAgICAgICAgICAgICAgIDEwLjIuNC40LiBUZW1wbGF0ZSBNYW5hZ2VtZW50IDxzcGFuIGNs YXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zOTwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgMTAuMi40LjQuICBUZW1wbGF0ZSBN YW5hZ2VtZW50IDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDQwPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgIDEwLjIuNS4gQ29sbGVjdGluZyBQ cm9jZXNzIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMzk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAg ICAxMC4yLjUuICBDb2xsZWN0aW5nIFByb2Nlc3MgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MDwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAg ICAgICAxMC4yLjYuIEZhaWxvdmVyIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjM5PC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgMTAuMi42LiAgRmFpbG92ZXIgIDxzcGFuIGNs YXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNDA8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIDEwLjMuIFVEUCA8c3BhbiBjbGFzcz0iZGVsZXRl Ij4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4zOTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAxMC4z LiAgVURQIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQwPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAg IDEwLjMuMS4gQ29uZ2VzdGlvbiBBdm9pZGFuY2UgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Li4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgICAgICAxMC4zLjEuICBDb25nZXN0aW9uIEF2b2lkYW5jZSAg PHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0 MDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgICAgICAgICAxMC4zLjIuIFJlbGlhYmlsaXR5IDxzcGFuIGNs YXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQw PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgMTAuMy4y LiAgUmVsaWFiaWxpdHkgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDE8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgMTAu My4zLiBNVFUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi40MDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgICAgIDEwLjMuMy4gIE1UVSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4u IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQxPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICAgICAgICAgIDEwLjMuNC4gUG9ydCBOdW1iZXJzIDxzcGFuIGNsYXNz PSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNDA8L3Nw YW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAxMC4zLjQuICBQ b3J0IE51bWJlcnMgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA0MTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAxMC4zLjUu IEV4cG9ydGluZyBQcm9jZXNzIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjQwPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICAgICAgMTAuMy41LiAgRXhwb3J0aW5nIFByb2Nlc3MgPHNwYW4gY2xhc3M9 Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDE8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgICAgICAgICAgMTAuMy42LiBUZW1wbGF0ZSBNYW5hZ2VtZW50IDxzcGFuIGNs YXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40MDwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgIDEwLjMuNi4gIFRlbXBs YXRlIE1hbmFnZW1lbnQgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDQxPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgIDEwLjMuNy4gQ29s bGVjdGluZyBQcm9jZXNzIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uNDE8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgICAgICAxMC4zLjcuICBDb2xsZWN0aW5nIFByb2Nlc3MgIDxzcGFuIGNsYXNzPSJp bnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0Mjwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgICAgICAgICAxMC4zLjguIEZhaWxvdmVyIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQyPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgMTAuMy44LiAgRmFpbG92ZXIg IDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNDM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIDEwLjQuIFRDUCA8c3BhbiBjbGFz cz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi40Mjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgICAxMC40LiAgVENQIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQzPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICAgICAgICAgIDEwLjQuMS4gQ29ubmVjdGlvbiBNYW5hZ2VtZW50IDxzcGFuIGNsYXNzPSJk ZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNDI8L3NwYW4+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAxMC40LjEuICBDb25uZWN0aW9uIE1h bmFnZW1lbnQgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA0Mzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgMTAuNC4xLjEuIENv bm5lY3Rpb24gRXN0YWJsaXNobWVudCA8c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4uLi4uLi4u Li4uLi4uLjQyPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAg ICAgICAxMC40LjEuMS4gIENvbm5lY3Rpb24gRXN0YWJsaXNobWVudCAgPHNwYW4gY2xhc3M9 Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDM8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAg ICAgICAgICAgICAgIDEwLjQuMS4yLiBHcmFjZWZ1bCBDb25uZWN0aW9uIFJlbGVhc2UgPHNw YW4gY2xhc3M9ImRlbGV0ZSI+Li4uLi4uLi4uLi4uLi40Mzwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgMTAuNC4xLjIuICBHcmFjZWZ1bCBDb25u ZWN0aW9uIFJlbGVhc2UgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4g LiAuIDQ0PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAxMC40LjEuMy4gUmVzdGFy dGluZyBJbnRlcnJ1cHRlZCBDb25uZWN0aW9ucyA8c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4u Li4uNDM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAg IDEwLjQuMS4zLiAgUmVzdGFydGluZyBJbnRlcnJ1cHRlZCBDb25uZWN0aW9ucyAgPHNwYW4g Y2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiA0NDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAg ICAgICAgICAgMTAuNC4xLjQuIEZhaWxvdmVyIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQzPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAxMC40LjEuNC4gIEZhaWxvdmVyICA8c3BhbiBj bGFzcz0iaW5zZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NDQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgMTAuNC4yLiBEYXRhIFRyYW5zbWlzc2lvbiA8 c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40 Mzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgIDEwLjQu Mi4gIERhdGEgVHJhbnNtaXNzaW9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ0PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAg ICAgICAxMC40LjIuMS4gSVBGSVggTWVzc2FnZSBFbmNvZGluZyA8c3BhbiBjbGFzcz0iZGVs ZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4uNDM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgICAgICAgIDEwLjQuMi4xLiAgSVBGSVggTWVzc2FnZSBFbmNvZGlu ZyAgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NDwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgMTAuNC4yLjIuIFRlbXBsYXRlIE1hbmFn ZW1lbnQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjQ0PC9z cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAxMC40LjIu Mi4gIFRlbXBsYXRlIE1hbmFnZW1lbnQgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gNDU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgICAg IDEwLjQuMi4zLiBDb25nZXN0aW9uIEhhbmRsaW5nIGFuZCBSZWxpYWJpbGl0eSA8c3BhbiBj bGFzcz0iZGVsZXRlIj4uLi4uLi40NDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAgICAgMTAuNC4yLjMuICBDb25nZXN0aW9uIEhhbmRsaW5nIGFuZCBS ZWxpYWJpbGl0eSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4uIC4gLiAuIC4gLiAuIDQ1PC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICAgICAgICAgIDEwLjQuMy4gQ29sbGVjdGluZyBQcm9jZXNzIDxzcGFuIGNs YXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNDU8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAxMC40LjMuICBDb2xs ZWN0aW5nIFByb2Nlc3MgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA0Nzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgMTEuIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjQ2PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICAxMS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIDxzcGFuIGNsYXNzPSJpbnNl cnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDg8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgIDExLjEuIEFwcGxpY2FiaWxpdHkgb2YgVExTIGFuZCBEVExTIDxzcGFuIGNs YXNzPSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40Nzwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAxMS4xLiAgQXBwbGljYWJpbGl0 eSBvZiBUTFMgYW5kIERUTFMgPHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDQ5PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAxMS4yLiBVc2FnZSA8c3BhbiBj bGFzcz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uNDg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgICAgMTEuMi4gIFVzYWdlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1MDwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgICAgMTEuMy4gQXV0aGVudGljYXRpb24gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Li4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQ4PC9zcGFuPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDExLjMuICBBdXRoZW50aWNhdGlvbiAg PHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gNTA8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIDExLjQuIFByb3RlY3Rpb24gYWdhaW5z dCBEb1MgQXR0YWNrcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi40ODwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg ICAxMS40LiAgUHJvdGVjdGlvbiBhZ2FpbnN0IERvUyBBdHRhY2tzICA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUwPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAg ICAxMS41LiBXaGVuIERUTFMgb3IgVExTIElzIE5vdCBhbiBPcHRpb24gPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNTA8L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgMTEuNS4gIFdoZW4gRFRMUyBvciBUTFMgSXMg Tm90IGFuIE9wdGlvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA1Mjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgMTEuNi4gTG9nZ2luZyBhbiBJUEZJWCBBdHRh Y2sgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjUwPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDEx LjYuICBMb2dnaW5nIGFuIElQRklYIEF0dGFjayA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4uIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTI8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIDEx LjcuIFNlY3VyaW5nIHRoZSBDb2xsZWN0b3IgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Li4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41MTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgICAxMS43LiAgU2VjdXJpbmcgdGhlIENvbGxlY3RvciAg PHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDUzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICAxMi4gSUFOQSBDb25zaWRlcmF0aW9ucyA8c3BhbiBjbGFz cz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u NTE8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDEyLiAgSUFO QSBDb25zaWRlcmF0aW9ucyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4uIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1Mzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQXBwZW5kaXgg QS4gSVBGSVggRW5jb2RpbmcgRXhhbXBsZXMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Li4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUyPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICBBcHBlbmRpeCBBLiAgSVBGSVggRW5jb2RpbmcgRXhhbXBsZXMg PHNwYW4gY2xhc3M9Imluc2VydCI+LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTQ8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgICAgIEEuMS4gTWVzc2FnZSBIZWFkZXIgPHNwYW4gY2xhc3M9ImRl bGV0ZSI+RXhhbXBsZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41Mjwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICBBLjEuICBNZXNz YWdlIEhlYWRlciA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5FeGFtcGxlIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU0PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBBLjIuIFRlbXBs YXRlIFNldCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5FeGFtcGxlcy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uNTM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgICAgQS4yLiAgVGVtcGxhdGUgU2V0IDxzcGFuIGNsYXNzPSJpbnNlcnQi PkV4YW1wbGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NTwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICAgICAgICBBLjIuMS4gVGVtcGxhdGUgU2V0IFVzaW5nIElFVEYtU3Bl Y2lmaWVkIEluZm9ybWF0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg ICAgICBBLjIuMS4gIFRlbXBsYXRlIFNldCBVc2luZyBJRVRGLVNwZWNpZmllZCBJbmZvcm1h dGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICBFbGVtZW50cyA8c3BhbiBjbGFzcz0iZGVs ZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNTM8L3Nw YW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgIEVs ZW1lbnRzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA1NTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICBBLjIuMi4g VGVtcGxhdGUgU2V0IFVzaW5nIEVudGVycHJpc2UtU3BlY2lmaWMgSW5mb3JtYXRpb248L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgIEEuMi4yLiAgVGVtcGxhdGUg U2V0IFVzaW5nIEVudGVycHJpc2UtU3BlY2lmaWMgSW5mb3JtYXRpb248L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAg ICAgICAgICAgICAgRWxlbWVudHMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Li4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUzPC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICBFbGVtZW50cyA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNTU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIEEuMy4gRGF0YSBTZXQgRXhhbXBsZSA8c3BhbiBj bGFzcz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li41NTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICBBLjMu ICBEYXRhIFNldCBFeGFtcGxlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU3PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBBLjQu IE9wdGlvbnMgVGVtcGxhdGUgU2V0IEV4YW1wbGVzIDxzcGFuIGNsYXNzPSJkZWxldGUiPi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNTY8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgICAgQS40LiAgT3B0aW9ucyBUZW1wbGF0ZSBTZXQgRXhhbXBs ZXMgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1 ODwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgICAgICAgICBBLjQuMS4gT3B0aW9ucyBUZW1wbGF0ZSBTZXQg VXNpbmcgSUVURi1TcGVjaWZpZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgICAgIEEuNC4xLiAgT3B0aW9ucyBUZW1wbGF0ZSBTZXQgVXNpbmcgSUVURi1TcGVjaWZp ZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICAgICAgICAgICAgICAgSW5mb3JtYXRpb24gRWxlbWVudHMgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjU2PC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICBJbmZv cm1hdGlvbiBFbGVtZW50cyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4uIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNTg8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgQS40LjIuIE9w dGlvbnMgVGVtcGxhdGUgU2V0IFVzaW5nIEVudGVycHJpc2UtU3BlY2lmaWM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgIEEuNC4yLiAgT3B0aW9ucyBUZW1wbGF0 ZSBTZXQgVXNpbmcgRW50ZXJwcmlzZS1TcGVjaWZpYzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAg ICBJbmZvcm1hdGlvbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5FbGVtZW50cyAuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uNTY8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgICAgICAgICAgICAgIEluZm9ybWF0aW9uICA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1ODwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICAgICAgICBBLjQuMy4gT3B0aW9ucyBUZW1wbGF0ZSBTZXQgVXNpbmcg YW4gRW50ZXJwcmlzZS1TcGVjaWZpYzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICAgICAgQS40LjMuICBPcHRpb25zIFRlbXBsYXRlIFNldCBVc2luZyBhbiBFbnRlcnBy aXNlLVNwZWNpZmljPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgICAgIFNjb3BlIDxzcGFuIGNsYXNz PSJkZWxldGUiPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li41Nzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAg ICAgICAgU2NvcGUgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU5PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAg IEEuNC40LiBEYXRhIFNldCBVc2luZyBhbiBFbnRlcnByaXNlLVNwZWNpZmljIFNjb3BlIDxz cGFuIGNsYXNzPSJkZWxldGUiPi4uLi4uLi4uNTg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgICAgICBBLjQuNC4gIERhdGEgU2V0IFVzaW5nIGFuIEVudGVy cHJpc2UtU3BlY2lmaWMgU2NvcGUgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiA2 MDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgICAgQS41LiBWYXJpYWJsZS1MZW5ndGggSW5mb3JtYXRpb24g RWxlbWVudCBFeGFtcGxlcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLjU5 PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIEEuNS4gIFZh cmlhYmxlLUxlbmd0aCBJbmZvcm1hdGlvbiBFbGVtZW50IEV4YW1wbGVzIDxzcGFuIGNsYXNz PSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gNjE8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgQS41 LjEuIEV4YW1wbGUgb2YgVmFyaWFibGUtTGVuZ3RoIEluZm9ybWF0aW9uIEVsZW1lbnQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgIEEuNS4xLiAgRXhhbXBsZSBv ZiBWYXJpYWJsZS1MZW5ndGggSW5mb3JtYXRpb24gRWxlbWVudCB3aXRoPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAg ICAgICAgICAgICAgIHdpdGggTGVuZ3RoIDxzcGFuIGNsYXNzPSJkZWxldGUiPkluZmVyaW9y IHRvIDI1NSBPY3RldHMgLi4uLi4uLi4uLi4uLi4uLi41OTwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgTGVuZ3RoIDxzcGFuIGNsYXNz PSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDYxPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgIEEuNS4yLiBFeGFtcGxlIG9mIFZhcmlh YmxlLUxlbmd0aCBJbmZvcm1hdGlvbiBFbGVtZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgICAgICBBLjUuMi4gIEV4YW1wbGUgb2YgVmFyaWFibGUtTGVuZ3RoIElu Zm9ybWF0aW9uIEVsZW1lbnQgd2l0aDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICB3aXRoIExl bmd0aCA8c3BhbiBjbGFzcz0iZGVsZXRlIj4yNTUgdG8gNjU1MzUgT2N0ZXRzIC4uLi4uLi4u Li4uLi4uLi4uLi4uNTk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjMgT2N0ZXQ8L3NwYW4+IExl bmd0aCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5FbmNvZGluZyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNjE8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFJlZmVyZW5jZXMgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi41OTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgUmVmZXJlbmNlcyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDYxPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICAgICBOb3JtYXRpdmUgUmVmZXJlbmNlcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNTk8L3NwYW4+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIDxzcGFu IGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA2MTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyA8 c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjYwPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBJ bmZvcm1hdGl2ZSBSZWZlcmVuY2VzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPi4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjI8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEFj a25vd2xlZGdtZW50cyA8c3BhbiBjbGFzcz0iZGVsZXRlIj4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42MTwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgQWNrbm93bGVkZ21lbnRzICA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDY0PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY1PC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4g Y2xhc3M9Imluc2VydCI+RE9ORTo8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBFcnJhdGEgSUQ6IDE2 NTUgKHRlY2huaWNhbCk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBFcnJhdGEgSUQ6IDI3OTEgKHRl Y2huaWNhbCk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBFcnJhdGEgSUQ6IDI4MTQgKGVkaXRvcmlh bCk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICAgICBFcnJhdGEgSUQ6IDE4MTggKGVkaXRvcmlhbCk8L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4gICAgICBFcnJhdGEgSUQ6IDI3OTIgKGVkaXRvcmlhbCk8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICAgICBFcnJhdGEgSUQ6IDI4ODggKGVkaXRvcmlhbCk8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICAgICBFcnJhdGEgSUQ6IDI4ODkgKGVkaXRvcmlhbCk8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBF cnJhdGEgSUQ6IDI4OTAgKGVkaXRvcmlhbCk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBFcnJhdGEg SUQ6IDI4OTEgKGVkaXRvcmlhbCk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBFcnJhdGEgSUQ6IDI4 OTIgKGVkaXRvcmlhbCk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBFcnJhdGEgSUQ6IDI5MDMgKGVk aXRvcmlhbCk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBFcnJhdGEgSUQ6IDI3NjEgKGVkaXRvcmlh bCk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICAgICBFcnJhdGEgSUQ6IDI3NjIgKGVkaXRvcmlhbCk8L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4gICAgICBFcnJhdGEgSUQ6IDI3NjMgKGVkaXRvcmlhbCk8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICAgICBFcnJhdGEgSUQ6IDI3NjQgKGVkaXRvcmlhbCk8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICAgICBFcnJhdGEgSUQ6IDI4NTIgKGVkaXRvcmlhbCk8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBF cnJhdGEgSUQ6IDI4NTcgKGVkaXRvcmlhbCk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICAgICBTZWN0aW9uIDg6ICJhIG5ldyBzYW1wbGluZyByYXRlIiBoYXMgYmVlbiByZW1v dmVkIGZyb20gdGhlIGxpc3Qgb2Y8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBl eGFtcGxlcyB0aGF0IHJlcXVpcmVzIGEgbmV3IFRlbXBsYXRlLjwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgICAgIElmIHRoZSBtZWFzdXJlbWVudCBwYXJhbWV0ZXJzIGNoYW5n ZSBzdWNoIHRoYXQgYSBuZXcgVGVtcGxhdGUgaXM8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICByZXF1aXJl ZCwgdGhlIFRlbXBsYXRlIE1VU1QgYmUgd2l0aGRyYXduICh1c2luZyBhIFRlbXBsYXRlIFdp dGhkcmF3PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgTWVzc2FnZSBhbmQgYSBuZXcgVGVtcGxhdGUgZGVm aW5pdGlvbikgb3IgYW4gdW51c2VkIFRlbXBsYXRlIElEIE1VU1Q8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICAgYmUgdXNlZC4gIEV4YW1wbGVzIG9mIHRoZSBtZWFzdXJlbWVudCBjaGFuZ2VzIGFyZTog YSBuZXcgc2FtcGxpbmc8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICByYXRlLCBhIG5ldyBGbG93IGV4cGly YXRpb24gcHJvY2VzcywgYSBuZXcgZmlsdGVyaW5nIGRlZmluaXRpb24sIGV0Yy48L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBVcGRhdGVkIHRoZSByZWZlcmVuY2VzPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgVXBkYXRlZCB0aGUgIkRvY3VtZW50 IG92ZXJ2aWV3IiBzZWN0aW9uLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAg IFRlbXBsYXRlIGFuZCBVRFA6IGluY2x1ZGVkIHRoZSBwcm9wb3NhbCBhdDwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pcGZpeC9jdXJy ZW50L21zZzA2MDUxLmh0bWw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UTyBETzo8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICAgICAidGltZSBmaXJzdCBmbG93IGRyb3BwZWQiIGFuZCAidGlt ZSBsYXN0IGZsb3cgZHJvcHBlZCI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBpbmNvbnNpc3RlbmN5LiBT ZWUgdGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgUmVw bGFjZSB0aGUgUkZDNTEwMiBieSBSRkM1MTAyYmlzLCB3aGVuIHRoZSBkcmFmdCB3aWxsIGJl IHBvc3RlZC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBSZXBsYWNlIHRoZSBSRkM1ODE1IGJ5IFJG QzU4MTViaXMsIHdoZW4gdGhlIGRyYWZ0IHdpbGwgYmUgcG9zdGVkLjwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgICAgIE5UUCBSRkMgMTMwNSBpcyBvYnNvbGV0ZWQgYnkgUkZDNTkwNS4gQ2hlY2sgaWYg dGhlIGZvcm1hdCBpcyB0aGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBzaW1pbGFyIGJlZm9yZSB1cGRh dGluZyB0aGUgcmVmZXJlbmNlLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIElETkEgUkZDIDM0OTAg aXMgb2Jzb2xldGVkIGJ5IFJGQzU4OTAgYW5kIFJGQzU4OTEuIERvdWJsZS1jaGVjazwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MS4gIEludHJv ZHVjdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjEuICBJbnRyb2R1Y3Rp b248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQSBkYXRh IG5ldHdvcmsgd2l0aCBJUCB0cmFmZmljIHByaW1hcmlseSBjb25zaXN0cyBvZiBJUCBmbG93 cyBwYXNzaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQSBkYXRhIG5l dHdvcmsgd2l0aCBJUCB0cmFmZmljIHByaW1hcmlseSBjb25zaXN0cyBvZiBJUCBmbG93cyBw YXNzaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICB0aHJvdWdoIHRoZSBuZXR3b3JrIGVsZW1lbnRzLiAgSXQgaXMgb2Z0 ZW4gaW50ZXJlc3RpbmcsIHVzZWZ1bCwgb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICB0aHJvdWdoIHRoZSBuZXR3b3JrIGVsZW1lbnRzLiAgSXQgaXMgb2Z0ZW4gaW50 ZXJlc3RpbmcsIHVzZWZ1bCwgb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGV2ZW4gcmVxdWlyZWQgdG8gaGF2ZSBhY2Nl c3MgdG8gaW5mb3JtYXRpb24gYWJvdXQgdGhlc2UgZmxvd3MgdGhhdDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGV2ZW4gcmVxdWlyZWQgdG8gaGF2ZSBhY2Nlc3MgdG8g aW5mb3JtYXRpb24gYWJvdXQgdGhlc2UgZmxvd3MgdGhhdDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcGFzcyB0aHJvdWdo IHRoZSBuZXR3b3JrIGVsZW1lbnRzIGZvciBhZG1pbmlzdHJhdGl2ZSBvciBvdGhlcjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHBhc3MgdGhyb3VnaCB0aGUgbmV0d29y ayBlbGVtZW50cyBmb3IgYWRtaW5pc3RyYXRpdmUgb3Igb3RoZXI8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHB1cnBvc2Vz LiAgVGhlIElQRklYIENvbGxlY3RpbmcgUHJvY2VzcyBzaG91bGQgYmUgYWJsZSB0byByZWNl aXZlIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHB1cnBvc2VzLiAg VGhlIElQRklYIENvbGxlY3RpbmcgUHJvY2VzcyBzaG91bGQgYmUgYWJsZSB0byByZWNlaXZl IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgZmxvdyBpbmZvcm1hdGlvbiBwYXNzaW5nIHRocm91Z2ggbXVsdGlwbGUg bmV0d29yayBlbGVtZW50cyB3aXRoaW4gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgZmxvdyBpbmZvcm1hdGlvbiBwYXNzaW5nIHRocm91Z2ggbXVsdGlwbGUgbmV0 d29yayBlbGVtZW50cyB3aXRoaW4gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkYXRhIG5ldHdvcmsuICBUaGlzIHJl cXVpcmVzIHVuaWZvcm1pdHkgaW4gdGhlIG1ldGhvZCBvZiByZXByZXNlbnRpbmc8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkYXRhIG5ldHdvcmsuICBUaGlzIHJlcXVp cmVzIHVuaWZvcm1pdHkgaW4gdGhlIG1ldGhvZCBvZiByZXByZXNlbnRpbmc8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAg ICAgPHRyIGJnY29sb3I9ImdyYXkiPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWwyIj48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgNCwgbGluZSAx OTwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXIyIj48c21hbGw+ c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgNiwgbGluZSA0PC9lbT48 L2E+PC90aD48dGQ+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNwZWNpZmllcyB0aGUgcHJv dG9jb2wgdG8gYWNoaWV2ZSB0aGVzZSBhZm9yZW1lbnRpb25lZCByZXF1aXJlbWVudHMuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc3BlY2lmaWVzIHRoZSBwcm90b2Nv bCB0byBhY2hpZXZlIHRoZXNlIGFmb3JlbWVudGlvbmVkIHJlcXVpcmVtZW50cy48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGluIGRldGFpbCB0aGUgcmVwcmVzZW50YXRpb24g b2YgZGlmZmVyZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBk b2N1bWVudCBzcGVjaWZpZXMgaW4gZGV0YWlsIHRoZSByZXByZXNlbnRhdGlvbiBvZiBkaWZm ZXJlbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGZsb3dzLCB0aGUgYWRkaXRpb25hbCBkYXRhIHJlcXVpcmVkIGZvciBm bG93IGludGVycHJldGF0aW9uLCBwYWNrZXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBmbG93cywgdGhlIGFkZGl0aW9uYWwgZGF0YSByZXF1aXJlZCBmb3IgZmxvdyBp bnRlcnByZXRhdGlvbiwgcGFja2V0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmb3JtYXQsIHRyYW5zcG9ydCBtZWNoYW5p c21zIHVzZWQsIHNlY3VyaXR5IGNvbmNlcm5zLCBldGMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgZm9ybWF0LCB0cmFuc3BvcnQgbWVjaGFuaXNtcyB1c2VkLCBzZWN1 cml0eSBjb25jZXJucywgZXRjLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4xLjEuICBJUEZJWCBEb2N1bWVudHMgT3ZlcnZpZXc8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4xLjEuICBJUEZJWCBEb2N1bWVudHMgT3ZlcnZpZXc8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIElQRklYIHByb3Rv Y29sIHByb3ZpZGVzIG5ldHdvcmsgYWRtaW5pc3RyYXRvcnMgd2l0aCBhY2Nlc3MgdG8gSVA8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgSVBGSVggcHJvdG9jb2wg cHJvdmlkZXMgbmV0d29yayBhZG1pbmlzdHJhdG9ycyB3aXRoIGFjY2VzcyB0byBJUDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgZmxvdyBpbmZvcm1hdGlvbi4gIFRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBleHBvcnQg b2YgbWVhc3VyZWQgSVA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmbG93 IGluZm9ybWF0aW9uLiAgVGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhlIGV4cG9ydCBvZiBtZWFz dXJlZCBJUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgZmxvdyBpbmZvcm1hdGlvbiBvdXQgb2YgYW4gSVBGSVggRXhwb3J0 aW5nIFByb2Nlc3MgdG8gYSBDb2xsZWN0aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgZmxvdyBpbmZvcm1hdGlvbiBvdXQgb2YgYW4gSVBGSVggRXhwb3J0aW5nIFBy b2Nlc3MgdG8gYSBDb2xsZWN0aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDYiPjwvYT48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBQcm9jZXNzIGlzIGRlZmluZWQgaW4gWzxzcGFu IGNsYXNzPSJkZWxldGUiPklQRklYLUFSQ0g8L3NwYW4+XSwgcGVyIHRoZSByZXF1aXJlbWVu dHMgZGVmaW5lZCBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBQcm9j ZXNzIGlzIGRlZmluZWQgaW4gWzxzcGFuIGNsYXNzPSJpbnNlcnQiPlJGQzU0NzA8L3NwYW4+ XSwgcGVyIHRoZSByZXF1aXJlbWVudHMgZGVmaW5lZCBpbjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzM5MTddLiAg VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgaG93IElQRklYIGRhdGEgcmVjb3JkcyBhbmQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDMzkxN10uICBUaGlzIGRvY3Vt ZW50IHNwZWNpZmllcyBob3cgSVBGSVggZGF0YSByZWNvcmRzIGFuZDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGVtcGxh dGVzIGFyZSBjYXJyaWVkIHZpYSBhIG51bWJlciBvZiB0cmFuc3BvcnQgcHJvdG9jb2xzIGZy b20gSVBGSVg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0ZW1wbGF0ZXMg YXJlIGNhcnJpZWQgdmlhIGEgbnVtYmVyIG9mIHRyYW5zcG9ydCBwcm90b2NvbHMgZnJvbSBJ UEZJWDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA3Ij48L2E+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgRXhwb3J0aW5nIFByb2Nlc3NlcyB0byBJUEZJWCBDb2xsZWN0aW5nIFByb2Nl c3Nlcy4gIElQRklYIGhhcyBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IEV4cG9ydGluZyBQcm9jZXNzZXMgdG8gSVBGSVggQ29sbGVjdGluZyBQcm9jZXNzZXMuICA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaHJlZSBJUEZJWDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgZm9ybWFs IGRlc2NyaXB0aW9uIG9mIElQRklYIEluZm9ybWF0aW9uIEVsZW1lbnRzLCB0aGVpciBuYW1l LCB0eXBlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgIG9wdGltaXphdGlvbnMvZXh0ZW5zaW9ucyBhcmUgY3VycmVudGx5IHNwZWNp ZmllZDogYSBiYW5kd2lkdGggc2F2aW5nPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBhbmQgYWRkaXRpb25h bCBzZW1hbnRpYyBpbmZvcm1hdGlvbiwgYXMgc3BlY2lmaWVkIGluIDxzcGFuIGNsYXNzPSJk ZWxldGUiPltSRkM1MTAyXS48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIG1ldGhvZCBmb3IgdGhlIElQRklYIHByb3Rv Y29sIGluIFtSRkM1NDczXSwgYW4gZWZmaWNpZW50IG1ldGhvZCBmb3I8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIEZpbmFsbHksIDxzcGFuIGNsYXNzPSJkZWxldGUiPltJUEZJWC1BU108L3NwYW4+IGRl c2NyaWJlcyB3aGF0IHR5cGUgb2YgYXBwbGljYXRpb25zIGNhbiB1c2UgdGhlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGV4cG9y dGluZyBiaWRpcmVjdGlvbmFsIGZsb3cgaW4gW1JGQzUxMDNdLCBhbmQgYW4gbWV0aG9kIGZv ciB0aGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIElQRklYIHByb3RvY29sIGFuZCBob3cgdGhleSBjYW4g dXNlIHRoZSBpbmZvcm1hdGlvbiBwcm92aWRlZC4gIEl0PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGRlZmluaXRpb24gYW5kIGV4 cG9ydCBvZiBjb21wbGV4IGRhdGEgc3RydWN0dXJlcyBpbiBbUkZDNjMxM10uPC9zcGFuPiAg SVBGSVg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgZnVydGhlcm1vcmUgc2hvd3MgaG93IHRoZSBJUEZJWCBmcmFtZXdv cmsgcmVsYXRlcyB0byBvdGhlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICBoYXMgYSBmb3JtYWwgZGVzY3JpcHRpb24gb2YgSVBGSVggSW5mb3JtYXRpb24gRWxlbWVu dHMsIHRoZWlyIG5hbWUsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGFyY2hpdGVjdHVyZXMgYW5kIGZyYW1ld29ya3Mu PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHR5cGUgYW5kIGFkZGl0aW9u YWwgc2VtYW50aWMgaW5mb3JtYXRpb24sIGFzIHNwZWNpZmllZCBpbiA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5bUkZDNTEwMl0sPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgd2l0aCB0aGUgZXhwb3J0IG9m IHRoZSBJbmZvcm1hdGlvbiBFbGVtZW50IHR5cGVzIHNwZWNpZmllZCBpbjwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgIFtSRkM1NjEwXS4gICAgW0lQRklYLUNPTkZdIHNwZWNpZmllcyBhIGRhdGEgbW9k ZWwgZm9yIGNvbmZpZ3VyaW5nIGFuZDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIG1vbml0b3JpbmcgSVBG SVggYW5kIFBTQU1QIGNvbXBsaWFudCBkZXZpY2VzIHVzaW5nIHRoZSBORVRDT05GPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgcHJvdG9jb2wsIHdoaWxlIHRoZSBbUkZDNTgxNV0gc3BlY2lmaWVzIGEg TUlCIG1vZHVsZSBmb3IgbW9uaXRvcmluZy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBJbiB0ZXJtcyBv ZiBkZXZlbG9wbWVudCwgW1JGQzUxNTNdIHByb3ZpZGVzIGd1aWRlbGluZXMgZm9yIHRoZTwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgIGltcGxlbWVudGF0aW9uIGFuZCB1c2Ugb2YgdGhlIElQRklYIHBy b3RvY29sLCB3aGlsZSBbUkZDNTQ3MV08L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBwcm92aWRlcyBndWlk ZWxpbmVzIGZvciB0ZXN0aW5nLjwvc3Bhbj4gICBGaW5hbGx5LCA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5bUkZDNTQ3Ml08L3NwYW4+IGRlc2NyaWJlcyB3aGF0PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB0eXBlIG9mIGFwcGxpY2F0aW9ucyBjYW4gdXNl IHRoZSBJUEZJWCBwcm90b2NvbCBhbmQgaG93IHRoZXkgY2FuIHVzZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGhlIGluZm9ybWF0aW9uIHByb3ZpZGVk LiAgSXQgZnVydGhlcm1vcmUgc2hvd3MgaG93IHRoZSBJUEZJWDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZnJhbWV3b3JrIHJlbGF0ZXMgdG8gb3RoZXIg YXJjaGl0ZWN0dXJlcyBhbmQgZnJhbWV3b3Jrcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+Mi4gIFRlcm1pbm9sb2d5PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+Mi4gIFRlcm1pbm9sb2d5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAi UkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJ UkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAiU0hPVUxEIiwgIlNIT1VMRCBO T1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpczwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIs ICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBk b2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5 IFtSRkMyMTE5XS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb2N1bWVu dCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMy MTE5XS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhl IGRlZmluaXRpb25zIG9mIHRoZSBiYXNpYyB0ZXJtcyBsaWtlIElQIFRyYWZmaWMgRmxvdywg RXhwb3J0aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGRlZmlu aXRpb25zIG9mIHRoZSBiYXNpYyB0ZXJtcyBsaWtlIElQIFRyYWZmaWMgRmxvdywgRXhwb3J0 aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBQcm9jZXNzLCBDb2xsZWN0aW5nIFByb2Nlc3MsIE9ic2VydmF0aW9uIFBv aW50cywgZXRjLiAgYXJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUHJv Y2VzcywgQ29sbGVjdGluZyBQcm9jZXNzLCBPYnNlcnZhdGlvbiBQb2ludHMsIGV0Yy4gIGFy ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgc2VtYW50aWNhbGx5IGlkZW50aWNhbCB0byB0aG9zZSBmb3VuZCBpbiB0aGUg SVBGSVggcmVxdWlyZW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg c2VtYW50aWNhbGx5IGlkZW50aWNhbCB0byB0aG9zZSBmb3VuZCBpbiB0aGUgSVBGSVggcmVx dWlyZW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBkb2N1bWVudCBbUkZDMzkxN10uICBTb21lIG9mIHRoZSB0ZXJt cyBoYXZlIGJlZW4gZXhwYW5kZWQgZm9yIG1vcmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBkb2N1bWVudCBbUkZDMzkxN10uICBTb21lIG9mIHRoZSB0ZXJtcyBoYXZl IGJlZW4gZXhwYW5kZWQgZm9yIG1vcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNsYXJpdHkgd2hlbiBkZWZpbmluZyB0 aGUgcHJvdG9jb2wuICBBZGRpdGlvbmFsIHRlcm1zIHJlcXVpcmVkIGZvcjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNsYXJpdHkgd2hlbiBkZWZpbmluZyB0aGUgcHJv dG9jb2wuICBBZGRpdGlvbmFsIHRlcm1zIHJlcXVpcmVkIGZvcjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHByb3Rv Y29sIGhhdmUgYWxzbyBiZWVuIGRlZmluZWQuICBEZWZpbml0aW9ucyBpbiB0aGlzIGRvY3Vt ZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIHByb3RvY29sIGhh dmUgYWxzbyBiZWVuIGRlZmluZWQuICBEZWZpbml0aW9ucyBpbiB0aGlzIGRvY3VtZW50PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDgiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICBhbmQgaW4gWzxzcGFuIGNsYXNzPSJkZWxldGUiPklQRklYLUFSQ0g8L3NwYW4+XSBhcmUg ZXF1aXZhbGVudCwgZXhjZXB0IHRoYXQgZGVmaW5pdGlvbnMgdGhhdCBhcmU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgYW5kIGluIFs8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij5SRkM1NDcwPC9zcGFuPl0gYXJlIGVxdWl2YWxlbnQsIGV4Y2VwdCB0aGF0IGRlZmluaXRp b25zIHRoYXQgYXJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBvbmx5IHJlbGV2YW50IHRvIHRoZSBJUEZJWCBwcm90b2Nv bCBvbmx5IGFwcGVhciBoZXJlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IG9ubHkgcmVsZXZhbnQgdG8gdGhlIElQRklYIHByb3RvY29sIG9ubHkgYXBwZWFyIGhlcmUu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSB0ZXJt aW5vbG9neSBzdW1tYXJ5IHRhYmxlIGluIFNlY3Rpb24gMi4xIGdpdmVzIGEgcXVpY2sgb3Zl cnZpZXc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgdGVybWlub2xv Z3kgc3VtbWFyeSB0YWJsZSBpbiBTZWN0aW9uIDIuMSBnaXZlcyBhIHF1aWNrIG92ZXJ2aWV3 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBvZiB0aGUgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIHNvbWUgb2YgdGhlIGRpZmZl cmVudCB0ZXJtcyBkZWZpbmVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IG9mIHRoZSByZWxhdGlvbnNoaXBzIGJldHdlZW4gc29tZSBvZiB0aGUgZGlmZmVyZW50IHRl cm1zIGRlZmluZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIE9ic2VydmF0aW9uIFBvaW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgT2JzZXJ2YXRpb24gUG9pbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgICAgQW4gT2JzZXJ2YXRpb24gUG9pbnQgaXMgYSBsb2NhdGlvbiBpbiB0 aGUgbmV0d29yayB3aGVyZSBJUCBwYWNrZXRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgQW4gT2JzZXJ2YXRpb24gUG9pbnQgaXMgYSBsb2NhdGlvbiBpbiB0aGUg bmV0d29yayB3aGVyZSBJUCBwYWNrZXRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBjYW4gYmUgb2JzZXJ2ZWQuICBF eGFtcGxlcyBpbmNsdWRlOiBhIGxpbmUgdG8gd2hpY2ggYSBwcm9iZSBpczwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGNhbiBiZSBvYnNlcnZlZC4gIEV4YW1wbGVz IGluY2x1ZGU6IGEgbGluZSB0byB3aGljaCBhIHByb2JlIGlzPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBhdHRhY2hl ZCwgYSBzaGFyZWQgbWVkaXVtLCBzdWNoIGFzIGFuIEV0aGVybmV0LWJhc2VkIExBTiwgYSBz aW5nbGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBhdHRhY2hlZCwg YSBzaGFyZWQgbWVkaXVtLCBzdWNoIGFzIGFuIEV0aGVybmV0LWJhc2VkIExBTiwgYSBzaW5n bGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPg0KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiPjx0ZD48L3RkPjx0aD48YSBuYW1l PSJwYXJ0LWwzIj48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBh Z2UgNSwgbGluZSAzMDwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0 LXIzIj48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgNywg bGluZSAyMDwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBPYnNl cnZhdGlvbiBEb21haW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBPYnNl cnZhdGlvbiBEb21haW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgQW4gT2JzZXJ2YXRpb24gRG9tYWluIGlzIHRoZSBsYXJnZXN0IHNldCBvZiBP YnNlcnZhdGlvbiBQb2ludHMgZm9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgQW4gT2JzZXJ2YXRpb24gRG9tYWluIGlzIHRoZSBsYXJnZXN0IHNldCBvZiBPYnNl cnZhdGlvbiBQb2ludHMgZm9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB3aGljaCBGbG93IGluZm9ybWF0aW9uIGNh biBiZSBhZ2dyZWdhdGVkIGJ5IGEgTWV0ZXJpbmcgUHJvY2Vzcy48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB3aGljaCBGbG93IGluZm9ybWF0aW9uIGNhbiBiZSBh Z2dyZWdhdGVkIGJ5IGEgTWV0ZXJpbmcgUHJvY2Vzcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIEZvciBleGFtcGxl LCBhIHJvdXRlciBsaW5lIGNhcmQgbWF5IGJlIGFuIE9ic2VydmF0aW9uIERvbWFpbiBpZiBp dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIEZvciBleGFtcGxlLCBh IHJvdXRlciBsaW5lIGNhcmQgbWF5IGJlIGFuIE9ic2VydmF0aW9uIERvbWFpbiBpZiBpdDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgaXMgY29tcG9zZWQgb2Ygc2V2ZXJhbCBpbnRlcmZhY2VzLCBlYWNoIG9mIHdo aWNoIGlzIGFuIE9ic2VydmF0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgaXMgY29tcG9zZWQgb2Ygc2V2ZXJhbCBpbnRlcmZhY2VzLCBlYWNoIG9mIHdoaWNo IGlzIGFuIE9ic2VydmF0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBQb2ludC4gIEluIHRoZSBJUEZJWCBNZXNz YWdlIGl0IGdlbmVyYXRlcywgdGhlIE9ic2VydmF0aW9uIERvbWFpbjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFBvaW50LiAgSW4gdGhlIElQRklYIE1lc3NhZ2Ug aXQgZ2VuZXJhdGVzLCB0aGUgT2JzZXJ2YXRpb24gRG9tYWluPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBpbmNsdWRl cyBpdHMgT2JzZXJ2YXRpb24gRG9tYWluIElELCB3aGljaCBpcyB1bmlxdWUgcGVyIEV4cG9y dGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGluY2x1ZGVzIGl0 cyBPYnNlcnZhdGlvbiBEb21haW4gSUQsIHdoaWNoIGlzIHVuaXF1ZSBwZXIgRXhwb3J0aW5n PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICBQcm9jZXNzLiAgVGhhdCB3YXksIHRoZSBDb2xsZWN0aW5nIFByb2Nlc3Mg Y2FuIGlkZW50aWZ5IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg IFByb2Nlc3MuICBUaGF0IHdheSwgdGhlIENvbGxlY3RpbmcgUHJvY2VzcyBjYW4gaWRlbnRp ZnkgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICBzcGVjaWZpYyBPYnNlcnZhdGlvbiBEb21haW4gZnJvbSB0aGUg RXhwb3J0ZXIgdGhhdCBzZW5kcyB0aGUgSVBGSVg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICBzcGVjaWZpYyBPYnNlcnZhdGlvbiBEb21haW4gZnJvbSB0aGUgRXhw b3J0ZXIgdGhhdCBzZW5kcyB0aGUgSVBGSVg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwOSI+ PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIE1lc3NhZ2VzLiA8c3BhbiBjbGFz cz0iZGVsZXRlIj4gPC9zcGFuPkV2ZXJ5IE9ic2VydmF0aW9uIFBvaW50IGlzIGFzc29jaWF0 ZWQgd2l0aCBhbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICBNZXNz YWdlcy4gRXZlcnkgT2JzZXJ2YXRpb24gUG9pbnQgaXMgYXNzb2NpYXRlZCB3aXRoIGFuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICBPYnNlcnZhdGlvbiBEb21haW4uICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IE9i c2VydmF0aW9uIERvbWFpbiBJRHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICBPYnNlcnZhdGlvbiBEb21haW4uICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IE9ic2Vy dmF0aW9uIERvbWFpbiBJRHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGFsc28gYmUgdW5pcXVlIHBlciBJUEZJWCBE ZXZpY2UuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgYWxzbyBiZSB1 bmlxdWUgcGVyIElQRklYIERldmljZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgSVAgVHJhZmZpYyBGbG93IG9yIEZsb3c8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBJUCBUcmFmZmljIEZsb3cgb3IgRmxvdzwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBUaGVyZSBhcmUgc2V2ZXJh bCBkZWZpbml0aW9ucyBvZiB0aGUgdGVybSAnZmxvdycgYmVpbmcgdXNlZCBieSB0aGU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBUaGVyZSBhcmUgc2V2ZXJhbCBk ZWZpbml0aW9ucyBvZiB0aGUgdGVybSAnZmxvdycgYmVpbmcgdXNlZCBieSB0aGU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgIEludGVybmV0IGNvbW11bml0eS4gIFdpdGhpbiB0aGUgY29udGV4dCBvZiBJUEZJWCB3 ZSB1c2UgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgSW50ZXJu ZXQgY29tbXVuaXR5LiAgV2l0aGluIHRoZSBjb250ZXh0IG9mIElQRklYIHdlIHVzZSB0aGU8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgIGZvbGxvd2luZyBkZWZpbml0aW9uOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgIGZvbGxvd2luZyBkZWZpbml0aW9uOjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBBIEZsb3cgaXMgZGVmaW5lZCBhcyBh IHNldCBvZiBJUCBwYWNrZXRzIHBhc3NpbmcgYW4gT2JzZXJ2YXRpb248L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBBIEZsb3cgaXMgZGVmaW5lZCBhcyBhIHNldCBv ZiBJUCBwYWNrZXRzIHBhc3NpbmcgYW4gT2JzZXJ2YXRpb248L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyIGJn Y29sb3I9ImdyYXkiPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWw0Ij48c21hbGw+c2tp cHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMTAsIGxpbmUgMzc8L2VtPjwv YT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yNCI+PHNtYWxsPnNraXBwaW5n IHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDEyLCBsaW5lIDIyPC9lbT48L2E+PC90 aD48dGQ+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBFeHBvcnRlciBNVVNUIGNvZGUg YWxsIGJpbmFyeSBpbnRlZ2VycyBvZiB0aGUgTWVzc2FnZSBIZWFkZXIgYW5kPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIEV4cG9ydGVyIE1VU1QgY29kZSBhbGwg YmluYXJ5IGludGVnZXJzIG9mIHRoZSBNZXNzYWdlIEhlYWRlciBhbmQ8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBk aWZmZXJlbnQgU2V0cyBpbiBuZXR3b3JrLWJ5dGUgb3JkZXIgKGFsc28ga25vd24gYXMgdGhl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIGRpZmZlcmVudCBTZXRz IGluIG5ldHdvcmstYnl0ZSBvcmRlciAoYWxzbyBrbm93biBhcyB0aGU8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJpZy1l bmRpYW4gYnl0ZSBvcmRlcmluZykuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgYmlnLWVuZGlhbiBieXRlIG9yZGVyaW5nKS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgRm9sbG93aW5nIGFyZSBzb21lIGV4YW1wbGVzIG9mIElQ RklYIE1lc3NhZ2VzOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEZvbGxv d2luZyBhcmUgc29tZSBleGFtcGxlcyBvZiBJUEZJWCBNZXNzYWdlczo8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMS4gQW4gSVBGSVggTWVzc2FnZSBj b25zaXN0aW5nIG9mIGludGVybGVhdmVkIFRlbXBsYXRlLCBEYXRhLCBhbmQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAxLiBBbiBJUEZJWCBNZXNzYWdlIGNvbnNpc3Rp bmcgb2YgaW50ZXJsZWF2ZWQgVGVtcGxhdGUsIERhdGEsIGFuZDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgT3B0aW9u cyBUZW1wbGF0ZSBTZXRzIC0tIEEgbmV3bHkgY3JlYXRlZCBUZW1wbGF0ZSBpcyBleHBvcnRl ZCBhczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIE9wdGlvbnMgVGVt cGxhdGUgU2V0cyAtLSBBIG5ld2x5IGNyZWF0ZWQgVGVtcGxhdGUgaXMgZXhwb3J0ZWQgYXM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgIHNvb24gYXMgcG9zc2libGUuICBTbywgaWYgdGhlcmUgaXMgYWxyZWFkeSBh biBJUEZJWCBNZXNzYWdlIHdpdGggYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgIHNvb24gYXMgcG9zc2libGUuICBTbywgaWYgdGhlcmUgaXMgYWxyZWFkeSBhbiBJ UEZJWCBNZXNzYWdlIHdpdGggYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgRGF0YSBTZXQgdGhhdCBpcyBiZWluZyBw cmVwYXJlZCBmb3IgZXhwb3J0LCB0aGUgVGVtcGxhdGUgYW5kPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgRGF0YSBTZXQgdGhhdCBpcyBiZWluZyBwcmVwYXJlZCBm b3IgZXhwb3J0LCB0aGUgVGVtcGxhdGUgYW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTAi PjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBPcHRpb24gVGVtcGxhdGUgU2V0 cyBhcmUgaW50ZXJsZWF2ZWQgd2l0aCB0aGlzIGluZm9ybWF0aW9uLDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICBPcHRpb248c3BhbiBjbGFzcz0iaW5zZXJ0Ij5z PC9zcGFuPiBUZW1wbGF0ZSBTZXRzIGFyZSBpbnRlcmxlYXZlZCB3aXRoIHRoaXMgaW5mb3Jt YXRpb24sPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICBzdWJqZWN0IHRvIGF2YWlsYWJpbGl0eSBvZiBzcGFjZS48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBzdWJqZWN0IHRvIGF2YWlsYWJp bGl0eSBvZiBzcGFjZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgKy0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICstLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwgICAgICAgIHwgKy0tLS0tLS0tLS0rICstLS0tLS0t LS0rICAgICArLS0tLS0tLS0tLS0rICstLS0tLS0tLS0rIHw8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICB8ICAgICAgICB8ICstLS0tLS0tLS0tKyArLS0tLS0tLS0tKyAg ICAgKy0tLS0tLS0tLS0tKyArLS0tLS0tLS0tKyB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB8TWVzc2FnZSB8IHwgVGVt cGxhdGUgfCB8IERhdGEgICAgfCAgICAgfCBPcHRpb25zICAgfCB8IERhdGEgICAgfCB8PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfE1lc3NhZ2UgfCB8IFRlbXBsYXRl IHwgfCBEYXRhICAgIHwgICAgIHwgT3B0aW9ucyAgIHwgfCBEYXRhICAgIHwgfDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg fCBIZWFkZXIgfCB8IFNldCAgICAgIHwgfCBTZXQgICAgIHwgLi4uIHwgVGVtcGxhdGUgIHwg fCBTZXQgICAgIHwgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHwgSGVh ZGVyIHwgfCBTZXQgICAgICB8IHwgU2V0ICAgICB8IC4uLiB8IFRlbXBsYXRlICB8IHwgU2V0 ICAgICB8IHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHwgICAgICAgIHwgfCAgICAgICAgICB8IHwgICAgICAgICB8ICAg ICB8IFNldCAgICAgICB8IHwgICAgICAgICB8IHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICB8ICAgICAgICB8IHwgICAgICAgICAgfCB8ICAgICAgICAgfCAgICAgfCBT ZXQgICAgICAgfCB8ICAgICAgICAgfCB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB8ICAgICAgICB8ICstLS0tLS0tLS0t KyArLS0tLS0tLS0tKyAgICAgKy0tLS0tLS0tLS0tKyArLS0tLS0tLS0tKyB8PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCAgICAgICAgfCArLS0tLS0tLS0tLSsgKy0t LS0tLS0tLSsgICAgICstLS0tLS0tLS0tLSsgKy0tLS0tLS0tLSsgfDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICstLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8 dHIgYmdjb2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDUiPjxzbWFs bD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxMywgbGluZSAzOTwv ZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI1Ij48c21hbGw+c2tp cHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMTUsIGxpbmUgMTQ8L2VtPjwv YT48L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgfCAgICAg ICAgICAgICAgICAgICAgICBFbnRlcnByaXNlIE51bWJlciAgICAgICAgICAgICAgICAgICAg ICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB8ICAgICAgICAgICAg ICAgICAgICAgIEVudGVycHJpc2UgTnVtYmVyICAgICAgICAgICAgICAgICAgICAgICAgfDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBGaWd1cmUgRzogRmllbGQgU3BlY2lmaWVyIEZvcm1hdDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIEZpZ3VyZSBHOiBGaWVsZCBTcGVjaWZpZXIgRm9ybWF0PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFdoZXJlOjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFdoZXJlOjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBFPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgRTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQ+PGEgbmFtZT0iZGlmZjAwMTEiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAg ICBFbnRlcnByaXNlIGJpdC4gIFRoaXMgaXMgdGhlIGZpcnN0IGJpdCBvZiB0aGUgRmllbGQg U3BlY2lmaWVyLiAgSWY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAg RW50ZXJwcmlzZSBiaXQuICBUaGlzIGlzIHRoZSBmaXJzdCBiaXQgb2YgdGhlIEZpZWxkICBT cGVjaWZpZXIuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgICAgIHRoaXMgYml0IGlzIHplcm8sIHRoZSBJbmZvcm1hdGlv biBFbGVtZW50IElkZW50aWZpZXIgaWRlbnRpZmllcyBhbjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICAgICBJZiB0aGlzIGJpdCBpcyB6ZXJvLCB0aGUgSW5mb3JtYXRp b24gRWxlbWVudCAgSWRlbnRpZmllcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBJRVRGLXNwZWNpZmllZCBJbmZv cm1hdGlvbiBFbGVtZW50LCBhbmQgdGhlIDxzcGFuIGNsYXNzPSJkZWxldGUiPmZvdXItb2N0 ZXQ8L3NwYW4+IEVudGVycHJpc2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgICAgaWRlbnRpZmllcyBhbiBJRVRGLXNwZWNpZmllZCBJbmZvcm1hdGlvbiBFbGVtZW50 LCAgYW5kIHRoZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5mb3VyLTwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg ICAgTnVtYmVyIGZpZWxkIE1VU1QgTk9UIGJlIHByZXNlbnQuICBJZiB0aGlzIGJpdCBpcyBv bmUsIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICAgICBvY3RldDwvc3Bhbj4gRW50ZXJwcmlzZSBOdW1iZXIgZmllbGQgTVVT VCBOT1QgYmUgcHJlc2VudC4gIElmIHRoaXMgYml0IGlzPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIEluZm9ybWF0 aW9uIEVsZW1lbnQgaWRlbnRpZmllciBpZGVudGlmaWVzIGFuIDxzcGFuIGNsYXNzPSJkZWxl dGUiPmVudGVycHJpc2Utc3BlY2lmaWM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgICAgIG9uZSwgdGhlIEluZm9ybWF0aW9uIEVsZW1lbnQgaWRlbnRpZmll ciBpZGVudGlmaWVzIGFuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmVudGVycHJpc2UtPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICAgICBJbmZvcm1hdGlvbiBFbGVtZW50LCBhbmQgdGhlIEVudGVycHJpc2Ug TnVtYmVyIGZpbGVkIE1VU1QgYmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgc3BlY2lmaWM8L3NwYW4+IEluZm9ybWF0aW9u ICBFbGVtZW50LCBhbmQgdGhlIEVudGVycHJpc2UgTnVtYmVyIGZpbGVkPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAg IHByZXNlbnQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIE1VU1Qg YmUgcHJlc2VudC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgSW5mb3JtYXRpb24gRWxlbWVudCBpZGVudGlmaWVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgSW5mb3JtYXRpb24gRWxlbWVudCBpZGVudGlmaWVyPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIEEgbnVtZXJpYyB2YWx1 ZSB0aGF0IHJlcHJlc2VudHMgdGhlIHR5cGUgb2YgSW5mb3JtYXRpb24gRWxlbWVudC48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBBIG51bWVyaWMgdmFsdWUgdGhh dCByZXByZXNlbnRzIHRoZSB0eXBlIG9mIEluZm9ybWF0aW9uIEVsZW1lbnQuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICBSZWZlciB0byBbUkZDNTEwMl0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgUmVmZXIgdG8gW1JGQzUxMDJdLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBGaWVsZCBMZW5ndGg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBGaWVsZCBMZW5ndGg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDEyIj48L2E+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICAgVGhlIGxlbmd0aCBvZiB0aGUgY29ycmVzcG9uZGluZyBlbmNvZGVk IEluZm9ybWF0aW9uIEVsZW1lbnQsIGluPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgICAgIFRoZSBsZW5ndGggb2YgdGhlIGNvcnJlc3BvbmRpbmcgZW5jb2RlZCBJbmZv cm1hdGlvbiBFbGVtZW50LCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gPC9zcGFuPmluPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICBvY3RldHMuICBSZWZlciB0byBbUkZDNTEwMl0uICBUaGUgZmllbGQgbGVuZ3RoIG1h eSBiZSBzbWFsbGVyIHRoYW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICBvY3RldHMuICBSZWZlciB0byBbUkZDNTEwMl0uICBUaGUgZmllbGQgbGVuZ3RoIG1heSBi ZSBzbWFsbGVyIHRoYW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHRoZSBkZWZpbml0aW9uIGluIFtSRkM1MTAyXSBp ZiB0aGUgcmVkdWNlZCBzaXplIGVuY29kaW5nIGlzIHVzZWQ8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICB0aGUgZGVmaW5pdGlvbiBpbiBbUkZDNTEwMl0gaWYgdGhl IHJlZHVjZWQgc2l6ZSBlbmNvZGluZyBpcyB1c2VkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAoc2VlIFNlY3Rpb24g Ni4yKS4gIFRoZSB2YWx1ZSA2NTUzNSBpcyByZXNlcnZlZCBmb3IgdmFyaWFibGUtPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKHNlZSBTZWN0aW9uIDYuMikuICBU aGUgdmFsdWUgNjU1MzUgaXMgcmVzZXJ2ZWQgZm9yIHZhcmlhYmxlLTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgbGVu Z3RoIEluZm9ybWF0aW9uIEVsZW1lbnRzIChzZWUgU2VjdGlvbiA3KS48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBsZW5ndGggSW5mb3JtYXRpb24gRWxlbWVudHMg KHNlZSBTZWN0aW9uIDcpLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBFbnRlcnByaXNlIE51bWJlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIEVudGVycHJpc2UgTnVtYmVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgIElBTkEgZW50ZXJwcmlzZSBudW1iZXIgW1BFTl0gb2YgdGhl IGF1dGhvcml0eSBkZWZpbmluZyB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICBJQU5BIGVudGVycHJpc2UgbnVtYmVyIFtQRU5dIG9mIHRoZSBhdXRob3JpdHkg ZGVmaW5pbmcgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBJbmZvcm1hdGlvbiBFbGVtZW50IGlkZW50aWZpZXIg aW4gdGhpcyBUZW1wbGF0ZSBSZWNvcmQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgSW5mb3JtYXRpb24gRWxlbWVudCBpZGVudGlmaWVyIGluIHRoaXMgVGVtcGxh dGUgUmVjb3JkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4N CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1s NiI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDE1LCBs aW5lIDQyPC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjYiPjxz bWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxNywgbGluZSAx ODwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB8ICAgICAgICAg IFNldCBJRCAgICAgICAgICAgICAgIHwgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgICAg fDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHwgICAgICAgICAgU2V0IElE ICAgICAgICAgICAgICAgfCAgICAgICAgICBMZW5ndGggICAgICAgICAgICAgICB8PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEZp Z3VyZSBJOiBTZXQgSGVhZGVyIEZvcm1hdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIEZpZ3VyZSBJOiBTZXQgSGVhZGVyIEZvcm1hdDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgU2V0IEhlYWRlciBGaWVsZCBEZWZpbml0 aW9ucyBhcmUgYXMgZm9sbG93czo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBUaGUgU2V0IEhlYWRlciBGaWVsZCBEZWZpbml0aW9ucyBhcmUgYXMgZm9sbG93czo8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU2V0IElEPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU2V0IElEPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIFNldCBJRCB2YWx1ZSBpZGVudGlmaWVz IHRoZSBTZXQuICBBIHZhbHVlIG9mIDIgaXMgcmVzZXJ2ZWQgZm9yIHRoZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFNldCBJRCB2YWx1ZSBpZGVudGlmaWVzIHRo ZSBTZXQuICBBIHZhbHVlIG9mIDIgaXMgcmVzZXJ2ZWQgZm9yIHRoZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDEzIj48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgVGVtcGxh dGUgU2V0LiAgQSB2YWx1ZSBvZiAzIGlzIHJlc2VydmVkIGZvciB0aGUgT3B0aW9uIFRlbXBs YXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIFRlbXBsYXRlIFNl dC4gIEEgdmFsdWUgb2YgMyBpcyByZXNlcnZlZCBmb3IgdGhlIE9wdGlvbjxzcGFuIGNsYXNz PSJpbnNlcnQiPnM8L3NwYW4+IFRlbXBsYXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBTZXQuICBBbGwgb3RoZXIg dmFsdWVzIGZyb20gNCB0byAyNTUgYXJlIHJlc2VydmVkIGZvciBmdXR1cmUgdXNlLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFNldC4gIEFsbCBvdGhlciB2YWx1 ZXMgZnJvbSA0IHRvIDI1NSBhcmUgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+ PGEgbmFtZT0iZGlmZjAwMTQiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBW YWx1ZXMgYWJvdmUgMjU1IGFyZSB1c2VkIGZvciBEYXRhIFNldHMuICBUaGUgU2V0IElEIHZh bHVlcyBvZiAwPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIFZhbHVl cyBhYm92ZSAyNTUgYXJlIHVzZWQgZm9yIERhdGEgU2V0cy4gIFRoZSAgU2V0IElEIHZhbHVl cyBvZiAwPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgICAgIGFuZCAxIGFyZSBub3QgdXNlZCBmb3IgaGlzdG9yaWNhbCBy ZWFzb25zIFtSRkMzOTU0XS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg ICAgYW5kIDEgYXJlIG5vdCB1c2VkIGZvciBoaXN0b3JpY2FsIHJlYXNvbnMgIFtSRkMzOTU0 XS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTGVuZ3Ro PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTGVuZ3RoPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIFRvdGFsIGxlbmd0aCBvZiB0 aGUgU2V0LCBpbiBvY3RldHMsIGluY2x1ZGluZyB0aGUgU2V0IEhlYWRlciwgYWxsPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgVG90YWwgbGVuZ3RoIG9mIHRoZSBT ZXQsIGluIG9jdGV0cywgaW5jbHVkaW5nIHRoZSBTZXQgSGVhZGVyLCBhbGw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg IHJlY29yZHMsIGFuZCB0aGUgb3B0aW9uYWwgcGFkZGluZy4gIEJlY2F1c2UgYW4gaW5kaXZp ZHVhbCBTZXQgTUFZPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgcmVj b3JkcywgYW5kIHRoZSBvcHRpb25hbCBwYWRkaW5nLiAgQmVjYXVzZSBhbiBpbmRpdmlkdWFs IFNldCBNQVk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgIGNvbnRhaW4gbXVsdGlwbGUgcmVjb3JkcywgdGhlIExlbmd0 aCB2YWx1ZSBNVVNUIGJlIHVzZWQgdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICBjb250YWluIG11bHRpcGxlIHJlY29yZHMsIHRoZSBMZW5ndGggdmFsdWUgTVVT VCBiZSB1c2VkIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBkZXRlcm1pbmUgdGhlIHBvc2l0aW9uIG9mIHRoZSBu ZXh0IFNldC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBkZXRlcm1p bmUgdGhlIHBvc2l0aW9uIG9mIHRoZSBuZXh0IFNldC48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+My40LiAgIFJlY29yZCBGb3JtYXQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4zLjQuICAgUmVjb3JkIEZvcm1hdDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5 Ij48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sNyI+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDE5LCBsaW5lIDE1PC9lbT48L2E+PC90aD48dGg+ IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjciPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2Ug YXQ8L3NtYWxsPjxlbT4gcGFnZSAyMCwgbGluZSAxNTwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBPbmUgT3B0aW9ucyBUZW1wbGF0ZSBSZWNvcmQgZXhhbXBs ZSBpcyB0aGUgIkZsb3cgS2V5cyIsIHdoaWNoIHJlcG9ydHM8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBPbmUgT3B0aW9ucyBUZW1wbGF0ZSBSZWNvcmQgZXhhbXBsZSBp cyB0aGUgIkZsb3cgS2V5cyIsIHdoaWNoIHJlcG9ydHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBGbG93IEtleXMg Zm9yIGEgVGVtcGxhdGUsIHdoaWNoIGlzIGRlZmluZWQgYXMgdGhlIHNjb3BlLiAgQW5vdGhl cjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBGbG93IEtleXMgZm9y IGEgVGVtcGxhdGUsIHdoaWNoIGlzIGRlZmluZWQgYXMgdGhlIHNjb3BlLiAgQW5vdGhlcjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgZXhhbXBsZSBpcyB0aGUgIlRlbXBsYXRlIGNvbmZpZ3VyYXRpb24iLCB3aGljaCBy ZXBvcnRzIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGV4YW1wbGUg aXMgdGhlICJUZW1wbGF0ZSBjb25maWd1cmF0aW9uIiwgd2hpY2ggcmVwb3J0cyB0aGU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGNvbmZpZ3VyYXRpb24gc2FtcGxpbmcgcGFyYW1ldGVyKHMpIGZvciB0aGUgVGVtcGxh dGUsIHdoaWNoIGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY29uZmln dXJhdGlvbiBzYW1wbGluZyBwYXJhbWV0ZXIocykgZm9yIHRoZSBUZW1wbGF0ZSwgd2hpY2gg aXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGRlZmluZWQgYXMgdGhlIHNjb3BlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIGRlZmluZWQgYXMgdGhlIHNjb3BlLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4zLjQuMi4xLiAgU2NvcGU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4zLjQuMi4xLiAgU2NvcGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIHNjb3BlLCB3aGljaCBpcyBvbmx5IGF2YWls YWJsZSBpbiB0aGUgT3B0aW9ucyBUZW1wbGF0ZSBTZXQsIGdpdmVzPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIHNjb3BlLCB3aGljaCBpcyBvbmx5IGF2YWlsYWJs ZSBpbiB0aGUgT3B0aW9ucyBUZW1wbGF0ZSBTZXQsIGdpdmVzPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgY29udGV4 dCBvZiB0aGUgcmVwb3J0ZWQgSW5mb3JtYXRpb24gRWxlbWVudHMgaW4gdGhlIERhdGEgUmVj b3Jkcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGUgY29udGV4dCBv ZiB0aGUgcmVwb3J0ZWQgSW5mb3JtYXRpb24gRWxlbWVudHMgaW4gdGhlIERhdGEgUmVjb3Jk cy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNSI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIE5vdGUgdGhhdCB0aGUgSVBGSVggTWVzc2FnZSBIZWFkZXIgYWxyZWFkeSBjb250 YWlucyB0aGUgT2JzZXJ2YXRpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+IDwvc3Bhbj5Ob3RlIHRoYXQgdGhlIElQRklYIE1l c3NhZ2UgSGVhZGVyIGFscmVhZHkgY29udGFpbnMgdGhlIE9ic2VydmF0aW9uPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBE b21haW4gSUQgKHRoZSBpZGVudGlmaWVyIG9mIHRoZSBPYnNlcnZhdGlvbiBEb21haW4pLiAg SWYgbm90IHplcm8sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRG9tYWlu IElEICh0aGUgaWRlbnRpZmllciBvZiB0aGUgT2JzZXJ2YXRpb24gRG9tYWluKS4gIElmIG5v dCB6ZXJvLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgdGhpcyBPYnNlcnZhdGlvbiBEb21haW4gSUQgY2FuIGJlIGNvbnNp ZGVyZWQgYXMgYW4gaW1wbGljaXQgc2NvcGUgZm9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgdGhpcyBPYnNlcnZhdGlvbiBEb21haW4gSUQgY2FuIGJlIGNvbnNpZGVy ZWQgYXMgYW4gaW1wbGljaXQgc2NvcGUgZm9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgRGF0YSBSZWNvcmRzIGlu IHRoZSBJUEZJWCBNZXNzYWdlLiAgVGhlIE9ic2VydmF0aW9uIERvbWFpbiBJRDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBEYXRhIFJlY29yZHMgaW4gdGhlIElQ RklYIE1lc3NhZ2UuICBUaGUgT2JzZXJ2YXRpb24gRG9tYWluIElEPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBNVVNUIGJl IHplcm8gd2hlbiB0aGUgSVBGSVggTWVzc2FnZSBjb250YWlucyBEYXRhIFJlY29yZHMgd2l0 aDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE1VU1QgYmUgemVybyB3aGVu IHRoZSBJUEZJWCBNZXNzYWdlIGNvbnRhaW5zIERhdGEgUmVjb3JkcyB3aXRoPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBk aWZmZXJlbnQgT2JzZXJ2YXRpb24gRG9tYWluIElEIHZhbHVlcyBkZWZpbmVkIGFzIHNjb3Bl cy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkaWZmZXJlbnQgT2JzZXJ2 YXRpb24gRG9tYWluIElEIHZhbHVlcyBkZWZpbmVkIGFzIHNjb3Blcy48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTXVsdGlwbGUgU2NvcGUgRmllbGRz IE1BWSBiZSBwcmVzZW50IGluIHRoZSBPcHRpb25zIFRlbXBsYXRlIFJlY29yZCw8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBNdWx0aXBsZSBTY29wZSBGaWVsZHMgTUFZ IGJlIHByZXNlbnQgaW4gdGhlIE9wdGlvbnMgVGVtcGxhdGUgUmVjb3JkLDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW4g d2hpY2ggY2FzZSwgdGhlIGNvbXBvc2l0ZSBzY29wZSBpcyB0aGUgY29tYmluYXRpb24gb2Yg dGhlIHNjb3Blcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbiB3aGlj aCBjYXNlLCB0aGUgY29tcG9zaXRlIHNjb3BlIGlzIHRoZSBjb21iaW5hdGlvbiBvZiB0aGUg c2NvcGVzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgRm9yIGV4YW1wbGUsIGlmIHRoZSB0d28gc2NvcGVzIGFyZSBkZWZp bmVkIGFzICJtZXRlcmluZyBwcm9jZXNzIiBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBGb3IgZXhhbXBsZSwgaWYgdGhlIHR3byBzY29wZXMgYXJlIGRlZmluZWQg YXMgIm1ldGVyaW5nIHByb2Nlc3MiIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgInRlbXBsYXRlIiwgdGhlIGNvbWJp bmVkIHNjb3BlIGlzIHRoaXMgVGVtcGxhdGUgZm9yIHRoaXMgTWV0ZXJpbmc8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAidGVtcGxhdGUiLCB0aGUgY29tYmluZWQgc2Nv cGUgaXMgdGhpcyBUZW1wbGF0ZSBmb3IgdGhpcyBNZXRlcmluZzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHIg Ymdjb2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDgiPjxzbWFsbD5z a2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAyMSwgbGluZSAxMjwvZW0+ PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI4Ij48c21hbGw+c2tpcHBp bmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMjIsIGxpbmUgMTI8L2VtPjwvYT48 L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGVtcGxhdGUgSUQgb2YgdGhpcyBP cHRpb25zIFRlbXBsYXRlIFJlY29yZC4gIFRoaXMgdmFsdWUgaXMgZ3JlYXRlcjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRlbXBsYXRlIElEIG9mIHRoaXMgT3B0aW9u cyBUZW1wbGF0ZSBSZWNvcmQuICBUaGlzIHZhbHVlIGlzIGdyZWF0ZXI8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoYW4g MjU1LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoYW4gMjU1LjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBGaWVsZCBDb3VudDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEZpZWxkIENvdW50PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE51bWJlciBvZiBhbGwgZmll bGRzIGluIHRoaXMgT3B0aW9ucyBUZW1wbGF0ZSBSZWNvcmQsIGluY2x1ZGluZyB0aGU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBOdW1iZXIgb2YgYWxsIGZpZWxkcyBp biB0aGlzIE9wdGlvbnMgVGVtcGxhdGUgUmVjb3JkLCBpbmNsdWRpbmcgdGhlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBT Y29wZSBGaWVsZHMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU2NvcGUg RmllbGRzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBT Y29wZSBGaWVsZCBDb3VudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNj b3BlIEZpZWxkIENvdW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNiI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIE51bWJlciBvZiBzY29wZSBmaWVsZHMgaW4gdGhpcyBPcHRpb25zIFRlbXBsYXRlIFJl Y29yZC4gIFRoZSBTY29wZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBO dW1iZXIgb2Ygc2NvcGUgZmllbGRzIGluIHRoaXMgT3B0aW9ucyBUZW1wbGF0ZSBSZWNvcmQu ICBUaGUgPHNwYW4gY2xhc3M9Imluc2VydCI+IDwvc3Bhbj5TY29wZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRmllbGRz IGFyZSBub3JtYWwgRmllbGRzIGV4Y2VwdCB0aGF0IHRoZXkgYXJlIGludGVycHJldGVkIGFz IHNjb3BlIGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRmllbGRzIGFy ZSBub3JtYWwgRmllbGRzIGV4Y2VwdCB0aGF0IHRoZXkgYXJlIGludGVycHJldGVkIGFzIHNj b3BlIGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTciPjwvYT48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICB0aGUgQ29sbGVjdG9yLiAgVGhlIFNjb3BlIEZpZWxkIENvdW50IE1VU1Qg Tk9UIGJlIHplcm8uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRoZSBD b2xsZWN0b3IuICBUaGUgU2NvcGUgRmllbGQgQ291bnQgPHNwYW4gY2xhc3M9Imluc2VydCI+ IDwvc3Bhbj5NVVNUIE5PVCBiZSB6ZXJvLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTgiPjwvYT48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICBUaGUgZXhhbXBsZSBpbiBGaWd1cmUgTyBzaG93cyBhbiBPcHRpb24g VGVtcGxhdGUgU2V0IHdpdGggbWl4ZWQgSUVURjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICBUaGUgZXhhbXBsZSBpbiBGaWd1cmUgTyBzaG93cyBhbiBPcHRpb248c3Bh biBjbGFzcz0iaW5zZXJ0Ij5zPC9zcGFuPiBUZW1wbGF0ZSBTZXQgd2l0aCBtaXhlZCBJRVRG PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBhbmQgZW50ZXJwcmlzZS1zcGVjaWZpYyBJbmZvcm1hdGlvbiBFbGVtZW50cy4g IEl0IGNvbnNpc3RzIG9mIGEgU2V0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgYW5kIGVudGVycHJpc2Utc3BlY2lmaWMgSW5mb3JtYXRpb24gRWxlbWVudHMuICBJdCBj b25zaXN0cyBvZiBhIFNldDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDE5Ij48L2E+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgSGVhZGVyLCBhbiBPcHRpb24gVGVtcGxhdGUgSGVhZGVy LCBhbmQgc2V2ZXJhbCBGaWVsZCBTcGVjaWZpZXJzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBIZWFkZXIsIGFuIE9wdGlvbjxzcGFuIGNsYXNzPSJpbnNlcnQiPnM8 L3NwYW4+IFRlbXBsYXRlIEhlYWRlciwgYW5kIHNldmVyYWwgRmllbGQgU3BlY2lmaWVycy48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMDIwIj48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgIDAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDM8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAwICAgICAgICAgICAgICAgICAg IDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHwgICAgICAgICAgU2V0IElEID0gMyAgICAg ICAgICAgfCAgICAgICAgICBMZW5ndGggICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgICB8ICAgICAgICAgIFNldCBJRCA9IDMgICAgICAgICAg IHwgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgfCAgICAgICAgIFRlbXBsYXRlIElEID0gMjU4ICAgICB8ICAgICAgICAgRmllbGQg Q291bnQgPSBOICsgTSAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg IHwgICAgICAgICBUZW1wbGF0ZSBJRCA9IDI1OCAgICAgfCAgICAgICAgIEZpZWxkIENvdW50 ID0gTiArIE0gICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB8ICAgICBTY29wZSBGaWVs ZCBDb3VudCA9IE4gICAgIHwwfCAgU2NvcGUgMSBJbmZvci4gRWxlbWVudCBJZC4gfDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgfCAgICAgU2NvcGUgRmllbGQgQ291 bnQgPSBOICAgICB8MHwgIFNjb3BlIDEgSW5mb3IuIEVsZW1lbnQgSWQuIHw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIHwgICAgIFNjb3BlIDEgRmllbGQgTGVuZ3RoICAgICAgfDB8ICBT Y29wZSAyIEluZm9yLiBFbGVtZW50IElkLiB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgICB8ICAgICBTY29wZSAxIEZpZWxkIExlbmd0aCAgICAgIHwwfCAgU2NvcGUg MiBJbmZvci4gRWxlbWVudCBJZC4gfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgfCAgICAg U2NvcGUgMiBGaWVsZCBMZW5ndGggICAgICB8ICAgICAgICAgICAgIC4uLiAgICAgICAgICAg ICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgIHwgICAgIFNjb3Bl IDIgRmllbGQgTGVuZ3RoICAgICAgfCAgICAgICAgICAgICAuLi4gICAgICAgICAgICAgICB8 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB8ICAgICAgICAgICAgLi4uICAgICAgICAgICAg ICAgIHwxfCAgU2NvcGUgTiBJbmZvci4gRWxlbWVudCBJZC4gfDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICAgfCAgICAgICAgICAgIC4uLiAgICAgICAgICAgICAgICB8 MXwgIFNjb3BlIE4gSW5mb3IuIEVsZW1lbnQgSWQuIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIHwgICAgIFNjb3BlIE4gRmllbGQgTGVuZ3RoICAgICAgfCAgIFNjb3BlIE4gRW50ZXJw cmlzZSBOdW1iZXIgLi4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICB8 ICAgICBTY29wZSBOIEZpZWxkIExlbmd0aCAgICAgIHwgICBTY29wZSBOIEVudGVycHJpc2Ug TnVtYmVyIC4uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIC4uLiAgU2NvcGUgTiBFbnRlcnBy aXNlIE51bWJlciAgIHwxfCBPcHRpb24gMSBJbmZvci4gRWxlbWVudCBJZC4gfDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIC4uLiAgU2NvcGUgTiBFbnRlcnByaXNlIE51 bWJlciAgIHwxfCBPcHRpb24gMSBJbmZvci4gRWxlbWVudCBJZC4gfDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDIxIj48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIHwgICAgT3B0aW9uIDEgRmllbGQgTGVuZ3RoICAgICAgfCAgT3B0aW9uIDEgRW50 ZXJwcmlzZSBOdW1iZXIgLi4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg ICB8ICAgIE9wdGlvbiAxIEZpZWxkIExlbmd0aCAgICAgIHwgIE9wdGlvbiAxIEVudGVycHJp c2UgTnVtYmVyIC4uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIC4uLiBPcHRpb24gMSBFbnRl cnByaXNlIE51bWJlciAgIHwgICAgICAgICAgICAgIC4uLiAgICAgICAgICAgICAgfDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIC4uLiBPcHRpb24gMSBFbnRlcnByaXNl IE51bWJlciAgIHwgICAgICAgICAgICAgIC4uLiAgICAgICAgICAgICAgfDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxh IG5hbWU9ImRpZmYwMDIyIj48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIHwgICAgICAgICAgICAgLi4uICAgICAgICAgICAgICAgfDB8IE9wdGlvbiBN IEluZm9yLiBFbGVtZW50IElkLiB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgICB8ICAgICAgICAgICAgIC4uLiAgICAgICAgICAgICAgIHwwfCBPcHRpb24gTSBJbmZv ci4gRWxlbWVudCBJZC4gfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgfCAgICAgT3B0aW9u IE0gRmllbGQgTGVuZ3RoICAgICB8ICAgICAgUGFkZGluZyAob3B0aW9uYWwpICAgICAgIHw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgIHwgICAgIE9wdGlvbiBNIEZp ZWxkIExlbmd0aCAgICAgfCAgICAgIFBhZGRpbmcgKG9wdGlvbmFsKSAgICAgICB8PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQ+PGEgbmFtZT0iZGlmZjAwMjMiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBG aWd1cmUgTzogT3B0aW9uIFRlbXBsYXRlIFNldCBFeGFtcGxlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIEZpZ3VyZSBPOiBPcHRpb248c3BhbiBjbGFzcz0iaW5zZXJ0 Ij5zPC9zcGFuPiBUZW1wbGF0ZSBTZXQgRXhhbXBsZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4zLjQuMy4gIERhdGEgUmVjb3JkIEZvcm1hdDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjMuNC4zLiAgRGF0YSBSZWNvcmQgRm9ybWF0PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBEYXRhIFJl Y29yZHMgYXJlIHNlbnQgaW4gRGF0YSBTZXRzLiAgVGhlIGZvcm1hdCBvZiB0aGUgRGF0YTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBEYXRhIFJlY29yZHMgYXJl IHNlbnQgaW4gRGF0YSBTZXRzLiAgVGhlIGZvcm1hdCBvZiB0aGUgRGF0YTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUmVj b3JkIGlzIHNob3duIGluIEZpZ3VyZSBQLiAgSXQgY29uc2lzdHMgb25seSBvZiBvbmUgb3Ig bW9yZSBGaWVsZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFJlY29yZCBp cyBzaG93biBpbiBGaWd1cmUgUC4gIEl0IGNvbnNpc3RzIG9ubHkgb2Ygb25lIG9yIG1vcmUg RmllbGQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFZhbHVlcy4gIFRoZSBUZW1wbGF0ZSBJRCB0byB3aGljaCB0aGUgRmll bGQgVmFsdWVzIGJlbG9uZyBpcyBlbmNvZGVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgVmFsdWVzLiAgVGhlIFRlbXBsYXRlIElEIHRvIHdoaWNoIHRoZSBGaWVsZCBW YWx1ZXMgYmVsb25nIGlzIGVuY29kZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluIHRoZSBTZXQgSGVhZGVyIGZpZWxk ICJTZXQgSUQiLCBpLmUuLCAiU2V0IElEIiA9ICJUZW1wbGF0ZSBJRCIuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW4gdGhlIFNldCBIZWFkZXIgZmllbGQgIlNldCBJ RCIsIGkuZS4sICJTZXQgSUQiID0gIlRlbXBsYXRlIElEIi48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHwgRmllbGQgVmFsdWUgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB8IEZpZWxk IFZhbHVlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAg ICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sOSI+ PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDIzLCBsaW5l IDMzPC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjkiPjxzbWFs bD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAyNCwgbGluZSAzMzwv ZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEZpZ3VyZSBROiBEYXRhIFNl dCwgQ29udGFpbmluZyBEYXRhIFJlY29yZHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBGaWd1cmUgUTogRGF0YSBTZXQsIENvbnRhaW5pbmcgRGF0YSBSZWNvcmRzPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuICBTcGVjaWZpYyBS ZXBvcnRpbmcgUmVxdWlyZW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ NC4gIFNwZWNpZmljIFJlcG9ydGluZyBSZXF1aXJlbWVudHM8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU29tZSBzcGVjaWZpYyBPcHRpb25zIFRlbXBs YXRlcyBhbmQgT3B0aW9ucyBUZW1wbGF0ZSBSZWNvcmRzIGFyZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFNvbWUgc3BlY2lmaWMgT3B0aW9ucyBUZW1wbGF0ZXMgYW5k IE9wdGlvbnMgVGVtcGxhdGUgUmVjb3JkcyBhcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG5lY2Vzc2FyeSB0byBwcm92 aWRlIGV4dHJhIGluZm9ybWF0aW9uIGFib3V0IHRoZSBGbG93IFJlY29yZHMgYW5kPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbmVjZXNzYXJ5IHRvIHByb3ZpZGUgZXh0 cmEgaW5mb3JtYXRpb24gYWJvdXQgdGhlIEZsb3cgUmVjb3JkcyBhbmQ8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFib3V0 IHRoZSBNZXRlcmluZyBQcm9jZXNzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGFib3V0IHRoZSBNZXRlcmluZyBQcm9jZXNzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjQiPjwvYT48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGUgT3B0aW9uIFRlbXBsYXRlIGFuZCBPcHRpb25zIFRl bXBsYXRlIFJlY29yZHMgZGVmaW5lZCBpbiB0aGVzZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBUaGUgT3B0aW9uPHNwYW4gY2xhc3M9Imluc2VydCI+czwvc3Bhbj4g VGVtcGxhdGUgYW5kIE9wdGlvbnMgVGVtcGxhdGUgUmVjb3JkcyBkZWZpbmVkIGluIHRoZXNl PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBzdWJzZWN0aW9ucywgd2hpY2ggaW1wb3NlIHNvbWUgY29uc3RyYWludHMgb24g dGhlIE1ldGVyaW5nIFByb2Nlc3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBzdWJzZWN0aW9ucywgd2hpY2ggaW1wb3NlIHNvbWUgY29uc3RyYWludHMgb24gdGhlIE1l dGVyaW5nIFByb2Nlc3M8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFuZCBFeHBvcnRpbmcgUHJvY2VzcyBpbXBsZW1lbnRh dGlvbnMsIE1BWSBiZSBpbXBsZW1lbnRlZC4gIElmPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgYW5kIEV4cG9ydGluZyBQcm9jZXNzIGltcGxlbWVudGF0aW9ucywgTUFZ IGJlIGltcGxlbWVudGVkLiAgSWY8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAyNSI+PC9hPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGltcGxlbWVudGVkLCB0aGUgc3BlY2lmaWMgT3B0 aW9uIFRlbXBsYXRlcyBTSE9VTEQgYmUgaW1wbGVtZW50ZWQgYXM8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgaW1wbGVtZW50ZWQsIHRoZSBzcGVjaWZpYyBPcHRpb248 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zPC9zcGFuPiBUZW1wbGF0ZXMgU0hPVUxEIGJlIGltcGxl bWVudGVkIGFzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBzcGVjaWZpZWQgaW4gdGhlc2Ugc3Vic2VjdGlvbnMuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc3BlY2lmaWVkIGluIHRoZXNlIHN1YnNl Y3Rpb25zLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBU aGUgbWluaW11bSBzZXQgb2YgSW5mb3JtYXRpb24gRWxlbWVudHMgaXMgYWx3YXlzIHNwZWNp ZmllZCBpbiB0aGVzZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBt aW5pbXVtIHNldCBvZiBJbmZvcm1hdGlvbiBFbGVtZW50cyBpcyBhbHdheXMgc3BlY2lmaWVk IGluIHRoZXNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBTcGVjaWZpYyBJUEZJWCBPcHRpb25zIFRlbXBsYXRlcy4gIE5l dmVydGhlbGVzcywgZXh0cmEgSW5mb3JtYXRpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBTcGVjaWZpYyBJUEZJWCBPcHRpb25zIFRlbXBsYXRlcy4gIE5ldmVydGhl bGVzcywgZXh0cmEgSW5mb3JtYXRpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEVsZW1lbnRzIG1heSBiZSB1c2VkIGlu IHRoZXNlIHNwZWNpZmljIE9wdGlvbnMgVGVtcGxhdGVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIEVsZW1lbnRzIG1heSBiZSB1c2VkIGluIHRoZXNlIHNwZWNpZmlj IE9wdGlvbnMgVGVtcGxhdGVzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjYiPjwvYT48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj40LjEuICBUaGUgTWV0ZXJpbmcgUHJvY2VzcyBTdGF0aXN0aWNzIE9wdGlvbiBUZW1w bGF0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj40LjEuICBUaGUgTWV0ZXJp bmcgUHJvY2VzcyBTdGF0aXN0aWNzIE9wdGlvbjxzcGFuIGNsYXNzPSJpbnNlcnQiPnM8L3Nw YW4+IFRlbXBsYXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZD48YSBuYW1lPSJkaWZmMDAyNyI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg IFRoZSBNZXRlcmluZyBQcm9jZXNzIFN0YXRpc3RpY3MgT3B0aW9uIFRlbXBsYXRlIHNwZWNp ZmllcyB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGhlIE1ldGVy aW5nIFByb2Nlc3MgU3RhdGlzdGljcyBPcHRpb248c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zPC9z cGFuPiBUZW1wbGF0ZSBzcGVjaWZpZXMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzdHJ1Y3R1cmUgb2YgYSBEYXRh IFJlY29yZCBmb3IgcmVwb3J0aW5nIE1ldGVyaW5nIFByb2Nlc3Mgc3RhdGlzdGljcy48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzdHJ1Y3R1cmUgb2YgYSBEYXRhIFJl Y29yZCBmb3IgcmVwb3J0aW5nIE1ldGVyaW5nIFByb2Nlc3Mgc3RhdGlzdGljcy48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZD48YSBuYW1lPSJkaWZmMDAyOCI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEl0 IFNIT1VMRCBjb250YWluIHRoZSBmb2xsb3dpbmcgSW5mb3JtYXRpb24gRWxlbWVudHMgdGhh dCBhcmUgZGVmaW5lZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgSXQg U0hPVUxEIGNvbnRhaW4gdGhlIGZvbGxvd2luZyBJbmZvcm1hdGlvbiBFbGVtZW50cyB0aGF0 IGFyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICBpbiBbUkZDNTEwMl06PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIGRlZmluZWQgaW4gW1JGQzUxMDJdOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvYnNlcnZhdGlvbkRvbWFpbklkPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb2JzZXJ2YXRpb25Eb21haW5JZDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgQW4gaWRlbnRpZmllciBvZiBhbiBPYnNlcnZhdGlvbiBE b21haW4gdGhhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgICAgICAgICAgICAgIEFuIGlkZW50aWZpZXIgb2YgYW4gT2JzZXJ2YXRpb24gRG9tYWlu IHRoYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIGxvY2FsbHkgdW5pcXVl IHRvIHRoZSBFeHBvcnRpbmcgUHJvY2Vzcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICBpcyBsb2NhbGx5IHVuaXF1ZSB0byB0 aGUgRXhwb3J0aW5nIFByb2Nlc3MuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICBU aGlzIEluZm9ybWF0aW9uIEVsZW1lbnQgTVVTVCBiZSBkZWZpbmVkIGFzIGE8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICBUaGlz IEluZm9ybWF0aW9uIEVsZW1lbnQgTVVTVCBiZSBkZWZpbmVkIGFzIGE8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAg ICAgICAgICAgICAgICAgICAgIFNjb3BlIEZpZWxkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFNjb3BlIEZpZWxkLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBleHBvcnRlZE1lc3Nh Z2VUb3RhbENvdW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZXhwb3J0 ZWRNZXNzYWdlVG90YWxDb3VudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhl IHRvdGFsIG51bWJlciBvZiBJUEZJWCBNZXNzYWdlcyB0aGF0IHRoZTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSB0b3Rh bCBudW1iZXIgb2YgSVBGSVggTWVzc2FnZXMgdGhhdCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAg ICAgICAgICAgICAgIEV4cG9ydGluZyBQcm9jZXNzIHN1Y2Nlc3NmdWxseSBzZW50IHRvIHRo ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAg ICAgICAgIEV4cG9ydGluZyBQcm9jZXNzIHN1Y2Nlc3NmdWxseSBzZW50IHRvIHRoZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ29sbGVjdGluZyBQcm9jZXNzIHNpbmNlIHRo ZSBFeHBvcnRpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAg ICAgICAgICAgICAgICAgICBDb2xsZWN0aW5nIFByb2Nlc3Mgc2luY2UgdGhlIEV4cG9ydGlu ZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgUHJvY2VzcyByZS1pbml0aWFsaXph dGlvbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAg ICAgICAgICAgICBQcm9jZXNzIHJlLWluaXRpYWxpemF0aW9uLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjkiPjwvYT48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBleHBvcnRlZEZsb3dUb3RhbENvdW50PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGV4cG9ydGVkRmxvdzxzcGFuIGNsYXNz PSJpbnNlcnQiPlJlY29yZDwvc3Bhbj5Ub3RhbENvdW50PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAg ICAgICAgICAgICBUaGUgdG90YWwgbnVtYmVyIG9mIEZsb3cgUmVjb3JkcyB0aGF0IHRoZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAg ICAgIFRoZSB0b3RhbCBudW1iZXIgb2YgRmxvdyBSZWNvcmRzIHRoYXQgdGhlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICAgICAgICAgICAgICAgICAgICBFeHBvcnRpbmcgUHJvY2VzcyBzdWNjZXNzZnVsbHkg c2VudCB0byB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAg ICAgICAgICAgICAgICAgICBFeHBvcnRpbmcgUHJvY2VzcyBzdWNjZXNzZnVsbHkgc2VudCB0 byB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgIENvbGxlY3RpbmcgUHJvY2Vz cyBzaW5jZSB0aGUgRXhwb3J0aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ29sbGVjdGluZyBQcm9jZXNzIHNpbmNlIHRo ZSBFeHBvcnRpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFByb2Nlc3MgcmUt aW5pdGlhbGl6YXRpb24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgUHJvY2VzcyByZS1pbml0aWFsaXphdGlvbi48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZXhwb3J0ZWRPY3RldFRv dGFsQ291bnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBleHBvcnRlZE9j dGV0VG90YWxDb3VudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlIHRvdGFs IG51bWJlciBvZiBvY3RldHMgdGhhdCB0aGUgRXhwb3J0aW5nPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlIHRvdGFsIG51 bWJlciBvZiBvY3RldHMgdGhhdCB0aGUgRXhwb3J0aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAg ICAgICAgICAgICBQcm9jZXNzIHN1Y2Nlc3NmdWxseSBzZW50IHRvIHRoZSBDb2xsZWN0aW5n PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgUHJvY2VzcyBzdWNjZXNzZnVsbHkgc2VudCB0byB0aGUgQ29sbGVjdGluZzwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgUHJvY2VzcyBzaW5jZSB0aGUgRXhwb3J0aW5n IFByb2Nlc3MgcmUtPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgUHJvY2VzcyBzaW5jZSB0aGUgRXhwb3J0aW5nIFByb2Nlc3Mg cmUtPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICBpbml0aWFsaXphdGlvbi48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAg ICBpbml0aWFsaXphdGlvbi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgVGhlIEV4cG9ydGluZyBQcm9jZXNzIFNIT1VMRCBleHBvcnQgdGhlIERhdGEg UmVjb3JkIHNwZWNpZmllZCBieSB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBUaGUgRXhwb3J0aW5nIFByb2Nlc3MgU0hPVUxEIGV4cG9ydCB0aGUgRGF0YSBSZWNv cmQgc3BlY2lmaWVkIGJ5IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDMwIj48L2E+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgTWV0ZXJpbmcgUHJvY2VzcyBTdGF0aXN0aWNzIE9w dGlvbiBUZW1wbGF0ZSBvbiBhIHJlZ3VsYXIgYmFzaXMgb3I8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgTWV0ZXJpbmcgUHJvY2VzcyBTdGF0aXN0aWNzIE9wdGlvbjxz cGFuIGNsYXNzPSJpbnNlcnQiPnM8L3NwYW4+IFRlbXBsYXRlIG9uIGEgcmVndWxhciBiYXNp cyBvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgYmFzZWQgb24gc29tZSBleHBvcnQgcG9saWN5LiAgVGhpcyBwZXJpb2Rp Y2l0eSBvciBleHBvcnQgcG9saWN5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgYmFzZWQgb24gc29tZSBleHBvcnQgcG9saWN5LiAgVGhpcyBwZXJpb2RpY2l0eSBvciBl eHBvcnQgcG9saWN5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBTSE9VTEQgYmUgY29uZmlndXJhYmxlLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNIT1VMRCBiZSBjb25maWd1cmFibGUuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE5vdGUgdGhhdCBpZiBz ZXZlcmFsIE1ldGVyaW5nIFByb2Nlc3NlcyBhcmUgYXZhaWxhYmxlIG9uIHRoZSBFeHBvcnRl cjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE5vdGUgdGhhdCBpZiBzZXZl cmFsIE1ldGVyaW5nIFByb2Nlc3NlcyBhcmUgYXZhaWxhYmxlIG9uIHRoZSBFeHBvcnRlcjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgT2JzZXJ2YXRpb24gRG9tYWluLCB0aGUgSW5mb3JtYXRpb24gRWxlbWVudCBtZXRl cmluZ1Byb2Nlc3NJZCBNVVNUIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgT2JzZXJ2YXRpb24gRG9tYWluLCB0aGUgSW5mb3JtYXRpb24gRWxlbWVudCBtZXRlcmlu Z1Byb2Nlc3NJZCBNVVNUIGJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzcGVjaWZpZWQgYXMgYW4gYWRkaXRpb25hbCBT Y29wZSBGaWVsZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzcGVjaWZp ZWQgYXMgYW4gYWRkaXRpb25hbCBTY29wZSBGaWVsZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDMxIj48L2E+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+NC4yLiAgVGhlIE1ldGVyaW5nIFByb2Nlc3MgUmVsaWFiaWxp dHkgU3RhdGlzdGljcyBPcHRpb24gVGVtcGxhdGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+NC4yLiAgVGhlIE1ldGVyaW5nIFByb2Nlc3MgUmVsaWFiaWxpdHkgU3RhdGlz dGljcyBPcHRpb248c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zPC9zcGFuPiBUZW1wbGF0ZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlm ZjAwMzIiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGUgTWV0ZXJpbmcgUHJv Y2VzcyBSZWxpYWJpbGl0eSBPcHRpb24gVGVtcGxhdGUgc3BlY2lmaWVzIHRoZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGUgTWV0ZXJpbmcgUHJvY2VzcyBSZWxp YWJpbGl0eSBPcHRpb248c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zPC9zcGFuPiBUZW1wbGF0ZSBz cGVjaWZpZXMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBzdHJ1Y3R1cmUgb2YgYSBEYXRhIFJlY29yZCBmb3IgcmVw b3J0aW5nIGxhY2sgb2YgcmVsaWFiaWxpdHkgaW4gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgc3RydWN0dXJlIG9mIGEgRGF0YSBSZWNvcmQgZm9yIHJlcG9ydGlu ZyBsYWNrIG9mIHJlbGlhYmlsaXR5IGluIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTWV0ZXJpbmcgUHJvY2Vzcy4g IEl0IFNIT1VMRCBjb250YWluIHRoZSBmb2xsb3dpbmcgSW5mb3JtYXRpb248L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBNZXRlcmluZyBQcm9jZXNzLiAgSXQgU0hPVUxE IGNvbnRhaW4gdGhlIGZvbGxvd2luZyBJbmZvcm1hdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRWxlbWVudHMgdGhh dCBhcmUgZGVmaW5lZCBpbiBbUkZDNTEwMl06PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgRWxlbWVudHMgdGhhdCBhcmUgZGVmaW5lZCBpbiBbUkZDNTEwMl06PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9ic2VydmF0aW9uRG9t YWluSWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvYnNlcnZhdGlvbkRv bWFpbklkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICBBbiBpZGVudGlmaWVyIG9m IGFuIE9ic2VydmF0aW9uIERvbWFpbiB0aGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQW4gaWRlbnRpZmllciBvZiBhbiBP YnNlcnZhdGlvbiBEb21haW4gdGhhdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg aXMgbG9jYWxseSB1bmlxdWUgdG8gdGhlIEV4cG9ydGluZyBQcm9jZXNzLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIGxv Y2FsbHkgdW5pcXVlIHRvIHRoZSBFeHBvcnRpbmcgUHJvY2Vzcy48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1l PSJkaWZmMDAzMyI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAg ICAgICAgICAgICAgIFRoaXMgSW5mb3JtYXRpb24gRWxlbWVudCBNVVNUIGJlIGRlZmluZWQg YXMgYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAg ICAgICAgICAgICBUaGlzIEluZm9ybWF0aW9uIEVsZW1lbnQgTVVTVCAgIGJlIGRlZmluZWQg YXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgU2NvcGUgRmllbGQuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAg IGEgU2NvcGUgRmllbGQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIGlnbm9yZWRQYWNrZXRUb3RhbENvdW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgaWdub3JlZFBhY2tldFRvdGFsQ291bnQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAg ICAgICAgICAgICAgIFRoZSB0b3RhbCBudW1iZXIgb2YgSVAgcGFja2V0cyB0aGF0IHRoZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAg ICAgIFRoZSB0b3RhbCBudW1iZXIgb2YgSVAgcGFja2V0cyB0aGF0IHRoZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgTWV0ZXJpbmcgUHJvY2VzcyBkaWQgbm90IHByb2Nlc3Mu PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgTWV0ZXJpbmcgUHJvY2VzcyBkaWQgbm90IHByb2Nlc3MuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGlnbm9yZWRPY3RldFRvdGFsQ291bnQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpZ25vcmVkT2N0ZXRUb3RhbENv dW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMzQiPjwvYT48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICBUaGUgdG90YWwgbnVtYmVyIG9mIG9j dGV0cyBpbiBvYnNlcnZlZCBJUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICAgICAgICAgICAgICAgICAgICAgICAgICBUaGUgdG90YWwgbnVtYmVyIG9mIG9jdGV0cyBp biBvYnNlcnZlZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gPC9zcGFuPklQPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg ICAgICAgICAgICAgICAgICAgICBwYWNrZXRzIHRoYXQgdGhlIE1ldGVyaW5nIFByb2Nlc3Mg ZGlkIG5vdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAg ICAgICAgICAgICAgIHBhY2tldHMgdGhhdCB0aGUgTWV0ZXJpbmcgUHJvY2VzcyBkaWQgbm90 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICBwcm9jZXNzLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb2Nlc3Mu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRpbWUgZmly c3QgaWdub3JlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUgZmly c3QgaWdub3JlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlIHRpbWVzdGFt cCBvZiB0aGUgZmlyc3QgSVAgcGFja2V0IHRoYXQgd2FzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlIHRpbWVzdGFtcCBv ZiB0aGUgZmlyc3QgSVAgcGFja2V0IHRoYXQgd2FzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAw MzUiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAg ICAgICBpZ25vcmVkIGJ5IHRoZSBNZXRlcmluZyBQcm9jZXNzLiAgRm9yIHRoaXM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg aWdub3JlZCBieSB0aGUgTWV0ZXJpbmcgPHNwYW4gY2xhc3M9Imluc2VydCI+IDwvc3Bhbj5Q cm9jZXNzLiAgRm9yIHRoaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgIHRpbWVz dGFtcCwgYW55IG9mIHRoZSAiZmxvd1N0YXJ0IiB0aW1lc3RhbXA8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICB0aW1lc3RhbXAs IGFueSBvZiB0aGUgImZsb3dTdGFydCIgdGltZXN0YW1wPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAg ICAgICAgICAgICBJbmZvcm1hdGlvbiBFbGVtZW50cyBmbG93U3RhcnRNaWxsaXNlY29uZHMs PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgSW5mb3JtYXRpb24gRWxlbWVudHMgZmxvd1N0YXJ0TWlsbGlzZWNvbmRzLDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkPjxhIG5hbWU9ImRpZmYwMDM2Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgZmxvd1N0YXJ0TWljcm9zZWNvbmRzLCBmbG93U3Rh cnROYW5vc2Vjb25kcyw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgZmxvd1N0YXJ0TWljcm9zZWNvbmRzLDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAg ICAgICAgICAgICAgICAgICAgICAgICBhbmQgZmxvd1N0YXJ0RGVsdGFNaWNyb3NlY29uZHMg Y2FuIGJlIHVzZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAg ICAgICAgICAgICAgICAgICAgIGZsb3dTdGFydE5hbm9zZWNvbmRzLCBhbmQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAg ICAgIGZsb3dTdGFydERlbHRhTWljcm9zZWNvbmRzIGNhbiBiZSB1c2VkLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aW1lIGxhc3QgaWdub3JlZDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUgbGFzdCBpZ25vcmVkPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICBUaGUgdGltZXN0YW1wIG9mIHRoZSBsYXN0 IElQIHBhY2tldCB0aGF0IHdhczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSB0aW1lc3RhbXAgb2YgdGhlIGxhc3QgSVAg cGFja2V0IHRoYXQgd2FzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMzciPjwvYT48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICBpZ25vcmVkIGJ5 IHRoZSBNZXRlcmluZyBQcm9jZXNzLiAgRm9yIHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgaWdub3JlZCBieSB0aGUg TWV0ZXJpbmcgPHNwYW4gY2xhc3M9Imluc2VydCI+IDwvc3Bhbj5Qcm9jZXNzLiAgRm9yIHRo aXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgIHRpbWVzdGFtcCwgYW55IG9mIHRo ZSAiZmxvd0VuZCIgdGltZXN0YW1wPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgdGltZXN0YW1wLCBhbnkgb2YgdGhlICJmbG93 RW5kIiB0aW1lc3RhbXA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0 aW9uIEVsZW1lbnRzIGZsb3dFbmRNaWxsaXNlY29uZHMsPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5mb3JtYXRpb24gRWxl bWVudHMgZmxvd0VuZE1pbGxpc2Vjb25kcyw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAg ICAgIGZsb3dFbmRNaWNyb3NlY29uZHMsIGZsb3dFbmROYW5vc2Vjb25kcywgYW5kPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg Zmxvd0VuZE1pY3Jvc2Vjb25kcywgZmxvd0VuZE5hbm9zZWNvbmRzLCBhbmQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICAgICAgICAgICAgICAgICAgICAgIGZsb3dFbmREZWx0YU1pY3Jvc2Vjb25kcyBjYW4gYmUg dXNlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAg ICAgICAgICAgICBmbG93RW5kRGVsdGFNaWNyb3NlY29uZHMgY2FuIGJlIHVzZWQuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBFeHBvcnRpbmcg UHJvY2VzcyBTSE9VTEQgZXhwb3J0IHRoZSBEYXRhIFJlY29yZCBzcGVjaWZpZWQgYnkgdGhl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIEV4cG9ydGluZyBQcm9j ZXNzIFNIT1VMRCBleHBvcnQgdGhlIERhdGEgUmVjb3JkIHNwZWNpZmllZCBieSB0aGU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZD48YSBuYW1lPSJkaWZmMDAzOCI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg IE1ldGVyaW5nIFByb2Nlc3MgUmVsaWFiaWxpdHkgU3RhdGlzdGljcyBPcHRpb24gVGVtcGxh dGUgb24gYSByZWd1bGFyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIE1l dGVyaW5nIFByb2Nlc3MgUmVsaWFiaWxpdHkgU3RhdGlzdGljcyBPcHRpb248c3BhbiBjbGFz cz0iaW5zZXJ0Ij5zPC9zcGFuPiBUZW1wbGF0ZSBvbiBhIHJlZ3VsYXI8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJhc2lz IG9yIGJhc2VkIG9uIHNvbWUgZXhwb3J0IHBvbGljeS4gIFRoaXMgcGVyaW9kaWNpdHkgb3Ig ZXhwb3J0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYmFzaXMgb3IgYmFz ZWQgb24gc29tZSBleHBvcnQgcG9saWN5LiAgVGhpcyBwZXJpb2RpY2l0eSBvciBleHBvcnQ8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIHBvbGljeSBTSE9VTEQgYmUgY29uZmlndXJhYmxlLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIHBvbGljeSBTSE9VTEQgYmUgY29uZmlndXJhYmxlLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBOb3RlIHRoYXQgaWYg c2V2ZXJhbCBNZXRlcmluZyBQcm9jZXNzZXMgYXJlIGF2YWlsYWJsZSBvbiB0aGUgRXhwb3J0 ZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBOb3RlIHRoYXQgaWYgc2V2 ZXJhbCBNZXRlcmluZyBQcm9jZXNzZXMgYXJlIGF2YWlsYWJsZSBvbiB0aGUgRXhwb3J0ZXI8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIE9ic2VydmF0aW9uIERvbWFpbiwgdGhlIEluZm9ybWF0aW9uIEVsZW1lbnQgbWV0 ZXJpbmdQcm9jZXNzSWQgTVVTVCBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIE9ic2VydmF0aW9uIERvbWFpbiwgdGhlIEluZm9ybWF0aW9uIEVsZW1lbnQgbWV0ZXJp bmdQcm9jZXNzSWQgTVVTVCBiZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc3BlY2lmaWVkIGFzIGFuIGFkZGl0aW9uYWwg U2NvcGUgRmllbGQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc3BlY2lm aWVkIGFzIGFuIGFkZGl0aW9uYWwgU2NvcGUgRmllbGQuPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAzOSI+PC9hPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjQuMy4gIFRoZSBFeHBvcnRpbmcgUHJvY2VzcyBSZWxpYWJp bGl0eSBTdGF0aXN0aWNzIE9wdGlvbiBUZW1wbGF0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj40LjMuICBUaGUgRXhwb3J0aW5nIFByb2Nlc3MgUmVsaWFiaWxpdHkgU3Rh dGlzdGljcyBPcHRpb248c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zPC9zcGFuPiBUZW1wbGF0ZTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0i ZGlmZjAwNDAiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGUgRXhwb3J0aW5n IFByb2Nlc3MgUmVsaWFiaWxpdHkgT3B0aW9uIFRlbXBsYXRlIHNwZWNpZmllcyB0aGU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGhlIEV4cG9ydGluZyBQcm9jZXNz IFJlbGlhYmlsaXR5IE9wdGlvbjxzcGFuIGNsYXNzPSJpbnNlcnQiPnM8L3NwYW4+IFRlbXBs YXRlIHNwZWNpZmllcyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHN0cnVjdHVyZSBvZiBhIERhdGEgUmVjb3JkIGZv ciByZXBvcnRpbmcgbGFjayBvZiByZWxpYWJpbGl0eSBpbiB0aGU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBzdHJ1Y3R1cmUgb2YgYSBEYXRhIFJlY29yZCBmb3IgcmVw b3J0aW5nIGxhY2sgb2YgcmVsaWFiaWxpdHkgaW4gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBFeHBvcnRpbmcgcHJv Y2Vzcy4gIEl0IFNIT1VMRCBjb250YWluIHRoZSBmb2xsb3dpbmcgSW5mb3JtYXRpb248L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBFeHBvcnRpbmcgcHJvY2Vzcy4gIEl0 IFNIT1VMRCBjb250YWluIHRoZSBmb2xsb3dpbmcgSW5mb3JtYXRpb248L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEVsZW1l bnRzIHRoYXQgYXJlIGRlZmluZWQgaW4gW1JGQzUxMDJdOjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIEVsZW1lbnRzIHRoYXQgYXJlIGRlZmluZWQgaW4gW1JGQzUxMDJd OjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBFeHBvcnRp bmcgUHJvY2VzcyBJRDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEV4cG9y dGluZyBQcm9jZXNzIElEPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICBUaGUgaWRlbnRp ZmllciBvZiB0aGUgRXhwb3J0aW5nIFByb2Nlc3MgZm9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgVGhlIGlkZW50aWZpZXIgb2Yg dGhlIEV4cG9ydGluZyBQcm9jZXNzIGZvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAg d2hpY2ggbGFjayBvZiByZWxpYWJpbGl0eSBpcyByZXBvcnRlZC4gIFRoZXJlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2gg bGFjayBvZiByZWxpYWJpbGl0eSBpcyByZXBvcnRlZC4gIFRoZXJlPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgICAgICAgICAgICBhcmUgdGhyZWUgSW5mb3JtYXRpb24gRWxlbWVudHMgc3BlY2lmaWVk IGluPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAg ICAgICAgYXJlIHRocmVlIEluZm9ybWF0aW9uIEVsZW1lbnRzIHNwZWNpZmllZCBpbjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgICAgICAgICAgICAgW1JGQzUxMDJdIHRoYXQgY2FuIGJlIHVzZWQgZm9y IHRoaXMgcHVycG9zZTo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICAgICAgICAgICAgICAgICBbUkZDNTEwMl0gdGhhdCBjYW4gYmUgdXNlZCBmb3IgdGhpcyBw dXJwb3NlOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgZXhwb3J0ZXJJUHY0QWRkcmVz cywgZXhwb3J0ZXJJUHY2QWRkcmVzcywgb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICBleHBvcnRlcklQdjRBZGRyZXNzLCBleHBv cnRlcklQdjZBZGRyZXNzLCBvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRk PjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDEwIj48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdl IGF0PC9zbWFsbD48ZW0+IHBhZ2UgMjYsIGxpbmUgMjg8L2VtPjwvYT48L3RoPjx0aD4gPC90 aD48dGg+PGEgbmFtZT0icGFydC1yMTAiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8 L3NtYWxsPjxlbT4gcGFnZSAyNywgbGluZSAyODwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICBDb2xsZWN0aW5nIFByb2Nl c3MuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAg ICAgICAgQ29sbGVjdGluZyBQcm9jZXNzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBub3RTZW50T2N0ZXRUb3RhbENvdW50PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgbm90U2VudE9jdGV0VG90YWxDb3VudDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICAgICAgICAgICAgICAgICAgVGhlIHRvdGFsIG51bWJlciBvZiBvY3RldHMgaW4gcGFja2V0 cyBpbiBGbG93PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAg ICAgICAgICAgICAgVGhlIHRvdGFsIG51bWJlciBvZiBvY3RldHMgaW4gcGFja2V0cyBpbiBG bG93PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICBSZWNvcmRzIHRoYXQgd2VyZSBnZW5l cmF0ZWQgYnkgdGhlIE1ldGVyaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgICAgICAgICAgICAgICAgICAgUmVjb3JkcyB0aGF0IHdlcmUgZ2VuZXJhdGVkIGJ5 IHRoZSBNZXRlcmluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgUHJvY2VzcyBhbmQg ZHJvcHBlZCBieSB0aGUgTWV0ZXJpbmcgUHJvY2VzcyBvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgIFByb2Nlc3MgYW5kIGRyb3Bw ZWQgYnkgdGhlIE1ldGVyaW5nIFByb2Nlc3Mgb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAg ICAgIGJ5IHRoZSBFeHBvcnRpbmcgUHJvY2VzcyBpbnN0ZWFkIG9mIGJlaW5nIHNlbnQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICBi eSB0aGUgRXhwb3J0aW5nIFByb2Nlc3MgaW5zdGVhZCBvZiBiZWluZyBzZW50PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICAgICAgICAgICAgICAgICB0byB0aGUgQ29sbGVjdGluZyBQcm9jZXNzLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgIHRvIHRo ZSBDb2xsZWN0aW5nIFByb2Nlc3MuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHRpbWUgZmlyc3QgZmxvdyBkcm9wcGVkPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgdGltZSBmaXJzdCBmbG93IGRyb3BwZWQ8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBu YW1lPSJkaWZmMDA0MSI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAg ICAgICAgICAgICAgIFRoZSB0aW1lc3RhbXAgb2YgdGhlIGZpcnN0IEZsb3cgd2FzIGRyb3Bw ZWQgYnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAg ICAgICAgICAgVGhlIHRpbWVzdGFtcCBvZiB0aGUgZmlyc3QgRmxvdyA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij50aGF0PC9zcGFuPiB3YXMgZHJvcHBlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAg ICAgICAgICB0aGUgTWV0ZXJpbmcgUHJvY2Vzcy4gIEZvciB0aGlzIHRpbWVzdGFtcCwgYW55 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAg ICAgIGJ5IHRoZSBNZXRlcmluZyAgUHJvY2Vzcy4gIEZvciB0aGlzIHRpbWVzdGFtcCw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgICAgICAgICAgICAgICAgICAgICAgb2YgdGhlICJmbG93U3RhcnQiIHRpbWVzdGFt cCBJbmZvcm1hdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAg ICAgICAgICAgICAgICAgICBhbnkgb2YgdGhlICJmbG93U3RhcnQiIHRpbWVzdGFtcCBJbmZv cm1hdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgRWxlbWVudHMgZmxvd1N0YXJ0 TWlsbGlzZWNvbmRzLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAg ICAgICAgICAgICAgICAgIEVsZW1lbnRzIGZsb3dTdGFydE1pbGxpc2Vjb25kcyw8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgICAgICAgICAgIGZsb3dTdGFydE1pY3Jvc2Vjb25kcywgZmxvd1N0YXJ0 TmFub3NlY29uZHMsIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgICAgICAgICAgICAgICAgIGZsb3dTdGFydE1pY3Jvc2Vjb25kcywgZmxvd1N0YXJ0TmFu b3NlY29uZHMsIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgZmxvd1N0YXJ0RGVs dGFNaWNyb3NlY29uZHMgY2FuIGJlIHVzZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgZmxvd1N0YXJ0RGVsdGFNaWNyb3NlY29u ZHMgY2FuIGJlIHVzZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIHRpbWUgbGFzdCBmbG93IGRyb3BwZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICB0aW1lIGxhc3QgZmxvdyBkcm9wcGVkPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAg ICAgICAgICBUaGUgdGltZXN0YW1wIG9mIHRoZSBsYXN0IElQIHBhY2tldCB0aGF0IHdhczwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAg IFRoZSB0aW1lc3RhbXAgb2YgdGhlIGxhc3QgSVAgcGFja2V0IHRoYXQgd2FzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+ PGEgbmFtZT0iZGlmZjAwNDIiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAg ICAgICAgICAgICAgICAgICBpZ25vcmVkIGJ5IHRoZSBNZXRlcmluZyBQcm9jZXNzLiAgRm9y IHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAg ICAgICAgICAgaWdub3JlZCBieSB0aGUgTWV0ZXJpbmcgPHNwYW4gY2xhc3M9Imluc2VydCI+ IDwvc3Bhbj5Qcm9jZXNzLiAgRm9yIHRoaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAg IHRpbWVzdGFtcCwgYW55IG9mIHRoZSAiZmxvd0VuZCIgdGltZXN0YW1wPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgdGltZXN0YW1w LCBhbnkgb2YgdGhlICJmbG93RW5kIiB0aW1lc3RhbXA8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAg ICAgICAgIEluZm9ybWF0aW9uIEVsZW1lbnRzIGZsb3dFbmRNaWxsaXNlY29uZHMsPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgSW5m b3JtYXRpb24gRWxlbWVudHMgZmxvd0VuZE1pbGxpc2Vjb25kcyw8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAg ICAgICAgICAgICAgIGZsb3dFbmRNaWNyb3NlY29uZHMsIGZsb3dFbmROYW5vc2Vjb25kcywg YW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAg ICAgICAgZmxvd0VuZE1pY3Jvc2Vjb25kcywgZmxvd0VuZE5hbm9zZWNvbmRzLCBhbmQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICAgICAgICAgICAgIGZsb3dFbmREZWx0YU1pY3Jvc2Vjb25kcyBjYW4g YmUgdXNlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAg ICAgICAgICAgICBmbG93RW5kRGVsdGFNaWNyb3NlY29uZHMgY2FuIGJlIHVzZWQuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBFeHBvcnRpbmcg UHJvY2VzcyBTSE9VTEQgZXhwb3J0IHRoZSBEYXRhIFJlY29yZCBzcGVjaWZpZWQgYnkgdGhl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIEV4cG9ydGluZyBQcm9j ZXNzIFNIT1VMRCBleHBvcnQgdGhlIERhdGEgUmVjb3JkIHNwZWNpZmllZCBieSB0aGU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZD48YSBuYW1lPSJkaWZmMDA0MyI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg IEV4cG9ydGluZyBQcm9jZXNzIFJlbGlhYmlsaXR5IFN0YXRpc3RpY3MgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+T3B0aW9uPC9zcGFuPiBUZW1wbGF0ZSBvbiBhIHJlZ3VsYXI8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgRXhwb3J0aW5nIFByb2Nlc3MgUmVsaWFiaWxp dHkgU3RhdGlzdGljcyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5PcHRpb25zPC9zcGFuPiBUZW1w bGF0ZSBvbiBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIGJhc2lzIG9yIGJhc2VkIG9uIHNvbWUgZXhwb3J0IHBvbGlj eS4gIFRoaXMgcGVyaW9kaWNpdHkgb3IgZXhwb3J0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIHJlZ3VsYXIgYmFzaXMgb3IgYmFzZWQgb24gc29tZSBleHBvcnQgcG9s aWN5LiAgVGhpcyBwZXJpb2RpY2l0eSBvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBwb2xpY3kgU0hPVUxEIGJlIGNv bmZpZ3VyYWJsZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZXhwb3J0 IHBvbGljeSBTSE9VTEQgYmUgY29uZmlndXJhYmxlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNDQiPjwvYT48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj40LjQuICBUaGUgRmxvdyBLZXlzIE9wdGlvbiBUZW1wbGF0ZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj40LjQuICBUaGUgRmxvdyBLZXlzIE9w dGlvbjxzcGFuIGNsYXNzPSJpbnNlcnQiPnM8L3NwYW4+IFRlbXBsYXRlPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA0NSI+ PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRoZSBGbG93IEtleXMgT3B0aW9uIFRl bXBsYXRlIHNwZWNpZmllcyB0aGUgc3RydWN0dXJlIG9mIGEgRGF0YTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGUgRmxvdyBLZXlzIE9wdGlvbjxzcGFuIGNsYXNz PSJpbnNlcnQiPnM8L3NwYW4+IFRlbXBsYXRlIHNwZWNpZmllcyB0aGUgc3RydWN0dXJlIG9m IGEgRGF0YTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgUmVjb3JkIGZvciByZXBvcnRpbmcgdGhlIEZsb3cgS2V5cyBvZiBy ZXBvcnRlZCBGbG93cy4gIEEgRmxvdyBLZXlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgUmVjb3JkIGZvciByZXBvcnRpbmcgdGhlIEZsb3cgS2V5cyBvZiByZXBvcnRl ZCBGbG93cy4gIEEgRmxvdyBLZXlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEYXRhIFJlY29yZCBleHRlbmRzIGEgcGFy dGljdWxhciBUZW1wbGF0ZSBSZWNvcmQgdGhhdCBpcyByZWZlcmVuY2VkPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRGF0YSBSZWNvcmQgZXh0ZW5kcyBhIHBhcnRpY3Vs YXIgVGVtcGxhdGUgUmVjb3JkIHRoYXQgaXMgcmVmZXJlbmNlZDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYnkgaXRzIHRl bXBsYXRlSWQgaWRlbnRpZmllci4gIFRoZSBUZW1wbGF0ZSBSZWNvcmQgaXMgZXh0ZW5kZWQg Ynk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBieSBpdHMgdGVtcGxhdGVJ ZCBpZGVudGlmaWVyLiAgVGhlIFRlbXBsYXRlIFJlY29yZCBpcyBleHRlbmRlZCBieTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgc3BlY2lmeWluZyB3aGljaCBvZiB0aGUgSW5mb3JtYXRpb24gRWxlbWVudHMgY29udGFp bmVkIGluIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNwZWNpZnlp bmcgd2hpY2ggb2YgdGhlIEluZm9ybWF0aW9uIEVsZW1lbnRzIGNvbnRhaW5lZCBpbiB0aGU8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIGNvcnJlc3BvbmRpbmcgRGF0YSBSZWNvcmRzIGRlc2NyaWJlIEZsb3cgcHJvcGVy dGllcyB0aGF0IHNlcnZlIGFzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg Y29ycmVzcG9uZGluZyBEYXRhIFJlY29yZHMgZGVzY3JpYmUgRmxvdyBwcm9wZXJ0aWVzIHRo YXQgc2VydmUgYXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIEZsb3cgS2V5cyBvZiB0aGUgcmVwb3J0ZWQgRmxvdy48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBGbG93IEtleXMgb2YgdGhlIHJlcG9y dGVkIEZsb3cuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZD48YSBuYW1lPSJkaWZmMDA0NiI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRo ZSBGbG93IEtleXMgT3B0aW9uIFRlbXBsYXRlIFNIT1VMRCBjb250YWluIHRoZSBmb2xsb3dp bmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGhlIEZsb3cgS2V5cyBP cHRpb248c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zPC9zcGFuPiBUZW1wbGF0ZSBTSE9VTEQgY29u dGFpbiB0aGUgZm9sbG93aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbmZvcm1hdGlvbiBFbGVtZW50cyB0aGF0IGFy ZSBkZWZpbmVkIGluIFtSRkM1MTAyXTo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBJbmZvcm1hdGlvbiBFbGVtZW50cyB0aGF0IGFyZSBkZWZpbmVkIGluIFtSRkM1MTAy XTo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGVtcGxh dGVJZCAgICAgICAgICAgICAgQW4gaWRlbnRpZmllciBvZiBhIFRlbXBsYXRlLiAgVGhpczwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRlbXBsYXRlSWQgICAgICAgICAg ICAgIEFuIGlkZW50aWZpZXIgb2YgYSBUZW1wbGF0ZS4gIFRoaXM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAg ICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uIEVsZW1lbnQgTVVTVCBiZSBkZWZpbmVkIGFz IGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAg ICAgICAgICBJbmZvcm1hdGlvbiBFbGVtZW50IE1VU1QgYmUgZGVmaW5lZCBhcyBhPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICAgICAgICAgICAgICAgICAgICBTY29wZSBGaWVsZC48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICBTY29wZSBGaWVs ZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZmxvd0tl eUluZGljYXRvciAgICAgICAgQml0bWFwIHdpdGggdGhlIHBvc2l0aW9ucyBvZiB0aGUgRmxv dyBLZXlzIGluPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZmxvd0tleUlu ZGljYXRvciAgICAgICAgQml0bWFwIHdpdGggdGhlIHBvc2l0aW9ucyBvZiB0aGUgRmxvdyBL ZXlzIGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgRGF0YSBSZWNvcmRz LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAg ICAgICAgIHRoZSBEYXRhIFJlY29yZHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjUuICBJUEZJWCBNZXNzYWdlIEhlYWRlciAiRXhwb3J0IFRpbWUiIGFu ZCBGbG93IFJlY29yZCBUaW1lPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NS4g IElQRklYIE1lc3NhZ2UgSGVhZGVyICJFeHBvcnQgVGltZSIgYW5kIEZsb3cgUmVjb3JkIFRp bWU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPg0KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiPjx0ZD48L3RkPjx0aD48YSBuYW1l PSJwYXJ0LWwxMSI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBw YWdlIDI4LCBsaW5lIDM2PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBh cnQtcjExIj48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2Ug MjksIGxpbmUgMzY8L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg dHJlYXRlZCBhcyBhIDYtb2N0ZXQgaW50ZWdlciwgdGhlIGlwdjRBZGRyZXNzIGFzIGEgNC1v Y3RldCBpbnRlZ2VyLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRyZWF0 ZWQgYXMgYSA2LW9jdGV0IGludGVnZXIsIHRoZSBpcHY0QWRkcmVzcyBhcyBhIDQtb2N0ZXQg aW50ZWdlciw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGFuZCB0aGUgaXB2NkFkZHJlc3MgYXMgYSAxNi1vY3RldCBpbnRl Z2VyLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCB0aGUgaXB2NkFk ZHJlc3MgYXMgYSAxNi1vY3RldCBpbnRlZ2VyLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij42LjEuMy4gIGZsb2F0MzI8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij42LjEuMy4gIGZsb2F0MzI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGZsb2F0MzIgZGF0YSB0eXBlIE1VU1QgYmUgZW5jb2Rl ZCBhcyBhbiBJRUVFIHNpbmdsZS1wcmVjaXNpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBUaGUgZmxvYXQzMiBkYXRhIHR5cGUgTVVTVCBiZSBlbmNvZGVkIGFzIGFu IElFRUUgc2luZ2xlLXByZWNpc2lvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMzItYml0IGZsb2F0aW5nIHBvaW50LXR5 cGUsIGFzIHNwZWNpZmllZCBpbiBbSUVFRS43NTQuMTk4NV0uPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgMzItYml0IGZsb2F0aW5nIHBvaW50LXR5cGUsIGFzIHNwZWNp ZmllZCBpbiBbSUVFRS43NTQuMTk4NV0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjYuMS40LiAgZmxvYXQ2NDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjYuMS40LiAgZmxvYXQ2NDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNDciPjwvYT48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICBUaGUgZmxvYXQ2NCBkYXRhIHR5cGUgTVVTVCBiZSBlbmNvZGVkIGFzIGFu IElFRUUgZG91YmxlLXByZWNpc2lvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICBUaGUgZmxvYXQ2NCBkYXRhIHR5cGUgTVVTVCBiZSBlbmNvZGVkIGFzIGFuIElFRUUg ZG91YmxlLXByZWNpc2lvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij42NC08L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPjY0LWJpdDwvc3Bhbj4gZmxvYXRpbmcgcG9pbnQt dHlwZSwgYXMgc3BlY2lmaWVkIGluIFtJRUVFLjc1NC4xOTg1XS48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgYml0PC9zcGFuPiBm bG9hdGluZyBwb2ludC10eXBlLCBhcyBzcGVjaWZpZWQgaW4gW0lFRUUuNzU0LjE5ODVdLjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij42LjEuNS4gIGJvb2xl YW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij42LjEuNS4gIGJvb2xlYW48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGJvb2xlYW4g ZGF0YSB0eXBlIGlzIHNwZWNpZmllZCBhY2NvcmRpbmcgdG8gdGhlIFRydXRoVmFsdWUgaW48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgYm9vbGVhbiBkYXRhIHR5 cGUgaXMgc3BlY2lmaWVkIGFjY29yZGluZyB0byB0aGUgVHJ1dGhWYWx1ZSBpbjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg W1JGQzI1NzldOiBpdCBpcyBhbiBpbnRlZ2VyIHdpdGggdGhlIHZhbHVlIDEgZm9yIHRydWUg YW5kIGEgdmFsdWUgMjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkMy NTc5XTogaXQgaXMgYW4gaW50ZWdlciB3aXRoIHRoZSB2YWx1ZSAxIGZvciB0cnVlIGFuZCBh IHZhbHVlIDI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGZvciBmYWxzZS4gIEV2ZXJ5IG90aGVyIHZhbHVlIGlzIHVuZGVm aW5lZC4gIFRoZSBib29sZWFuIGRhdGEgdHlwZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGZvciBmYWxzZS4gIEV2ZXJ5IG90aGVyIHZhbHVlIGlzIHVuZGVmaW5lZC4g IFRoZSBib29sZWFuIGRhdGEgdHlwZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTVVTVCBiZSBlbmNvZGVkIGluIGEgc2lu Z2xlIG9jdGV0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE1VU1QgYmUg ZW5jb2RlZCBpbiBhIHNpbmdsZSBvY3RldC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDQ4Ij48L2E+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+Ni4xLjYuICBzdHJpbmcgYW5kIG9jdGV0PHNwYW4gY2xhc3M9ImRlbGV0 ZSI+YTwvc3Bhbj5ycmF5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjYuMS42 LiAgc3RyaW5nIGFuZCBvY3RldDxzcGFuIGNsYXNzPSJpbnNlcnQiPkE8L3NwYW4+cnJheTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgZGF0YSB0 eXBlIHN0cmluZyByZXByZXNlbnRzIGEgZmluaXRlIGxlbmd0aCBzdHJpbmcgb2YgdmFsaWQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgZGF0YSB0eXBlIHN0cmlu ZyByZXByZXNlbnRzIGEgZmluaXRlIGxlbmd0aCBzdHJpbmcgb2YgdmFsaWQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNo YXJhY3RlcnMgb2YgdGhlIFVuaWNvZGUgY2hhcmFjdGVyIGVuY29kaW5nIHNldC4gIFRoZSBz dHJpbmcgZGF0YTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNoYXJhY3Rl cnMgb2YgdGhlIFVuaWNvZGUgY2hhcmFjdGVyIGVuY29kaW5nIHNldC4gIFRoZSBzdHJpbmcg ZGF0YTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgdHlwZSBNVVNUIGJlIGVuY29kZWQgaW4gVVRGLTggZm9ybWF0LiAgVGhl IHN0cmluZyBpcyBzZW50IGFzIGFuIGFycmF5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgdHlwZSBNVVNUIGJlIGVuY29kZWQgaW4gVVRGLTggZm9ybWF0LiAgVGhlIHN0 cmluZyBpcyBzZW50IGFzIGFuIGFycmF5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvZiBvY3RldHMgdXNpbmcgYW4gSW5m b3JtYXRpb24gRWxlbWVudCBvZiBmaXhlZCBvciB2YXJpYWJsZSBsZW5ndGguPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb2Ygb2N0ZXRzIHVzaW5nIGFuIEluZm9ybWF0 aW9uIEVsZW1lbnQgb2YgZml4ZWQgb3IgdmFyaWFibGUgbGVuZ3RoLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgbGVuZ3RoIG9mIHRoZSBJbmZv cm1hdGlvbiBFbGVtZW50IHNwZWNpZmllcyB0aGUgbGVuZ3RoIG9mIHRoZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBsZW5ndGggb2YgdGhlIEluZm9ybWF0aW9u IEVsZW1lbnQgc3BlY2lmaWVzIHRoZSBsZW5ndGggb2YgdGhlPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0i ZGlmZjAwNDkiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBvY3RldDxzcGFuIGNs YXNzPSJkZWxldGUiPmE8L3NwYW4+cnJheS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgb2N0ZXQ8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5BPC9zcGFuPnJyYXkuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjYuMS43LiAgZGF0ZVRpbWVT ZWNvbmRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Ni4xLjcuICBkYXRlVGlt ZVNlY29uZHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk PjxhIG5hbWU9ImRpZmYwMDUwIj48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVGhl IGRhdGEgdHlwZSBkYXRlVGltZTxzcGFuIGNsYXNzPSJkZWxldGUiPnM8L3NwYW4+ZWNvbmRz IHJlcHJlc2VudHMgYSB0aW1lIHZhbHVlIGluIHVuaXRzIG9mPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIFRoZSBkYXRhIHR5cGUgZGF0ZVRpbWU8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5TPC9zcGFuPmVjb25kcyByZXByZXNlbnRzIGEgdGltZSB2YWx1ZSBpbiB1bml0 cyBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgc2Vjb25kcyBub3JtYWxpemVkIHRvIHRoZSBHTVQgdGltZXpvbmUuICBJ dCBNVVNUIGJlIGVuY29kZWQgaW4gYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHNlY29uZHMgbm9ybWFsaXplZCB0byB0aGUgR01UIHRpbWV6b25lLiAgSXQgTVVTVCBi ZSBlbmNvZGVkIGluIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDMyLWJpdCBpbnRlZ2VyIGNvbnRhaW5pbmcgdGhlIG51 bWJlciBvZiBzZWNvbmRzIHNpbmNlIDAwMDAgVVRDIEphbiAxLDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIDMyLWJpdCBpbnRlZ2VyIGNvbnRhaW5pbmcgdGhlIG51bWJl ciBvZiBzZWNvbmRzIHNpbmNlIDAwMDAgVVRDIEphbiAxLDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMTk3MC4gIFRoZSAz Mi1iaXQgaW50ZWdlciBhbGxvd3MgdGhlIHRpbWUgZW5jb2RpbmcgdXAgdG8gMTM2IHllYXJz LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDE5NzAuICBUaGUgMzItYml0 IGludGVnZXIgYWxsb3dzIHRoZSB0aW1lIGVuY29kaW5nIHVwIHRvIDEzNiB5ZWFycy48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ni4xLjguICBkYXRlVGlt ZU1pbGxpc2Vjb25kczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjYuMS44LiAg ZGF0ZVRpbWVNaWxsaXNlY29uZHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgVGhlIGRhdGEgdHlwZSBkYXRlVGltZU1pbGxpc2Vjb25kcyByZXByZXNl bnRzIGEgdGltZSB2YWx1ZSBpbiB1bml0czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFRoZSBkYXRhIHR5cGUgZGF0ZVRpbWVNaWxsaXNlY29uZHMgcmVwcmVzZW50cyBh IHRpbWUgdmFsdWUgaW4gdW5pdHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9mIG1pbGxpc2Vjb25kcyBub3JtYWxpemVk IHRvIHRoZSBHTVQgdGltZXpvbmUuICBJdCBNVVNUIGJlIGVuY29kZWQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvZiBtaWxsaXNlY29uZHMgbm9ybWFsaXplZCB0byB0 aGUgR01UIHRpbWV6b25lLiAgSXQgTVVTVCBiZSBlbmNvZGVkPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbiBhIDY0LWJp dCBpbnRlZ2VyIGNvbnRhaW5pbmcgdGhlIG51bWJlciBvZiBtaWxsaXNlY29uZHMgc2luY2Ug MDAwMDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluIGEgNjQtYml0IGlu dGVnZXIgY29udGFpbmluZyB0aGUgbnVtYmVyIG9mIG1pbGxpc2Vjb25kcyBzaW5jZSAwMDAw PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBVVEMgSmFuIDEsIDE5NzAuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgVVRDIEphbiAxLCAxOTcwLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+ PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDEyIj48c21hbGw+c2tpcHBpbmcgdG8gY2hh bmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMjksIGxpbmUgMzc8L2VtPjwvYT48L3RoPjx0aD4g PC90aD48dGg+PGEgbmFtZT0icGFydC1yMTIiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2Ug YXQ8L3NtYWxsPjxlbT4gcGFnZSAzMCwgbGluZSAzNzwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjYuMS4xMC4gIGRhdGVUaW1lTmFub3NlY29uZHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij42LjEuMTAuICBkYXRlVGltZU5hbm9zZWNvbmRzPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBkYXRhIHR5cGUgb2YgZGF0ZVRpbWVO YW5vc2Vjb25kcyByZXByZXNlbnRzIGEgdGltZSB2YWx1ZSBpbiB1bml0czwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBkYXRhIHR5cGUgb2YgZGF0ZVRpbWVOYW5v c2Vjb25kcyByZXByZXNlbnRzIGEgdGltZSB2YWx1ZSBpbiB1bml0czwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb2YgbmFu b3NlY29uZHMgbm9ybWFsaXplZCB0byB0aGUgR01UIHRpbWUgem9uZS4gIEl0IE1VU1QgYmUg ZW5jb2RlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9mIG5hbm9zZWNv bmRzIG5vcm1hbGl6ZWQgdG8gdGhlIEdNVCB0aW1lIHpvbmUuICBJdCBNVVNUIGJlIGVuY29k ZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGluIGEgNjQtYml0IGludGVnZXIsIGFjY29yZGluZyB0byB0aGUgTlRQIGZv cm1hdCBnaXZlbiBpbiBbUkZDMTMwNV0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgaW4gYSA2NC1iaXQgaW50ZWdlciwgYWNjb3JkaW5nIHRvIHRoZSBOVFAgZm9ybWF0 IGdpdmVuIGluIFtSRkMxMzA1XS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+Ni4yLiAgUmVkdWNlZCBTaXplIEVuY29kaW5nIG9mIEludGVnZXIgYW5kIEZs b2F0IFR5cGVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Ni4yLiAgUmVkdWNl ZCBTaXplIEVuY29kaW5nIG9mIEludGVnZXIgYW5kIEZsb2F0IFR5cGVzPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEluZm9ybWF0aW9uIEVsZW1lbnRz IGNvbnRhaW5pbmcgaW50ZWdlciwgc3RyaW5nLCBmbG9hdCwgYW5kPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgSW5mb3JtYXRpb24gRWxlbWVudHMgY29udGFpbmluZyBp bnRlZ2VyLCBzdHJpbmcsIGZsb2F0LCBhbmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA1MSI+ PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIG9jdGV0PHNwYW4gY2xhc3M9ImRlbGV0 ZSI+YTwvc3Bhbj5ycmF5IHR5cGVzIGluIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBNQVkgYmUg ZW5jb2RlZCB1c2luZyBmZXdlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICBvY3RldDxzcGFuIGNsYXNzPSJpbnNlcnQiPkE8L3NwYW4+cnJheSB0eXBlcyBpbiB0aGUg aW5mb3JtYXRpb24gbW9kZWwgTUFZIGJlIGVuY29kZWQgdXNpbmcgZmV3ZXI8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9j dGV0cyB0aGFuIHRob3NlIGltcGxpZWQgYnkgdGhlaXIgdHlwZSBpbiB0aGUgaW5mb3JtYXRp b24gbW9kZWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvY3RldHMgdGhh biB0aG9zZSBpbXBsaWVkIGJ5IHRoZWlyIHR5cGUgaW4gdGhlIGluZm9ybWF0aW9uIG1vZGVs PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBkZWZpbml0aW9uIFtSRkM1MTAyXSwgYmFzZWQgb24gdGhlIGFzc3VtcHRpb24g dGhhdCB0aGUgc21hbGxlciBzaXplPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgZGVmaW5pdGlvbiBbUkZDNTEwMl0sIGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQg dGhlIHNtYWxsZXIgc2l6ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaXMgc3VmZmljaWVudCB0byBjYXJyeSBhbnkgdmFs dWUgdGhlIEV4cG9ydGVyIG1heSBuZWVkIHRvIGRlbGl2ZXIuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgaXMgc3VmZmljaWVudCB0byBjYXJyeSBhbnkgdmFsdWUgdGhl IEV4cG9ydGVyIG1heSBuZWVkIHRvIGRlbGl2ZXIuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIHJlZHVjZXMgdGhl IG5ldHdvcmsgYmFuZHdpZHRoIHJlcXVpcmVtZW50IGJldHdlZW4gdGhlIEV4cG9ydGVyPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyByZWR1Y2VzIHRoZSBuZXR3 b3JrIGJhbmR3aWR0aCByZXF1aXJlbWVudCBiZXR3ZWVuIHRoZSBFeHBvcnRlcjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg YW5kIHRoZSBDb2xsZWN0b3IuICBOb3RlIHRoYXQgdGhlIEluZm9ybWF0aW9uIEVsZW1lbnQg ZGVmaW5pdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbmQgdGhl IENvbGxlY3Rvci4gIE5vdGUgdGhhdCB0aGUgSW5mb3JtYXRpb24gRWxlbWVudCBkZWZpbml0 aW9uczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgW1JGQzUxMDJdIHdpbGwgYWx3YXlzIGRlZmluZSB0aGUgbWF4aW11bSBl bmNvZGluZyBzaXplLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkM1 MTAyXSB3aWxsIGFsd2F5cyBkZWZpbmUgdGhlIG1heGltdW0gZW5jb2Rpbmcgc2l6ZS48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRm9yIGluc3RhbmNl LCB0aGUgaW5mb3JtYXRpb24gbW9kZWwgW1JGQzUxMDJdIGRlZmluZXMgYnl0ZUNvdW50IGFz IGFuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRm9yIGluc3RhbmNlLCB0 aGUgaW5mb3JtYXRpb24gbW9kZWwgW1JGQzUxMDJdIGRlZmluZXMgYnl0ZUNvdW50IGFzIGFu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICB1bnNpZ25lZDY0IHR5cGUsIHdoaWNoIHdvdWxkIHJlcXVpcmUgNjQgYml0cy4g IEhvd2V2ZXIsIGlmIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHVu c2lnbmVkNjQgdHlwZSwgd2hpY2ggd291bGQgcmVxdWlyZSA2NCBiaXRzLiAgSG93ZXZlciwg aWYgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBFeHBvcnRlciB3aWxsIG5ldmVyIGxvY2FsbHkgZW5jb3VudGVyIHRo ZSBuZWVkIHRvIHNlbmQgYSB2YWx1ZSBsYXJnZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBFeHBvcnRlciB3aWxsIG5ldmVyIGxvY2FsbHkgZW5jb3VudGVyIHRoZSBu ZWVkIHRvIHNlbmQgYSB2YWx1ZSBsYXJnZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoYW4gNDI5NDk2NzI5NSwgaXQg bWF5IGNob3NlIHRvIHNlbmQgdGhlIHZhbHVlIGluc3RlYWQgYXMgYW48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGFuIDQyOTQ5NjcyOTUsIGl0IG1heSBjaG9zZSB0 byBzZW5kIHRoZSB2YWx1ZSBpbnN0ZWFkIGFzIGFuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB1bnNpZ25lZDMyLiAgRm9y IGV4YW1wbGUsIGEgY29yZSByb3V0ZXIgd291bGQgcmVxdWlyZSBhbiB1bnNpZ25lZDY0PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdW5zaWduZWQzMi4gIEZvciBleGFt cGxlLCBhIGNvcmUgcm91dGVyIHdvdWxkIHJlcXVpcmUgYW4gdW5zaWduZWQ2NDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg Ynl0ZUNvdW50LCB3aGlsZSBhbiB1bnNpZ25lZDMyIG1pZ2h0IGJlIHN1ZmZpY2llbnQgZm9y IGFuIGFjY2VzczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGJ5dGVDb3Vu dCwgd2hpbGUgYW4gdW5zaWduZWQzMiBtaWdodCBiZSBzdWZmaWNpZW50IGZvciBhbiBhY2Nl c3M8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHJvdXRlci48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBy b3V0ZXIuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRo aXMgYmVoYXZpb3IgaXMgaW5kaWNhdGVkIGJ5IHRoZSBFeHBvcnRlciBieSBzcGVjaWZ5aW5n IGEgdHlwZSBzaXplPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBi ZWhhdmlvciBpcyBpbmRpY2F0ZWQgYnkgdGhlIEV4cG9ydGVyIGJ5IHNwZWNpZnlpbmcgYSB0 eXBlIHNpemU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHdpdGggYSBzbWFsbGVyIGxlbmd0aCB0aGFuIHRoYXQgYXNzb2Np YXRlZCB3aXRoIHRoZSBhc3NpZ25lZCB0eXBlIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgd2l0aCBhIHNtYWxsZXIgbGVuZ3RoIHRoYW4gdGhhdCBhc3NvY2lhdGVk IHdpdGggdGhlIGFzc2lnbmVkIHR5cGUgb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBJbmZvcm1hdGlvbiBFbGVt ZW50LiAgSW4gdGhlIGV4YW1wbGUgYWJvdmUsIHRoZSBFeHBvcnRlciB3b3VsZDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBJbmZvcm1hdGlvbiBFbGVtZW50LiAg SW4gdGhlIGV4YW1wbGUgYWJvdmUsIHRoZSBFeHBvcnRlciB3b3VsZDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcGxhY2Ug YSBsZW5ndGggb2YgNCB2ZXJzdXMgOCBpbiB0aGUgVGVtcGxhdGUuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgcGxhY2UgYSBsZW5ndGggb2YgNCB2ZXJzdXMgOCBpbiB0 aGUgVGVtcGxhdGUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZD48YSBuYW1lPSJkaWZmMDA1MiI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg IElmIHJlZHVjZWQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+c2l6aW5nPC9zcGFuPiBpcyB1c2Vk LCBpdCBNVVNUIG9ubHkgYmUgYXBwbGllZCB0byB0aGUgZm9sbG93aW5nPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIElmIHJlZHVjZWQgPHNwYW4gY2xhc3M9Imluc2Vy dCI+c2l6ZSBlbmNvZGluZzwvc3Bhbj4gaXMgdXNlZCwgaXQgTVVTVCBvbmx5IGJlIGFwcGxp ZWQgdG8gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIGludGVnZXIgdHlwZXM6IHVuc2lnbmVkNjQsIHNpZ25lZDY0 LCB1bnNpZ25lZDMyLCBzaWduZWQzMiw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgZm9sbG93aW5nIGludGVnZXIgdHlwZXM6IHVuc2lnbmVkNjQsIHNpZ25lZDY0LCB1 bnNpZ25lZDMyLCBzaWduZWQzMiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHVuc2lnbmVkMTYsIGFuZCBzaWduZWQxNi4g IFRoZSBzaWduZWQgdmVyc3VzIHVuc2lnbmVkIHByb3BlcnR5IG9mIHRoZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHVuc2lnbmVkMTYsIGFuZCBzaWduZWQxNi4gIFRo ZSBzaWduZWQgdmVyc3VzIHVuc2lnbmVkIHByb3BlcnR5IG9mIHRoZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcmVwb3J0 ZWQgdmFsdWUgTVVTVCBiZSBwcmVzZXJ2ZWQuICBUaGUgcmVkdWN0aW9uIGluIHNpemUgY2Fu IGJlIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVwb3J0ZWQgdmFs dWUgTVVTVCBiZSBwcmVzZXJ2ZWQuICBUaGUgcmVkdWN0aW9uIGluIHNpemUgY2FuIGJlIHRv PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBhbnkgbnVtYmVyIG9mIG9jdGV0cyBzbWFsbGVyIHRoYW4gdGhlIG9yaWdpbmFs IHR5cGUgaWYgdGhlIGRhdGEgdmFsdWU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBhbnkgbnVtYmVyIG9mIG9jdGV0cyBzbWFsbGVyIHRoYW4gdGhlIG9yaWdpbmFsIHR5 cGUgaWYgdGhlIGRhdGEgdmFsdWU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHN0aWxsIGZpdHMsIGkuZS4sIHNvIHRoYXQg b25seSBsZWFkaW5nIHplcm9lcyBhcmUgZHJvcHBlZC4gIEZvcjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIHN0aWxsIGZpdHMsIGkuZS4sIHNvIHRoYXQgb25seSBsZWFk aW5nIHplcm9lcyBhcmUgZHJvcHBlZC4gIEZvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZXhhbXBsZSwgYW4gdW5zaWdu ZWQ2NCBjYW4gYmUgcmVkdWNlZCBpbiBzaXplIHRvIDcsIDYsIDUsIDQsIDMsIDIsIG9yPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZXhhbXBsZSwgYW4gdW5zaWduZWQ2 NCBjYW4gYmUgcmVkdWNlZCBpbiBzaXplIHRvIDcsIDYsIDUsIDQsIDMsIDIsIG9yPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAxIG9jdGV0KHMpLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDEgb2N0 ZXQocykuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48 YSBuYW1lPSJkaWZmMDA1MyI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFJlZHVj ZWQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+c2l6aW5nPC9zcGFuPiBjYW4gYWxzbyBiZSB1c2Vk IHRvIHJlZHVjZSBmbG9hdDY0IHRvIGZsb2F0MzIuICBUaGU8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgUmVkdWNlZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zaXplIGVu Y29kaW5nPC9zcGFuPiBjYW4gYWxzbyBiZSB1c2VkIHRvIHJlZHVjZSBmbG9hdDY0IHRvIGZs b2F0MzIuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIGZsb2F0MzIgbm90IG9ubHkgaGFzIGEgcmVkdWNlZCBudW1iZXIg cmFuZ2UsIGJ1dCBkdWUgdG8gdGhlIHNtYWxsZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgVGhlIGZsb2F0MzIgbm90IG9ubHkgaGFzIGEgcmVkdWNlZCBudW1iZXIg cmFuZ2UsIGJ1dCBkdWUgdG8gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIG1hbnRpc3NhLCBpcyBhbHNvIGxlc3Mg cHJlY2lzZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgc21hbGxlciBt YW50aXNzYSwgaXMgYWxzbyBsZXNzIHByZWNpc2UuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSByZWR1Y2VkIHNpemUgZW5jb2RpbmcgTVVTVCBO T1QgYmUgYXBwbGllZCB0byBkYXRlVGltZU1pY3Jvc2Vjb25kczwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSByZWR1Y2VkIHNpemUgZW5jb2RpbmcgTVVTVCBOT1Qg YmUgYXBwbGllZCB0byBkYXRlVGltZU1pY3Jvc2Vjb25kczwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb3IgdG8gZGF0ZVRp bWVOYW5vc2Vjb25kcyBiZWNhdXNlIHRoZXNlIHJlcHJlc2VudCBhbiBpbmhlcmVudDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9yIHRvIGRhdGVUaW1lTmFub3NlY29u ZHMgYmVjYXVzZSB0aGVzZSByZXByZXNlbnQgYW4gaW5oZXJlbnQ8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHN0cnVjdHVy ZSB0aGF0IHdvdWxkIGJlIGRlc3Ryb3llZCBieSB1c2luZyBsZXNzIHRoYW4gdGhlIG9yaWdp bmFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc3RydWN0dXJlIHRoYXQg d291bGQgYmUgZGVzdHJveWVkIGJ5IHVzaW5nIGxlc3MgdGhhbiB0aGUgb3JpZ2luYWw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIG51bWJlciBvZiBieXRlcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBudW1iZXIgb2YgYnl0ZXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjcuICBWYXJpYWJsZS1MZW5ndGggSW5mb3JtYXRpb24gRWxlbWVudDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjcuICBWYXJpYWJsZS1MZW5ndGggSW5mb3JtYXRp b24gRWxlbWVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBUaGUgSVBGSVggVGVtcGxhdGUgbWVjaGFuaXNtIGlzIG9wdGltaXplZCBmb3IgZml4ZWQt bGVuZ3RoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIElQRklYIFRl bXBsYXRlIG1lY2hhbmlzbSBpcyBvcHRpbWl6ZWQgZm9yIGZpeGVkLWxlbmd0aDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg SW5mb3JtYXRpb24gRWxlbWVudHMgW1JGQzUxMDJdLiAgV2hlcmUgYW4gSW5mb3JtYXRpb24g RWxlbWVudCBoYXMgYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEluZm9y bWF0aW9uIEVsZW1lbnRzIFtSRkM1MTAyXS4gIFdoZXJlIGFuIEluZm9ybWF0aW9uIEVsZW1l bnQgaGFzIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPg0KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiPjx0ZD48L3RkPjx0aD48 YSBuYW1lPSJwYXJ0LWwxMyI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+ PGVtPiBwYWdlIDMxLCBsaW5lIDE1PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5h bWU9InBhcnQtcjEzIj48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+ IHBhZ2UgMzIsIGxpbmUgMTU8L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAg ICAgICAgICAgICAgIDM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgMCAg ICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAg ICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwgTGVuZ3RoICgmbHQ7IDI1NSl8 ICAgICAgICAgIEluZm9ybWF0aW9uIEVsZW1lbnQgICAgICAgICAgICAgICAgICB8PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCBMZW5ndGggKCZsdDsgMjU1KXwgICAg ICAgICAgSW5mb3JtYXRpb24gRWxlbWVudCAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHwgICAgICAgICAgICAgICAgICAgICAgLi4uIGNvbnRpbnVpbmcgYXMgbmVl ZGVkICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgfCAgICAgICAgICAgICAgICAgICAgICAuLi4gY29udGludWluZyBhcyBuZWVkZWQgICAg ICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgRmlndXJlIFI6IFZhcmlhYmxlLUxlbmd0aCBJbmZvcm1hdGlv biBFbGVtZW50IChsZW5ndGggJmx0OyAyNTUgb2N0ZXRzKTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIEZpZ3VyZSBSOiBWYXJpYWJsZS1MZW5ndGggSW5mb3JtYXRpb24g RWxlbWVudCAobGVuZ3RoICZsdDsgMjU1IG9jdGV0cyk8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDU0Ij48L2E+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+SWY8L3NwYW4+IHRo ZSBsZW5ndGggb2YgdGhlIEluZm9ybWF0aW9uIEVsZW1lbnQgPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+aXM8L3NwYW4+IGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0bzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGUgbGVuZ3RoIG1h eSBhbHNvIGJlIGVuY29kZWQgaW50byAzIG9jdGV0cyBiZWZvcmUgdGhlIEluZm9ybWF0aW9u PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICAyNTUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+b2N0ZXRzLCB0aGUg bGVuZ3RoIGlzIGVuY29kZWQgaW50byAzIG9jdGV0cyBiZWZvcmUgdGhlPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBl bGVtZW50IGFsbG93aW5nPC9zcGFuPiB0aGUgbGVuZ3RoIG9mIHRoZSBJbmZvcm1hdGlvbiBF bGVtZW50IDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRvIGJlPC9zcGFuPiBncmVhdGVyPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIEluZm9ybWF0aW9uIEVsZW1lbnQuICBUaGU8L3Nw YW4+IGZpcnN0IG9jdGV0IDxzcGFuIGNsYXNzPSJkZWxldGUiPmlzPC9zcGFuPiAyNTUsIGFu ZCB0aGUgbGVuZ3RoIGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRo YW4gb3IgZXF1YWwgdG8gMjU1IDxzcGFuIGNsYXNzPSJpbnNlcnQiPm9jdGV0cy4gSW4gdGhp cyBjYXNlLDwvc3Bhbj4gZmlyc3Qgb2N0ZXQgPHNwYW4gY2xhc3M9Imluc2VydCI+b2YgdGhl IExlbmd0aDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgY2FycmllZCBpbiB0aGUgc2Vjb25kIGFuZCB0aGly ZCBvY3RldHMsIGFzIHNob3duIGluIEZpZ3VyZSBTLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBmaWVsZCBNVVNUIGJlPC9zcGFu PiAyNTUsIGFuZCB0aGUgbGVuZ3RoIGlzIGNhcnJpZWQgaW4gdGhlIHNlY29uZCBhbmQgdGhp cmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIG9jdGV0cywg YXMgc2hvd24gaW4gRmlndXJlIFMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAg MiAgICAgICAgICAgICAgICAgICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg ICAgICAgICAgIDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB8ICAgICAgMjU1ICAg ICAgfCAgICAgIExlbmd0aCAoMCB0byA2NTUzNSkgICAgICB8ICAgICAgIElFICAgICAgfDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHwgICAgICAyNTUgICAgICB8ICAg ICAgTGVuZ3RoICgwIHRvIDY1NTM1KSAgICAgIHwgICAgICAgSUUgICAgICB8PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICB8ICAgICAgICAgICAgICAgICAgICAgIC4uLiBjb250aW51aW5nIGFzIG5l ZWRlZCAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHwgICAgICAgICAgICAgICAgICAgICAgLi4uIGNvbnRpbnVpbmcgYXMgbmVlZGVkICAg ICAgICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIEZpZ3VyZSBTOiBWYXJpYWJsZS1MZW5ndGggSW5mb3JtYXRp b24gRWxlbWVudCAobGVuZ3RoIDAgdG8gNjU1MzU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBGaWd1cmUgUzogVmFyaWFibGUtTGVuZ3RoIEluZm9ybWF0aW9uIEVsZW1l bnQgKGxlbmd0aCAwIHRvIDY1NTM1PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48 dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMTQiPjxzbWFsbD5za2lwcGluZyB0byBjaGFu Z2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAzMywgbGluZSAzNTwvZW0+PC9hPjwvdGg+PHRoPiA8 L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXIxNCI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBh dDwvc21hbGw+PGVtPiBwYWdlIDM0LCBsaW5lIDM1PC9lbT48L2E+PC90aD48dGQ+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIE9ic2VydmF0aW9uIERvbWFpbiBJRCBzcGVjaWZpZWQgaW4g dGhlIElQRklYIE1lc3NhZ2UgSGVhZGVyLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIE9ic2VydmF0aW9uIERvbWFpbiBJRCBzcGVjaWZpZWQgaW4gdGhlIElQRklYIE1l c3NhZ2UgSGVhZGVyLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBUaGUgVGVtcGxhdGUgV2l0aGRyYXdhbCBNZXNzYWdlIG1heSBiZSBzZW50IG9uIGFu eSBTQ1RQIHN0cmVhbS4gIFRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFRoZSBUZW1wbGF0ZSBXaXRoZHJhd2FsIE1lc3NhZ2UgbWF5IGJlIHNlbnQgb24gYW55IFND VFAgc3RyZWFtLiAgVGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUZW1wbGF0ZSBXaXRoZHJhd2FsIE1lc3NhZ2UgTVVT VCBiZSBzZW50IHJlbGlhYmx5LCB1c2luZyBTQ1RQLW9yZGVyZWQ8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBUZW1wbGF0ZSBXaXRoZHJhd2FsIE1lc3NhZ2UgTVVTVCBi ZSBzZW50IHJlbGlhYmx5LCB1c2luZyBTQ1RQLW9yZGVyZWQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRlbGl2ZXJ5Ljwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRlbGl2ZXJ5LjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgVGVtcGxhdGUgV2l0aGRy YXdhbCBNZXNzYWdlIE1VU1QgTk9UIGNvbnRhaW4gbmV3IFRlbXBsYXRlIG9yPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIFRlbXBsYXRlIFdpdGhkcmF3YWwgTWVz c2FnZSBNVVNUIE5PVCBjb250YWluIG5ldyBUZW1wbGF0ZSBvcjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgT3B0aW9ucyBU ZW1wbGF0ZSBSZWNvcmRzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE9w dGlvbnMgVGVtcGxhdGUgUmVjb3Jkcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgSWYgdGhlIG1lYXN1cmVtZW50IHBhcmFtZXRlcnMgY2hhbmdlIHN1 Y2ggdGhhdCBhIG5ldyBUZW1wbGF0ZSBpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIElmIHRoZSBtZWFzdXJlbWVudCBwYXJhbWV0ZXJzIGNoYW5nZSBzdWNoIHRoYXQg YSBuZXcgVGVtcGxhdGUgaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA1NSI+PC9hPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIHJlcXVpcmVkLCB0aGUgVGVtcGxhdGUgTVVTVCBiZSB3 aXRoZHJhd24gKHVzaW5nIGEgVGVtcGxhdGUgV2l0aGRyYXc8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgcmVxdWlyZWQsIHRoZSBUZW1wbGF0ZSBNVVNUIGJlIHdpdGhk cmF3biAodXNpbmcgYSBUZW1wbGF0ZSBXaXRoZHJhdzxzcGFuIGNsYXNzPSJpbnNlcnQiPmFs PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgTWVzc2FnZSBhbmQgYSBuZXcgVGVtcGxhdGUgZGVmaW5pdGlvbikg b3IgYW4gdW51c2VkIFRlbXBsYXRlIElEIE1VU1Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBNZXNzYWdlIGFuZCBhIG5ldyBUZW1wbGF0ZSBkZWZpbml0aW9uKSBvciBh biB1bnVzZWQgVGVtcGxhdGUgSUQgTVVTVDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDU2Ij48 L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgYmUgdXNlZC4gIEV4YW1wbGVzIG9mIHRo ZSBtZWFzdXJlbWVudCBjaGFuZ2VzIGFyZTogYSBuZXcgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ c2FtcGxpbmc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGJl IHVzZWQuICBFeGFtcGxlcyBvZiB0aGUgbWVhc3VyZW1lbnQgY2hhbmdlcyBhcmU6IGEgbmV3 IEZsb3c8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgcmF0ZSwgYSBuZXc8L3NwYW4+ IEZsb3cgZXhwaXJhdGlvbiBwcm9jZXNzLCBhIG5ldyBmaWx0ZXJpbmcgZGVmaW5pdGlvbiwg ZXRjLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBleHBpcmF0aW9uIHBy b2Nlc3MsIGEgbmV3IGZpbHRlcmluZyBkZWZpbml0aW9uLCBldGMuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFdoZW4gdGhlIFNDVFAgYXNzb2NpYXRp b24gc2h1dHMgZG93biBvciB0aGUgRXhwb3J0aW5nIFByb2Nlc3M8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBXaGVuIHRoZSBTQ1RQIGFzc29jaWF0aW9uIHNodXRzIGRv d24gb3IgdGhlIEV4cG9ydGluZyBQcm9jZXNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZXN0YXJ0cywgYWxsIFRlbXBs YXRlIGFzc2lnbm1lbnRzIGFyZSBsb3N0IGFuZCBUZW1wbGF0ZSBJRHMgTVVTVCBiZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlc3RhcnRzLCBhbGwgVGVtcGxhdGUg YXNzaWdubWVudHMgYXJlIGxvc3QgYW5kIFRlbXBsYXRlIElEcyBNVVNUIGJlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBy ZWFzc2lnbmVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlYXNzaWdu ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIElmIHRo ZSBNZXRlcmluZyBQcm9jZXNzIHJlc3RhcnRzLCB0aGUgRXhwb3J0aW5nIFByb2Nlc3MgTVVT VCBlaXRoZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJZiB0aGUgTWV0 ZXJpbmcgUHJvY2VzcyByZXN0YXJ0cywgdGhlIEV4cG9ydGluZyBQcm9jZXNzIE1VU1QgZWl0 aGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICByZXVzZSB0aGUgcHJldmlvdXNseSBhc3NpZ25lZCBUZW1wbGF0ZSBJRCBm b3IgZWFjaCBUZW1wbGF0ZSwgb3IgaXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICByZXVzZSB0aGUgcHJldmlvdXNseSBhc3NpZ25lZCBUZW1wbGF0ZSBJRCBmb3IgZWFj aCBUZW1wbGF0ZSwgb3IgaXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE1VU1Qgd2l0aGRyYXcgdGhlIHByZXZpb3VzbHkg aXNzdWVkIFRlbXBsYXRlIElEcyBieSBzZW5kaW5nIFRlbXBsYXRlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgTVVTVCB3aXRoZHJhdyB0aGUgcHJldmlvdXNseSBpc3N1 ZWQgVGVtcGxhdGUgSURzIGJ5IHNlbmRpbmcgVGVtcGxhdGU8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJk aWZmMDA1NyI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFdpdGhkcmF3IE1lc3Nh Z2UocykgYmVmb3JlIHJldXNpbmcgdGhlbS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgV2l0aGRyYXc8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hPC9zcGFuPiBNZXNzYWdl KHMpIGJlZm9yZSByZXVzaW5nIHRoZW0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIEEgVGVtcGxhdGUgV2l0aGRyYXdhbCBNZXNzYWdlIHRvIHdpdGhk cmF3IGFsbCBUZW1wbGF0ZXMgZm9yIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIEEgVGVtcGxhdGUgV2l0aGRyYXdhbCBNZXNzYWdlIHRvIHdpdGhkcmF3IGFsbCBU ZW1wbGF0ZXMgZm9yIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgT2JzZXJ2YXRpb24gRG9tYWluIElEIHNwZWNpZmll ZCBpbiB0aGUgSVBGSVggTWVzc2FnZSBIZWFkZXIgTUFZIGJlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgT2JzZXJ2YXRpb24gRG9tYWluIElEIHNwZWNpZmllZCBpbiB0 aGUgSVBGSVggTWVzc2FnZSBIZWFkZXIgTUFZIGJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB1c2VkLiAgSXRzIGZvcm1h dCBpcyBzaG93biBpbiBGaWd1cmUgVS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICB1c2VkLiAgSXRzIGZvcm1hdCBpcyBzaG93biBpbiBGaWd1cmUgVS48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIDAgICAgICAgICAgICAgICAg ICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAg ICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHwgICAgICAgICAgICAgU2V0IElEID0gMiAgICAgICAgfCAgICAgICAgICBM ZW5ndGggPSA4ICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgfCAgICAgICAgICAgICBTZXQgSUQgPSAyICAgICAgICB8ICAgICAgICAgIExlbmd0aCA9 IDggICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyIGJnY29sb3I9Imdy YXkiPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWwxNSI+PHNtYWxsPnNraXBwaW5nIHRv IGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDM0LCBsaW5lIDM0PC9lbT48L2E+PC90aD48 dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjE1Ij48c21hbGw+c2tpcHBpbmcgdG8gY2hh bmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMzUsIGxpbmUgMzQ8L2VtPjwvYT48L3RoPjx0ZD48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgfCAgICAgICAgIFRlbXBsYXRlIElEID0gMyAgICAg ICB8ICAgICAgICBGaWVsZCBDb3VudCA9IDAgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICB8ICAgICAgICAgVGVtcGxhdGUgSUQgPSAzICAgICAgIHwgICAg ICAgIEZpZWxkIENvdW50ID0gMCAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBGaWd1cmUgVjogQWxsIE9wdGlvbnMg VGVtcGxhdGVzIFdpdGhkcmF3YWwgTWVzc2FnZSBGb3JtYXQ8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBGaWd1cmUgVjogQWxsIE9wdGlvbnMgVGVtcGxhdGVzIFdpdGhk cmF3YWwgTWVzc2FnZSBGb3JtYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgV2hlbiB0aGUgU0NUUCBhc3NvY2lhdGlvbiByZXN0YXJ0cywgdGhlIEV4 cG9ydGluZyBQcm9jZXNzIE1VU1QgcmVzZW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgV2hlbiB0aGUgU0NUUCBhc3NvY2lhdGlvbiByZXN0YXJ0cywgdGhlIEV4cG9y dGluZyBQcm9jZXNzIE1VU1QgcmVzZW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbGwgdGhlIFRlbXBsYXRlIFJlY29y ZHMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYWxsIHRoZSBUZW1wbGF0 ZSBSZWNvcmRzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij45 LiAgVGhlIENvbGxlY3RpbmcgUHJvY2VzcydzIFNpZGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij45LiAgVGhlIENvbGxlY3RpbmcgUHJvY2VzcydzIFNpZGU8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDU4 Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJl cyB0aGUgQ29sbGVjdGluZyBQcm9jZXNzIHdoZW4gdXNpbmcgU0NUUCBhbmQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUg Q29sbGVjdGluZyBQcm9jZXNzIHdoZW4gdXNpbmcgU0NUUCBhbmQgPHNwYW4gY2xhc3M9Imlu c2VydCI+UFItPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5QUi1TQ1RQ PC9zcGFuPiBhcyB0aGUgdHJhbnNwb3J0IHByb3RvY29sLiAgQW55IG5lY2Vzc2FyeSBjaGFu Z2VzIHRvIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4gICBTQ1RQPC9zcGFuPiBhcyB0aGUgdHJhbnNwb3J0IHByb3RvY29sLiAg QW55IG5lY2Vzc2FyeSBjaGFuZ2VzIHRvIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29sbGVjdGluZyBQcm9jZXNz IHNwZWNpZmljYWxseSByZWxhdGVkIHRvIFRDUCBvciBVRFAgdHJhbnNwb3J0PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29sbGVjdGluZyBQcm9jZXNzIHNwZWNpZmlj YWxseSByZWxhdGVkIHRvIFRDUCBvciBVRFAgdHJhbnNwb3J0PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwcm90b2NvbHMg YXJlIHNwZWNpZmllZCBpbiBTZWN0aW9uIDEwLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIHByb3RvY29scyBhcmUgc3BlY2lmaWVkIGluIFNlY3Rpb24gMTAuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBDb2xsZWN0aW5n IFByb2Nlc3MgU0hPVUxEIGxpc3RlbiBmb3IgYSBuZXcgYXNzb2NpYXRpb24gcmVxdWVzdDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBDb2xsZWN0aW5nIFByb2Nl c3MgU0hPVUxEIGxpc3RlbiBmb3IgYSBuZXcgYXNzb2NpYXRpb24gcmVxdWVzdDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ZnJvbSB0aGUgRXhwb3J0aW5nIFByb2Nlc3MuICBUaGUgRXhwb3J0aW5nIFByb2Nlc3Mgd2ls bCByZXF1ZXN0IGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmcm9tIHRo ZSBFeHBvcnRpbmcgUHJvY2Vzcy4gIFRoZSBFeHBvcnRpbmcgUHJvY2VzcyB3aWxsIHJlcXVl c3QgYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgbnVtYmVyIG9mIHN0cmVhbXMgdG8gdXNlIGZvciBleHBvcnQuICBBbiBF eHBvcnRpbmcgUHJvY2VzcyBNQVk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBudW1iZXIgb2Ygc3RyZWFtcyB0byB1c2UgZm9yIGV4cG9ydC4gIEFuIEV4cG9ydGluZyBQ cm9jZXNzIE1BWTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgcmVxdWVzdCBhbmQgc3VwcG9ydCBtb3JlIHRoYW4gb25lIHN0 cmVhbSBwZXIgU0NUUCBhc3NvY2lhdGlvbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICByZXF1ZXN0IGFuZCBzdXBwb3J0IG1vcmUgdGhhbiBvbmUgc3RyZWFtIHBlciBT Q1RQIGFzc29jaWF0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBJZiB0aGUgQ29sbGVjdGluZyBQcm9jZXNzIHJlY2VpdmVzIGEgbWFsZm9ybWVk IElQRklYIE1lc3NhZ2UsIGl0IE1VU1Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBJZiB0aGUgQ29sbGVjdGluZyBQcm9jZXNzIHJlY2VpdmVzIGEgbWFsZm9ybWVkIElQ RklYIE1lc3NhZ2UsIGl0IE1VU1Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlc2V0IHRoZSBTQ1RQIGFzc29jaWF0aW9u LCBkaXNjYXJkIHRoZSBJUEZJWCBNZXNzYWdlLCBhbmQgU0hPVUxEIGxvZzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlc2V0IHRoZSBTQ1RQIGFzc29jaWF0aW9uLCBk aXNjYXJkIHRoZSBJUEZJWCBNZXNzYWdlLCBhbmQgU0hPVUxEIGxvZzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIGVy cm9yLiAgTm90ZSB0aGF0IG5vbi16ZXJvIFNldCBwYWRkaW5nIGRvZXMgbm90IGNvbnN0aXR1 dGUgYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBlcnJvci4gIE5v dGUgdGhhdCBub24temVybyBTZXQgcGFkZGluZyBkb2VzIG5vdCBjb25zdGl0dXRlIGE8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIG1hbGZvcm1lZCBJUEZJWCBNZXNzYWdlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIG1hbGZvcm1lZCBJUEZJWCBNZXNzYWdlLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNTkiPjwvYT48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUZW1wbGF0ZSBTZXRzIGFuZCBPcHRpb24gVGVtcGxh dGUgU2V0cyBhcmUgb25seSBzZW50IG9uY2UuICBUaGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgVGVtcGxhdGUgU2V0cyBhbmQgT3B0aW9uPHNwYW4gY2xhc3M9Imlu c2VydCI+czwvc3Bhbj4gVGVtcGxhdGUgU2V0cyBhcmUgb25seSBzZW50IG9uY2UuICBUaGU8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIENvbGxlY3RpbmcgUHJvY2VzcyBNVVNUIHN0b3JlIHRoZSBUZW1wbGF0ZSBSZWNv cmQgaW5mb3JtYXRpb24gZm9yIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIENvbGxlY3RpbmcgUHJvY2VzcyBNVVNUIHN0b3JlIHRoZSBUZW1wbGF0ZSBSZWNvcmQg aW5mb3JtYXRpb24gZm9yIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZHVyYXRpb24gb2YgdGhlIGFzc29jaWF0aW9u IHNvIHRoYXQgaXQgY2FuIGludGVycHJldCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBkdXJhdGlvbiBvZiB0aGUgYXNzb2NpYXRpb24gc28gdGhhdCBpdCBjYW4g aW50ZXJwcmV0IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29ycmVzcG9uZGluZyBEYXRhIFJlY29yZHMgdGhhdCBh cmUgcmVjZWl2ZWQgaW4gc3Vic2VxdWVudCBEYXRhIFNldHMuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgY29ycmVzcG9uZGluZyBEYXRhIFJlY29yZHMgdGhhdCBhcmUg cmVjZWl2ZWQgaW4gc3Vic2VxdWVudCBEYXRhIFNldHMuPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRlbXBsYXRlIElEcyBhcmUgdW5pcXVlIHBlciBT Q1RQIGFzc29jaWF0aW9uIGFuZCBwZXIgT2JzZXJ2YXRpb248L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBUZW1wbGF0ZSBJRHMgYXJlIHVuaXF1ZSBwZXIgU0NUUCBhc3Nv Y2lhdGlvbiBhbmQgcGVyIE9ic2VydmF0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEb21haW4uICBJZiB0aGUgQ29s bGVjdGluZyBQcm9jZXNzIHJlY2VpdmVzIGEgVGVtcGxhdGUgdGhhdCBoYXM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEb21haW4uICBJZiB0aGUgQ29sbGVjdGluZyBQ cm9jZXNzIHJlY2VpdmVzIGEgVGVtcGxhdGUgdGhhdCBoYXM8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFscmVhZHkgYmVl biByZWNlaXZlZCBidXQgdGhhdCBoYXMgbm90IHByZXZpb3VzbHkgYmVlbiB3aXRoZHJhd248 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbHJlYWR5IGJlZW4gcmVjZWl2 ZWQgYnV0IHRoYXQgaGFzIG5vdCBwcmV2aW91c2x5IGJlZW4gd2l0aGRyYXduPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAo aS5lLiwgYSBUZW1wbGF0ZSBSZWNvcmQgZnJvbSB0aGUgc2FtZSBFeHBvcnRlciBPYnNlcnZh dGlvbiBEb21haW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAoaS5lLiwg YSBUZW1wbGF0ZSBSZWNvcmQgZnJvbSB0aGUgc2FtZSBFeHBvcnRlciBPYnNlcnZhdGlvbiBE b21haW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHdpdGggdGhlIHNhbWUgVGVtcGxhdGUgSUQgcmVjZWl2ZWQgb24gdGhl IFNDVFAgYXNzb2NpYXRpb24pLCB0aGVuIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIHdpdGggdGhlIHNhbWUgVGVtcGxhdGUgSUQgcmVjZWl2ZWQgb24gdGhlIFND VFAgYXNzb2NpYXRpb24pLCB0aGVuIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29sbGVjdGluZyBQcm9jZXNzIE1V U1Qgc2h1dCBkb3duIHRoZSBhc3NvY2lhdGlvbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBDb2xsZWN0aW5nIFByb2Nlc3MgTVVTVCBzaHV0IGRvd24gdGhlIGFzc29j aWF0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+DQogICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRoPjxh IG5hbWU9InBhcnQtbDE2Ij48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48 ZW0+IHBhZ2UgMzYsIGxpbmUgNTwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1l PSJwYXJ0LXIxNiI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBw YWdlIDM3LCBsaW5lIDU8L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgQ29sbGVjdG9yIHJlc291cmNlIGV4aGF1c3Rpb24gd2hlcmUgaXQgY2Fubm90IHByb2Nl c3MgdGhlIElQRklYPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29sbGVj dG9yIHJlc291cmNlIGV4aGF1c3Rpb24gd2hlcmUgaXQgY2Fubm90IHByb2Nlc3MgdGhlIElQ RklYPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBNZXNzYWdlcyBhdCB0aGVpciBhcnJpdmFsIHJhdGUsIG91dC1vZi1vcmRl ciBwYWNrZXQgcmVjZXB0aW9uLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IE1lc3NhZ2VzIGF0IHRoZWlyIGFycml2YWwgcmF0ZSwgb3V0LW9mLW9yZGVyIHBhY2tldCBy ZWNlcHRpb24sPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBkdXBsaWNhdGUgcGFja2V0IHJlY2VwdGlvbiwgb3IgYW4gYXR0 YWNrZXIgaW5qZWN0aW5nIGZhbHNlIG1lc3NhZ2VzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIGR1cGxpY2F0ZSBwYWNrZXQgcmVjZXB0aW9uLCBvciBhbiBhdHRhY2tl ciBpbmplY3RpbmcgZmFsc2UgbWVzc2FnZXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIElmIGEgQ29sbGVjdGluZyBQcm9jZXNzIHJlY2VpdmVzIGEg VGVtcGxhdGUgV2l0aGRyYXdhbCBNZXNzYWdlLCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBJZiBhIENvbGxlY3RpbmcgUHJvY2VzcyByZWNlaXZlcyBhIFRlbXBs YXRlIFdpdGhkcmF3YWwgTWVzc2FnZSwgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb2xsZWN0aW5nIFByb2Nlc3Mg TVVTVCBkZWxldGUgdGhlIGNvcnJlc3BvbmRpbmcgVGVtcGxhdGUgUmVjb3JkczwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvbGxlY3RpbmcgUHJvY2VzcyBNVVNUIGRl bGV0ZSB0aGUgY29ycmVzcG9uZGluZyBUZW1wbGF0ZSBSZWNvcmRzPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhc3NvY2lh dGVkIHdpdGggdGhlIHNwZWNpZmljIFNDVFAgYXNzb2NpYXRpb24gYW5kIHNwZWNpZmljPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBz cGVjaWZpYyBTQ1RQIGFzc29jaWF0aW9uIGFuZCBzcGVjaWZpYzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgT2JzZXJ2YXRp b24gRG9tYWluLCBhbmQgc3RvcCBkZWNvZGluZyBJUEZJWCBNZXNzYWdlcyB0aGF0IHVzZSB0 aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBPYnNlcnZhdGlvbiBEb21h aW4sIGFuZCBzdG9wIGRlY29kaW5nIElQRklYIE1lc3NhZ2VzIHRoYXQgdXNlIHRoZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgd2l0aGRyYXduIFRlbXBsYXRlcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICB3aXRoZHJhd24gVGVtcGxhdGVzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNjAiPjwvYT48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICBJZiB0aGUgQ29sbGVjdGluZyBQcm9jZXNzIHJlY2VpdmVzIGEgVGVt cGxhdGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+V2l0aGRyYXcgbWVzc2FnZTwvc3Bhbj4gZm9y IGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgSWYgdGhlIENvbGxlY3Rp bmcgUHJvY2VzcyByZWNlaXZlcyBhIFRlbXBsYXRlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPldp dGhkcmF3YWwgTWVzc2FnZTwvc3Bhbj4gZm9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRlbXBsYXRlIFJlY29yZCBp dCBoYXMgbm90IHJlY2VpdmVkIGJlZm9yZSBvbiB0aGlzIFNDVFAgYXNzb2NpYXRpb24sPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGEgVGVtcGxhdGUgUmVjb3JkIGl0 IGhhcyBub3QgcmVjZWl2ZWQgYmVmb3JlIG9uIHRoaXMgU0NUUDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBpdCBNVVNU IHJlc2V0IHRoZSBTQ1RQIGFzc29jaWF0aW9uLCBkaXNjYXJkIHRoZSBJUEZJWCBNZXNzYWdl LCBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgYXNzb2NpYXRpb24s IGl0IE1VU1QgcmVzZXQgdGhlIFNDVFAgYXNzb2NpYXRpb24sIGRpc2NhcmQgdGhlIElQRklY PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIFNIT1VMRCBsb2cgdGhlIGVycm9yIGFzIGl0IGRvZXMgZm9yIG1hbGZvcm1l ZCBJUEZJWCBNZXNzYWdlcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg TWVzc2FnZSwgYW5kIFNIT1VMRCBsb2cgdGhlIGVycm9yIGFzIGl0IGRvZXMgZm9yIG1hbGZv cm1lZCBJUEZJWDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg TWVzc2FnZXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IEEgQ29sbGVjdGluZyBQcm9jZXNzIHRoYXQgcmVjZWl2ZXMgSVBGSVggTWVzc2FnZXMgZnJv bSBzZXZlcmFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQSBDb2xsZWN0 aW5nIFByb2Nlc3MgdGhhdCByZWNlaXZlcyBJUEZJWCBNZXNzYWdlcyBmcm9tIHNldmVyYWw8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIE9ic2VydmF0aW9uIERvbWFpbnMgb24gdGhlIHNhbWUgVHJhbnNwb3J0IFNlc3Np b24gTVVTVCBiZSBhd2FyZSB0aGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgT2JzZXJ2YXRpb24gRG9tYWlucyBvbiB0aGUgc2FtZSBUcmFuc3BvcnQgU2Vzc2lvbiBN VVNUIGJlIGF3YXJlIHRoYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSB1bmlxdWVuZXNzIG9mIHRoZSBUZW1wbGF0 ZSBJRCBpcyBub3QgZ3VhcmFudGVlZCBhY3Jvc3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICB0aGUgdW5pcXVlbmVzcyBvZiB0aGUgVGVtcGxhdGUgSUQgaXMgbm90IGd1 YXJhbnRlZWQgYWNyb3NzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBPYnNlcnZhdGlvbiBEb21haW5zLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE9ic2VydmF0aW9uIERvbWFpbnMuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBDb2xsZWN0b3IgTVVT VCBzdXBwb3J0IHRoZSB1c2Ugb2YgVGVtcGxhdGVzIGNvbnRhaW5pbmcgbXVsdGlwbGU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgQ29sbGVjdG9yIE1VU1Qgc3Vw cG9ydCB0aGUgdXNlIG9mIFRlbXBsYXRlcyBjb250YWluaW5nIG11bHRpcGxlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBv Y2N1cnJlbmNlcyBvZiB0aGUgc2ltaWxhciBJbmZvcm1hdGlvbiBFbGVtZW50cy48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvY2N1cnJlbmNlcyBvZiB0aGUgc2ltaWxh ciBJbmZvcm1hdGlvbiBFbGVtZW50cy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+MTAuICBUcmFuc3BvcnQgUHJvdG9jb2w8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4xMC4gIFRyYW5zcG9ydCBQcm90b2NvbDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHIg Ymdjb2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDE3Ij48c21hbGw+ c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgNDAsIGxpbmUgNDY8L2Vt PjwvYT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yMTciPjxzbWFsbD5za2lw cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA0MSwgbGluZSA0NjwvZW0+PC9h PjwvdGg+PHRkPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb2xsZWN0aW5nIFByb2Nlc3Nl cyB0byB1c2UgYSBkaWZmZXJlbnQgVURQIHBvcnQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgQ29sbGVjdGluZyBQcm9jZXNzZXMgdG8gdXNlIGEgZGlmZmVyZW50IFVE UCBwb3J0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xMC4z LjUuICBFeHBvcnRpbmcgUHJvY2VzczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjEwLjMuNS4gIEV4cG9ydGluZyBQcm9jZXNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBFeHBvcnRpbmcgUHJvY2VzcyBNQVkgZHVwbGljYXRl IHRoZSBJUEZJWCBNZXNzYWdlIHRvIHRoZSBzZXZlcmFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgVGhlIEV4cG9ydGluZyBQcm9jZXNzIE1BWSBkdXBsaWNhdGUgdGhl IElQRklYIE1lc3NhZ2UgdG8gdGhlIHNldmVyYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvbGxlY3RpbmcgUHJvY2Vz c2VzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvbGxlY3RpbmcgUHJv Y2Vzc2VzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xMC4z LjYuICBUZW1wbGF0ZSBNYW5hZ2VtZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+MTAuMy42LiAgVGVtcGxhdGUgTWFuYWdlbWVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBXaGVuIElQRklYIHVzZXMgVURQIGFzIHRoZSB0cmFu c3BvcnQgcHJvdG9jb2wsIFRlbXBsYXRlIFNldHMgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgV2hlbiBJUEZJWCB1c2VzIFVEUCBhcyB0aGUgdHJhbnNwb3J0IHBy b3RvY29sLCBUZW1wbGF0ZSBTZXRzIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDYxIj48 L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgT3B0aW9uIFRlbXBsYXRlIFNldHMgTVVT VCBiZSByZS1zZW50IGF0IHJlZ3VsYXIgaW50ZXJ2YWxzLiAgVGhlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgIE9wdGlvbjxzcGFuIGNsYXNzPSJpbnNlcnQiPnM8L3Nw YW4+IFRlbXBsYXRlIFNldHMgTVVTVCBiZSByZS1zZW50IGF0IHJlZ3VsYXIgaW50ZXJ2YWxz LiAgVGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBmcmVxdWVuY3kgb2YgdGhlIChPcHRpb25zKSBUZW1wbGF0ZSB0cmFu c21pc3Npb24gTVVTVCBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGZy ZXF1ZW5jeSBvZiB0aGUgKE9wdGlvbnMpIFRlbXBsYXRlIHRyYW5zbWlzc2lvbiBNVVNUIGJl PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNjIiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICBjb25maWd1cmFibGUuICBUaGUgZGVmYXVsdCB2YWx1ZSBmb3IgdGhlIGZyZXF1ZW5j eSBvZiB0aGUgKE9wdGlvbnMpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IGNvbmZpZ3VyYWJsZS4gVGhlIGRlZmF1bHQgdmFsdWUgZm9yIHRoZSBmcmVxdWVuY3kgb2Yg dGhlIChPcHRpb25zKTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUZW1wbGF0ZSB0cmFuc21pc3Npb24gaXMgMTAgbWlu dXRlcy4gIFRoZSBFeHBvcnRpbmcgUHJvY2VzcyBTSE9VTEQ8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgVGVtcGxhdGUgdHJhbnNtaXNzaW9uIGlzIDEwIG1pbnV0ZXMu ICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5Ob3RlIHRoYXQgdGhlIGZyZXF1ZW5jeSBvZiB0aGU8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIHRyYW5zbWl0IHRoZSBUZW1wbGF0ZSBTZXQgYW5kIE9wdGlvbnMg VGVtcGxhdGUgU2V0IGluIGFkdmFuY2Ugb2YgYW55PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIChPcHRpb25zKSBUZW1wbGF0ZSB0 cmFuc21pc3Npb24gY2FuIGJlIG1vbml0b3JlZCBhbmQgY29uZmlndXJlZCB3aXRoPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICBEYXRhIFNldHMgdGhhdCB1c2UgdGhhdCAoT3B0aW9ucykgVGVtcGxhdGUg SUQgdG8gaGVscCBlbnN1cmUgdGhhdCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgdGhlIHRlbXBsYXRlUmVmcmVzaFRpbWVv dXQgYW5kIG9wdGlvbnNUZW1wbGF0ZVJlZnJlc2hUaW1lb3V0IGluPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICBDb2xsZWN0b3IgaGFzIHRoZSBUZW1wbGF0ZSBSZWNvcmQgYmVmb3JlIHJlY2VpdmluZyB0 aGUgZmlyc3QgRGF0YTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICBbSVBGSVgtQ09ORl0uPC9zcGFuPiBUaGUgRXhwb3J0aW5nIFBy b2Nlc3MgU0hPVUxEIHRyYW5zbWl0IHRoZSBUZW1wbGF0ZSBTZXQ8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgUmVjb3Jk LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBhbmQgT3B0aW9ucyBUZW1w bGF0ZSBTZXQgaW4gYWR2YW5jZSBvZiBhbnkgRGF0YSBTZXRzIHRoYXQgdXNlIHRoYXQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIChPcHRpb25zKSBUZW1w bGF0ZSBJRCB0byBoZWxwIGVuc3VyZSB0aGF0IHRoZSBDb2xsZWN0b3IgaGFzIHRoZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGVtcGxhdGUgUmVjb3Jk IGJlZm9yZSByZWNlaXZpbmcgdGhlIGZpcnN0IERhdGEgUmVjb3JkLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbiB0aGUgZXZlbnQgb2YgY29uZmln dXJhdGlvbiBjaGFuZ2VzLCB0aGUgRXhwb3J0aW5nIFByb2Nlc3MgU0hPVUxEPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW4gdGhlIGV2ZW50IG9mIGNvbmZpZ3VyYXRp b24gY2hhbmdlcywgdGhlIEV4cG9ydGluZyBQcm9jZXNzIFNIT1VMRDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2VuZCBt dWx0aXBsZSBjb3BpZXMgb2YgdGhlIG5ldyBUZW1wbGF0ZSBkZWZpbml0aW9ucywgaW4gZGlm ZmVyZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc2VuZCBtdWx0aXBs ZSBjb3BpZXMgb2YgdGhlIG5ldyBUZW1wbGF0ZSBkZWZpbml0aW9ucywgaW4gZGlmZmVyZW50 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBJUEZJWCBNZXNzYWdlcywgYXQgYW4gYWNjZWxlcmF0ZWQgcmF0ZS4gIEluIHN1 Y2ggYSBjYXNlLCBpdCBTSE9VTEQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBJUEZJWCBNZXNzYWdlcywgYXQgYW4gYWNjZWxlcmF0ZWQgcmF0ZS4gIEluIHN1Y2ggYSBj YXNlLCBpdCBTSE9VTEQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRyYW5zbWl0IHRoZSBjaGFuZ2VkIFRlbXBsYXRlIFJl Y29yZChzKSBhbmQgT3B0aW9ucyBUZW1wbGF0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIHRyYW5zbWl0IHRoZSBjaGFuZ2VkIFRlbXBsYXRlIFJlY29yZChzKSBhbmQg T3B0aW9ucyBUZW1wbGF0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUmVjb3JkKHMpLCB3aXRob3V0IGFueSBkYXRhLCBp biBhZHZhbmNlIHRvIGhlbHAgZW5zdXJlIHRoYXQgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgUmVjb3JkKHMpLCB3aXRob3V0IGFueSBkYXRhLCBpbiBhZHZhbmNl IHRvIGhlbHAgZW5zdXJlIHRoYXQgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb2xsZWN0b3Igd2lsbCBoYXZlIHRo ZSBjb3JyZWN0IFRlbXBsYXRlIGluZm9ybWF0aW9uIGJlZm9yZSByZWNlaXZpbmc8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDb2xsZWN0b3Igd2lsbCBoYXZlIHRoZSBj b3JyZWN0IFRlbXBsYXRlIGluZm9ybWF0aW9uIGJlZm9yZSByZWNlaXZpbmc8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRo ZSBmaXJzdCBkYXRhLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBm aXJzdCBkYXRhLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQ+PGEgbmFtZT0iZGlmZjAwNjMiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBJ ZiB0aGUgT3B0aW9uIFRlbXBsYXRlIHNjb3BlIGlzIGRlZmluZWQgaW4gYW5vdGhlciBUZW1w bGF0ZSwgdGhlbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBJZiB0aGUg T3B0aW9uPHNwYW4gY2xhc3M9Imluc2VydCI+czwvc3Bhbj4gVGVtcGxhdGUgc2NvcGUgaXMg ZGVmaW5lZCBpbiBhbm90aGVyIFRlbXBsYXRlLCB0aGVuPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBib3RoIFRlbXBsYXRl cyBTSE9VTEQgYmUgc2VudCBpbiB0aGUgc2FtZSBJUEZJWCBNZXNzYWdlLiAgRm9yPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYm90aCBUZW1wbGF0ZXMgU0hPVUxEIGJl IHNlbnQgaW4gdGhlIHNhbWUgSVBGSVggTWVzc2FnZS4gIEZvcjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMDY0Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgZXhhbXBsZSwgaWYg YSBGbG93IEtleSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5PcHRpb248L3NwYW4+IFRlbXBsYXRl IChzZWUgU2VjdGlvbiA0LjQpIGlzIHNlbnQgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgZXhhbXBsZSwgaWYgYSBGbG93IEtleSA8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij5PcHRpb25zPC9zcGFuPiBUZW1wbGF0ZSAoc2VlIFNlY3Rpb24gNC40KSBpcyBzZW50IGlu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIGFuIDxzcGFuIGNsYXNzPSJkZWxldGUiPk9wdGlvbjwvc3Bhbj4gVGVtcGxh dGUsIHRoZW4gdGhlIGFzc29jaWF0ZWQgVGVtcGxhdGUgU0hPVUxEIGJlIHNlbnQgaW48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgYW4gPHNwYW4gY2xhc3M9Imluc2Vy dCI+T3B0aW9uczwvc3Bhbj4gVGVtcGxhdGUsIHRoZW4gdGhlIGFzc29jaWF0ZWQgVGVtcGxh dGUgU0hPVUxEIGJlIHNlbnQgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBzYW1lIElQRklYIE1lc3NhZ2UuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIHNhbWUgSVBGSVggTWVzc2Fn ZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRm9sbG93 aW5nIGEgY29uZmlndXJhdGlvbiBjaGFuZ2UgdGhhdCBjYW4gbW9kaWZ5IHRoZSBpbnRlcnBy ZXRhdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEZvbGxvd2luZyBh IGNvbmZpZ3VyYXRpb24gY2hhbmdlIHRoYXQgY2FuIG1vZGlmeSB0aGUgaW50ZXJwcmV0YXRp b248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIG9mIHRoZSBEYXRhIFJlY29yZHMgKGZvciBleGFtcGxlLCBhIHNhbXBsaW5n IHJhdGUgY2hhbmdlKSBhIG5ldzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IG9mIHRoZSBEYXRhIFJlY29yZHMgKGZvciBleGFtcGxlLCBhIHNhbXBsaW5nIHJhdGUgY2hh bmdlKSBhIG5ldzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgVGVtcGxhdGUgSUQgTVVTVCBiZSB1c2VkLCBhbmQgdGhlIG9s ZCBUZW1wbGF0ZSBJRCBNVVNUIE5PVCBiZSByZXVzZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBUZW1wbGF0ZSBJRCBNVVNUIGJlIHVzZWQsIGFuZCB0aGUgb2xkIFRl bXBsYXRlIElEIE1VU1QgTk9UIGJlIHJldXNlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdW50aWwgaXRzIGxpZmV0aW1l IChzZWUgU2VjdGlvbiAxMC4zLjcpIGhhcyBleHBpcmVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHVudGlsIGl0cyBsaWZldGltZSAoc2VlIFNlY3Rpb24gMTAuMy43 KSBoYXMgZXhwaXJlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDY1Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgSWYgVURQIGlzIHNlbGVjdGVkIGFzIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wsIHRoZSBU ZW1wbGF0ZSBXaXRoZHJhdzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBJ ZiBVRFAgaXMgc2VsZWN0ZWQgYXMgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCwgdGhlIFRlbXBs YXRlIFdpdGhkcmF3PHNwYW4gY2xhc3M9Imluc2VydCI+YWw8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBNZXNz YWdlcyBNVVNUIE5PVCBiZSB1c2VkLCBhcyB0aGlzIG1ldGhvZCBpcyBpbmVmZmljaWVudCBk dWUgdG8gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTWVzc2FnZXMg TVVTVCBOT1QgYmUgdXNlZCwgYXMgdGhpcyBtZXRob2QgaXMgaW5lZmZpY2llbnQgZHVlIHRv IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgdW5yZWxpYWJsZSBuYXR1cmUgb2YgVURQLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIHVucmVsaWFibGUgbmF0dXJlIG9mIFVEUC48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MTAuMy43LiAgQ29sbGVjdGluZyBQ cm9jZXNzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+MTAuMy43LiAgQ29sbGVj dGluZyBQcm9jZXNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFRoZSBDb2xsZWN0aW5nIFByb2Nlc3MgTVVTVCBhc3NvY2lhdGUgYSBsaWZldGltZSB3 aXRoIGVhY2ggVGVtcGxhdGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBU aGUgQ29sbGVjdGluZyBQcm9jZXNzIE1VU1QgYXNzb2NpYXRlIGEgbGlmZXRpbWUgd2l0aCBl YWNoIFRlbXBsYXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAob3IgYW5vdGhlciBkZWZpbml0aW9uIG9mIGFuIGlkZW50 aWZpZXIgY29uc2lkZXJlZCB1bmlxdWUgd2l0aGluIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIChvciBhbm90aGVyIGRlZmluaXRpb24gb2YgYW4gaWRlbnRpZmll ciBjb25zaWRlcmVkIHVuaXF1ZSB3aXRoaW4gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUcmFuc3BvcnQgU2Vzc2lv bikgcmVjZWl2ZWQgdmlhIFVEUC4gIFRlbXBsYXRlcyAoYW5kIHNpbWlsYXI8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUcmFuc3BvcnQgU2Vzc2lvbikgcmVjZWl2ZWQg dmlhIFVEUC4gIFRlbXBsYXRlcyAoYW5kIHNpbWlsYXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRlZmluaXRpb25zKSBu b3QgcmVmcmVzaGVkIGJ5IHRoZSBFeHBvcnRpbmcgUHJvY2VzcyB3aXRoaW4gdGhlPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVmaW5pdGlvbnMpIG5vdCByZWZyZXNo ZWQgYnkgdGhlIEV4cG9ydGluZyBQcm9jZXNzIHdpdGhpbiB0aGU8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGxpZmV0aW1l IGFyZSBleHBpcmVkIGF0IHRoZSBDb2xsZWN0aW5nIFByb2Nlc3MuICBJZiB0aGUgVGVtcGxh dGUgKG9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbGlmZXRpbWUgYXJl IGV4cGlyZWQgYXQgdGhlIENvbGxlY3RpbmcgUHJvY2Vzcy4gIElmIHRoZSBUZW1wbGF0ZSAo b3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIG90aGVyIGRlZmluaXRpb24pIGlzIG5vdCByZWZyZXNoZWQgYmVmb3JlIHRo YXQgbGlmZXRpbWUgaGFzIGV4cGlyZWQsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgb3RoZXIgZGVmaW5pdGlvbikgaXMgbm90IHJlZnJlc2hlZCBiZWZvcmUgdGhhdCBs aWZldGltZSBoYXMgZXhwaXJlZCw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBDb2xsZWN0aW5nIFByb2Nlc3MgTVVT VCBkaXNjYXJkIHRoYXQgZGVmaW5pdGlvbiBhbmQgYW55IGN1cnJlbnQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGUgQ29sbGVjdGluZyBQcm9jZXNzIE1VU1QgZGlz Y2FyZCB0aGF0IGRlZmluaXRpb24gYW5kIGFueSBjdXJyZW50PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbmQgZnV0dXJl IGFzc29jaWF0ZWQgRGF0YSBSZWNvcmRzLiAgSW4gd2hpY2ggY2FzZSwgYW4gYWxhcm0gTVVT VCBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCBmdXR1cmUgYXNz b2NpYXRlZCBEYXRhIFJlY29yZHMuICBJbiB3aGljaCBjYXNlLCBhbiBhbGFybSBNVVNUIGJl PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBsb2dnZWQuICBUaGUgQ29sbGVjdGluZyBQcm9jZXNzIE1VU1QgTk9UIGRlY29k ZSBhbnkgZnVydGhlciBEYXRhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg bG9nZ2VkLiAgVGhlIENvbGxlY3RpbmcgUHJvY2VzcyBNVVNUIE5PVCBkZWNvZGUgYW55IGZ1 cnRoZXIgRGF0YTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgUmVjb3JkcyB0aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGggdGhl IGV4cGlyZWQgVGVtcGxhdGUuICBJZiBhIFRlbXBsYXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgUmVjb3JkcyB0aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGggdGhlIGV4 cGlyZWQgVGVtcGxhdGUuICBJZiBhIFRlbXBsYXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpcyByZWZyZXNoZWQgd2l0 aCBhIFRlbXBsYXRlIFJlY29yZCB0aGF0IGRpZmZlcnMgZnJvbSB0aGUgcHJldmlvdXNseTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGlzIHJlZnJlc2hlZCB3aXRoIGEg VGVtcGxhdGUgUmVjb3JkIHRoYXQgZGlmZmVycyBmcm9tIHRoZSBwcmV2aW91c2x5PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICByZWNlaXZlZCBUZW1wbGF0ZSBSZWNvcmQsIHRoZSBDb2xsZWN0aW5nIFByb2Nlc3MgU0hP VUxEIGxvZyBhIHdhcm5pbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBy ZWNlaXZlZCBUZW1wbGF0ZSBSZWNvcmQsIHRoZSBDb2xsZWN0aW5nIFByb2Nlc3MgU0hPVUxE IGxvZyBhIHdhcm5pbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFuZCByZXBsYWNlIHRoZSBwcmV2aW91c2x5IHJlY2Vp dmVkIFRlbXBsYXRlIFJlY29yZCB3aXRoIHRoZSBuZXcgb25lLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCByZXBsYWNlIHRoZSBwcmV2aW91c2x5IHJlY2VpdmVk IFRlbXBsYXRlIFJlY29yZCB3aXRoIHRoZSBuZXcgb25lLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRp ZmYwMDY2Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVGhlIFRlbXBsYXRlIGxp ZmV0aW1lIGF0IHRoZSBDb2xsZWN0aW5nIFByb2Nlc3MgTVVTVCBiZSBhdCBsZWFzdCAzPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQi PiA8L3NwYW4+VGhlIFRlbXBsYXRlIGxpZmV0aW1lIGF0IHRoZSBDb2xsZWN0aW5nIFByb2Nl c3MgTVVTVCBiZSBhdCBsZWFzdCAzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aW1lcyBoaWdoZXIgdGhhbiB0aGUgVGVt cGxhdGUgcmVmcmVzaCB0aW1lb3V0IGNvbmZpZ3VyZWQgb24gdGhlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgdGltZXMgaGlnaGVyIHRoYW4gdGhlIFRlbXBsYXRlIHJl ZnJlc2ggdGltZW91dCBjb25maWd1cmVkIG9uIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRXhwb3J0aW5nIFByb2Nl c3MuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRXhwb3J0aW5nIFByb2Nl c3MuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRlbXBs YXRlIElEcyBhcmUgdW5pcXVlIHBlciBVRFAgc2Vzc2lvbiBhbmQgcGVyIE9ic2VydmF0aW9u IERvbWFpbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUZW1wbGF0ZSBJ RHMgYXJlIHVuaXF1ZSBwZXIgVURQIHNlc3Npb24gYW5kIHBlciBPYnNlcnZhdGlvbiBEb21h aW4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBBdCBhbnkgZ2l2ZW4gdGltZSwgdGhlIENvbGxlY3RpbmcgUHJvY2VzcyBT SE9VTEQgbWFpbnRhaW4gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg QXQgYW55IGdpdmVuIHRpbWUsIHRoZSBDb2xsZWN0aW5nIFByb2Nlc3MgU0hPVUxEIG1haW50 YWluIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgZm9sbG93aW5nIGZvciBhbGwgdGhlIGN1cnJlbnQgVGVtcGxhdGUg UmVjb3JkcyBhbmQgT3B0aW9ucyBUZW1wbGF0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGZvbGxvd2luZyBmb3IgYWxsIHRoZSBjdXJyZW50IFRlbXBsYXRlIFJlY29y ZHMgYW5kIE9wdGlvbnMgVGVtcGxhdGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFJlY29yZHM6ICZsdDtJUEZJWCBEZXZp Y2UsIEV4cG9ydGVyIHNvdXJjZSBVRFAgcG9ydCwgT2JzZXJ2YXRpb24gRG9tYWluPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUmVjb3JkczogJmx0O0lQRklYIERldmlj ZSwgRXhwb3J0ZXIgc291cmNlIFVEUCBwb3J0LCBPYnNlcnZhdGlvbiBEb21haW48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IElELCBUZW1wbGF0ZSBJRCwgVGVtcGxhdGUgRGVmaW5pdGlvbiwgTGFzdCBSZWNlaXZlZCZn dDsuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSUQsIFRlbXBsYXRlIElE LCBUZW1wbGF0ZSBEZWZpbml0aW9uLCBMYXN0IFJlY2VpdmVkJmd0Oy48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIENvbGxlY3RpbmcgUHJvY2Vz cyBTSE9VTEQgYWNjZXB0IERhdGEgUmVjb3JkcyB3aXRob3V0IHRoZTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBDb2xsZWN0aW5nIFByb2Nlc3MgU0hPVUxEIGFj Y2VwdCBEYXRhIFJlY29yZHMgd2l0aG91dCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyIGJnY29sb3I9 ImdyYXkiPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWwxOCI+PHNtYWxsPnNraXBwaW5n IHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDQ1LCBsaW5lIDI5PC9lbT48L2E+PC90 aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjE4Ij48c21hbGw+c2tpcHBpbmcgdG8g Y2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgNDcsIGxpbmUgMjk8L2VtPjwvYT48L3RoPjx0 ZD48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MTAuNC4zLiAgQ29sbGVjdGluZyBQcm9jZXNzPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+MTAuNC4zLiAgQ29sbGVjdGluZyBQcm9j ZXNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBD b2xsZWN0aW5nIFByb2Nlc3MgU0hPVUxEIGxpc3RlbiBmb3IgYSBuZXcgVENQIGNvbm5lY3Rp b24gZnJvbTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBDb2xsZWN0 aW5nIFByb2Nlc3MgU0hPVUxEIGxpc3RlbiBmb3IgYSBuZXcgVENQIGNvbm5lY3Rpb24gZnJv bTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgdGhlIEV4cG9ydGluZyBQcm9jZXNzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIHRoZSBFeHBvcnRpbmcgUHJvY2Vzcy48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSWYgdGhlIENvbGxlY3RpbmcgUHJvY2VzcyBy ZWNlaXZlcyBhIG1hbGZvcm1lZCBJUEZJWCBNZXNzYWdlLCBpdCBNVVNUPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYgdGhlIENvbGxlY3RpbmcgUHJvY2VzcyByZWNl aXZlcyBhIG1hbGZvcm1lZCBJUEZJWCBNZXNzYWdlLCBpdCBNVVNUPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZXNldCB0 aGUgVENQIGNvbm5lY3Rpb24sIGRpc2NhcmQgdGhlIElQRklYIE1lc3NhZ2UsIGFuZCBTSE9V TEQgbG9nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVzZXQgdGhlIFRD UCBjb25uZWN0aW9uLCBkaXNjYXJkIHRoZSBJUEZJWCBNZXNzYWdlLCBhbmQgU0hPVUxEIGxv ZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgdGhlIGVycm9yLiAgTm90ZSB0aGF0IG5vbi16ZXJvIFNldCBwYWRkaW5nIGRv ZXMgbm90IGNvbnN0aXR1dGUgYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IHRoZSBlcnJvci4gIE5vdGUgdGhhdCBub24temVybyBTZXQgcGFkZGluZyBkb2VzIG5vdCBj b25zdGl0dXRlIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIG1hbGZvcm1lZCBJUEZJWCBNZXNzYWdlLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1hbGZvcm1lZCBJUEZJWCBNZXNzYWdlLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlm ZjAwNjciPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUZW1wbGF0ZSBTZXRzIGFu ZCBPcHRpb24gVGVtcGxhdGUgU2V0cyBhcmUgb25seSBzZW50IG9uY2UuICBUaGU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGVtcGxhdGUgU2V0cyBhbmQgT3B0aW9u PHNwYW4gY2xhc3M9Imluc2VydCI+czwvc3Bhbj4gVGVtcGxhdGUgU2V0cyBhcmUgb25seSBz ZW50IG9uY2UuICBUaGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvbGxlY3RpbmcgUHJvY2VzcyBNVVNUIHN0b3JlIHRo ZSBUZW1wbGF0ZSBSZWNvcmQgaW5mb3JtYXRpb24gZm9yIHRoZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIENvbGxlY3RpbmcgUHJvY2VzcyBNVVNUIHN0b3JlIHRoZSBU ZW1wbGF0ZSBSZWNvcmQgaW5mb3JtYXRpb24gZm9yIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZHVyYXRpb24gb2Yg dGhlIGNvbm5lY3Rpb24gc28gdGhhdCBpdCBjYW4gaW50ZXJwcmV0IHRoZSBjb3JyZXNwb25k aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZHVyYXRpb24gb2YgdGhl IGNvbm5lY3Rpb24gc28gdGhhdCBpdCBjYW4gaW50ZXJwcmV0IHRoZSBjb3JyZXNwb25kaW5n PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBEYXRhIFJlY29yZHMgdGhhdCBhcmUgcmVjZWl2ZWQgaW4gc3Vic2VxdWVudCBE YXRhIFNldHMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRGF0YSBSZWNv cmRzIHRoYXQgYXJlIHJlY2VpdmVkIGluIHN1YnNlcXVlbnQgRGF0YSBTZXRzLjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUZW1wbGF0ZSBJRHMgYXJl IHVuaXF1ZSBwZXIgVENQIGNvbm5lY3Rpb24gYW5kIHBlciBPYnNlcnZhdGlvbjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRlbXBsYXRlIElEcyBhcmUgdW5pcXVlIHBl ciBUQ1AgY29ubmVjdGlvbiBhbmQgcGVyIE9ic2VydmF0aW9uPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEb21haW4uICBJ ZiB0aGUgQ29sbGVjdGluZyBQcm9jZXNzIHJlY2VpdmVzIGEgVGVtcGxhdGUgdGhhdCBoYXM8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEb21haW4uICBJZiB0aGUgQ29s bGVjdGluZyBQcm9jZXNzIHJlY2VpdmVzIGEgVGVtcGxhdGUgdGhhdCBoYXM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFs cmVhZHkgYmVlbiByZWNlaXZlZCBidXQgdGhhdCBoYXMgbm90IHByZXZpb3VzbHkgYmVlbiB3 aXRoZHJhd248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbHJlYWR5IGJl ZW4gcmVjZWl2ZWQgYnV0IHRoYXQgaGFzIG5vdCBwcmV2aW91c2x5IGJlZW4gd2l0aGRyYXdu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAoaS5lLiwgYSBUZW1wbGF0ZSBSZWNvcmQgZnJvbSB0aGUgc2FtZSBFeHBvcnRl ciBPYnNlcnZhdGlvbiBEb21haW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAoaS5lLiwgYSBUZW1wbGF0ZSBSZWNvcmQgZnJvbSB0aGUgc2FtZSBFeHBvcnRlciBPYnNl cnZhdGlvbiBEb21haW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdpdGggdGhlIHNhbWUgVGVtcGxhdGUgSUQgcmVjZWl2 ZWQgb24gdGhlIFRDUCBjb25uZWN0aW9uKSwgdGhlbiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICB3aXRoIHRoZSBzYW1lIFRlbXBsYXRlIElEIHJlY2VpdmVkIG9u IHRoZSBUQ1AgY29ubmVjdGlvbiksIHRoZW4gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb2xsZWN0aW5nIFByb2Nl c3MgTVVTVCBzaHV0IGRvd24gdGhlIGNvbm5lY3Rpb24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgQ29sbGVjdGluZyBQcm9jZXNzIE1VU1Qgc2h1dCBkb3duIHRoZSBj b25uZWN0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRo PjxhIG5hbWU9InBhcnQtbDE5Ij48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFs bD48ZW0+IHBhZ2UgNDcsIGxpbmUgMTA8L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PGEg bmFtZT0icGFydC1yMTkiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxl bT4gcGFnZSA0OSwgbGluZSAxMDwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBleHBvcnRlZCwgaXQgU0hPVUxEIGJlIHRyYW5zbWl0dGVkIHRvIHRoZSBDb2xs ZWN0aW5nIFByb2Nlc3MgdXNpbmcgYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGV4cG9ydGVkLCBpdCBTSE9VTEQgYmUgdHJhbnNtaXR0ZWQgdG8gdGhlIENvbGxlY3Rp bmcgUHJvY2VzcyB1c2luZyBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtZWFucyB0aGF0IHNlY3VyZXMgaXRzIGNvbnRl bnRzIGFnYWluc3QgZWF2ZXNkcm9wcGluZy4gIFN1aXRhYmxlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgbWVhbnMgdGhhdCBzZWN1cmVzIGl0cyBjb250ZW50cyBhZ2Fp bnN0IGVhdmVzZHJvcHBpbmcuICBTdWl0YWJsZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbWVjaGFuaXNtcyBpbmNsdWRl IHRoZSB1c2Ugb2YgZWl0aGVyIGEgZGlyZWN0IHBvaW50LXRvLXBvaW50PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWVjaGFuaXNtcyBpbmNsdWRlIHRoZSB1c2Ugb2Yg ZWl0aGVyIGEgZGlyZWN0IHBvaW50LXRvLXBvaW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb25uZWN0aW9uIG9yIHRo ZSB1c2Ugb2YgYW4gZW5jcnlwdGlvbiBtZWNoYW5pc20uICBJdCBpcyB0aGU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb25uZWN0aW9uIG9yIHRoZSB1c2Ugb2YgYW4g ZW5jcnlwdGlvbiBtZWNoYW5pc20uICBJdCBpcyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlc3BvbnNpYmlsaXR5 IG9mIHRoZSBDb2xsZWN0aW5nIFByb2Nlc3MgdG8gcHJvdmlkZSBhIHNhdGlzZmFjdG9yeTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlc3BvbnNpYmlsaXR5IG9mIHRo ZSBDb2xsZWN0aW5nIFByb2Nlc3MgdG8gcHJvdmlkZSBhIHNhdGlzZmFjdG9yeTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ZGVncmVlIG9mIHNlY3VyaXR5IGZvciB0aGlzIGNvbGxlY3RlZCBkYXRhLCBpbmNsdWRpbmcs IGlmIG5lY2Vzc2FyeSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZWdy ZWUgb2Ygc2VjdXJpdHkgZm9yIHRoaXMgY29sbGVjdGVkIGRhdGEsIGluY2x1ZGluZywgaWYg bmVjZXNzYXJ5LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgYW5vbnltaXphdGlvbiBvZiBhbnkgcmVwb3J0ZWQgZGF0YS48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbm9ueW1pemF0aW9uIG9mIGFu eSByZXBvcnRlZCBkYXRhLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4xMS4xLiAgQXBwbGljYWJpbGl0eSBvZiBUTFMgYW5kIERUTFM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4xMS4xLiAgQXBwbGljYWJpbGl0eSBvZiBUTFMgYW5kIERU TFM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDY4Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVHJhbnNwb3J0 IExheWVyIFNlY3VyaXR5IChUTFMpIFtSRkM8c3BhbiBjbGFzcz0iZGVsZXRlIj40Mzwvc3Bh bj40Nl0gYW5kIERhdGFncmFtIFRyYW5zcG9ydCBMYXllcjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykgW1JGQzxz cGFuIGNsYXNzPSJpbnNlcnQiPjUyPC9zcGFuPjQ2XSBhbmQgRGF0YWdyYW0gVHJhbnNwb3J0 IExheWVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBTZWN1cml0eSAoRFRMUykgW1JGQzQzNDddIHdlcmUgZGVzaWduZWQg dG8gcHJvdmlkZSB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTZWN1 cml0eSAoRFRMUykgW1JGQzQzNDddIHdlcmUgZGVzaWduZWQgdG8gcHJvdmlkZSB0aGU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGNvbmZpZGVudGlhbGl0eSwgaW50ZWdyaXR5LCBhbmQgYXV0aGVudGljYXRpb24gYXNz dXJhbmNlcyByZXF1aXJlZCBieTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGNvbmZpZGVudGlhbGl0eSwgaW50ZWdyaXR5LCBhbmQgYXV0aGVudGljYXRpb24gYXNzdXJh bmNlcyByZXF1aXJlZCBieTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIElQRklYIHByb3RvY29sLCB3aXRob3V0IHRo ZSBuZWVkIGZvciBwcmUtc2hhcmVkIGtleXMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgdGhlIElQRklYIHByb3RvY29sLCB3aXRob3V0IHRoZSBuZWVkIGZvciBwcmUt c2hhcmVkIGtleXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFdpdGggdGhlIG1hbmRhdG9yeSBTQ1RQIGFuZCBQUi1TQ1RQIHRyYW5zcG9ydCBwcm90 b2NvbHMgZm9yIElQRklYLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFdp dGggdGhlIG1hbmRhdG9yeSBTQ1RQIGFuZCBQUi1TQ1RQIHRyYW5zcG9ydCBwcm90b2NvbHMg Zm9yIElQRklYLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgRFRMUyBbUkZDNDM0N10gTVVTVCBiZSBpbXBsZW1lbnRlZC4g IElmIFVEUCBpcyBzZWxlY3RlZCBhcyB0aGUgSVBGSVg8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBEVExTIFtSRkM0MzQ3XSBNVVNUIGJlIGltcGxlbWVudGVkLiAgSWYg VURQIGlzIHNlbGVjdGVkIGFzIHRoZSBJUEZJWDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdHJhbnNwb3J0IHByb3RvY29s LCBEVExTIFtSRkM0MzQ3XSBNVVNUIGJlIGltcGxlbWVudGVkLiAgSWYgVENQIGlzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdHJhbnNwb3J0IHByb3RvY29sLCBEVExT IFtSRkM0MzQ3XSBNVVNUIGJlIGltcGxlbWVudGVkLiAgSWYgVENQIGlzPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEg bmFtZT0iZGlmZjAwNjkiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzZWxlY3Rl ZCBhcyB0aGUgSVBGSVggdHJhbnNwb3J0IHByb3RvY29sLCBUTFMgW1JGQzxzcGFuIGNsYXNz PSJkZWxldGUiPjQzPC9zcGFuPjQ2XSBNVVNUIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIHNlbGVjdGVkIGFzIHRoZSBJUEZJWCB0cmFuc3BvcnQgcHJvdG9jb2ws IFRMUyBbUkZDPHNwYW4gY2xhc3M9Imluc2VydCI+NTI8L3NwYW4+NDZdIE1VU1QgYmU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGltcGxlbWVudGVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGlt cGxlbWVudGVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQ+PGEgbmFtZT0iZGlmZjAwNzAiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBO b3RlIHRoYXQgRFRMUyBpcyBzZWxlY3RlZCBhcyB0aGUgc2VjdXJpdHkgbWVjaGFuaXNtIGZv ciBTQ1RQIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBOb3RlIHRo YXQgRFRMUyBpcyBzZWxlY3RlZCBhcyB0aGUgc2VjdXJpdHkgbWVjaGFuaXNtIGZvciBTQ1RQ IGFuZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5QUi08L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNs YXNzPSJkZWxldGUiPlBSLVNDVFAuPC9zcGFuPiAgVGhvdWdoIFRMUyBiaW5kaW5ncyB0byBT Q1RQIGFyZSBkZWZpbmVkIGluIFtSRkMzNDM2XSwgdGhleTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBTQ1RQLjwvc3Bhbj4gIFRo b3VnaCBUTFMgYmluZGluZ3MgdG8gU0NUUCBhcmUgZGVmaW5lZCBpbiBbUkZDMzQzNl0sIHRo ZXk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHJlcXVpcmUgYWxsIGNvbW11bmljYXRpb24gdG8gYmUgb3ZlciByZWxpYWJs ZSwgYmlkaXJlY3Rpb25hbCBzdHJlYW1zLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIHJlcXVpcmUgYWxsIGNvbW11bmljYXRpb24gdG8gYmUgb3ZlciByZWxpYWJsZSwg YmlkaXJlY3Rpb25hbCBzdHJlYW1zLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIHJlcXVpcmUgb25lIFRMUyBjb25u ZWN0aW9uIHBlciBzdHJlYW0uICBUaGlzIGFycmFuZ2VtZW50IGlzIG5vdDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCByZXF1aXJlIG9uZSBUTFMgY29ubmVjdGlv biBwZXIgc3RyZWFtLiAgVGhpcyBhcnJhbmdlbWVudCBpcyBub3Q8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbXBhdGli bGUgd2l0aCB0aGUgcmF0aW9uYWxlIGJlaGluZCB0aGUgY2hvaWNlIG9mIFNDVFAgYXMgYW4g SVBGSVg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb21wYXRpYmxlIHdp dGggdGhlIHJhdGlvbmFsZSBiZWhpbmQgdGhlIGNob2ljZSBvZiBTQ1RQIGFzIGFuIElQRklY PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICB0cmFuc3BvcnQgcHJvdG9jb2wuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgdHJhbnNwb3J0IHByb3RvY29sLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBOb3RlIHRoYXQgdXNpbmcgRFRMUyBbUkZDNDM0N10gaGFz IGEgdnVsbmVyYWJpbGl0eSwgaS5lLiwgYSB0cnVlIG1hbjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIE5vdGUgdGhhdCB1c2luZyBEVExTIFtSRkM0MzQ3XSBoYXMgYSB2 dWxuZXJhYmlsaXR5LCBpLmUuLCBhIHRydWUgbWFuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbiB0aGUgbWlkZGxlIG1h eSBhdHRlbXB0IHRvIHRha2UgZGF0YSBvdXQgb2YgYW4gYXNzb2NpYXRpb24gYW5kIGZvb2w8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbiB0aGUgbWlkZGxlIG1heSBh dHRlbXB0IHRvIHRha2UgZGF0YSBvdXQgb2YgYW4gYXNzb2NpYXRpb24gYW5kIGZvb2w8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIHRoZSBzZW5kZXIgaW50byB0aGlua2luZyB0aGF0IHRoZSBkYXRhIHdhcyBhY3R1YWxs eSByZWNlaXZlZCBieSB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0 aGUgc2VuZGVyIGludG8gdGhpbmtpbmcgdGhhdCB0aGUgZGF0YSB3YXMgYWN0dWFsbHkgcmVj ZWl2ZWQgYnkgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBwZWVyLiAgSW4gZ2VuZXJpYyBUTFMgZm9yIFNDVFAgKGFu ZC9vciBUQ1ApLCB0aGlzIGlzIG5vdCBwb3NzaWJsZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBwZWVyLiAgSW4gZ2VuZXJpYyBUTFMgZm9yIFNDVFAgKGFuZC9vciBU Q1ApLCB0aGlzIGlzIG5vdCBwb3NzaWJsZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgbWVhbnMgdGhhdCB0aGUg cmVtb3ZhbCBvZiBhIG1lc3NhZ2UgbWF5IGJlY29tZSBoaWRkZW4gZnJvbSB0aGU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIG1lYW5zIHRoYXQgdGhlIHJlbW92 YWwgb2YgYSBtZXNzYWdlIG1heSBiZWNvbWUgaGlkZGVuIGZyb20gdGhlPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzZW5k ZXIgb3IgcmVjZWl2ZXIuICBBbm90aGVyIHZ1bG5lcmFiaWxpdHkgb2YgdXNpbmcgUFItU0NU UCB3aXRoIERUTFM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzZW5kZXIg b3IgcmVjZWl2ZXIuICBBbm90aGVyIHZ1bG5lcmFiaWxpdHkgb2YgdXNpbmcgUFItU0NUUCB3 aXRoIERUTFM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGlzIHRoYXQgc29tZW9uZSBjb3VsZCBpbmplY3QgU0NUUCBjb250 cm9sIGluZm9ybWF0aW9uIHRvIHNodXQgZG93bjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGlzIHRoYXQgc29tZW9uZSBjb3VsZCBpbmplY3QgU0NUUCBjb250cm9sIGlu Zm9ybWF0aW9uIHRvIHNodXQgZG93bjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIFNDVFAgYXNzb2NpYXRpb24sIGVm ZmVjdGl2ZWx5IGdlbmVyYXRpbmcgYSBsb3NzIG9mIElQRklYIE1lc3NhZ2VzPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIFNDVFAgYXNzb2NpYXRpb24sIGVmZmVj dGl2ZWx5IGdlbmVyYXRpbmcgYSBsb3NzIG9mIElQRklYIE1lc3NhZ2VzPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEg bmFtZT0iZGlmZjAwNzEiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBpZiB0aG9z ZSBhcmUgYnVmZmVyZWQgb3V0c2lkZSBvZiB0aGUgU0NUUCBhc3NvY2lhdGlvbi4gIDxzcGFu IGNsYXNzPSJkZWxldGUiPkluIHRoZTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgaWYgdGhvc2UgYXJlIGJ1ZmZlcmVkIG91dHNpZGUgb2YgdGhlIFNDVFAg YXNzb2NpYXRpb24uICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UZWNobmlxdWVzPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBmdXR1cmUsIHRlY2huaXF1ZXM8L3NwYW4+ IHN1Y2ggYXMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+W2R0bHMtZm9yLXNjdHBdPC9zcGFuPiBj b3VsZCBiZSB1c2VkIHRvIG92ZXJjb21lPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIHN1Y2ggYXMgPHNwYW4gY2xhc3M9Imluc2VydCI+W1JGQzYwODNdPC9zcGFuPiBj b3VsZCBiZSB1c2VkIHRvIG92ZXJjb21lIHRoZXNlIHZ1bG5lcmFiaWxpdGllcy48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgdGhlc2UgdnVsbmVyYWJpbGl0aWVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgV2hl biB1c2luZyBEVExTIG92ZXIgU0NUUCwgdGhlIEV4cG9ydGluZyBQcm9jZXNzIE1VU1QgZW5z dXJlIHRoYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBXaGVuIHVzaW5n IERUTFMgb3ZlciBTQ1RQLCB0aGUgRXhwb3J0aW5nIFByb2Nlc3MgTVVTVCBlbnN1cmUgdGhh dDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgZWFjaCBJUEZJWCBNZXNzYWdlIGlzIHNlbnQgb3ZlciB0aGUgc2FtZSBTQ1RQ IHN0cmVhbSB0aGF0IHdvdWxkIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgZWFjaCBJUEZJWCBNZXNzYWdlIGlzIHNlbnQgb3ZlciB0aGUgc2FtZSBTQ1RQIHN0cmVh bSB0aGF0IHdvdWxkIGJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB1c2VkIHdoZW4gc2VuZGluZyB0aGUgc2FtZSBJUEZJ WCBNZXNzYWdlIGRpcmVjdGx5IG92ZXIgU0NUUC4gIE5vdGU8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICB1c2VkIHdoZW4gc2VuZGluZyB0aGUgc2FtZSBJUEZJWCBNZXNz YWdlIGRpcmVjdGx5IG92ZXIgU0NUUC4gIE5vdGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoYXQgRFRMUyBtYXkgc2Vu ZCBpdHMgb3duIGNvbnRyb2wgbWVzc2FnZXMgb24gc3RyZWFtIDAgd2l0aCBmdWxsPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhhdCBEVExTIG1heSBzZW5kIGl0cyBv d24gY29udHJvbCBtZXNzYWdlcyBvbiBzdHJlYW0gMCB3aXRoIGZ1bGw8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlbGlh YmlsaXR5OyBob3dldmVyLCB0aGlzIHdpbGwgbm90IGludGVyZmVyZSB3aXRoIHRoZSBwcm9j ZXNzaW5nIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVsaWFiaWxp dHk7IGhvd2V2ZXIsIHRoaXMgd2lsbCBub3QgaW50ZXJmZXJlIHdpdGggdGhlIHByb2Nlc3Np bmcgb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHN0cmVhbSAwIElQRklYIE1lc3NhZ2VzIGF0IHRoZSBDb2xsZWN0aW5n IFByb2Nlc3MsIGJlY2F1c2UgRFRMUzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHN0cmVhbSAwIElQRklYIE1lc3NhZ2VzIGF0IHRoZSBDb2xsZWN0aW5nIFByb2Nlc3Ms IGJlY2F1c2UgRFRMUzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29uc3VtZXMgaXRzIG93biBjb250cm9sIG1lc3NhZ2Vz IGJlZm9yZSBwYXNzaW5nIElQRklYIE1lc3NhZ2VzIHVwIHRvPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgY29uc3VtZXMgaXRzIG93biBjb250cm9sIG1lc3NhZ2VzIGJl Zm9yZSBwYXNzaW5nIElQRklYIE1lc3NhZ2VzIHVwIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgYXBwbGljYXRp b24gbGF5ZXIuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIGFwcGxp Y2F0aW9uIGxheWVyLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4xMS4yLiAgVXNhZ2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4xMS4yLiAg VXNhZ2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhl IElQRklYIEV4cG9ydGluZyBQcm9jZXNzIGluaXRpYXRlcyB0aGUgY29tbXVuaWNhdGlvbiB0 byB0aGUgSVBGSVg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgSVBG SVggRXhwb3J0aW5nIFByb2Nlc3MgaW5pdGlhdGVzIHRoZSBjb21tdW5pY2F0aW9uIHRvIHRo ZSBJUEZJWDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDcyIj48L2E+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgQ29sbGVjdGluZyBQcm9jZXNzLCBhbmQgYWN0cyBhcyBhIFRMUyBvciBE VExTIGNsaWVudCBhY2NvcmRpbmcgdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgIENvbGxlY3RpbmcgUHJvY2VzcywgYW5kIGFjdHMgYXMgYSBUTFMgb3IgRFRMUyBj bGllbnQgYWNjb3JkaW5nIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPltSRkM0 MzQ2XTwvc3Bhbj4gYW5kIFtSRkM0MzQ3XSwgd2hpbGUgdGhlIElQRklYIENvbGxlY3Rpbmcg UHJvY2VzcyBhY3RzIGFzIGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg PHNwYW4gY2xhc3M9Imluc2VydCI+W1JGQzUyNDZdPC9zcGFuPiBhbmQgW1JGQzQzNDddLCB3 aGlsZSB0aGUgSVBGSVggQ29sbGVjdGluZyBQcm9jZXNzIGFjdHMgYXMgYTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVExT IG9yIERUTFMgc2VydmVyLiAgVGhlIERUTFMgY2xpZW50IG9wZW5zIGEgc2VjdXJlIGNvbm5l Y3Rpb24gb24gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVExTIG9y IERUTFMgc2VydmVyLiAgVGhlIERUTFMgY2xpZW50IG9wZW5zIGEgc2VjdXJlIGNvbm5lY3Rp b24gb24gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBTQ1RQIHBvcnQgNDc0MCBvZiB0aGUgRFRMUyBzZXJ2ZXIgaWYg U0NUUCBvciBQUi1TQ1RQIGlzIHNlbGVjdGVkIGFzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgU0NUUCBwb3J0IDQ3NDAgb2YgdGhlIERUTFMgc2VydmVyIGlmIFNDVFAg b3IgUFItU0NUUCBpcyBzZWxlY3RlZCBhczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHRyYW5zcG9ydCBwcm90b2Nv bC4gIFRoZSBUTFMgY2xpZW50IG9wZW5zIGEgc2VjdXJlIGNvbm5lY3Rpb24gb248L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGUgdHJhbnNwb3J0IHByb3RvY29sLiAg VGhlIFRMUyBjbGllbnQgb3BlbnMgYSBzZWN1cmUgY29ubmVjdGlvbiBvbjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhl IFRDUCBwb3J0IDQ3NDAgb2YgdGhlIFRMUyBzZXJ2ZXIgaWYgVENQIGlzIHNlbGVjdGVkIGFz IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBUQ1AgcG9ydCA0 NzQwIG9mIHRoZSBUTFMgc2VydmVyIGlmIFRDUCBpcyBzZWxlY3RlZCBhcyB0aGU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHRyYW5zcG9ydCBwcm90b2NvbC4gIFRoZSBEVExTIGNsaWVudCBvcGVucyBhIHNlY3VyZSBj b25uZWN0aW9uIG9uIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRy YW5zcG9ydCBwcm90b2NvbC4gIFRoZSBEVExTIGNsaWVudCBvcGVucyBhIHNlY3VyZSBjb25u ZWN0aW9uIG9uIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgVURQIHBvcnQgNDc0MCBvZiB0aGUgRFRMUyBzZXJ2ZXIg aWYgVURQIGlzIHNlbGVjdGVkIGFzIHRoZSB0cmFuc3BvcnQ8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBVRFAgcG9ydCA0NzQwIG9mIHRoZSBEVExTIHNlcnZlciBpZiBV RFAgaXMgc2VsZWN0ZWQgYXMgdGhlIHRyYW5zcG9ydDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHJvdG9jb2wuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJvdG9jb2wuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjExLjMuICBBdXRoZW50aWNhdGlvbjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjExLjMuICBBdXRoZW50aWNhdGlvbjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJUEZJWCBFeHBvcnRp bmcgUHJvY2Vzc2VzIGFuZCBJUEZJWCBDb2xsZWN0aW5nIFByb2Nlc3NlcyBhcmU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJUEZJWCBFeHBvcnRpbmcgUHJvY2Vzc2Vz IGFuZCBJUEZJWCBDb2xsZWN0aW5nIFByb2Nlc3NlcyBhcmU8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGlkZW50aWZpZWQg YnkgdGhlIGZ1bGx5IHF1YWxpZmllZCBkb21haW4gbmFtZSBvZiB0aGUgaW50ZXJmYWNlIG9u PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaWRlbnRpZmllZCBieSB0aGUg ZnVsbHkgcXVhbGlmaWVkIGRvbWFpbiBuYW1lIG9mIHRoZSBpbnRlcmZhY2Ugb248L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHdoaWNoIElQRklYIE1lc3NhZ2VzIGFyZSBzZW50IG9yIHJlY2VpdmVkLCBmb3IgcHVycG9z ZXMgb2YgWC41MDk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3aGljaCBJ UEZJWCBNZXNzYWdlcyBhcmUgc2VudCBvciByZWNlaXZlZCwgZm9yIHB1cnBvc2VzIG9mIFgu NTA5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNzMiPjwvYT48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICBjbGllbnQgYW5kIHNlcnZlciBjZXJ0aWZpY2F0ZXMgYXMgaW4gW1JGQzxzcGFu IGNsYXNzPSJkZWxldGUiPjM8L3NwYW4+MjgwXS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgY2xpZW50IGFuZCBzZXJ2ZXIgY2VydGlmaWNhdGVzIGFzIGluIFtSRkM8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij41PC9zcGFuPjI4MF0uPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRvIHByZXZlbnQgbWFuLWluLXRoZS1taWRkbGUg YXR0YWNrcyBmcm9tIGltcG9zdG9yIEV4cG9ydGluZyBvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIFRvIHByZXZlbnQgbWFuLWluLXRoZS1taWRkbGUgYXR0YWNrcyBm cm9tIGltcG9zdG9yIEV4cG9ydGluZyBvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29sbGVjdGluZyBQcm9jZXNzZXMs IHRoZSBhY2NlcHRhbmNlIG9mIGRhdGEgZnJvbSBhbiB1bmF1dGhvcml6ZWQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDb2xsZWN0aW5nIFByb2Nlc3NlcywgdGhlIGFj Y2VwdGFuY2Ugb2YgZGF0YSBmcm9tIGFuIHVuYXV0aG9yaXplZDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRXhwb3J0aW5n IFByb2Nlc3MsIG9yIHRoZSBleHBvcnQgb2YgZGF0YSB0byBhbiB1bmF1dGhvcml6ZWQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBFeHBvcnRpbmcgUHJvY2Vzcywgb3Ig dGhlIGV4cG9ydCBvZiBkYXRhIHRvIGFuIHVuYXV0aG9yaXplZDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29sbGVjdGlu ZyBQcm9jZXNzLCBzdHJvbmcgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIHZpYSBhc3ltbWV0cmlj IGtleXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDb2xsZWN0aW5nIFBy b2Nlc3MsIHN0cm9uZyBtdXR1YWwgYXV0aGVudGljYXRpb24gdmlhIGFzeW1tZXRyaWMga2V5 czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgTVVTVCBiZSB1c2VkIGZvciBib3RoIFRMUyBhbmQgRFRMUy4gIEVhY2ggb2Yg dGhlIElQRklYIEV4cG9ydGluZyBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBNVVNUIGJlIHVzZWQgZm9yIGJvdGggVExTIGFuZCBEVExTLiAgRWFjaCBvZiB0aGUg SVBGSVggRXhwb3J0aW5nIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29sbGVjdGluZyBQcm9jZXNzZXMgTVVTVCB2 ZXJpZnkgdGhlIGlkZW50aXR5IG9mIGl0cyBwZWVyIGFnYWluc3QgaXRzPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29sbGVjdGluZyBQcm9jZXNzZXMgTVVTVCB2ZXJp ZnkgdGhlIGlkZW50aXR5IG9mIGl0cyBwZWVyIGFnYWluc3QgaXRzPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhdXRob3Jp emVkIGNlcnRpZmljYXRlcywgYW5kIE1VU1QgdmVyaWZ5IHRoYXQgdGhlIHBlZXIncyBjZXJ0 aWZpY2F0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGF1dGhvcml6ZWQg Y2VydGlmaWNhdGVzLCBhbmQgTVVTVCB2ZXJpZnkgdGhhdCB0aGUgcGVlcidzIGNlcnRpZmlj YXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBtYXRjaGVzIGl0cyBmdWxseSBxdWFsaWZpZWQgZG9tYWluIG5hbWUsIG9y LCBpbiB0aGUgY2FzZSBvZiBTQ1RQLCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBtYXRjaGVzIGl0cyBmdWxseSBxdWFsaWZpZWQgZG9tYWluIG5hbWUsIG9yLCBp biB0aGUgY2FzZSBvZiBTQ1RQLCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGZ1bGx5IHF1YWxpZmllZCBkb21haW4g bmFtZSBvZiBvbmUgb2YgaXRzIGVuZHBvaW50cy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBmdWxseSBxdWFsaWZpZWQgZG9tYWluIG5hbWUgb2Ygb25lIG9mIGl0cyBl bmRwb2ludHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48dGQ+PC90ZD48dGg+ PGEgbmFtZT0icGFydC1sMjAiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxs PjxlbT4gcGFnZSA0OSwgbGluZSAyMDwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBu YW1lPSJwYXJ0LXIyMCI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVt PiBwYWdlIDUxLCBsaW5lIDIwPC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU0NUUCBtYW5k YXRlcyBhIGNvb2tpZS1leGNoYW5nZSBtZWNoYW5pc20gZGVzaWduZWQgdG8gZGVmZW5kIGFn YWluc3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTQ1RQIG1hbmRhdGVz IGEgY29va2llLWV4Y2hhbmdlIG1lY2hhbmlzbSBkZXNpZ25lZCB0byBkZWZlbmQgYWdhaW5z dDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgU0NUUCBzdGF0ZSBleGhhdXN0aW9uIGRlbmlhbC1vZi1zZXJ2aWNlIGF0dGFj a3MuICBTaW1pbGFybHksIFRDUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFNDVFAgc3RhdGUgZXhoYXVzdGlvbiBkZW5pYWwtb2Ytc2VydmljZSBhdHRhY2tzLiAgU2lt aWxhcmx5LCBUQ1A8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIHByb3ZpZGVzIHRoZSAiU1lOIGNvb2tpZSIgbWVjaGFuaXNt IHRvIG1pdGlnYXRlIHN0YXRlIGV4aGF1c3Rpb247IFNZTjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHByb3ZpZGVzIHRoZSAiU1lOIGNvb2tpZSIgbWVjaGFuaXNtIHRv IG1pdGlnYXRlIHN0YXRlIGV4aGF1c3Rpb247IFNZTjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29va2llcyBTSE9VTEQg YmUgdXNlZCBieSBhbnkgQ29sbGVjdGluZyBQcm9jZXNzIGFjY2VwdGluZyBUQ1A8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb29raWVzIFNIT1VMRCBiZSB1c2VkIGJ5 IGFueSBDb2xsZWN0aW5nIFByb2Nlc3MgYWNjZXB0aW5nIFRDUDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29ubmVjdGlv bnMuICBEVExTIGFsc28gcHJvdmlkZXMgY29va2llIGV4Y2hhbmdlIHRvIHByb3RlY3QgYWdh aW5zdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbm5lY3Rpb25zLiAg RFRMUyBhbHNvIHByb3ZpZGVzIGNvb2tpZSBleGNoYW5nZSB0byBwcm90ZWN0IGFnYWluc3Q8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIERUTFMgc2VydmVyIHN0YXRlIGV4aGF1c3Rpb24uPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgRFRMUyBzZXJ2ZXIgc3RhdGUgZXhoYXVzdGlvbi48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIHJlYWRlciBzaG91 bGQgbm90ZSB0aGF0IHRoZXJlIGlzIG5vIHdheSB0byBwcmV2ZW50IGZha2UgSVBGSVg8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgcmVhZGVyIHNob3VsZCBub3Rl IHRoYXQgdGhlcmUgaXMgbm8gd2F5IHRvIHByZXZlbnQgZmFrZSBJUEZJWDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTWVz c2FnZSBwcm9jZXNzaW5nIChhbmQgc3RhdGUgY3JlYXRpb24pIGZvciBVRFAgJmFtcDsgU0NU UCBjb21tdW5pY2F0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE1l c3NhZ2UgcHJvY2Vzc2luZyAoYW5kIHN0YXRlIGNyZWF0aW9uKSBmb3IgVURQICZhbXA7IFND VFAgY29tbXVuaWNhdGlvbi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA3NCI+PC9hPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRoZSB1c2Ugb2YgVExTIGFuZCBEVExTIGNhbiBvYnZp b3VzbHkgcHJldmVudCB0aGUgY3JlYXRpb24gb2YgZmFrZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gPC9zcGFuPlRoZSB1c2Ug b2YgVExTIGFuZCBEVExTIGNhbiBvYnZpb3VzbHkgcHJldmVudCB0aGUgY3JlYXRpb24gb2Yg ZmFrZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgc3RhdGVzLCBidXQgdGhleSBhcmUgdGhlbXNlbHZlcyBwcm9uZSB0byBz dGF0ZSBleGhhdXN0aW9uIGF0dGFja3MuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgc3RhdGVzLCBidXQgdGhleSBhcmUgdGhlbXNlbHZlcyBwcm9uZSB0byBzdGF0ZSBl eGhhdXN0aW9uIGF0dGFja3MuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGVyZWZvcmUsIENvbGxlY3RvciByYXRlIGxp bWl0aW5nIFNIT1VMRCBiZSB1c2VkIHRvIHByb3RlY3QgVExTICZhbXA7PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlcmVmb3JlLCBDb2xsZWN0b3IgcmF0ZSBsaW1p dGluZyBTSE9VTEQgYmUgdXNlZCB0byBwcm90ZWN0IFRMUyAmYW1wOzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRFRMUyAo bGlrZSBsaW1pdGluZyB0aGUgbnVtYmVyIG9mIG5ldyBUTFMgb3IgRFRMUyBzZXNzaW9uIHBl ciBzZWNvbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEVExTIChsaWtl IGxpbWl0aW5nIHRoZSBudW1iZXIgb2YgbmV3IFRMUyBvciBEVExTIHNlc3Npb24gcGVyIHNl Y29uZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgdG8gYSBzZW5zaWJsZSBudW1iZXIpLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHRvIGEgc2Vuc2libGUgbnVtYmVyKS48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSVBGSVggc3RhdGUgZXhoYXVzdGlvbiBh dHRhY2tzIGNhbiBiZSBtaXRpZ2F0ZWQgYnkgbGltaXRpbmcgdGhlIHJhdGU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJUEZJWCBzdGF0ZSBleGhhdXN0aW9uIGF0dGFj a3MgY2FuIGJlIG1pdGlnYXRlZCBieSBsaW1pdGluZyB0aGUgcmF0ZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXQgd2hp Y2ggbmV3IGNvbm5lY3Rpb25zIG9yIGFzc29jaWF0aW9ucyB3aWxsIGJlIG9wZW5lZCBieSB0 aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhdCB3aGljaCBuZXcgY29u bmVjdGlvbnMgb3IgYXNzb2NpYXRpb25zIHdpbGwgYmUgb3BlbmVkIGJ5IHRoZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg Q29sbGVjdGluZyBQcm9jZXNzLCB0aGUgcmF0ZSBhdCB3aGljaCBJUEZJWCBNZXNzYWdlcyB3 aWxsIGJlIGFjY2VwdGVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29s bGVjdGluZyBQcm9jZXNzLCB0aGUgcmF0ZSBhdCB3aGljaCBJUEZJWCBNZXNzYWdlcyB3aWxs IGJlIGFjY2VwdGVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBieSB0aGUgQ29sbGVjdGluZyBQcm9jZXNzLCBhbmQgYWRh cHRpdmVseSBsaW1pdGluZyB0aGUgYW1vdW50IG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgYnkgdGhlIENvbGxlY3RpbmcgUHJvY2VzcywgYW5kIGFkYXB0aXZlbHkg bGltaXRpbmcgdGhlIGFtb3VudCBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc3RhdGUga2VwdCwgcGFydGljdWxhcmx5 IHJlY29yZHMgd2FpdGluZyBvbiBUZW1wbGF0ZXMuICBUaGVzZSByYXRlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc3RhdGUga2VwdCwgcGFydGljdWxhcmx5IHJlY29y ZHMgd2FpdGluZyBvbiBUZW1wbGF0ZXMuICBUaGVzZSByYXRlPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0ciBi Z2NvbG9yPSJncmF5Ij48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMjEiPjxzbWFsbD5z a2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA1MSwgbGluZSAyNTwvZW0+ PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXIyMSI+PHNtYWxsPnNraXBw aW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDUzLCBsaW5lIDI1PC9lbT48L2E+ PC90aD48dGQ+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgSVBGSVggTWVzc2FnZXMgdXNlIHR3byBmaWVsZHMgd2l0aCBh c3NpZ25lZCB2YWx1ZXMuICBUaGVzZSBhcmUgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgSVBGSVggTWVzc2FnZXMgdXNlIHR3byBmaWVsZHMgd2l0aCBhc3NpZ25l ZCB2YWx1ZXMuICBUaGVzZSBhcmUgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJUEZJWCBWZXJzaW9uIE51bWJlciwg aW5kaWNhdGluZyB3aGljaCB2ZXJzaW9uIG9mIHRoZSBJUEZJWCBQcm90b2NvbDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElQRklYIFZlcnNpb24gTnVtYmVyLCBpbmRp Y2F0aW5nIHdoaWNoIHZlcnNpb24gb2YgdGhlIElQRklYIFByb3RvY29sPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3YXMg dXNlZCB0byBleHBvcnQgYW4gSVBGSVggTWVzc2FnZSwgYW5kIHRoZSBJUEZJWCBTZXQgSUQs IGluZGljYXRpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3YXMgdXNl ZCB0byBleHBvcnQgYW4gSVBGSVggTWVzc2FnZSwgYW5kIHRoZSBJUEZJWCBTZXQgSUQsIGlu ZGljYXRpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHRoZSB0eXBlIGZvciBlYWNoIHNldCBvZiBpbmZvcm1hdGlvbiB3 aXRoaW4gYW4gSVBGSVggTWVzc2FnZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICB0aGUgdHlwZSBmb3IgZWFjaCBzZXQgb2YgaW5mb3JtYXRpb24gd2l0aGluIGFuIElQ RklYIE1lc3NhZ2UuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFRoZSBJUEZJWCBWZXJzaW9uIE51bWJlciB2YWx1ZSBvZiAxMCBpcyByZXNlcnZlZCBm b3IgdGhlIElQRklYPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIElQ RklYIFZlcnNpb24gTnVtYmVyIHZhbHVlIG9mIDEwIGlzIHJlc2VydmVkIGZvciB0aGUgSVBG SVg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHByb3RvY29sIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50LiAgU2V0IElE IHZhbHVlcyBvZiAwIGFuZCAxIGFyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHByb3RvY29sIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50LiAgU2V0IElEIHZhbHVl cyBvZiAwIGFuZCAxIGFyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbm90IHVzZWQgZm9yIGhpc3RvcmljYWwgcmVhc29u cyBbUkZDMzk1NF0uICBUaGUgU2V0IElEIHZhbHVlIG9mIDIgaXM8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBub3QgdXNlZCBmb3IgaGlzdG9yaWNhbCByZWFzb25zIFtS RkMzOTU0XS4gIFRoZSBTZXQgSUQgdmFsdWUgb2YgMiBpczwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcmVzZXJ2ZWQgZm9y IHRoZSBUZW1wbGF0ZSBTZXQuICBUaGUgU2V0IElEIHZhbHVlIG9mIDMgaXMgcmVzZXJ2ZWQg Zm9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVzZXJ2ZWQgZm9yIHRo ZSBUZW1wbGF0ZSBTZXQuICBUaGUgU2V0IElEIHZhbHVlIG9mIDMgaXMgcmVzZXJ2ZWQgZm9y PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNzUiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICB0aGUgT3B0aW9uIFRlbXBsYXRlIFNldC4gIEFsbCBvdGhlciBTZXQgSUQgdmFsdWVz IGZyb20gNCB0byAyNTUgYXJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IHRoZSBPcHRpb248c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zPC9zcGFuPiBUZW1wbGF0ZSBTZXQu ICBBbGwgb3RoZXIgU2V0IElEIHZhbHVlcyBmcm9tIDQgdG8gMjU1IGFyZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcmVz ZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UuICBTZXQgSUQgdmFsdWVzIGFib3ZlIDI1NSBhcmUgdXNl ZCBmb3IgRGF0YTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlc2VydmVk IGZvciBmdXR1cmUgdXNlLiAgU2V0IElEIHZhbHVlcyBhYm92ZSAyNTUgYXJlIHVzZWQgZm9y IERhdGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFNldHMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg U2V0cy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTmV3 IGFzc2lnbm1lbnRzIGluIGVpdGhlciBJUEZJWCBWZXJzaW9uIE51bWJlciBvciBJUEZJWCBT ZXQgSUQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBOZXcgYXNzaWdubWVu dHMgaW4gZWl0aGVyIElQRklYIFZlcnNpb24gTnVtYmVyIG9yIElQRklYIFNldCBJRDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkPjxhIG5hbWU9ImRpZmYwMDc2Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg YXNzaWdubWVudHMgcmVxdWlyZSBhIFN0YW5kYXJkcyBBY3Rpb24gW1JGQzxzcGFuIGNsYXNz PSJkZWxldGUiPjI0MzQ8L3NwYW4+XSwgaS5lLiwgdGhleSBhcmUgdG88L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgYXNzaWdubWVudHMgcmVxdWlyZSBhIFN0YW5kYXJk cyBBY3Rpb24gW1JGQzxzcGFuIGNsYXNzPSJpbnNlcnQiPjUyMjY8L3NwYW4+XSwgaS5lLiwg dGhleSBhcmUgdG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIGJlIG1hZGUgdmlhIFN0YW5kYXJkcyBUcmFjayBSRkNzIGFw cHJvdmVkIGJ5IHRoZSBJRVNHLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGJlIG1hZGUgdmlhIFN0YW5kYXJkcyBUcmFjayBSRkNzIGFwcHJvdmVkIGJ5IHRoZSBJRVNH LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BcHBlbmRpeCBB LiAgSVBGSVggRW5jb2RpbmcgRXhhbXBsZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij5BcHBlbmRpeCBBLiAgSVBGSVggRW5jb2RpbmcgRXhhbXBsZXM8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBhcHBlbmRpeCwgd2hpY2gg aXMgYSBub3QgYSBub3JtYXRpdmUgcmVmZXJlbmNlLCBjb250YWlucyBJUEZJWDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgYXBwZW5kaXgsIHdoaWNoIGlzIGEg bm90IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSwgY29udGFpbnMgSVBGSVg8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGVuY29k aW5nIGV4YW1wbGVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGVuY29k aW5nIGV4YW1wbGVzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQ+PGEgbmFtZT0iZGlmZjAwNzciPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICBMZXQncyBjb25zaWRlciB0aGUgZXhhbXBsZSBvZiBhbiBJUEZJWCBNZXNzYWdlIGNvbXBv c2VkIG9mIGEgVGVtcGxhdGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg TGV0J3MgY29uc2lkZXIgdGhlIGV4YW1wbGUgb2YgYW4gSVBGSVggTWVzc2FnZSBjb21wb3Nl ZCBvZiBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIFNldCwgYSBEYXRhIFNldCAod2hpY2ggY29udGFpbnMgdGhyZWUg RGF0YSBSZWNvcmRzKSwgYW4gT3B0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBUZW1wbGF0ZSBTZXQsIGEgRGF0YSBTZXQgKHdoaWNoIGNvbnRhaW5zIHRocmVl IERhdGEgUmVjb3JkcyksIGFuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRlbXBsYXRlIFNldCBhbmQgYSBEYXRhIFNl dCAod2hpY2ggY29udGFpbnMgMiBEYXRhIFJlY29yZHMgcmVsYXRlZCB0bzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBPcHRpb25zIFRlbXBsYXRlIFNldCBhbmQgYSBE YXRhIFNldCAod2hpY2ggY29udGFpbnMgMiBEYXRhIFJlY29yZHM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgdGhlIHBy ZXZpb3VzIE9wdGlvbnMgVGVtcGxhdGUgUmVjb3JkKS48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgcmVsYXRlZCB0byB0aGUgcHJldmlvdXMgT3B0aW9ucyBUZW1wbGF0 ZSBSZWNvcmQpLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBJUEZJWCBNZXNzYWdlOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElQ RklYIE1lc3NhZ2U6PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICstLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0uIC4gLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICstLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0uIC4gLjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg fCAgICAgICAgfCArLS0tLS0tLS0tLS0tLS0rICstLS0tLS0tLS0tLS0tLS0tLS0rPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCAgICAgICAgfCArLS0tLS0tLS0tLS0t LS0rICstLS0tLS0tLS0tLS0tLS0tLS0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB8TWVzc2FnZSB8IHwgVGVtcGxhdGUg ICAgIHwgfCBEYXRhICAgICAgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICB8TWVzc2FnZSB8IHwgVGVtcGxhdGUgICAgIHwgfCBEYXRhICAgICAgICAgICAg IHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHwgSGVhZGVyIHwgfCBTZXQgICAgICAgICAgfCB8IFNldCAgICAgICAgICAg ICAgfCAgIC4gLiAuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCBIZWFk ZXIgfCB8IFNldCAgICAgICAgICB8IHwgU2V0ICAgICAgICAgICAgICB8ICAgLiAuIC48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIHwgICAgICAgIHwgfCAoMSBUZW1wbGF0ZSkgfCB8ICgzIERhdGEgUmVjb3JkcykgfDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHwgICAgICAgIHwgfCAoMSBUZW1w bGF0ZSkgfCB8ICgzIERhdGEgUmVjb3JkcykgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgfCAgICAgICAgfCArLS0tLS0t LS0tLS0tLS0rICstLS0tLS0tLS0tLS0tLS0tLS0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgfCAgICAgICAgfCArLS0tLS0tLS0tLS0tLS0rICstLS0tLS0tLS0tLS0t LS0tLS0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICArLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLiAuIC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAr LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLiAu IC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPg0KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiPjx0ZD48L3RkPjx0aD48YSBuYW1l PSJwYXJ0LWwyMiI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBw YWdlIDUzLCBsaW5lIDIwPC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBh cnQtcjIyIj48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2Ug NTUsIGxpbmUgMjA8L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAtIFRoZSBJUHY0IHNvdXJj ZSBJUCBhZGRyZXNzOiBzb3VyY2VJUHY0QWRkcmVzcyBpbiBbUkZDNTEwMl0sPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgLSBUaGUgSVB2NCBzb3VyY2UgSVAgYWRkcmVz czogc291cmNlSVB2NEFkZHJlc3MgaW4gW1JGQzUxMDJdLDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICB3aXRoIGEgbGVu Z3RoIG9mIDQgb2N0ZXRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICB3 aXRoIGEgbGVuZ3RoIG9mIDQgb2N0ZXRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIC0gVGhlIElQdjQgZGVzdGluYXRpb24gSVAgYWRkcmVzczogZGVz dGluYXRpb25JUHY0QWRkcmVzcyBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIC0gVGhlIElQdjQgZGVzdGluYXRpb24gSVAgYWRkcmVzczogZGVzdGluYXRpb25JUHY0 QWRkcmVzcyBpbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICBbUkZDNTEwMl0sIHdpdGggYSBsZW5ndGggb2YgNCBvY3Rl dHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIFtSRkM1MTAyXSwgd2l0 aCBhIGxlbmd0aCBvZiA0IG9jdGV0czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAtIFRoZSBuZXh0LWhvcCBJUCBhZGRyZXNzIChJUHY0KTogaXBOZXh0 SG9wSVB2NEFkZHJlc3MgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAt IFRoZSBuZXh0LWhvcCBJUCBhZGRyZXNzIChJUHY0KTogaXBOZXh0SG9wSVB2NEFkZHJlc3Mg aW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgW1JGQzUxMDJdLCB3aXRoIGEgbGVuZ3RoIG9mIDQgb2N0ZXRzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICBbUkZDNTEwMl0sIHdpdGggYSBsZW5n dGggb2YgNCBvY3RldHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDc4Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgLSBUaGUgbnVtYmVyIG9mIHBhY2tldHMgb2YgdGhlIEZsb3c6IDxzcGFuIGNsYXNzPSJk ZWxldGUiPmluUDwvc3Bhbj5hY2tldERlbHRhQ291bnQgaW48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgLSBUaGUgbnVtYmVyIG9mIHBhY2tldHMgb2YgdGhlIEZsb3c6 IDxzcGFuIGNsYXNzPSJpbnNlcnQiPnA8L3NwYW4+YWNrZXREZWx0YUNvdW50IGluPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgIFtSRkM1MTAyXSwgd2l0aCBhIGxlbmd0aCBvZiA0IG9jdGV0czwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgW1JGQzUxMDJdLCB3aXRoIGEgbGVuZ3RoIG9mIDQg b2N0ZXRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48 YSBuYW1lPSJkaWZmMDA3OSI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIC0gVGhl IG51bWJlciBvZiBvY3RldHMgb2YgdGhlIEZsb3c6IDxzcGFuIGNsYXNzPSJkZWxldGUiPmlu Tzwvc3Bhbj5jdGV0RGVsdGFDb3VudCBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICAtIFRoZSBudW1iZXIgb2Ygb2N0ZXRzIG9mIHRoZSBGbG93OiA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij5vPC9zcGFuPmN0ZXREZWx0YUNvdW50IGluPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIFtSRkM1MTAy XSwgd2l0aCBhIGxlbmd0aCBvZiA0IG9jdGV0czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgW1JGQzUxMDJdLCB3aXRoIGEgbGVuZ3RoIG9mIDQgb2N0ZXRzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZXJlZm9yZSwgdGhl IFRlbXBsYXRlIFNldCB3aWxsIGJlIGNvbXBvc2VkIG9mIHRoZSBmb2xsb3dpbmc6PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlcmVmb3JlLCB0aGUgVGVtcGxhdGUg U2V0IHdpbGwgYmUgY29tcG9zZWQgb2YgdGhlIGZvbGxvd2luZzo8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIDAgICAgICAgICAgICAgICAgICAgMSAg ICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDM8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAg ICAgICAgIDIgICAgICAgICAgICAgICAgICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIHwgICAgICAgICBTZXQgSUQgPSAyICAgICAgICAgICAgfCAgICAgIExlbmd0aCA9IDI4 IG9jdGV0cyAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCAg ICAgICAgIFNldCBJRCA9IDIgICAgICAgICAgICB8ICAgICAgTGVuZ3RoID0gMjggb2N0ZXRz ICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwgICAgICAgVGVtcGxhdGUgSUQgMjU2ICAg ICAgICAgfCAgICAgICBGaWVsZCBDb3VudCA9IDUgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgfCAgICAgICBUZW1wbGF0ZSBJRCAyNTYgICAgICAgICB8 ICAgICAgIEZpZWxkIENvdW50ID0gNSAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHww fCAgICBzb3VyY2VJUHY0QWRkcmVzcyA9IDggICAgfCAgICAgICBGaWVsZCBMZW5ndGggPSA0 ICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfDB8ICAgIHNv dXJjZUlQdjRBZGRyZXNzID0gOCAgICB8ICAgICAgIEZpZWxkIExlbmd0aCA9IDQgICAgICAg IHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwwfCBkZXN0aW5hdGlvbklQdjRBZGRyZXNzID0gMTIg fCAgICAgICBGaWVsZCBMZW5ndGggPSA0ICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgfDB8IGRlc3RpbmF0aW9uSVB2NEFkZHJlc3MgPSAxMiB8ICAgICAg IEZpZWxkIExlbmd0aCA9IDQgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwwfCAgaXBO ZXh0SG9wSVB2NEFkZHJlc3MgPSAxNSAgfCAgICAgICBGaWVsZCBMZW5ndGggPSA0ICAgICAg ICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfDB8ICBpcE5leHRIb3BJ UHY0QWRkcmVzcyA9IDE1ICB8ICAgICAgIEZpZWxkIExlbmd0aCA9IDQgICAgICAgIHw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA4MCI+PC9hPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIHwwfCAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPmluUGFja2V0RGVsdGFD b3VudCA9IDI8L3NwYW4+ICAgIHwgICAgICAgRmllbGQgTGVuZ3RoID0gNCAgICAgICAgfDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB8MHwgICA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gcGFja2V0RGVsdGFDb3VudCA9IDIgPC9zcGFuPiAgICB8ICAgICAgIEZpZWxk IExlbmd0aCA9IDQgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZm MDA4MSI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHwwfCAgIDxzcGFuIGNsYXNz PSJkZWxldGUiPmluT2N0ZXREZWx0YUNvdW50ID0gIDE8L3NwYW4+ICAgIHwgICAgICAgRmll bGQgTGVuZ3RoID0gNCAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICB8MHwgICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gb2N0ZXREZWx0YUNvdW50ID0gMSAg PC9zcGFuPiAgICB8ICAgICAgIEZpZWxkIExlbmd0aCA9IDQgICAgICAgIHw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QS4yLjIuICBU ZW1wbGF0ZSBTZXQgVXNpbmcgRW50ZXJwcmlzZS1TcGVjaWZpYyBJbmZvcm1hdGlvbiBFbGVt ZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkEuMi4yLiAgVGVtcGxhdGUg U2V0IFVzaW5nIEVudGVycHJpc2UtU3BlY2lmaWMgSW5mb3JtYXRpb24gRWxlbWVudHM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgV2Ugd2FudCB0byBy ZXBvcnQgdGhlIGZvbGxvd2luZyBJbmZvcm1hdGlvbiBFbGVtZW50czo8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBXZSB3YW50IHRvIHJlcG9ydCB0aGUgZm9sbG93aW5n IEluZm9ybWF0aW9uIEVsZW1lbnRzOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAtIFRoZSBJUHY0IHNvdXJjZSBJUCBhZGRyZXNzOiBzb3VyY2VJUHY0 QWRkcmVzcyBpbiBbUkZDNTEwMl0sIHdpdGggYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIC0gVGhlIElQdjQgc291cmNlIElQIGFkZHJlc3M6IHNvdXJjZUlQdjRBZGRy ZXNzIGluIFtSRkM1MTAyXSwgd2l0aCBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIGxlbmd0aCBvZiA0IG9jdGV0czwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgbGVuZ3RoIG9mIDQgb2N0ZXRz PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIC0gVGhlIElQ djQgZGVzdGluYXRpb24gSVAgYWRkcmVzczogZGVzdGluYXRpb25JUHY0QWRkcmVzcyBpbjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIC0gVGhlIElQdjQgZGVzdGluYXRp b24gSVAgYWRkcmVzczogZGVzdGluYXRpb25JUHY0QWRkcmVzcyBpbjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICBbUkZD NTEwMl0sIHdpdGggYSBsZW5ndGggb2YgNCBvY3RldHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgIFtSRkM1MTAyXSwgd2l0aCBhIGxlbmd0aCBvZiA0IG9jdGV0czwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0i ZGlmZjAwODIiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAtIEFuIGVudGVycHJp c2Utc3BlY2lmaWMgSW5mb3JtYXRpb24gRWxlbWVudCByZXByZXNlbnRpbmcgcHJvcHJpZXRh cnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgLSBBbiBlbnRlcnByaXNl LXNwZWNpZmljIEluZm9ybWF0aW9uIEVsZW1lbnQgcmVwcmVzZW50aW5nPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAg aW5mb3JtYXRpb24sIHdpdGggYSB0eXBlIG9mIDE1IGFuZCBhIGxlbmd0aCBvZiA0PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgcHJvcHJpZXRhcnkgaW5mb3JtYXRp b24sIHdpdGggYSB0eXBlIG9mIDE1IGFuZCBhIGxlbmd0aCBvZiA0PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA4MyI+PC9h PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIC0gVGhlIG51bWJlciBvZiBwYWNrZXRzIG9m IHRoZSBGbG93OiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5pblBhY2tldERlbHRhQ291bnQgaW48 L3NwYW4+IFtSRkM1MTAyXSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg LSBUaGUgbnVtYmVyIG9mIHBhY2tldHMgb2YgdGhlIEZsb3c6IDxzcGFuIGNsYXNzPSJpbnNl cnQiPnBhY2tldERlbHRhQ291bnQgaW4gPC9zcGFuPiBbUkZDNTEwMl0sPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIHdp dGggYSBsZW5ndGggb2YgNCBvY3RldHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgIHdpdGggYSBsZW5ndGggb2YgNCBvY3RldHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDg0Ij48L2E+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgLSBUaGUgbnVtYmVyIG9mIG9jdGV0cyBvZiB0aGUgRmxv dzogPHNwYW4gY2xhc3M9ImRlbGV0ZSI+aW5PY3RldERlbHRhQ291bnQgaW48L3NwYW4+IFtS RkM1MTAyXSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgLSBUaGUgbnVt YmVyIG9mIG9jdGV0cyBvZiB0aGUgRmxvdzogPHNwYW4gY2xhc3M9Imluc2VydCI+b2N0ZXRE ZWx0YUNvdW50IGluIDwvc3Bhbj4gW1JGQzUxMDJdLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICB3aXRoIGEgbGVuZ3Ro IG9mIDQgb2N0ZXRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICB3aXRo IGEgbGVuZ3RoIG9mIDQgb2N0ZXRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFRoZXJlZm9yZSwgdGhlIFRlbXBsYXRlIFNldCB3aWxsIGJlIGNvbXBv c2VkIG9mIHRoZSBmb2xsb3dpbmc6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgVGhlcmVmb3JlLCB0aGUgVGVtcGxhdGUgU2V0IHdpbGwgYmUgY29tcG9zZWQgb2YgdGhl IGZvbGxvd2luZzo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg ICAgICAgICAgIDM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgMCAgICAg ICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAg MzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwgICAgICAgICBTZXQgSUQgPSAyICAg ICAgICAgICAgfCAgICAgIExlbmd0aCA9IDMyIG9jdGV0cyAgICAgICB8PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCAgICAgICAgIFNldCBJRCA9IDIgICAgICAgICAg ICB8ICAgICAgTGVuZ3RoID0gMzIgb2N0ZXRzICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHwgICAgICAgVGVtcGxhdGUgSUQgMjU3ICAgICAgICAgfCAgICAgICBGaWVsZCBDb3VudCA9 IDUgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCAgICAg ICBUZW1wbGF0ZSBJRCAyNTcgICAgICAgICB8ICAgICAgIEZpZWxkIENvdW50ID0gNSAgICAg ICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwwfCAgICBzb3VyY2VJUHY0QWRkcmVzcyA9IDgg ICAgfCAgICAgICBGaWVsZCBMZW5ndGggPSA0ICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgfDB8ICAgIHNvdXJjZUlQdjRBZGRyZXNzID0gOCAgICB8ICAg ICAgIEZpZWxkIExlbmd0aCA9IDQgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwwfCBk ZXN0aW5hdGlvbklQdjRBZGRyZXNzID0gMTIgfCAgICAgICBGaWVsZCBMZW5ndGggPSA0ICAg ICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfDB8IGRlc3RpbmF0 aW9uSVB2NEFkZHJlc3MgPSAxMiB8ICAgICAgIEZpZWxkIExlbmd0aCA9IDQgICAgICAgIHw8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIHwxfCBJbmZvcm1hdGlvbiBFbGVtZW50IElkLiA9IDE1fCAg ICAgICBGaWVsZCBMZW5ndGggPSA0ICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgfDF8IEluZm9ybWF0aW9uIEVsZW1lbnQgSWQuID0gMTV8ICAgICAgIEZp ZWxkIExlbmd0aCA9IDQgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwgICAgICAgICAg ICAgICAgICAgICAgIEVudGVycHJpc2UgbnVtYmVyICAgICAgICAgICAgICAgICAgICAgICB8 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCAgICAgICAgICAgICAgICAg ICAgICAgRW50ZXJwcmlzZSBudW1iZXIgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA4NSI+PC9hPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIHwwfCAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPmluUGFja2V0RGVsdGFDb3Vu dCA9IDI8L3NwYW4+ICAgIHwgICAgICAgRmllbGQgTGVuZ3RoID0gNCAgICAgICAgfDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB8MHwgICA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gcGFja2V0RGVsdGFDb3VudCA9IDIgPC9zcGFuPiAgICB8ICAgICAgIEZpZWxkIExl bmd0aCA9IDQgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA4 NiI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHwwfCAgIDxzcGFuIGNsYXNzPSJk ZWxldGUiPmluT2N0ZXREZWx0YUNvdW50ID0gMTwvc3Bhbj4gICAgIHwgICAgICAgRmllbGQg TGVuZ3RoID0gNCAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICB8MHwgICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gb2N0ZXREZWx0YUNvdW50ID0gMSA8L3Nw YW4+ICAgICB8ICAgICAgIEZpZWxkIExlbmd0aCA9IDQgICAgICAgIHw8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QS4zLiAgRGF0YSBT ZXQgRXhhbXBsZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkEuMy4gIERhdGEg U2V0IEV4YW1wbGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgSW4gdGhpcyBleGFtcGxlLCB3ZSByZXBvcnQgdGhlIGZvbGxvd2luZyB0aHJlZSBGbG93 IFJlY29yZHM6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW4gdGhpcyBl eGFtcGxlLCB3ZSByZXBvcnQgdGhlIGZvbGxvd2luZyB0aHJlZSBGbG93IFJlY29yZHM6PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNyYyBJUCBhZGRy LiB8IERzdCBJUCBhZGRyLiAgfCBOZXh0IEhvcCBhZGRyLiB8IFBhY2tldCB8IE9jdGV0czwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNyYyBJUCBhZGRyLiB8IERzdCBJ UCBhZGRyLiAgfCBOZXh0IEhvcCBhZGRyLiB8IFBhY2tldCB8IE9jdGV0czwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgTnVtYmVyIHwg TnVtYmVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgTnVtYmVyIHwgTnVtYmVyPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIDE5Mi4wLjIuMTIgICB8IDE5Mi4wLjIuMjU0ICAgfCAxOTIu MC4yLjEgICAgICB8IDUwMDkgICB8IDUzNDQzODU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAxOTIuMC4yLjEyICAgfCAxOTIuMC4yLjI1NCAgIHwgMTkyLjAuMi4xICAg ICAgfCA1MDA5ICAgfCA1MzQ0Mzg1PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48 dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMjMiPjxzbWFsbD5za2lwcGluZyB0byBjaGFu Z2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA1NiwgbGluZSAxMjwvZW0+PC9hPjwvdGg+PHRoPiA8 L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXIyMyI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBh dDwvc21hbGw+PGVtPiBwYWdlIDU4LCBsaW5lIDEyPC9lbT48L2E+PC90aD48dGQ+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgTm90ZSB0aGF0IHBhZGRpbmcgaXMgbm90IG5lY2Vzc2FyeSBpbiB0aGlzIGV4YW1wbGUu PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTm90ZSB0aGF0IHBhZGRpbmcg aXMgbm90IG5lY2Vzc2FyeSBpbiB0aGlzIGV4YW1wbGUuPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPkEuNC4gIE9wdGlvbnMgVGVtcGxhdGUgU2V0IEV4YW1w bGVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+QS40LiAgT3B0aW9ucyBUZW1w bGF0ZSBTZXQgRXhhbXBsZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+QS40LjEuICBPcHRpb25zIFRlbXBsYXRlIFNldCBVc2luZyBJRVRGLVNwZWNpZmll ZCBJbmZvcm1hdGlvbiBFbGVtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PkEuNC4xLiAgT3B0aW9ucyBUZW1wbGF0ZSBTZXQgVXNpbmcgSUVURi1TcGVjaWZpZWQgSW5m b3JtYXRpb24gRWxlbWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgUGVyIGxpbmUgY2FyZCAodGhlIHJvdXRlciBiZWluZyBjb21wb3NlZCBvZiB0 d28gbGluZSBjYXJkcyksIHdlIHdhbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBQZXIgbGluZSBjYXJkICh0aGUgcm91dGVyIGJlaW5nIGNvbXBvc2VkIG9mIHR3byBs aW5lIGNhcmRzKSwgd2Ugd2FudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdG8gcmVwb3J0IHRoZSBmb2xsb3dpbmcgSW5m b3JtYXRpb24gRWxlbWVudHM6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg dG8gcmVwb3J0IHRoZSBmb2xsb3dpbmcgSW5mb3JtYXRpb24gRWxlbWVudHM6PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA4 NyI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIC0gVG90YWwgbnVtYmVyIG9mIElQ RklYIE1lc3NhZ2VzOiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5leHBvcnRlZFBhY2tldENvdW50 PC9zcGFuPiBbUkZDNTEwMl0sIHdpdGg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgLSBUb3RhbCBudW1iZXIgb2YgSVBGSVggTWVzc2FnZXM6IDxzcGFuIGNsYXNzPSJp bnNlcnQiPmV4cG9ydGVkTWVzc2FnZVRvdGFsQ291bnQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgYSBs ZW5ndGggb2YgMiBvY3RldHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg ICBbUkZDNTEwMl0sIHdpdGggYSBsZW5ndGggb2YgMiBvY3RldHM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDg4Ij48L2E+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgLSBUb3RhbCBudW1iZXIgb2YgZXhwb3J0ZWQg Rmxvd3M6IDxzcGFuIGNsYXNzPSJkZWxldGUiPmV4cG9ydGVkRmxvd0NvdW50PC9zcGFuPiBb UkZDNTEwMl0sIHdpdGggYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAt IFRvdGFsIG51bWJlciBvZiBleHBvcnRlZCBGbG93czogPHNwYW4gY2xhc3M9Imluc2VydCI+ ZXhwb3J0ZWRGbG93UmVjb3JkVG90YWxDb3VudDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICBsZW5ndGgg b2YgMiBvY3RldHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICBbUkZD NTEwMl0sIHdpdGggYSBsZW5ndGggb2YgMiBvY3RldHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGxpbmUgY2FyZCwgd2hpY2ggaXMgcmVwcmVz ZW50ZWQgYnkgdGhlIGxpbmVDYXJkSWQgSW5mb3JtYXRpb248L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBUaGUgbGluZSBjYXJkLCB3aGljaCBpcyByZXByZXNlbnRlZCBi eSB0aGUgbGluZUNhcmRJZCBJbmZvcm1hdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRWxlbWVudCBbUkZDNTEwMl0s IGlzIHVzZWQgYXMgdGhlIFNjb3BlIEZpZWxkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIEVsZW1lbnQgW1JGQzUxMDJdLCBpcyB1c2VkIGFzIHRoZSBTY29wZSBGaWVs ZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlcmVm b3JlLCB0aGUgT3B0aW9ucyBUZW1wbGF0ZSBTZXQgd2lsbCBiZTo8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGVyZWZvcmUsIHRoZSBPcHRpb25zIFRlbXBsYXRlIFNl dCB3aWxsIGJlOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAg ICAgICAgICAgMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAwICAgICAg ICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAz PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgfCAgICAgICAgIFNldCBJRCA9IDMgICAg ICAgICAgICB8ICAgICAgICAgIExlbmd0aCA9IDI0ICAgICAgICAgIHw8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB8ICAgICAgICAgU2V0IElEID0gMyAgICAgICAgICAg IHwgICAgICAgICAgTGVuZ3RoID0gMjQgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg fCAgICAgICBUZW1wbGF0ZSBJRCAyNTggICAgICAgICB8ICAgICAgICBGaWVsZCBDb3VudCA9 IDMgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB8ICAgICAg IFRlbXBsYXRlIElEIDI1OCAgICAgICAgIHwgICAgICAgIEZpZWxkIENvdW50ID0gMyAgICAg ICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgfCAgICAgU2NvcGUgRmllbGQgQ291bnQgPSAxICAg ICB8MHwgICAgIGxpbmVDYXJkSWQgPSAxNDEgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICB8ICAgICBTY29wZSBGaWVsZCBDb3VudCA9IDEgICAgIHwwfCAg ICAgbGluZUNhcmRJZCA9IDE0MSAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDg5Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgfCAgIFNjb3Bl IDEgRmllbGQgTGVuZ3RoID0gNCAgICB8MHw8c3BhbiBjbGFzcz0iZGVsZXRlIj4gIGV4cG9y dGVkUGFja2V0Q291bnQgPSA0MSAgPC9zcGFuPiB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIHwgICBTY29wZSAxIEZpZWxkIExlbmd0aCA9IDQgICAgfDB8PHNwYW4g Y2xhc3M9Imluc2VydCI+ZXhwb3J0ZWRNZXNzYWdlVG90YWxDb3VudD00MTwvc3Bhbj4gfDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDkwIj48L2E+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgfCAgICAgICBGaWVsZCBMZW5ndGggPSAyICAgICAgICB8MHw8c3Bh biBjbGFzcz0iZGVsZXRlIj4gICBleHBvcnRlZEZsb3dDb3VudCA9IDQyICAgIDwvc3Bhbj58 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHwgICAgICAgRmllbGQgTGVu Z3RoID0gMiAgICAgICAgfDB8PHNwYW4gY2xhc3M9Imluc2VydCI+ZXhwb3J0ZWRGbG93UmVj b3JkVG90YWxDby49NDI8L3NwYW4+fDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgfCAgICAgICBGaWVs ZCBMZW5ndGggPSAyICAgICAgICB8ICAgICAgICAgICBQYWRkaW5nICAgICAgICAgICAgIHw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB8ICAgICAgIEZpZWxkIExlbmd0 aCA9IDIgICAgICAgIHwgICAgICAgICAgIFBhZGRpbmcgICAgICAgICAgICAgfDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BLjQuMi4g IE9wdGlvbnMgVGVtcGxhdGUgU2V0IFVzaW5nIEVudGVycHJpc2UtU3BlY2lmaWMgSW5mb3Jt YXRpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5BLjQuMi4gIE9wdGlvbnMg VGVtcGxhdGUgU2V0IFVzaW5nIEVudGVycHJpc2UtU3BlY2lmaWMgSW5mb3JtYXRpb248L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgRWxlbWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICAgIEVsZW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFBlciBsaW5lIGNhcmQgKHRoZSByb3V0ZXIgYmVpbmcgY29tcG9zZWQgb2YgdHdvIGxp bmUgY2FyZHMpLCB3ZSB3YW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg UGVyIGxpbmUgY2FyZCAodGhlIHJvdXRlciBiZWluZyBjb21wb3NlZCBvZiB0d28gbGluZSBj YXJkcyksIHdlIHdhbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRvIHJlcG9ydCB0aGUgZm9sbG93aW5nIEluZm9ybWF0 aW9uIEVsZW1lbnRzOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRvIHJl cG9ydCB0aGUgZm9sbG93aW5nIEluZm9ybWF0aW9uIEVsZW1lbnRzOjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwOTEiPjwv YT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAtIFRvdGFsIG51bWJlciBvZiBJUEZJ WCBNZXNzYWdlczogPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZXhwb3J0ZWRQYWNrZXRDb3VudDwv c3Bhbj4gW1JGQzUxMDJdLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAg ICAtIFRvdGFsIG51bWJlciBvZiBJUEZJWCBNZXNzYWdlczogPHNwYW4gY2xhc3M9Imluc2Vy dCI+ZXhwb3J0ZWRNZXNzYWdlVG90YWxDb3VudDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICB3aXRo IGEgbGVuZ3RoIG9mIDIgb2N0ZXRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgICAgICAgW1JGQzUxMDJdLCB3aXRoIGEgbGVuZ3RoIG9mIDIgb2N0ZXRzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIC0gQW4gZW50ZXJwcmlz ZS1zcGVjaWZpYyBudW1iZXIgb2YgZXhwb3J0ZWQgRmxvd3MsIHdpdGggYSB0eXBlIG9mPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgLSBBbiBlbnRlcnByaXNlLXNw ZWNpZmljIG51bWJlciBvZiBleHBvcnRlZCBGbG93cywgd2l0aCBhIHR5cGUgb2Y8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgNDIgYW5kIGEgbGVuZ3RoIG9mIDQgb2N0ZXRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICA0MiBhbmQgYSBsZW5ndGggb2YgNCBvY3RldHM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGxpbmUgY2FyZCwg d2hpY2ggaXMgcmVwcmVzZW50ZWQgYnkgdGhlIGxpbmVDYXJkSWQgSW5mb3JtYXRpb248L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgbGluZSBjYXJkLCB3aGljaCBp cyByZXByZXNlbnRlZCBieSB0aGUgbGluZUNhcmRJZCBJbmZvcm1hdGlvbjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRWxl bWVudCBbUkZDNTEwMl0sIGlzIHVzZWQgYXMgdGhlIFNjb3BlIEZpZWxkLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEVsZW1lbnQgW1JGQzUxMDJdLCBpcyB1c2VkIGFz IHRoZSBTY29wZSBGaWVsZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgVGhlIGZvcm1hdCBvZiB0aGUgT3B0aW9ucyBUZW1wbGF0ZSBTZXQgaXMgYXMg Zm9sbG93czo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgZm9ybWF0 IG9mIHRoZSBPcHRpb25zIFRlbXBsYXRlIFNldCBpcyBhcyBmb2xsb3dzOjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDAgICAgICAgICAgICAgICAg ICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAg ICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDM8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgIHwgICAgICAgICBTZXQgSUQgPSAzICAgICAgICAgICAgfCAgICAg ICAgICBMZW5ndGggPSAyOCAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgIHwgICAgICAgICBTZXQgSUQgPSAzICAgICAgICAgICAgfCAgICAgICAgICBM ZW5ndGggPSAyOCAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICB8ICAgICAgIFRl bXBsYXRlIElEIDI1OSAgICAgICAgIHwgICAgICAgIEZpZWxkIENvdW50ID0gMyAgICAgICAg fDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICB8ICAgICAgIFRlbXBsYXRl IElEIDI1OSAgICAgICAgIHwgICAgICAgIEZpZWxkIENvdW50ID0gMyAgICAgICAgfDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgfCAgICAgU2NvcGUgRmllbGQgQ291bnQgPSAxICAgICB8MHwg ICAgIGxpbmVDYXJkSWQgPSAxNDEgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgfCAgICAgU2NvcGUgRmllbGQgQ291bnQgPSAxICAgICB8MHwgICAgIGxp bmVDYXJkSWQgPSAxNDEgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMDkyIj48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgIHwgICBTY29wZSAx IEZpZWxkIExlbmd0aCA9IDQgICAgfDB8PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICBleHBvcnRl ZFBhY2tldENvdW50ID0gNDEgICA8L3NwYW4+fDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICAgfCAgIFNjb3BlIDEgRmllbGQgTGVuZ3RoID0gNCAgICB8MHw8c3BhbiBj bGFzcz0iaW5zZXJ0Ij5leHBvcnRlZEZsb3dSZWNvcmRUb3RhbENvLj00MTwvc3Bhbj58PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICB8ICAgICAgIEZpZWxkIExlbmd0aCA9IDIgICAgICAgIHwx fEluZm9ybWF0aW9uIEVsZW1lbnQgSWQuID0gNDIgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICB8ICAgICAgIEZpZWxkIExlbmd0aCA9IDIgICAgICAgIHwxfEluZm9y bWF0aW9uIEVsZW1lbnQgSWQuID0gNDIgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFt ZT0iZGlmZjAwOTMiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgfCAgICAgICBG aWVsZCBMZW5ndGggPSA0ICAgICAgICB8ICAgICAgIEVudGVycHJpc2UgbnVtYmVyICAgICAu Li48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgIHwgICAgICAgRmllbGQg TGVuZ3RoID0gNCAgICAgICAgfCAgICAgICBFbnRlcnByaXNlIG51bWJlciAgICAgPHNwYW4g Y2xhc3M9Imluc2VydCI+IDwvc3Bhbj4uLi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDk0Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xh c3M9ImRlbGV0ZSI+IC4uLjwvc3Bhbj4gICAgICBFbnRlcnByaXNlIG51bWJlciAgICAgIHwg ICAgICAgICAgIFBhZGRpbmcgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4uLi4gPC9zcGFuPiAgICAgIEVu dGVycHJpc2UgbnVtYmVyICAgICAgfCAgICAgICAgICAgUGFkZGluZyAgICAgICAgICAgICB8 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+QS40LjMuICBPcHRpb25zIFRlbXBsYXRlIFNldCBVc2luZyBhbiBFbnRlcnByaXNlLVNw ZWNpZmljIFNjb3BlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+QS40LjMuICBP cHRpb25zIFRlbXBsYXRlIFNldCBVc2luZyBhbiBFbnRlcnByaXNlLVNwZWNpZmljIFNjb3Bl PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEluIHRoaXMg ZXhhbXBsZSwgd2Ugd2FudCB0byBleHBvcnQgdGhlIHNhbWUgaW5mb3JtYXRpb24gYXMgaW4g dGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW4gdGhpcyBleGFtcGxl LCB3ZSB3YW50IHRvIGV4cG9ydCB0aGUgc2FtZSBpbmZvcm1hdGlvbiBhcyBpbiB0aGU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGV4YW1wbGUgaW4gU2VjdGlvbiBBLjQuMTo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBleGFtcGxlIGluIFNlY3Rpb24gQS40LjE6PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA5NSI+PC9hPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIC0gVG90YWwgbnVtYmVyIG9mIElQRklYIE1l c3NhZ2VzOiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5leHBvcnRlZFBhY2tldENvdW50PC9zcGFu PiBbUkZDNTEwMl0sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIC0g VG90YWwgbnVtYmVyIG9mIElQRklYIE1lc3NhZ2VzOiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5l eHBvcnRlZE1lc3NhZ2VUb3RhbENvdW50PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgIHdpdGggYSBs ZW5ndGggb2YgMiBvY3RldHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg ICAgICBbUkZDNTEwMl0sIHdpdGggYSBsZW5ndGggb2YgMiBvY3RldHM8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDk2Ij48 L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgLSBUb3RhbCBudW1iZXIgb2YgZXhw b3J0ZWQgRmxvd3M6IDxzcGFuIGNsYXNzPSJkZWxldGUiPmV4cG9ydGVkRmxvd0NvdW50PC9z cGFuPiBbUkZDNTEwMl0sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAg IC0gVG90YWwgbnVtYmVyIG9mIGV4cG9ydGVkIEZsb3dzOiA8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij5leHBvcnRlZEZsb3dSZWNvcmRUb3RhbENvdW50PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgIHdp dGggYSBsZW5ndGggb2YgMiBvY3RldHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgICAgICBbUkZDNTEwMl0sIHdpdGggYSBsZW5ndGggb2YgMiBvY3RldHM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQnV0IHRoaXMgdGltZSwg dGhlIGluZm9ybWF0aW9uIHBlcnRhaW5zIHRvIGEgcHJvcHJpZXRhcnkgc2NvcGUsPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQnV0IHRoaXMgdGltZSwgdGhlIGluZm9y bWF0aW9uIHBlcnRhaW5zIHRvIGEgcHJvcHJpZXRhcnkgc2NvcGUsPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpZGVudGlm aWVkIGJ5IGVudGVycHJpc2Utc3BlY2lmaWMgSW5mb3JtYXRpb24gRWxlbWVudCBudW1iZXIg MTIzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGlkZW50aWZpZWQgYnkg ZW50ZXJwcmlzZS1zcGVjaWZpYyBJbmZvcm1hdGlvbiBFbGVtZW50IG51bWJlciAxMjMuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBmb3JtYXQg b2YgdGhlIE9wdGlvbnMgVGVtcGxhdGUgU2V0IGlzIG5vdyBhcyBmb2xsb3dzOjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBmb3JtYXQgb2YgdGhlIE9wdGlvbnMg VGVtcGxhdGUgU2V0IGlzIG5vdyBhcyBmb2xsb3dzOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAg ICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDM8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAg ICAyICAgICAgICAgICAgICAgICAgIDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgIHwgICAgICAgICBTZXQgSUQgPSAzICAgICAgICAgICAgfCAgICAgICAgICBMZW5ndGgg PSAyOCAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIHwg ICAgICAgICBTZXQgSUQgPSAzICAgICAgICAgICAgfCAgICAgICAgICBMZW5ndGggPSAyOCAg ICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICB8ICAgICAgIFRlbXBsYXRlIElEIDI2 MCAgICAgICAgIHwgICAgICAgIEZpZWxkIENvdW50ID0gMyAgICAgICAgfDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICB8ICAgICAgIFRlbXBsYXRlIElEIDI2MCAgICAg ICAgIHwgICAgICAgIEZpZWxkIENvdW50ID0gMyAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgfCAgICAgU2NvcGUgRmllbGQgQ291bnQgPSAxICAgICB8MXxTY29wZSAxIEluZm9y LiBFbC4gSWQuID0gMTIzIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg fCAgICAgU2NvcGUgRmllbGQgQ291bnQgPSAxICAgICB8MXxTY29wZSAxIEluZm9yLiBFbC4g SWQuID0gMTIzIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIHwgICAgU2NvcGUgMSBGaWVsZCBM ZW5ndGggPSA0ICAgfCAgICAgICBFbnRlcnByaXNlIE51bWJlciAgICAgIC4uLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICB8ICAgIFNjb3BlIDEgRmllbGQgTGVuZ3Ro ID0gNCAgIHwgICAgICAgRW50ZXJwcmlzZSBOdW1iZXIgICAgICAuLi48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDk3Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgLi4uICAgICAgIEVudGVycHJpc2UgTnVtYmVyICAgICAgfDB8PHNwYW4gY2xhc3M9 ImRlbGV0ZSI+ICBleHBvcnRlZFBhY2tldENvdW50ID0gNDEgICA8L3NwYW4+fDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAuLi4gICAgICAgRW50ZXJwcmlzZSBOdW1i ZXIgICAgICB8MHw8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5leHBvcnRlZEZsb3dSZWNvcmRUb3Rh bENvLj00MTwvc3Bhbj58PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA5 OCI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICB8ICAgICAgIEZpZWxkIExlbmd0 aCA9IDIgICAgICAgIHwwfDxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGV4cG9ydGVkRmxvd0Nv dW50ID0gNDIgICAgPC9zcGFuPnw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgIHwgICAgICAgRmllbGQgTGVuZ3RoID0gMiAgICAgICAgfDB8PHNwYW4gY2xhc3M9Imlu c2VydCI+ZXhwb3J0ZWRGbG93UmVjb3JkVG90YWxDby49NDI8L3NwYW4+fDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgfCAgICAgICBGaWVsZCBMZW5ndGggPSAyICAgICAgICB8ICAgICAgICAg ICBQYWRkaW5nICAgICAgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgfCAgICAgICBGaWVsZCBMZW5ndGggPSAyICAgICAgICB8ICAgICAgICAgICBQYWRk aW5nICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BLjQuNC4gIERhdGEgU2V0IFVzaW5nIGFuIEVudGVycHJp c2UtU3BlY2lmaWMgU2NvcGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5BLjQu NC4gIERhdGEgU2V0IFVzaW5nIGFuIEVudGVycHJpc2UtU3BlY2lmaWMgU2NvcGU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW4gdGhpcyBleGFtcGxl LCB3ZSByZXBvcnQgdGhlIGZvbGxvd2luZyB0d28gRGF0YSBSZWNvcmRzOjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEluIHRoaXMgZXhhbXBsZSwgd2UgcmVwb3J0IHRo ZSBmb2xsb3dpbmcgdHdvIERhdGEgUmVjb3Jkczo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDk5Ij48L2E+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+TGluZSBDYXJkIElEICAg ICAgICAgICAgPC9zcGFuPiAgIHwgSVBGSVggTWVzc2FnZSAgfCBFeHBvcnRlZCBGbG93IFJl Y29yZHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9 Imluc2VydCI+RW50ZXJwcmlzZSBmaWVsZCAxMjM8L3NwYW4+ICAgfCBJUEZJWCBNZXNzYWdl ICB8IEV4cG9ydGVkIEZsb3cgUmVjb3JkczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBu YW1lPSJkaWZmMDEwMCI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNs YXNzPSJkZWxldGUiPkxpbmUgQ2FyZDwvc3Bhbj4gMSA8c3BhbiBjbGFzcz0iZGVsZXRlIj4o bGluZUNhcmRJZD0xKTwvc3Bhbj4gfCAzNDUgICAgICAgICAgICB8IDEwMjAxPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDEgICAgICAgICAgICAgICAgICAgICAgfCAz NDUgICAgICAgICAgICB8IDEwMjAxPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPkxp bmUgQ2FyZDwvc3Bhbj4gMiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4obGluZUNhcmRJZD0yKTwv c3Bhbj4gfCA2OTAgICAgICAgICAgICB8IDIwNDAyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIDIgICAgICAgICAgICAgICAgICAgICAgfCA2OTAgICAgICAgICAgICB8 IDIwNDAyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAw ICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAg ICAgICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIDAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB8ICAgICAgU2V0IElEID0gMjYwICAgICAgICAg ICAgIHwgICAgICAgICBMZW5ndGggPSAyMCAgICAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIHwgICAgICBTZXQgSUQgPSAyNjAgICAgICAgICAgICAgfCAg ICAgICAgIExlbmd0aCA9IDIwICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICB8ICAgICAgICAgICAgIDM0NSAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAxMDIwMSAgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIHwgICAgICAgICAgICAgMzQ1ICAgICAgICAgICAgICAgfCAgICAgICAg ICAgIDEwMjAxICAgICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0ciBi Z2NvbG9yPSJncmF5Ij48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMjQiPjxzbWFsbD5z a2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA1OSwgbGluZSAxODwvZW0+ PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXIyNCI+PHNtYWxsPnNraXBw aW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDYxLCBsaW5lIDE4PC9lbT48L2E+ PC90aD48dGQ+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgSW5mZXJpb3IgdG8gMjU1 IE9jdGV0czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgSW5mZXJp b3IgdG8gMjU1IE9jdGV0czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAg ICAgICAgICAgICAgICAgMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAw ICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAg ICAgICAzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgfCAgICAgICA1ICAgICAgIHwg ICAgICAgICAgNSBvY3RldCBJbmZvcm1hdGlvbiBFbGVtZW50ICAgICAgICAgIHw8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB8ICAgICAgIDUgICAgICAgfCAgICAgICAg ICA1IG9jdGV0IEluZm9ybWF0aW9uIEVsZW1lbnQgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMTAxIj48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+QS41LjIuICBFeGFt cGxlIG9mIFZhcmlhYmxlLUxlbmd0aCBJbmZvcm1hdGlvbiBFbGVtZW50IHdpdGggTGVuZ3Ro IDxzcGFuIGNsYXNzPSJkZWxldGUiPjI1NTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+QS41LjIuICBFeGFtcGxlIG9mIFZhcmlhYmxlLUxlbmd0aCBJbmZvcm1h dGlvbiBFbGVtZW50IHdpdGggPHNwYW4gY2xhc3M9Imluc2VydCI+MyBPY3RldDwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICB0byA2NTUzNSBPY3RldHM8L3Nw YW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgTGVuZ3RoIDxz cGFuIGNsYXNzPSJpbnNlcnQiPkVuY29kaW5nPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAg ICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMzwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAg ICAgMiAgICAgICAgICAgICAgICAgICAzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg fCAgICAgIDI1NSAgICAgIHwgICAgICAgICAgICAgMTAwMCAgICAgICAgICAgICAgfCAgICBJ RSAuLi4gICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB8ICAgICAg MjU1ICAgICAgfCAgICAgICAgICAgICAxMDAwICAgICAgICAgICAgICB8ICAgIElFIC4uLiAg ICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgfCAgICAgICAgICAgICAgICAxMDAwIG9jdGV0IElu Zm9ybWF0aW9uIEVsZW1lbnQgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICB8ICAgICAgICAgICAgICAgIDEwMDAgb2N0ZXQgSW5mb3JtYXRp b24gRWxlbWVudCAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgOiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC4uLiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA6ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLi4uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRo PjxhIG5hbWU9InBhcnQtbDI1Ij48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFs bD48ZW0+IHBhZ2UgNTksIGxpbmUgNDQ8L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PGEg bmFtZT0icGFydC1yMjUiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxl bT4gcGFnZSA2MSwgbGluZSA0NDwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPk5vcm1hdGl2ZSBS ZWZlcmVuY2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Tm9ybWF0aXZlIFJl ZmVyZW5jZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg W1JGQzEzMDVdICAgICAgIE1pbGxzLCBELiwgIk5ldHdvcmsgVGltZSBQcm90b2NvbCAoVmVy c2lvbiAzKTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkMxMzA1XSAg ICAgICBNaWxscywgRC4sICJOZXR3b3JrIFRpbWUgUHJvdG9jb2wgKFZlcnNpb24gMyk8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uLCBJbXBsZW1lbnRhdGlvbiBhbmQg QW5hbHlzaXMiLCBSRkM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiwgSW1wbGVtZW50YXRpb24gYW5kIEFuYWx5c2lz IiwgUkZDPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgMTMwNSwgTWFyY2ggMTk5Mi48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgMTMwNSwgTWFy Y2ggMTk5Mi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg W1JGQzIxMTldICAgICAgIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZD cyB0byBJbmRpY2F0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkMy MTE5XSAgICAgICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8g SW5kaWNhdGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBC Q1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQs IFJGQyAyMTE5LCBNYXJjaCAxOTk3LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAxMDIiPjwvYT48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICBbUkZDPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MjQzNDwvc3Bhbj5dICAgICAg IE5hcnRlbiwgVC4gYW5kIEguIEFsdmVzdHJhbmQsICJHdWlkZWxpbmVzIGZvciBXcml0aW5n PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFtSRkM8c3BhbiBjbGFzcz0i aW5zZXJ0Ij41MjI2PC9zcGFuPl0gICAgICAgTmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFu ZCwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICBhbiBJ QU5BIENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4gUkZDcyIsIEJDUCAyNiwgUkZDPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgIGFuIElBTkEg Q29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzIiwgQkNQIDI2LCBSRkM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48 YSBuYW1lPSJkaWZmMDEwMyI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAg ICAgICAgICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4yNDM0LCBPY3RvYmVyIDE5OTwvc3Bh bj44LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAg ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+NTIyNiwgTWF5IDIwMDwvc3Bhbj44LjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAx MDQiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRl Ij5bUkZDMzI4MF08L3NwYW4+ICAgICAgIEhvdXNsZXksIFIuLCA8c3BhbiBjbGFzcz0iZGVs ZXRlIj5Qb2xrLCBXLiwgRm9yZCwgVy4sPC9zcGFuPiBhbmQgPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+RC4gU29sbyw8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IDxzcGFuIGNsYXNzPSJpbnNlcnQiPltSRkM1MjgwXSAgICAgICBDb29wZXIsIEQuLCBTYW50 ZXNzb24sIFMuLCBGYXJyZWxsLCBTLiBCb2V5ZW4sIFMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAg ICAgICAgICAgICAgIkludGVybmV0IFguNTA5IFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUg Q2VydGlmaWNhdGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAg ICAgICAgICAgIEhvdXNsZXksIFIuLCBhbmQgPHNwYW4gY2xhc3M9Imluc2VydCI+Vy4gUG9s ayw8L3NwYW4+ICJJbnRlcm5ldCBYLjUwOSBQdWJsaWMgS2V5PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAg ICAgICAgICBhbmQgQ2VydGlmaWNhdGUgUmV2b2NhdGlvbiBMaXN0IChDUkwpIFByb2ZpbGUi LCBSRkM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAg ICAgIEluZnJhc3RydWN0dXJlIENlcnRpZmljYXRlIGFuZCBDZXJ0aWZpY2F0ZSBSZXZvY2F0 aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgICAgICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4zMjgw LDwvc3Bhbj4gQXByaWwgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MjAwMi48L3NwYW4+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICBMaXN0IChD UkwpIFByb2ZpbGUiLCBSRkMgPHNwYW4gY2xhc3M9Imluc2VydCI+NTI4MCw8L3NwYW4+IEFw cmlsIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjIwMDguPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDMzQzNl0gICAgICAgSnVuZ21haWVy LCBBLiwgUmVzY29ybGEsIEUuLCBhbmQgTS4gVHVleGVuLDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIFtSRkMzNDM2XSAgICAgICBKdW5nbWFpZXIsIEEuLCBSZXNjb3Js YSwgRS4sIGFuZCBNLiBUdWV4ZW4sPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgIlRyYW5zcG9y dCBMYXllciBTZWN1cml0eSBvdmVyIFN0cmVhbSBDb250cm9sPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICJUcmFuc3BvcnQgTGF5ZXIgU2Vj dXJpdHkgb3ZlciBTdHJlYW0gQ29udHJvbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgIFRyYW5z bWlzc2lvbiBQcm90b2NvbCIsIFJGQyAzNDM2LCBEZWNlbWJlciAyMDAyLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICBUcmFuc21pc3Npb24g UHJvdG9jb2wiLCBSRkMgMzQzNiwgRGVjZW1iZXIgMjAwMi48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzM3NThdICAgICAgIFN0ZXdhcnQsIFIu LCBSYW1hbGhvLCBNLiwgWGllLCBRLiwgVHVleGVuLCBNLiwgYW5kIFAuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JGQzM3NThdICAgICAgIFN0ZXdhcnQsIFIuLCBS YW1hbGhvLCBNLiwgWGllLCBRLiwgVHVleGVuLCBNLiwgYW5kIFAuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgICAgICAgQ29ucmFkLCAiU3RyZWFtIENvbnRyb2wgVHJhbnNtaXNzaW9uIFByb3RvY29s IChTQ1RQKTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAg ICAgICBDb25yYWQsICJTdHJlYW0gQ29udHJvbCBUcmFuc21pc3Npb24gUHJvdG9jb2wgKFND VFApPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgUGFydGlhbCBSZWxpYWJpbGl0eSBFeHRlbnNp b24iLCBSRkMgMzc1OCwgTWF5IDIwMDQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICAgICAgICAgICAgIFBhcnRpYWwgUmVsaWFiaWxpdHkgRXh0ZW5zaW9uIiwg UkZDIDM3NTgsIE1heSAyMDA0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAxMDUiPjwvYT48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5bUkZDNDM0Nl08L3NwYW4+ICAgICAgIERp ZXJrcywgVC4gYW5kIEUuIFJlc2NvcmxhLCAiVGhlIFRyYW5zcG9ydCBMYXllcjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5bUkZD NTI0Nl08L3NwYW4+ICAgICAgIERpZXJrcywgVC4gYW5kIEUuIFJlc2NvcmxhLCAiVGhlIFRy YW5zcG9ydCBMYXllcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAgU2VjdXJpdHkgKFRMUykg UHJvdG9jb2wgVmVyc2lvbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xLjEiLDwvc3Bhbj4gUkZD IDxzcGFuIGNsYXNzPSJkZWxldGUiPjQzNDYsIEFwcmlsPC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgU2VjdXJpdHkgKFRMUykg UHJvdG9jb2wgVmVyc2lvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xLjIiLDwvc3Bhbj4gUkZD IDxzcGFuIGNsYXNzPSJpbnNlcnQiPjUyNDYsPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj4gICAgICAgICAgICAgICAgICAgMjAwNi48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAg ICAgICBBdWd1c3QgMjAwOC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFtSRkM0MzQ3XSAgICAgICBSZXNjb3JsYSwgRS4gYW5kIE4uIE1v ZGFkdWd1LCAiRGF0YWdyYW0gVHJhbnNwb3J0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgW1JGQzQzNDddICAgICAgIFJlc2NvcmxhLCBFLiBhbmQgTi4gTW9kYWR1Z3Us ICJEYXRhZ3JhbSBUcmFuc3BvcnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICBMYXllciBTZWN1 cml0eSIsIFJGQyA0MzQ3LCBBcHJpbCAyMDA2LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgICAgICAgICAgICAgICBMYXllciBTZWN1cml0eSIsIFJGQyA0MzQ3LCBB cHJpbCAyMDA2LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBbUkZDMzQ5MF0gICAgICAgRmFsdHN0cm9tLCBQLiwgSG9mZm1hbiwgUC4sIGFuZCBBLiBD b3N0ZWxsbyw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDMzQ5MF0g ICAgICAgRmFsdHN0cm9tLCBQLiwgSG9mZm1hbiwgUC4sIGFuZCBBLiBDb3N0ZWxsbyw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICAgICAgICAiSW50ZXJuYXRpb25hbGl6aW5nIERvbWFpbiBOYW1lcyBp biBBcHBsaWNhdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICAgICAgICAgICAgIkludGVybmF0aW9uYWxpemluZyBEb21haW4gTmFtZXMgaW4gQXBwbGlj YXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgKElETkEpIiwgUkZDIDM0OTAsIE1hcmNo IDIwMDMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAg ICAgIChJRE5BKSIsIFJGQyAzNDkwLCBNYXJjaCAyMDAzLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDMzQ5Ml0gICAgICAgQ29zdGVsbG8sIEEu LCAiUHVueWNvZGU6IEEgQm9vdHN0cmluZyBlbmNvZGluZyBvZjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkMzNDkyXSAgICAgICBDb3N0ZWxsbywgQS4sICJQdW55 Y29kZTogQSBCb290c3RyaW5nIGVuY29kaW5nIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAg VW5pY29kZSBmb3IgSW50ZXJuYXRpb25hbGl6ZWQgRG9tYWluIE5hbWVzIGluPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgIFVuaWNvZGUgZm9y IEludGVybmF0aW9uYWxpemVkIERvbWFpbiBOYW1lcyBpbjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHIgYmdj b2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDI2Ij48c21hbGw+c2tp cHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgNjAsIGxpbmUgNDM8L2VtPjwv YT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yMjYiPjxzbWFsbD5za2lwcGlu ZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA2MiwgbGluZSA0MzwvZW0+PC9hPjwv dGg+PHRkPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgRXhwb3J0 IiwgUkZDIDUxMDIsIEphbnVhcnkgMjAwOC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgICAgICAgICAgRXhwb3J0IiwgUkZDIDUxMDIsIEphbnVhcnkgMjAw OC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1RDUF0g ICAgICAgICAgIFBvc3RlbCwgSi4sICJUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbCIs IFNURCA3LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtUQ1BdICAgICAg ICAgICBQb3N0ZWwsIEouLCAiVHJhbnNtaXNzaW9uIENvbnRyb2wgUHJvdG9jb2wiLCBTVEQg Nyw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICAgICAgICAgICAgICBSRkMgNzkzLCBTZXB0ZW1iZXIgMTk4MS48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgUkZDIDc5 MywgU2VwdGVtYmVyIDE5ODEuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFtVRFBdICAgICAgICAgICBQb3N0ZWwsIEouLCAiVXNlciBEYXRhZ3JhbSBQ cm90b2NvbCIsIFNURCA2LCBSRkMgNzY4LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFtVRFBdICAgICAgICAgICBQb3N0ZWwsIEouLCAiVXNlciBEYXRhZ3JhbSBQcm90 b2NvbCIsIFNURCA2LCBSRkMgNzY4LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAx OTgwLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAg ICBBdWd1c3QgMTk4MC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+SW5mb3JtYXRpdmUgUmVmZXJlbmNlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPkluZm9ybWF0aXZlIFJlZmVyZW5jZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMTA2Ij48L2E+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+W0lQRklYLUFSQ0hdICAgIFNh ZGFzaXZhbiwgRy4sIEJyb3dubGVlLCBOLiwgQ2xhaXNlLCBCLiwgYW5kIEouPC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRl bGV0ZSI+ICAgICAgICAgICAgICAgICAgIFF1aXR0ZWssICJBcmNoaXRlY3R1cmUgTW9kZWwg Zm9yIElQIEZsb3cgSW5mb3JtYXRpb248L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICAgICAgICAgICAg ICAgRXhwb3J0IiwgV29yayBpbiBQcm9ncmVzcywgU2VwdGVtYmVyIDIwMDYuPC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRl bGV0ZSI+PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgW0lQRklYLUFTXSAgICAgIFpzZWJ5LCBULiwgQm9z Y2hpLCBFLiwgQnJvd25sZWUsIE4uLCBhbmQgQi4gQ2xhaXNlLDwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAg ICAgICAgICAgICAgICAgICAiSVBGSVggQXBwbGljYWJpbGl0eSIsIFdvcmsgaW4gUHJvZ3Jl c3MsIEp1bmUgMjAwNy48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgW1BFTl0gICAgICAgICAgIElBTkEgUHJpdmF0ZSBFbnRlcnByaXNl IE51bWJlcnMgcmVnaXN0cnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBb UEVOXSAgICAgICAgICAgSUFOQSBQcml2YXRlIEVudGVycHJpc2UgTnVtYmVycyByZWdpc3Ry eTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVu dHMvZW50ZXJwcmlzZS1udW1iZXJzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICAgICAgICAgICAgICBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2Vu dGVycHJpc2UtbnVtYmVycy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgW1JGQzE5NDhdICAgICAgIEJlbGxvdmluLCBTLiwgIkRlZmVuZGluZyBBZ2Fp bnN0IFNlcXVlbmNlIE51bWJlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFtSRkMxOTQ4XSAgICAgICBCZWxsb3ZpbiwgUy4sICJEZWZlbmRpbmcgQWdhaW5zdCBTZXF1 ZW5jZSBOdW1iZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICBBdHRhY2tzIiwgUkZDIDE5NDgs IE1heSAxOTk2LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgICAgICBBdHRhY2tzIiwgUkZDIDE5NDgsIE1heSAxOTk2LjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDMjU3OV0gICAgICAgTWNDbG9naHJp ZSwgSy4sIFBlcmtpbnMsIEQuLCBhbmQgSi4gU2Nob2Vud2FlbGRlciw8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDMjU3OV0gICAgICAgTWNDbG9naHJpZSwgSy4s IFBlcmtpbnMsIEQuLCBhbmQgSi4gU2Nob2Vud2FlbGRlciw8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAg ICAgICAiVGV4dHVhbCBDb252ZW50aW9ucyBmb3IgU01JdjIiLCBTVEQgNTgsIFJGQyAyNTc5 LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAi VGV4dHVhbCBDb252ZW50aW9ucyBmb3IgU01JdjIiLCBTVEQgNTgsIFJGQyAyNTc5LDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgICAgICAgIEFwcmlsIDE5OTkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgICAgICAgICAgICAgIEFwcmlsIDE5OTkuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAgPHRyIGJnY29sb3I9ImdyYXki Pjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWwyNyI+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDYxLCBsaW5lIDIzPC9lbT48L2E+PC90aD48dGg+ IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjI3Ij48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdl IGF0PC9zbWFsbD48ZW0+IHBhZ2UgNjMsIGxpbmUgMjM8L2VtPjwvYT48L3RoPjx0ZD48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICJSZXF1aXJlbWVudHMgZm9y IElQIEZsb3cgSW5mb3JtYXRpb24gRXhwb3J0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAgICAgICAgICAgICJSZXF1aXJlbWVudHMgZm9yIElQIEZsb3cgSW5m b3JtYXRpb24gRXhwb3J0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgKElQRklYKSIsIFJGQyAz OTE3LCBPY3RvYmVyIDIwMDQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgICAgICAgICAgICAgIChJUEZJWCkiLCBSRkMgMzkxNywgT2N0b2JlciAyMDA0LjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDMzU1MF0gICAg ICAgU2NodWx6cmlubmUsIEguLCBDYXNuZXIsIFMuLCBGcmVkZXJpY2ssIFIuLCBhbmQgVi48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDMzU1MF0gICAgICAgU2No dWx6cmlubmUsIEguLCBDYXNuZXIsIFMuLCBGcmVkZXJpY2ssIFIuLCBhbmQgVi48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgICAgICBKYWNvYnNvbiwgIlJUUDogQSBUcmFuc3BvcnQgUHJvdG9jb2wg Zm9yIFJlYWwtVGltZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAg ICAgICAgICAgICBKYWNvYnNvbiwgIlJUUDogQSBUcmFuc3BvcnQgUHJvdG9jb2wgZm9yIFJl YWwtVGltZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgIEFwcGxpY2F0aW9ucyIsIFNURCA2NCwg UkZDIDM1NTAsIEp1bHkgMjAwMy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICAgICAgICAgICAgICAgQXBwbGljYXRpb25zIiwgU1REIDY0LCBSRkMgMzU1MCwgSnVs eSAyMDAzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBb UkZDMzk1NF0gICAgICAgQ2xhaXNlLCBCLiwgRWQuLCAiQ2lzY28gU3lzdGVtcyBOZXRGbG93 IFNlcnZpY2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JGQzM5NTRd ICAgICAgIENsYWlzZSwgQi4sIEVkLiwgIkNpc2NvIFN5c3RlbXMgTmV0RmxvdyBTZXJ2aWNl czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgICAgICAgIEV4cG9ydCBWZXJzaW9uIDkiLCBSRkMgMzk1NCwg T2N0b2JlciAyMDA0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAg ICAgICAgICAgICBFeHBvcnQgVmVyc2lvbiA5IiwgUkZDIDM5NTQsIE9jdG9iZXIgMjAwNC48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMTA3Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPltSRkM1MTAzXSAg ICAgICBUcmFtbWVsLCBCLiwgYW5kIEUuIEJvc2NoaSwgIkJpZGlyZWN0aW9uYWwgRmxvdzwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICBFeHBvcnQgVXNpbmcgSVAgRmxvdyBJ bmZvcm1hdGlvbiBFeHBvcnQgKElQRklYKSIsIFJGQzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAg ICAgICAgICAgICA1MTAzLCBKYW51YXJ5IDIwMDguPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgW1JGQzUxNTNdICAgICAgIEJvc2NoaSwgRS4sIE1hcmssIEwuLCBRdWl0dGVr IEouLCBhbmQgUC4gQWl0a2VuLCAiSVA8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAg ICAgRmxvdyBJbmZvcm1hdGlvbiBFeHBvcnQgKElQRklYKSBJbXBsZW1lbnRhdGlvbjwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICBHdWlkZWxpbmVzIiwgUkZDNTE1MywgQXBy aWwgMjAwODwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFtSRkM1NDcwXSAgICBT YWRhc2l2YW4sIEcuLCBCcm93bmxlZSwgTi4sIENsYWlzZSwgQi4sIGFuZCBKLiBRdWl0dGVr LDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICAiQXJjaGl0ZWN0dXJlIGZvciBJ UCBGbG93IEluZm9ybWF0aW9uIEV4cG9ydCIsPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAg ICAgICAgIFJGQzU0NzAsIE1hcmNoIDIwMDkuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgW1JGQzU0NzJdICAgICAgWnNlYnksIFQuLCBCb3NjaGksIEUuLCBCcm93bmxlZSwg Ti4sIGFuZCBCLiBDbGFpc2UsPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAgICAgICJJ UCBGbG93IEluZm9ybWF0aW9uIEV4cG9ydCAoSVBGSVgpIEFwcGxpY2FiaWxpdHkiLDwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICBSRkM1NDcyLCBNYXJjaCAyMDA5Ljwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFtSRkM1NDcxXSAgICAgIFNjaG1vbGwsIEMu LCBBaXRrZW4sIFAuLCBhbmQgQi4gQ2xhaXNlLCAiR3VpZGVsaW5lczwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgICAgICAgICAgICAgICAgICBmb3IgSVAgRmxvdyBJbmZvcm1hdGlvbiBFeHBvcnQgKElQ RklYKSBUZXN0aW5nIiw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAgICAgUkZDNTQ3 MSwgTWFyY2ggMjAwOTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFtSRkM1NDcz XSAgICAgIEJvc2NoaSwgRS4sIE1hcmssIEwuLCBhbmQgQi4gQ2xhaXNlLCAiUmVkdWNpbmc8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAgICAgUmVkdW5kYW5jeSBpbiBJUCBGbG93 IEluZm9ybWF0aW9uIEV4cG9ydCAoSVBGSVgpIGFuZDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAg ICAgICAgICAgICBQYWNrZXQgU2FtcGxpbmcgKFBTQU1QKSBSZXBvcnRzIiwgUkZDNTQ3Mywg TWFyY2ggMjAwOTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFtSRkM1NjEwXSAg ICAgIEJvc2NoaSwgRS4sIFRyYW1tZWxsLCBCLiwgTWFyaywgTC4sIGFuZCBULiBac2VieSw8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAgICAgIkV4cG9ydGluZyBUeXBlIEluZm9y bWF0aW9uIGZvciBJUCBGbG93IEluZm9ybWF0aW9uPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAg ICAgICAgICAgIEV4cG9ydCAoSVBGSVgpIEluZm9ybWF0aW9uIEVsZW1lbnRzIiwgSnVseSAy MDA5Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFtSRkM1ODE1XSAgICAgIERp ZXR6LCBULiwgS29iYXlhc2hpLCBBLiwgQ2xhaXNlLCBCLiwgYW5kIEcuIE11ZW56LDwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICAiRGVmaW5pdGlvbnMgb2YgTWFuYWdlZCBP YmplY3RzIGZvciBJUCBGbG93PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAgICAgIElu Zm9ybWF0aW9uIEV4cG9ydCAiLCBBcHJpbCAyMDEwLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgIFtSRkM2MDgzXSAgICAgIFR1ZXhlbiwgTS4sIFNlZ2dlbG1hbiwgUi4gYW5k IEUuIFJlc2NvbGEsICJEYXRhZ3JhbTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICAg ICBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKERUTFMpIGZvciBTdHJlYW0gQ29udHJvbDwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICBUcmFuc21pc3Npb24gUHJvdG9jb2wg KFNDVFApIiwgUkZDNjA4MywgSmFudWFyeSAyMDExLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgIFtSRkM2MzEzXSAgICAgIENsYWlzZSwgQi4sIERoYW5kYXBhbmksIEcuLCBB aXRrZW4sIFAsIGFuZCBTLiBZYXRlcyw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAg ICAgIkV4cG9ydCBvZiBTdHJ1Y3R1cmVkIERhdGEgaW4gSVAgRmxvdyBJbmZvcm1hdGlvbjwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICBFeHBvcnQgKElQRklYKSIsIFJGQzYz MTMsIEp1bHkgMjAxMS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbSUVFRS43NTQuMTk4NV0gSW5z dGl0dXRlIG9mIEVsZWN0cmljYWwgYW5kIEVsZWN0cm9uaWNzIEVuZ2luZWVycyw8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbSUVFRS43NTQuMTk4NV0gSW5zdGl0dXRl IG9mIEVsZWN0cmljYWwgYW5kIEVsZWN0cm9uaWNzIEVuZ2luZWVycyw8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAg ICAgICAgICAgICAiU3RhbmRhcmQgZm9yIEJpbmFyeSBGbG9hdGluZy1Qb2ludCBBcml0aG1l dGljIiwgSUVFRTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgICAgICAiU3RhbmRhcmQgZm9yIEJpbmFyeSBGbG9hdGluZy1Qb2ludCBBcml0aG1ldGlj IiwgSUVFRTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgIFN0YW5kYXJkIDc1NCwgQXVndXN0IDE5 ODUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAg IFN0YW5kYXJkIDc1NCwgQXVndXN0IDE5ODUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDEwOCI+PC9hPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPltkdGxzLWZvci1zY3RwXSBU dWV4ZW4sIE0uPC9zcGFuPiBhbmQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+RS4gUmVzY29sYSwg IkRhdGFncmFtIFRyYW5zcG9ydCBMYXllcjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+W0lQRklYLUNPTkZdICAgIE11 ZW56LCBHLiwgQ2xhaXNlLCBCLiw8L3NwYW4+IGFuZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5Q LiBBaXRrZW4sICJDb25maWd1cmF0aW9uPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs ZXRlIj4gICAgICAgICAgICAgICAgICAgU2VjdXJpdHk8L3NwYW4+IGZvciA8c3BhbiBjbGFz cz0iZGVsZXRlIj5TdHJlYW0gQ29udHJvbCBUcmFuc21pc3Npb24gUHJvdG9jb2wiLDwvc3Bh bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgICAgICAgICAgICAgICAgIERhdGEgTW9kZWw8L3NwYW4+IGZvciA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij5JUEZJWCBhbmQgUFNBTVAiLDwvc3Bhbj4gV29yayBpbiBQcm9ncmVzcyw8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgICAgICAgICAgICAgICAgIFdvcmsgaW4gUHJvZ3Jlc3MsIDxzcGFuIGNsYXNz PSJkZWxldGUiPk5vdmVtYmVyIDIwMDcuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+SnVs eSAyMDExLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+QWNrbm93bGVkZ21lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+QWNr bm93bGVkZ21lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFdlIHdvdWxkIGxpa2UgdG8gdGhhbmsgdGhlIGZvbGxvd2luZyBwZXJzb25zOiBHYW5l c2ggU2FkYXNpdmFuIGZvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFdl IHdvdWxkIGxpa2UgdG8gdGhhbmsgdGhlIGZvbGxvd2luZyBwZXJzb25zOiBHYW5lc2ggU2Fk YXNpdmFuIGZvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgaGlzIHNpZ25pZmljYW50IGNvbnRyaWJ1dGlvbiBkdXJpbmcg dGhlIGluaXRpYWwgcGhhc2VzIG9mIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGhpcyBzaWduaWZpY2FudCBjb250cmlidXRpb24gZHVyaW5nIHRoZSBpbml0aWFs IHBoYXNlcyBvZiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHByb3RvY29sIHNwZWNpZmljYXRpb247IEp1ZXJnZW4g UXVpdHRlayBmb3IgdGhlIGNvb3JkaW5hdGlvbiBqb2I8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBwcm90b2NvbCBzcGVjaWZpY2F0aW9uOyBKdWVyZ2VuIFF1aXR0ZWsg Zm9yIHRoZSBjb29yZGluYXRpb24gam9iPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3aXRoaW4gSVBGSVggYW5kIFBTQU1Q OyBOZXZpbCBCcm93bmxlZSwgRGF2ZSBQbG9ua2EsIFBhdWwgQWl0a2VuLCBhbmQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3aXRoaW4gSVBGSVggYW5kIFBTQU1QOyBO ZXZpbCBCcm93bmxlZSwgRGF2ZSBQbG9ua2EsIFBhdWwgQWl0a2VuLCBhbmQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFu ZHJldyBKb2huc29uIGZvciB0aGUgdGhvcm91Z2ggcmV2aWV3czsgUmFuZGFsbCBTdGV3YXJ0 IGFuZCBQZXRlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEFuZHJldyBK b2huc29uIGZvciB0aGUgdGhvcm91Z2ggcmV2aWV3czsgUmFuZGFsbCBTdGV3YXJ0IGFuZCBQ ZXRlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgTGVpIGZvciB0aGVpciBTQ1RQIGV4cGVydGlzZSBhbmQgY29udHJpYnV0 aW9uczsgTWFydGluIERqZXJuYWVzIGZvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIExlaSBmb3IgdGhlaXIgU0NUUCBleHBlcnRpc2UgYW5kIGNvbnRyaWJ1dGlvbnM7 IE1hcnRpbiBEamVybmFlcyBmb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBmaXJzdCBlc3NheSBvbiB0aGUgU0NU UCBzZWN0aW9uOyBNaWNoYWVsIEJlaHJpbmdlciBhbmQgRXJpYzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBmaXJzdCBlc3NheSBvbiB0aGUgU0NUUCBzZWN0aW9u OyBNaWNoYWVsIEJlaHJpbmdlciBhbmQgRXJpYzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHIgYmdjb2xvcj0i Z3JheSI+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDI4Ij48c21hbGw+c2tpcHBpbmcg dG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgNjMsIGxpbmUgNDwvZW0+PC9hPjwvdGg+ PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXIyOCI+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGVtPiBsaW5lIDI5MzI8L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgRU1haWw6IFRob21hcy5EaWV0ekBudy5uZWNsYWIuZXU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBFTWFpbDogVGhvbWFzLkRpZXR6QG53 Lm5lY2xhYi5ldTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBCcmlhbiBILiBUcmFtbWVsbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IEJyaWFuIEguIFRyYW1tZWxsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDRVJUIE5ldHdvcmsgU2l0dWF0aW9uYWwgQXdh cmVuZXNzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ0VSVCBOZXR3b3Jr IFNpdHVhdGlvbmFsIEF3YXJlbmVzczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU29mdHdhcmUgRW5naW5lZXJpbmcgSW5z dGl0dXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU29mdHdhcmUgRW5n aW5lZXJpbmcgSW5zdGl0dXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA0NTAwIEZpZnRoIEF2ZW51ZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDQ1MDAgRmlmdGggQXZlbnVlPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQaXR0 c2J1cmdoLCBQQSAxNTIxMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBp dHRzYnVyZ2gsIFBBIDE1MjEzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBVbml0ZWQgU3RhdGVzPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgVW5pdGVkIFN0YXRlczwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUGhvbmU6ICsxIDQx MiAyNjggOTc0ODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBob25lOiAr MSA0MTIgMjY4IDk3NDg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEVNYWlsOiBiaHRAY2VydC5vcmc8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBFTWFpbDogYmh0QGNlcnQub3JnPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEg bmFtZT0iZGlmZjAxMDkiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj5GdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQ8L3NwYW4+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRl Ij48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj4gICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA4 KS48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBUaGlzIGRvY3VtZW50IGlzIHN1 YmplY3QgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9uczwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJk ZWxldGUiPiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRo IHRoZXJlaW4sIHRoZSBhdXRob3JzPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgcmV0YWluIGFsbCB0aGVp ciByaWdodHMuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgVGhpcyBkb2N1bWVu dCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9u IGFuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNw YW4gY2xhc3M9ImRlbGV0ZSI+ICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9S LCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTPC9zcGFuPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAg T1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSwgVEhF IElFVEYgVFJVU1QgQU5EPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgVEhFIElOVEVSTkVUIEVOR0lORUVS SU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1M8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj4gICBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFO WSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0Y8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBUSEUgSU5GT1JN QVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJ RUQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj4gICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBG SVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj48L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj5JbnRlbGxlY3R1YWwgUHJvcGVydHk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj48L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs ZXRlIj4gICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlk aXR5IG9yIHNjb3BlIG9mIGFueTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIEludGVsbGVjdHVhbCBQcm9w ZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bzwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNs YXNzPSJkZWxldGUiPiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBv ZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICB0aGlzIGRv Y3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCBy aWdodHM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxl OyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXM8L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBt YWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRz LiAgSW5mb3JtYXRpb248L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRo IHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0 ZSI+ICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuPC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+PC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9 ImRlbGV0ZSI+ICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRG IFNlY3JldGFyaWF0IGFuZCBhbnk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBhc3N1cmFuY2VzIG9mIGxp Y2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9 ImRlbGV0ZSI+ICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBv ciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgc3VjaCBwcm9w cmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXM8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj4gICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRG IG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBodHRwOi8vd3d3 LmlldGYub3JnL2lwci48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBUaGUgSUVU RiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRp b24gYW55PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQg YXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeTwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHJp Z2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRv IGltcGxlbWVudDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRk cmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQ8L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBp ZXRmLWlwckBpZXRmLm9yZy48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQoN CiAgICAgPHRyPjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQ+PC90ZD48L3RyPg0KICAgICA8dHIgYmdjb2xvcj0i Z3JheSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiPjxhIG5hbWU9ImVuZCI+Jm5i c3A7RW5kIG9mIGNoYW5nZXMuIDEwOSBjaGFuZ2UgYmxvY2tzLiZuYnNwOzwvYT48L3RoPjwv dHI+DQogICAgIDx0ciBjbGFzcz0ic3RhdHMiPjx0ZD48L3RkPjx0aD48aT4zMDkgbGluZXMg Y2hhbmdlZCBvciBkZWxldGVkPC9pPjwvdGg+PHRoPjxpPiA8L2k+PC90aD48dGg+PGk+NDI5 IGxpbmVzIGNoYW5nZWQgb3IgYWRkZWQ8L2k+PC90aD48dGQ+PC90ZD48L3RyPg0KICAgICA8 dHI+PHRkIGNvbHNwYW49IjUiIGNsYXNzPSJzbWFsbCIgYWxpZ249ImNlbnRlciI+PGJyPlRo aXMgaHRtbCBkaWZmIHdhcyBwcm9kdWNlZCBieSByZmNkaWZmIDEuMzkuIFRoZSBsYXRlc3Qg dmVyc2lvbiBpcyBhdmFpbGFibGUgZnJvbSA8YSBocmVmPSJodHRwOi8vd3d3LnRvb2xzLmll dGYub3JnL3Rvb2xzL3JmY2RpZmYvIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZj ZGlmZi88L2E+IDwvdGQ+PC90cj4NCiAgIDwvdGJvZHk+PC90YWJsZT4NCiAgIA0KICAgDQo8 L2JvZHk+PC9odG1sPg== --------------000706050905040209050406-- From trammell@tik.ee.ethz.ch Tue Sep 20 05:30:18 2011 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 1567821F8C66 for ; Tue, 20 Sep 2011 05:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 hZS70enxsN6a for ; Tue, 20 Sep 2011 05:30:15 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id DB68321F8BB5 for ; Tue, 20 Sep 2011 05:30:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 06453D930F; Tue, 20 Sep 2011 14:32:39 +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 RJ1wduVOx14y; Tue, 20 Sep 2011 14:32:38 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (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 937B7D930B; Tue, 20 Sep 2011 14:32:38 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4E786FD4.2010901@cisco.com> Date: Tue, 20 Sep 2011 14:32:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110920103441.5003.50588.idtracker@ietfa.amsl.com> <4E786FD4.2010901@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1084) Cc: Thomas Dietz , Simon Leinen , "ipfix@ietf.org" Subject: Re: [IPFIX] New Version Notification for draft-claise-ipfix-protocol-rfc5101bis-00.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, 20 Sep 2011 12:30:18 -0000 Hi, Benoit, Two minor personal changes:=20 1. Ensure that my name is spelled correctly everywhere (found at least = one "Trammel" in the references, 5103) 2. My address is now: Brian Trammell Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 632 70 13 EMail: trammell@tik.ee.ethz.ch Otherwise, agree that all presently filed errata are addressed. See my other message to you re: 3490. For 1305, replace with 5905 but note that we use the 64-bit "timestamp" = format, as opposed to either the 32- or 128-bit formats. (May want to = note that this will require the data type to be updated before 2038) Additionally, I believe that a resolution to the template lifetime = mechanism for UDP is missing, and given that the present specification = is questionably interoperable, that such certain strategies for = resolution would be within scope of 5101bis. This would be more or less = my suggested variant of "Solution 3" in = http://www.ietf.org/mail-archive/web/ipfix/current/msg06047.html: = 5655-style template management everywhere with infinite timeout, with an = explicit note that doing this on UDP is fraught with peril. Not sure what the right _administrative_ way to do this would be though: = do we need to file a technical errata on 5101 that we can then address = in 5101bis? Best regards, Brian On Sep 20, 2011, at 12:49 PM, Benoit Claise wrote: > Dear all, >=20 > Here is a new draft, to advance RFC 5101 to the next stage of = standardization on the standards track, as foreseen by the future = charter. >=20 > DONE: > Errata ID: 1655 (technical) > Errata ID: 2791 (technical) > Errata ID: 2814 (editorial)=20 > Errata ID: 1818 (editorial) > Errata ID: 2792 (editorial) > Errata ID: 2888 (editorial) > Errata ID: 2889 (editorial) > Errata ID: 2890 (editorial) > Errata ID: 2891 (editorial) > Errata ID: 2892 (editorial) > Errata ID: 2903 (editorial) > Errata ID: 2761 (editorial) > Errata ID: 2762 (editorial) > Errata ID: 2763 (editorial) > Errata ID: 2764 (editorial) > Errata ID: 2852 (editorial) > Errata ID: 2857 (editorial) >=20 > Section 8: "a new sampling rate" has been removed from the list = of > examples that requires a new Template.=20 >=20 > If the measurement parameters change such that a new Template is = =20 > required, the Template MUST be withdrawn (using a Template Withdraw = =20 > Message and a new Template definition) or an unused Template ID = MUST=20 > be used. Examples of the measurement changes are: a new sampling =20= > rate, a new Flow expiration process, a new filtering definition, = etc. >=20 > Updated the references >=20 > Updated the "Document overview" section. >=20 > Template and UDP: included the proposal at > http://www.ietf.org/mail-archive/web/ipfix/current/msg06051.html >=20 >=20 > TO DO: > "time first flow dropped" and "time last flow dropped" = inconsistency. See the discussion on the list. > Replace the RFC5102 by RFC5102bis, when the draft will be = posted. > Replace the RFC5815 by RFC5815bis, when the draft will be = posted. > NTP RFC 1305 is obsoleted by RFC5905. Check if the format is the = similar before updating the reference. > IDNA RFC 3490 is obsoleted by RFC5890 and RFC5891. Double-check >=20 > Did I miss anything, which is within the boundary of what we can = change for the next level of standardization? >=20 > For your convenience, a diff between RFC5101 and this draft is = included. >=20 > Regards, Benoit. >=20 > -------- Original Message -------- > Subject: New Version Notification for = draft-claise-ipfix-protocol-rfc5101bis-00.txt > Date: Tue, 20 Sep 2011 03:34:41 -0700 > From: internet-drafts@ietf.org > To: bclaise@cisco.com > CC: bclaise@cisco.com >=20 > A new version of I-D, draft-claise-ipfix-protocol-rfc5101bis-00.txt = has been successfully submitted by Benoit Claise and posted to the IETF = repository. >=20 > Filename: draft-claise-ipfix-protocol-rfc5101bis > Revision: 00 > Title: Specification of the IP Flow Information eXport = (IPFIX) Protocol for the Exchange of IP Traffic Flow Information > Creation date: 2011-09-20 > WG ID: Individual Submission > Number of pages: 66 >=20 > Abstract: > This document specifies the IP Flow Information Export (IPFIX) > protocol that serves for transmitting IP Traffic Flow information > over the network. In order to transmit IP Traffic Flow information > from an Exporting Process to an information Collecting Process, a > common representation of flow data and a standard means of > communicating them is required. This document describes how the > IPFIX Data and 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. >=20 > = =20 >=20 >=20 > The IETF Secretariat >=20 > From bclaise@cisco.com Tue Sep 20 07:17:03 2011 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 AFFEB21F8A56 for ; Tue, 20 Sep 2011 07:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.121, 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 sTQYZdtWRTWI for ; Tue, 20 Sep 2011 07:17:02 -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 EC0AD21F87C2 for ; Tue, 20 Sep 2011 07:17:01 -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 p8KEJPJt007648 for ; Tue, 20 Sep 2011 16:19:25 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8KEJO3v024601 for ; Tue, 20 Sep 2011 16:19:24 +0200 (CEST) Message-ID: <4E78A0EC.9030003@cisco.com> Date: Tue, 20 Sep 2011 16:19:24 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <4A8015DF.6040903@cisco.com> In-Reply-To: <4A8015DF.6040903@cisco.com> X-Forwarded-Message-Id: <4A8015DF.6040903@cisco.com> Content-Type: multipart/alternative; boundary="------------060508030409000901020108" Subject: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 20 Sep 2011 14:17:03 -0000 This is a multi-part message in MIME format. --------------060508030409000901020108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, [this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt, TO DO -> "time first flow dropped" and "time last flow dropped" inconsistency. See the discussion on the list.] Paul Aitken discovered this issue., From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template time first flow dropped The timestamp of the first _Flow _was dropped by the Metering Process. For this timestamp, any of the "flowStart" timestamp Information Elements flowStartMilliseconds, flowStartMicroseconds, flowStartNanoseconds, and flowStartDeltaMicroseconds can be used. time last flow dropped The timestamp of the last _IP packet_ that was ignored by the Metering Process. For this timestamp, any of the "flowEnd" timestamp Information Elements flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds can be used. Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that". Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter? Here is a proposal for 4.2 and 4.3. The underlined parts are new 4.2. The Metering Process Reliability Statistics Option Template The Metering Process Reliability Option Template specifies the structure of a Data Record for reporting lack of reliability in the Metering Process. It SHOULD contain the following Information Elements that are defined in [RFC5102 ]: observationDomainId An identifier of an Observation Domain that is locally unique to the Exporting Process. This Information Element MUST be defined as a Scope Field. _ meteringProcessId (*) The identifier of the Metering Process for which lack of reliability is reported. There This Information Element MUST be defined as a Scope Field._ ignoredPacketTotalCount The total number of IP packets that the Metering Process did not process. ignoredOctetTotalCount The total number of octets in observed IP packets that the Metering Process did not process. time first_packet_ignored The timestamp of the first IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowStart" timestamp Information Elements flowStartMilliseconds, flowStartMicroseconds, flowStartNanoseconds, and flowStartDeltaMicroseconds can be used. time last_packet_ignored The timestamp of the last IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowEnd" timestamp Information Elements flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds can be used. 4.3. The Exporting Process Reliability Statistics Option Template The Exporting Process Reliability Option Template specifies the structure of a Data Record for reporting lack of reliability in the Exporting process. It SHOULD contain the following Information Elements that are defined in [RFC5102 ]: Exporting Process ID The identifier of the Exporting Process for which lack of reliability is reported. There are three Information Elements specified in [RFC5102 ] that can be used for this purpose: exporterIPv4Address, exporterIPv6Address, or exportingProcessId. This Information Element MUST be defined as a Scope Field. notSentFlowTotalCount The total number of Flows that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process. notSentPacketTotalCount The total number of packets in Flow Records that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process. notSentOctetTotalCount The total number of octets in packets in Flow Records that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process. time first flow dropped _ The time at which the first Flow Record was dropped by the__Exporting Process._ For this timestamp, any of the "flowStart" timestamp Information Elements flowStartMilliseconds, flowStartMicroseconds, flowStartNanoseconds, and flowStartDeltaMicroseconds can be used. time last flow dropped _The time at which the last Flow Record was dropped by the Exporting Process_. For this timestamp, any of the "flowEnd" timestamp Information Elements flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds can be used. The Exporting Process SHOULD export the Data Record specified by the Exporting Process Reliability Statistics Option Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable. (*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id 1. there is a meteringProcessId in IPFIX IANA while there is no cache id 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId? [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name. From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process. If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below 4.3. Cache Class +-----------------------------------+ | Cache | +-----------------------------------+ 1 +------------------+ | name |<>--------| immediateCache/ | | dataRecords {readOnly} | | timeoutCache/ | | cacheDiscontinuityTime {readOnly} | | naturalCache/ | | | | permanentCache | | | +------------------+ | | | | 0..* +------------------+ | |--------->| ExportingProcess | +-----------------------------------+ +------------------+ Figure 12: Cache class What do you think? Do you see another way? Regards, Paul & Benoit. --------------060508030409000901020108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

[this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO DO -> "time first flow dropped" and "time last flow dropped" inconsistency.  See the discussion on the list.]

Paul Aitken discovered this issue.,

From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template

time first flow dropped
                        The timestamp of the first Flow was dropped by
                        the Metering Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

time last flow dropped
                        The timestamp of the last IP packet that was
                        ignored by the Metering Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.


Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o

Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".

Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter?

Here is a proposal for 4.2 and 4.3. The underlined parts are new

4.2.  The Metering Process Reliability Statistics Option Template


   The Metering Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.

    
   meteringProcessId (*)
                           The identifier of the Metering Process for
                           which lack of reliability is reported.  There
                           This Information Element MUST be defined as a 
                           Scope Field.

   ignoredPacketTotalCount
                           The total number of IP packets that the
                           Metering Process did not process.

   ignoredOctetTotalCount
                           The total number of octets in observed IP
                           packets that the Metering Process did not
                           process.

   time first packet ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last packet ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.



4.3.  The Exporting Process Reliability Statistics Option Template

   The Exporting Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Exporting process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.

   notSentFlowTotalCount
                        The total number of Flows that were generated by
                        the Metering Process and dropped by the Metering
                        Process or by the Exporting Process instead of
                        being sent to the Collecting Process.

   notSentPacketTotalCount
                        The total number of packets in Flow Records that
                        were generated by the Metering Process and
                        dropped by the Metering Process or by the
                        Exporting Process instead of being sent to the
                        Collecting Process.

   notSentOctetTotalCount
                        The total number of octets in packets in Flow
                        Records that were generated by the Metering
                        Process and dropped by the Metering Process or
                        by the Exporting Process instead of being sent
                        to the Collecting Process.

   time first flow dropped
                        The time at which the first Flow Record was dropped by
                        the Exporting Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

   time last flow dropped
                        The time at which the last Flow Record was
                        dropped by the Exporting Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.

   The Exporting Process SHOULD export the Data Record specified by the
   Exporting Process Reliability Statistics Option Template on a regular
   basis or based on some export policy.  This periodicity or export
   policy SHOULD be configurable.




(*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id
1. there is a meteringProcessId in IPFIX IANA while there is no cache id
2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId?
    [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
    From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process.
    If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below
4.3.  Cache Class

    +-----------------------------------+
    | Cache                             |
    +-----------------------------------+        1 +------------------+
    | name                              |<>--------| immediateCache/  |
    | dataRecords {readOnly}            |          | timeoutCache/    |
    | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
    |                                   |          | permanentCache   |
    |                                   |          +------------------+
    |                                   |
    |                                   |     0..* +------------------+
    |                                   |--------->| ExportingProcess |
    +-----------------------------------+          +------------------+

                          Figure 12: Cache class
What do you think? Do you see another way?

Regards, Paul & Benoit.
--------------060508030409000901020108-- From andrewf@plixer.com Tue Sep 20 12:52:34 2011 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 341961F0C40 for ; Tue, 20 Sep 2011 12:52:34 -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=[AWL=-0.000, 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 3+hOVtJNEBKn for ; Tue, 20 Sep 2011 12:52:32 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 8348C1F0C41 for ; Tue, 20 Sep 2011 12:52:32 -0700 (PDT) Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Sep 2011 15:54:59 -0400 Message-ID: <4E78EF92.1070107@plixer.com> Date: Tue, 20 Sep 2011 15:54:58 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110914 Thunderbird/9.0a1 MIME-Version: 1.0 To: ipfix@ietf.org References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> In-Reply-To: <4E78A0EC.9030003@cisco.com> Content-Type: multipart/alternative; boundary="------------050800020806060902090105" X-OriginalArrivalTime: 20 Sep 2011 19:54:59.0014 (UTC) FILETIME=[2D608E60:01CC77CF] Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 20 Sep 2011 19:52:34 -0000 This is a multi-part message in MIME format. --------------050800020806060902090105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/20/2011 10:19 AM, Benoit Claise wrote: > Dear all, > > [this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt, > TO DO -> "time first flow dropped" and "time last flow dropped" > inconsistency. See the discussion on the list.] > > Paul Aitken discovered this issue., > > [ snip ] > > > 4.2. The Metering Process Reliability Statistics Option Template > > > > The Metering Process Reliability Option Template specifies the > structure of a Data Record for reporting lack of reliability in the > Metering Process. It SHOULD contain the following Information > Elements that are defined in [RFC5102 ]: > > observationDomainId > An identifier of an Observation Domain that > is locally unique to the Exporting Process. > This Information Element MUST be defined as a > Scope Field. > > > _ meteringProcessId (*) > The identifier of the Metering Process for > which lack of reliability is reported. There > This Information Element MUST be defined as a > Scope Field._ There is an extra "There" there. :-) [ snip ] > (*) regarding the meteringProcessId, we were hesitating between the > meteringProcessId and the cache id > 1. there is a meteringProcessId in IPFIX IANA while there is no cache id > 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should > be the value in meteringProcessId? > [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name. > From figure 1 and 2, it seems that there is a one to one matching > between the cache and the metering process. > If this is the case, a solution could be to add a meteringProcess > inside the cache in the figure 12 in [IPFIX-CONF] below > > > 4.3. Cache Class > > > +-----------------------------------+ > | Cache | > +-----------------------------------+ 1 +------------------+ > | name |<>--------| immediateCache/ | > | dataRecords {readOnly} | | timeoutCache/ | > | cacheDiscontinuityTime {readOnly} | | naturalCache/ | > | | | permanentCache | > | | +------------------+ > | | > | | 0..* +------------------+ > | |--------->| ExportingProcess | > +-----------------------------------+ +------------------+ > > Figure 12: Cache class > What do you think? Do you see another way? meteringProcessId makes sense to me since you are exporting "Metering Process Reliability Statistics". If you want to send a cache id as meteringProcessId (and your cache ids are "unique per IPFIX Device") I don't see any harm. At least as long as the 1:1 relationship between metering process and cache holds. The IDs aren't meaningful to me as anything other than an identifier. -Andrew --------------050800020806060902090105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/20/2011 10:19 AM, Benoit Claise wrote:
Dear all,

[this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO DO -> "time first flow dropped" and "time last flow dropped" inconsistency.  See the discussion on the list.]

Paul Aitken discovered this issue.,


[ snip ]
4.2.  The Metering Process Reliability Statistics Option Template


   The Metering Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.

    
   meteringProcessId (*)
                           The identifier of the Metering Process for
                           which lack of reliability is reported.  There
                           This Information Element MUST be defined as a 
                           Scope Field.

There is an extra "There" there.  :-)


[ snip ]

(*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id
1. there is a meteringProcessId in IPFIX IANA while there is no cache id
2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId?
    [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
    From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process.
    If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below
4.3.  Cache Class

    +-----------------------------------+
    | Cache                             |
    +-----------------------------------+        1 +------------------+
    | name                              |<>--------| immediateCache/  |
    | dataRecords {readOnly}            |          | timeoutCache/    |
    | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
    |                                   |          | permanentCache   |
    |                                   |          +------------------+
    |                                   |
    |                                   |     0..* +------------------+
    |                                   |--------->| ExportingProcess |
    +-----------------------------------+          +------------------+

                          Figure 12: Cache class
What do you think? Do you see another way?

meteringProcessId makes sense to me since you are exporting "Metering Process Reliability Statistics".

If you want to send a cache id as meteringProcessId (and your cache ids are "unique per IPFIX Device") I don't see any harm.  At least as long as the 1:1 relationship between metering process and cache holds.  The IDs aren't meaningful to me as anything other than an identifier.

-Andrew

--------------050800020806060902090105-- From paitken@cisco.com Tue Sep 20 13:30:03 2011 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 0BB6211E80E0 for ; Tue, 20 Sep 2011 13:30:03 -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 JPf73aHzoYxA for ; Tue, 20 Sep 2011 13:30:02 -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 4EF5B11E80D8 for ; Tue, 20 Sep 2011 13:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1005; q=dns/txt; s=iport; t=1316550749; x=1317760349; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tXDLw0rYt+7HzEsuxM/6qWXZ4oDkz0rka3xWB9m+tHU=; b=O64BcC3CdazeEhv84GUr17ScYsUJnGBbWiaenzTDiVlHTH7h+i+izhX/ jjKPLNtDnTomir9EUO3M990vhR/v4Pab5CwTSgdBwV52D0hbM78nftJtq kY/UJQln7fEF4f/QwKfb0k2ezDSLtMpWAAv30/VQ4GlBo4Vb+M/F/c4mz o=; X-IronPort-AV: E=Sophos;i="4.68,413,1312156800"; d="scan'208";a="55379839" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 20 Sep 2011 20:32:24 +0000 Received: from [10.61.85.15] (ams3-vpn-dhcp5392.cisco.com [10.61.85.15]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8KKWMQ9005999; Tue, 20 Sep 2011 20:32:22 GMT Message-ID: <4E78F855.3070800@cisco.com> Date: Tue, 20 Sep 2011 21:32:21 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Benoit Claise References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> In-Reply-To: <4E78A0EC.9030003@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] RFC5101: time first flow dropped and time last flow dropped 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, 20 Sep 2011 20:30:03 -0000 Benoit, > 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should > be the value in meteringProcessId? > [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name. IPFIX-CONF (or any configurer) wouldn't set the process ID; it's read-only. The configurer would create the process (technically, add the config which causes the process to be created by the OS), then could be told (or could discover) what the process ID is. The cache name could be used to relate the given config to the process ID. > From figure 1 and 2, it seems that there is a one to one matching > between the cache and the metering process. > If this is the case, a solution could be to add a meteringProcess > inside the cache in the figure 12 in [IPFIX-CONF] below Do you mean, a "meteringProcessId" (IANA #144) as a read-only property? And also an "exportingProcessId" (IANA #145) as a read-only property in the ExportingProcess? Those seem useful. P. From bclaise@cisco.com Tue Sep 20 13:54:16 2011 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 633E111E80EE for ; Tue, 20 Sep 2011 13:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, 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 jFHFN+HPezAF for ; Tue, 20 Sep 2011 13:54:13 -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 3E6D311E80C2 for ; Tue, 20 Sep 2011 13:54:13 -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 p8KKuZSp019243; Tue, 20 Sep 2011 22:56:36 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8KKuW5Z003779; Tue, 20 Sep 2011 22:56:32 +0200 (CEST) Message-ID: <4E78FDFF.7010900@cisco.com> Date: Tue, 20 Sep 2011 22:56:31 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Andrew Feren , Gerhard Muenz References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E78EF92.1070107@plixer.com> In-Reply-To: <4E78EF92.1070107@plixer.com> Content-Type: multipart/alternative; boundary="------------030607020104020304060800" Cc: ipfix@ietf.org Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 20 Sep 2011 20:54:16 -0000 This is a multi-part message in MIME format. --------------030607020104020304060800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andrew, Thanks for your comments. See in line. > On 09/20/2011 10:19 AM, Benoit Claise wrote: >> Dear all, >> >> [this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt, >> TO DO -> "time first flow dropped" and "time last flow dropped" >> inconsistency. See the discussion on the list.] >> >> Paul Aitken discovered this issue., >> >> > [ snip ] >> >> >> 4.2. The Metering Process Reliability Statistics Option Template >> >> >> >> The Metering Process Reliability Option Template specifies the >> structure of a Data Record for reporting lack of reliability in the >> Metering Process. It SHOULD contain the following Information >> Elements that are defined in [RFC5102 ]: >> >> observationDomainId >> An identifier of an Observation Domain that >> is locally unique to the Exporting Process. >> This Information Element MUST be defined as a >> Scope Field. >> >> >> _ meteringProcessId (*) >> The identifier of the Metering Process for >> which lack of reliability is reported. There >> This Information Element MUST be defined as a >> Scope Field._ > > There is an extra "There" there. :-) Thanks > > > [ snip ] > >> (*) regarding the meteringProcessId, we were hesitating between the >> meteringProcessId and the cache id >> 1. there is a meteringProcessId in IPFIX IANA while there is no cache id >> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should >> be the value in meteringProcessId? >> [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name. >> From figure 1 and 2, it seems that there is a one to one matching >> between the cache and the metering process. >> If this is the case, a solution could be to add a meteringProcess >> inside the cache in the figure 12 in [IPFIX-CONF] below >> >> >> 4.3. Cache Class >> >> >> +-----------------------------------+ >> | Cache | >> +-----------------------------------+ 1 +------------------+ >> | name |<>--------| immediateCache/ | >> | dataRecords {readOnly} | | timeoutCache/ | >> | cacheDiscontinuityTime {readOnly} | | naturalCache/ | >> | | | permanentCache | >> | | +------------------+ >> | | >> | | 0..* +------------------+ >> | |--------->| ExportingProcess | >> +-----------------------------------+ +------------------+ >> >> Figure 12: Cache class >> What do you think? Do you see another way? > > meteringProcessId makes sense to me since you are exporting "Metering > Process Reliability Statistics". > > If you want to send a cache id as meteringProcessId (and your cache > ids are "unique per IPFIX Device") I don't see any harm. At least as > long as the 1:1 relationship between metering process and cache holds. That's something I was unable to double check in [IPFIX-CONF] or RFC5470, even if I believe it's a right assumption. Gerhard? Regards, Benoit. > The IDs aren't meaningful to me as anything other than an identifier. > > -Andrew > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------030607020104020304060800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Andrew,

Thanks for your comments.
See in line.
On 09/20/2011 10:19 AM, Benoit Claise wrote:
Dear all,

[this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO DO -> "time first flow dropped" and "time last flow dropped" inconsistency.  See the discussion on the list.]

Paul Aitken discovered this issue.,


[ snip ]
4.2.  The Metering Process Reliability Statistics Option Template


   The Metering Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.

    
   meteringProcessId (*)
                           The identifier of the Metering Process for
                           which lack of reliability is reported.  There
                           This Information Element MUST be defined as a 
                           Scope Field.

There is an extra "There" there.  :-)
Thanks


[ snip ]

(*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id
1. there is a meteringProcessId in IPFIX IANA while there is no cache id
2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId?
    [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
    From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process.
    If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below
4.3.  Cache Class

    +-----------------------------------+
    | Cache                             |
    +-----------------------------------+        1 +------------------+
    | name                              |<>--------| immediateCache/  |
    | dataRecords {readOnly}            |          | timeoutCache/    |
    | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
    |                                   |          | permanentCache   |
    |                                   |          +------------------+
    |                                   |
    |                                   |     0..* +------------------+
    |                                   |--------->| ExportingProcess |
    +-----------------------------------+          +------------------+

                          Figure 12: Cache class
What do you think? Do you see another way?

meteringProcessId makes sense to me since you are exporting "Metering Process Reliability Statistics".

If you want to send a cache id as meteringProcessId (and your cache ids are "unique per IPFIX Device") I don't see any harm.  At least as long as the 1:1 relationship between metering process and cache holds. 
That's something I was unable to double check in [IPFIX-CONF] or RFC5470, even if I believe it's a right assumption.
Gerhard?

Regards, Benoit.

The IDs aren't meaningful to me as anything other than an identifier.

-Andrew



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

--------------030607020104020304060800-- From bclaise@cisco.com Tue Sep 20 14:02:39 2011 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 321DC21F8AE6 for ; Tue, 20 Sep 2011 14:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 cp5q02NlhHoV for ; Tue, 20 Sep 2011 14:02:38 -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 7189B21F8AD8 for ; Tue, 20 Sep 2011 14:02:38 -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 p8KKvqrf019382 for ; Tue, 20 Sep 2011 22:57:52 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8KKvqnQ005047; Tue, 20 Sep 2011 22:57:52 +0200 (CEST) Message-ID: <4E78FE4F.9060409@cisco.com> Date: Tue, 20 Sep 2011 22:57:51 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Paul Aitken References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E78F855.3070800@cisco.com> In-Reply-To: <4E78F855.3070800@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] RFC5101: time first flow dropped and time last flow dropped 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, 20 Sep 2011 21:02:39 -0000 On 20/09/2011 22:32, Paul Aitken wrote: > Benoit, > >> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should >> be the value in meteringProcessId? >> [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache >> name. > > IPFIX-CONF (or any configurer) wouldn't set the process ID; it's > read-only. > > The configurer would create the process (technically, add the config > which causes the process to be created by the OS), then could be told > (or could discover) what the process ID is. > The cache name could be used to relate the given config to the process > ID. Agreed. > > >> From figure 1 and 2, it seems that there is a one to one matching >> between the cache and the metering process. >> If this is the case, a solution could be to add a meteringProcess >> inside the cache in the figure 12 in [IPFIX-CONF] below > > Do you mean, a "meteringProcessId" (IANA #144) as a read-only property? > > And also an "exportingProcessId" (IANA #145) as a read-only property > in the ExportingProcess? That would solve the issue. Regards, Benoit. > > Those seem useful. > > P. From bclaise@cisco.com Tue Sep 20 14:33:38 2011 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 E93361F0C87 for ; Tue, 20 Sep 2011 14:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 E9KG4UPpEtwk for ; Tue, 20 Sep 2011 14:33:38 -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 C19A81F0C62 for ; Tue, 20 Sep 2011 14:33:37 -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 p8KLa32U023306; Tue, 20 Sep 2011 23:36:03 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8KLZwIi024527; Tue, 20 Sep 2011 23:35:58 +0200 (CEST) Message-ID: <4E79073C.5090605@cisco.com> Date: Tue, 20 Sep 2011 23:35:56 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Brian Trammell References: <20110920103441.5003.50588.idtracker@ietfa.amsl.com> <4E786FD4.2010901@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Dietz , Simon Leinen , "ipfix@ietf.org" Subject: Re: [IPFIX] New Version Notification for draft-claise-ipfix-protocol-rfc5101bis-00.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, 20 Sep 2011 21:33:39 -0000 Hi Brian, > Hi, Benoit, > > Two minor personal changes: > > 1. Ensure that my name is spelled correctly everywhere (found at least one "Trammel" in the references, 5103) Sorry about that. Done. > > 2. My address is now: > > Brian Trammell > Swiss Federal Institute of Technology Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 13 > EMail: trammell@tik.ee.ethz.ch > > Otherwise, agree that all presently filed errata are addressed. Done. > > See my other message to you re: 3490. > > For 1305, replace with 5905 but note that we use the 64-bit "timestamp" format, as opposed to either the 32- or 128-bit formats. (May want to note that this will require the data type to be updated before 2038) Currently in discussion with Stewart Bryant. > > Additionally, I believe that a resolution to the template lifetime mechanism for UDP is missing, and given that the present specification is questionably interoperable, that such certain strategies for resolution would be within scope of 5101bis. This would be more or less my suggested variant of "Solution 3" in http://www.ietf.org/mail-archive/web/ipfix/current/msg06047.html: 5655-style template management everywhere with infinite timeout, with an explicit note that doing this on UDP is fraught with peril. Let me think some more about this one. Regards, Benoit. > > Not sure what the right _administrative_ way to do this would be though: do we need to file a technical errata on 5101 that we can then address in 5101bis? > > Best regards, > > Brian > > On Sep 20, 2011, at 12:49 PM, Benoit Claise wrote: > >> Dear all, >> >> Here is a new draft, to advance RFC 5101 to the next stage of standardization on the standards track, as foreseen by the future charter. >> >> DONE: >> Errata ID: 1655 (technical) >> Errata ID: 2791 (technical) >> Errata ID: 2814 (editorial) >> Errata ID: 1818 (editorial) >> Errata ID: 2792 (editorial) >> Errata ID: 2888 (editorial) >> Errata ID: 2889 (editorial) >> Errata ID: 2890 (editorial) >> Errata ID: 2891 (editorial) >> Errata ID: 2892 (editorial) >> Errata ID: 2903 (editorial) >> Errata ID: 2761 (editorial) >> Errata ID: 2762 (editorial) >> Errata ID: 2763 (editorial) >> Errata ID: 2764 (editorial) >> Errata ID: 2852 (editorial) >> Errata ID: 2857 (editorial) >> >> Section 8: "a new sampling rate" has been removed from the list of >> examples that requires a new Template. >> >> If the measurement parameters change such that a new Template is >> required, the Template MUST be withdrawn (using a Template Withdraw >> Message and a new Template definition) or an unused Template ID MUST >> be used. Examples of the measurement changes are: a new sampling >> rate, a new Flow expiration process, a new filtering definition, etc. >> >> Updated the references >> >> Updated the "Document overview" section. >> >> Template and UDP: included the proposal at >> http://www.ietf.org/mail-archive/web/ipfix/current/msg06051.html >> >> >> TO DO: >> "time first flow dropped" and "time last flow dropped" inconsistency. See the discussion on the list. >> Replace the RFC5102 by RFC5102bis, when the draft will be posted. >> Replace the RFC5815 by RFC5815bis, when the draft will be posted. >> NTP RFC 1305 is obsoleted by RFC5905. Check if the format is the similar before updating the reference. >> IDNA RFC 3490 is obsoleted by RFC5890 and RFC5891. Double-check >> >> Did I miss anything, which is within the boundary of what we can change for the next level of standardization? >> >> For your convenience, a diff between RFC5101 and this draft is included. >> >> Regards, Benoit. >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-claise-ipfix-protocol-rfc5101bis-00.txt >> Date: Tue, 20 Sep 2011 03:34:41 -0700 >> From: internet-drafts@ietf.org >> To: bclaise@cisco.com >> CC: bclaise@cisco.com >> >> A new version of I-D, draft-claise-ipfix-protocol-rfc5101bis-00.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. >> >> Filename: draft-claise-ipfix-protocol-rfc5101bis >> Revision: 00 >> Title: Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information >> Creation date: 2011-09-20 >> WG ID: Individual Submission >> Number of pages: 66 >> >> Abstract: >> This document specifies the IP Flow Information Export (IPFIX) >> protocol that serves for transmitting IP Traffic Flow information >> over the network. In order to transmit IP Traffic Flow information >> from an Exporting Process to an information Collecting Process, a >> common representation of flow data and a standard means of >> communicating them is required. This document describes how the >> IPFIX Data and 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 IETF Secretariat >> >> From n.brownlee@auckland.ac.nz Tue Sep 20 15:46:24 2011 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 B3DCF11E80D8 for ; Tue, 20 Sep 2011 15:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.794 X-Spam-Level: X-Spam-Status: No, score=-102.794 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1, 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 Q0UZoECkDh6j for ; Tue, 20 Sep 2011 15:46:23 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2484C11E80D5 for ; Tue, 20 Sep 2011 15:46:22 -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=1316558931; x=1348094931; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to:content-transfer-encoding; z=Message-ID:=20<4E791849.1070909@auckland.ac.nz>|Date:=20 Wed,=2021=20Sep=202011=2010:48:41=20+1200|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|CC:=20IPFIX=20Working=20Group=20, =20=0D=0A=20draft-ietf-ipfix-flow-selection-tech@tools.ie tf.org|Subject:=20Re:=20[IPFIX]=20Any=20last=20comments =20on=20draft-ietf-ipfix-flow-selection-tech-07=0D=0A=20? ??|References:=20<4E558AE2.9000308@auckland.ac.nz>=20<4E6 5246F.5070406@cisco.com>=20<4E65FF30.5070504@cisco.com> |In-Reply-To:=20<4E65FF30.5070504@cisco.com> |Content-Transfer-Encoding:=207bit; bh=5K+FbcqgcHaE00KzuROlCByaqteowBTtB2a+0nU7xRg=; b=EPmhKB40Ne2M+ex/j61wuqxPgPRCl+qNYTSlB1ME0s5m1qU86b0oiEin sLnn3El5g/AH8t7uB/1o6nh7cC2Apg7jPhfWwQ0d6EJ7hHIDrEPPsz90P ydtd3l4k+lCtDZaasDCGWJSMX/biKiGqZ7opTaFdEgoACv4P+orbUq4nd 4=; X-IronPort-AV: E=Sophos;i="4.68,413,1312113600"; d="scan'208";a="84672964" 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; 21 Sep 2011 10:48:42 +1200 Message-ID: <4E791849.1070909@auckland.ac.nz> Date: Wed, 21 Sep 2011 10:48:41 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 References: <4E558AE2.9000308@auckland.ac.nz> <4E65246F.5070406@cisco.com> <4E65FF30.5070504@cisco.com> In-Reply-To: <4E65FF30.5070504@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org, IPFIX Working Group Subject: Re: [IPFIX] Any last comments on draft-ietf-ipfix-flow-selection-tech-07 ??? 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, 20 Sep 2011 22:46:24 -0000 Hi again flow-selection authors: Reading Paul's comment again (below), do you agree with his suggestion about 'Informational?' If not, the draft really does need to specify at least some of the sampling methods ... Cheers again, Nevil On 6/09/11 11:08 PM, Paul Aitken wrote: > Dear all, > > Considering the draft some more... > > A standards track document should specify and contain everything that > needs to be known and understood in order to implement the specified > methods. > > However, this draft reads more as an overview of the methods, rather > than a specification of them. While reading it gave an idea of the > available methods, what actually needs done to correctly implement each > method is not spelled out. eg, there are only two MUSTs in the document, > both in the first paragraph of section 1. The average over all the IPFIX > drafts is over 15 MUSTs. > > In short, it seems more Informational than Standards track. > > P. -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From andrewf@plixer.com Wed Sep 21 11:21:04 2011 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 F0A171F0C45 for ; Wed, 21 Sep 2011 11:21:03 -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=[AWL=-0.000, 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 jzZU5VuWmq+x for ; Wed, 21 Sep 2011 11:21:02 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 360371F0C47 for ; Wed, 21 Sep 2011 11:21:02 -0700 (PDT) Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Sep 2011 14:23:30 -0400 Message-ID: <4E7A2BA2.5000206@plixer.com> Date: Wed, 21 Sep 2011 14:23:30 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110914 Thunderbird/9.0a1 MIME-Version: 1.0 To: ipfix@ietf.org References: <20110920103441.5003.50588.idtracker@ietfa.amsl.com> <4E786FD4.2010901@cisco.com> In-Reply-To: <4E786FD4.2010901@cisco.com> Content-Type: multipart/alternative; boundary="------------000705050600090406090101" X-OriginalArrivalTime: 21 Sep 2011 18:23:30.0723 (UTC) FILETIME=[90838F30:01CC788B] Subject: Re: [IPFIX] Fwd: New Version Notification for draft-claise-ipfix-protocol-rfc5101bis-00.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: Wed, 21 Sep 2011 18:21:04 -0000 This is a multi-part message in MIME format. --------------000705050600090406090101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In new version (page 34) "Withdrawa Message(s) before reusing them." should be "Withdrawal Message(s) before reusing them." New version (A.4.3 page 58) changes (41) "exportedPacketCount" to "exportedMessageTotalCount" (42) "exportedFlowCount" to "exportedFlowRecordTotalCount" but then uses "exportedFlowRecordTotalCount" for both 41 and 42 in the diagram of the options template. ... Enterprise Number |0| exportedFlowRecordTotalCo.=41| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| should read as follows ... Enterprise Number |0|exportedMessageTotalCount=41 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| -Andrew On 09/20/2011 06:49 AM, Benoit Claise wrote: > Dear all, > > Here is a new draft, to advance RFC 5101 to the next stage of > standardization on the standards track, as foreseen by the future charter. > > DONE: > Errata ID: 1655 (technical) > Errata ID: 2791 (technical) > Errata ID: 2814 (editorial) > Errata ID: 1818 (editorial) > Errata ID: 2792 (editorial) > Errata ID: 2888 (editorial) > Errata ID: 2889 (editorial) > Errata ID: 2890 (editorial) > Errata ID: 2891 (editorial) > Errata ID: 2892 (editorial) > Errata ID: 2903 (editorial) > Errata ID: 2761 (editorial) > Errata ID: 2762 (editorial) > Errata ID: 2763 (editorial) > Errata ID: 2764 (editorial) > Errata ID: 2852 (editorial) > Errata ID: 2857 (editorial) > > Section 8: "a new sampling rate" has been removed from the list of > examples that requires a new Template. > > If the measurement parameters change such that a new Template is > required, the Template MUST be withdrawn (using a Template Withdraw > Message and a new Template definition) or an unused Template ID MUST > be used. Examples of the measurement changes are: a new sampling > rate, a new Flow expiration process, a new filtering definition, etc. > > Updated the references > > Updated the "Document overview" section. > > Template and UDP: included the proposal at > http://www.ietf.org/mail-archive/web/ipfix/current/msg06051.html > > > TO DO: > "time first flow dropped" and "time last flow dropped" > inconsistency. See the discussion on the list. > Replace the RFC5102 by RFC5102bis, when the draft will be posted. > Replace the RFC5815 by RFC5815bis, when the draft will be posted. > NTP RFC 1305 is obsoleted by RFC5905. Check if the format is the > similar before updating the reference. > IDNA RFC 3490 is obsoleted by RFC5890 and RFC5891. Double-check > > Did I miss anything, which is within the boundary of what we can > change for the next level of standardization? > > For your convenience, a diff between RFC5101 and this draft is included. > > Regards, Benoit. > > -------- Original Message -------- > Subject: New Version Notification for > draft-claise-ipfix-protocol-rfc5101bis-00.txt > Date: Tue, 20 Sep 2011 03:34:41 -0700 > From: internet-drafts@ietf.org > To: bclaise@cisco.com > CC: bclaise@cisco.com > > > > A new version of I-D, draft-claise-ipfix-protocol-rfc5101bis-00.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. > > Filename: draft-claise-ipfix-protocol-rfc5101bis > Revision: 00 > Title: Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information > Creation date: 2011-09-20 > WG ID: Individual Submission > Number of pages: 66 > > Abstract: > This document specifies the IP Flow Information Export (IPFIX) > protocol that serves for transmitting IP Traffic Flow information > over the network. In order to transmit IP Traffic Flow information > from an Exporting Process to an information Collecting Process, a > common representation of flow data and a standard means of > communicating them is required. This document describes how the > IPFIX Data and 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 IETF Secretariat > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------000705050600090406090101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
In new version (page 34)
"Withdrawa Message(s) before reusing them."
should be
"Withdrawal Message(s) before reusing them."

New version (A.4.3 page 58)
changes
(41) "exportedPacketCount" to "exportedMessageTotalCount"
(42) "exportedFlowCount" to "exportedFlowRecordTotalCount"

but then uses "exportedFlowRecordTotalCount" for both 41 and 42 in the diagram of the options template.


 ...       Enterprise Number      |0| exportedFlowRecordTotalCo.=41|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       Field Length = 2        |0|exportedFlowRecordTotalCo.=42|

should read as follows

 ...       Enterprise Number      |0|exportedMessageTotalCount=41 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       Field Length = 2        |0|exportedFlowRecordTotalCo.=42|

-Andrew

On 09/20/2011 06:49 AM, Benoit Claise wrote:
Dear all,

Here is a new draft, to advance RFC 5101 to the next stage of standardization on the standards track, as foreseen by the future charter.

DONE:
      Errata ID: 1655 (technical)
      Errata ID: 2791 (technical)
      Errata ID: 2814 (editorial)
      Errata ID: 1818 (editorial)
      Errata ID: 2792 (editorial)
      Errata ID: 2888 (editorial)
      Errata ID: 2889 (editorial)
      Errata ID: 2890 (editorial)
      Errata ID: 2891 (editorial)
      Errata ID: 2892 (editorial)
      Errata ID: 2903 (editorial)
      Errata ID: 2761 (editorial)
      Errata ID: 2762 (editorial)
      Errata ID: 2763 (editorial)
      Errata ID: 2764 (editorial)
      Errata ID: 2852 (editorial)
      Errata ID: 2857 (editorial)

      Section 8: "a new sampling rate" has been removed from the list of
   examples that requires a new Template.

      If the measurement parameters change such that a new Template is 
   required, the Template MUST be withdrawn (using a Template Withdraw 
   Message and a new Template definition) or an unused Template ID MUST
    be used.  Examples of the measurement changes are: a new sampling 
   rate, a new Flow expiration process, a new filtering definition, etc.

      Updated the references

      Updated the "Document overview" section.

      Template and UDP: included the proposal at
   http://www.ietf.org/mail-archive/web/ipfix/current/msg06051.html


TO DO:
      "time first flow dropped" and "time last flow dropped" inconsistency. See the discussion on the list.
      Replace the RFC5102 by RFC5102bis, when the draft will be posted.
      Replace the RFC5815 by RFC5815bis, when the draft will be posted.
      NTP RFC 1305 is obsoleted by RFC5905. Check if the format is the similar before updating the reference.
      IDNA RFC 3490 is obsoleted by RFC5890 and RFC5891. Double-check

Did I miss anything, which is within the boundary of what we can change for the next level of standardization?

For your convenience, a diff between RFC5101 and this draft is included.

Regards, Benoit.

-------- Original Message --------
Subject: New Version Notification for draft-claise-ipfix-protocol-rfc5101bis-00.txt
Date: Tue, 20 Sep 2011 03:34:41 -0700
From: internet-drafts@ietf.org
To: bclaise@cisco.com
CC: bclaise@cisco.com 


A new version of I-D, draft-claise-ipfix-protocol-rfc5101bis-00.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-ipfix-protocol-rfc5101bis
Revision:	 00
Title:		 Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
Creation date:	 2011-09-20
WG ID:		 Individual Submission
Number of pages: 66

Abstract:
   This document specifies the IP Flow Information Export (IPFIX)
   protocol that serves for transmitting IP Traffic Flow information
   over the network.  In order to transmit IP Traffic Flow information
   from an Exporting Process to an information Collecting Process, a
   common representation of flow data and a standard means of
   communicating them is required.  This document describes how the
   IPFIX Data and 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 IETF Secretariat



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

--------------000705050600090406090101-- From muenz@net.in.tum.de Wed Sep 21 12:20:25 2011 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 8254111E811B for ; Wed, 21 Sep 2011 12:20:25 -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=[AWL=-0.000, 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 duhxjJnSft1M for ; Wed, 21 Sep 2011 12:20:24 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id BABE811E8127 for ; Wed, 21 Sep 2011 12:20:23 -0700 (PDT) Received: from [192.168.2.26] (g229030004.adsl.alicedsl.de [92.229.30.4]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 172C2208BD81; Wed, 21 Sep 2011 21:22:53 +0200 (CEST) Message-ID: <4E7A397B.3080802@net.in.tum.de> Date: Wed, 21 Sep 2011 21:22:35 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Benoit Claise References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> In-Reply-To: <4E78A0EC.9030003@cisco.com> Content-Type: multipart/alternative; boundary="------------060900060009020500020603" Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 21 Sep 2011 19:20:25 -0000 This is a multi-part message in MIME format. --------------060900060009020500020603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Benoit, See comments inline. On 20.09.2011 16:19, Benoit Claise wrote: > Dear all, > > [this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt, > TO DO -> "time first flow dropped" and "time last flow dropped" > inconsistency. See the discussion on the list.] > > Paul Aitken discovered this issue., > > From [RFC5101], section 4.3. The Exporting Process Reliability > Statistics Option Template > > time first flow dropped > The timestamp of the first _Flow _was dropped by > the Metering Process. For this timestamp, any > of the "flowStart" timestamp Information > Elements flowStartMilliseconds, > flowStartMicroseconds, flowStartNanoseconds, and > flowStartDeltaMicroseconds can be used. > > time last flow dropped > The timestamp of the last _IP packet_ that was > ignored by the Metering Process. For this > timestamp, any of the "flowEnd" timestamp > Information Elements flowEndMilliseconds, > flowEndMicroseconds, flowEndNanoseconds, and > flowEndDeltaMicroseconds can be used. > > > Firstly, these definitions are inconsistent since the names and the > first definition say "flow" while the second definition says "IP > packet". Obviously "IP packet" != "flow" :-o > > Secondly, "The timestamp of the first Flow was dropped by the Metering > Process." is bad English: at least it's missing "that". > > Thirdly, the section 4.2 doesn't take into account a metering process > id. Indeed, what if we have multiple caches on the exporter? > > Here is a proposal for 4.2 and 4.3. The underlined parts are new > > > 4.2. The Metering Process Reliability Statistics Option Template > > > > The Metering Process Reliability Option Template specifies the > structure of a Data Record for reporting lack of reliability in the > Metering Process. It SHOULD contain the following Information > Elements that are defined in [RFC5102 ]: > > observationDomainId > An identifier of an Observation Domain that > is locally unique to the Exporting Process. > This Information Element MUST be defined as a > Scope Field. > > > _ meteringProcessId (*) > The identifier of the Metering Process for > which lack of reliability is reported. There > This Information Element MUST be defined as a > Scope Field._ > > ignoredPacketTotalCount > The total number of IP packets that the > Metering Process did not process. > > ignoredOctetTotalCount > The total number of octets in observed IP > packets that the Metering Process did not > process. > > time first_packet_ignored > The timestamp of the first IP packet that was > ignored by the Metering Process. For this > timestamp, any of the "flowStart" timestamp > Information Elements flowStartMilliseconds, > flowStartMicroseconds, flowStartNanoseconds, > and flowStartDeltaMicroseconds can be used. > > time last_packet_ignored > The timestamp of the last IP packet that was > ignored by the Metering Process. For this > timestamp, any of the "flowEnd" timestamp > Information Elements flowEndMilliseconds, > flowEndMicroseconds, flowEndNanoseconds, and > flowEndDeltaMicroseconds can be used. I do not find these IEs in RFC5102. > > > 4.3. The Exporting Process Reliability Statistics Option Template > > > The Exporting Process Reliability Option Template specifies the > structure of a Data Record for reporting lack of reliability in the > Exporting process. It SHOULD contain the following Information > Elements that are defined in [RFC5102 ]: > > Exporting Process ID > The identifier of the Exporting Process for > which lack of reliability is reported. There > are three Information Elements specified in > [RFC5102 ] that can be used for this purpose: > exporterIPv4Address, exporterIPv6Address, or > exportingProcessId. This Information Element > MUST be defined as a Scope Field. > > notSentFlowTotalCount > The total number of Flows that were generated by > the Metering Process and dropped by the Metering > Process or by the Exporting Process instead of > being sent to the Collecting Process. > > notSentPacketTotalCount > The total number of packets in Flow Records that > were generated by the Metering Process and > dropped by the Metering Process or by the > Exporting Process instead of being sent to the > Collecting Process. > > notSentOctetTotalCount > The total number of octets in packets in Flow > Records that were generated by the Metering > Process and dropped by the Metering Process or > by the Exporting Process instead of being sent > to the Collecting Process. > > time first flow dropped > _ The time at which the first Flow Record was dropped by > the__Exporting Process._ For this timestamp, any > of the "flowStart" timestamp Information > Elements flowStartMilliseconds, > flowStartMicroseconds, flowStartNanoseconds, and > flowStartDeltaMicroseconds can be used. > > time last flow dropped > _The time at which the last Flow Record was > dropped by the Exporting Process_. For this > timestamp, any of the "flowEnd" timestamp > Information Elements flowEndMilliseconds, > flowEndMicroseconds, flowEndNanoseconds, and > flowEndDeltaMicroseconds can be used. Again, I do not find these IEs in RFC5102. > > The Exporting Process SHOULD export the Data Record specified by the > Exporting Process Reliability Statistics Option Template on a regular > basis or based on some export policy. This periodicity or export > policy SHOULD be configurable. > > > > > (*) regarding the meteringProcessId, we were hesitating between the > meteringProcessId and the cache id > 1. there is a meteringProcessId in IPFIX IANA while there is no cache id meteringProcessId should do the job. > 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should > be the value in meteringProcessId? > [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name. > From figure 1 and 2, it seems that there is a one to one matching > between the cache and the metering process. > If this is the case, a solution could be to add a meteringProcess > inside the cache in the figure 12 in [IPFIX-CONF] below See reply to Pauls mail. Regards, Gerhard > > 4.3. Cache Class > > > +-----------------------------------+ > | Cache | > +-----------------------------------+ 1 +------------------+ > | name |<>--------| immediateCache/ | > | dataRecords {readOnly} | | timeoutCache/ | > | cacheDiscontinuityTime {readOnly} | | naturalCache/ | > | | | permanentCache | > | | +------------------+ > | | > | | 0..* +------------------+ > | |--------->| ExportingProcess | > +-----------------------------------+ +------------------+ > > Figure 12: Cache class > What do you think? Do you see another way? > > Regards, Paul & Benoit. > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------060900060009020500020603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Benoit,

See comments inline.

On 20.09.2011 16:19, Benoit Claise wrote:
Dear all,

[this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO DO -> "time first flow dropped" and "time last flow dropped" inconsistency.  See the discussion on the list.]

Paul Aitken discovered this issue.,

From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template

time first flow dropped
                        The timestamp of the first Flow was dropped by
                        the Metering Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

time last flow dropped
                        The timestamp of the last IP packet that was
                        ignored by the Metering Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.


Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o

Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".

Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter?

Here is a proposal for 4.2 and 4.3. The underlined parts are new

4.2.  The Metering Process Reliability Statistics Option Template


   The Metering Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.

    
   meteringProcessId (*)
                           The identifier of the Metering Process for
                           which lack of reliability is reported.  There
                           This Information Element MUST be defined as a 
                           Scope Field.

   ignoredPacketTotalCount
                           The total number of IP packets that the
                           Metering Process did not process.

   ignoredOctetTotalCount
                           The total number of octets in observed IP
                           packets that the Metering Process did not
                           process.

   time first packet ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last packet ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.

I do not find these IEs in RFC5102. 




4.3.  The Exporting Process Reliability Statistics Option Template

   The Exporting Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Exporting process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.

   notSentFlowTotalCount
                        The total number of Flows that were generated by
                        the Metering Process and dropped by the Metering
                        Process or by the Exporting Process instead of
                        being sent to the Collecting Process.

   notSentPacketTotalCount
                        The total number of packets in Flow Records that
                        were generated by the Metering Process and
                        dropped by the Metering Process or by the
                        Exporting Process instead of being sent to the
                        Collecting Process.

   notSentOctetTotalCount
                        The total number of octets in packets in Flow
                        Records that were generated by the Metering
                        Process and dropped by the Metering Process or
                        by the Exporting Process instead of being sent
                        to the Collecting Process.

   time first flow dropped
                        The time at which the first Flow Record was dropped by
                        the Exporting Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

   time last flow dropped
                        The time at which the last Flow Record was
                        dropped by the Exporting Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.

Again, I do not find these IEs in RFC5102. 


   The Exporting Process SHOULD export the Data Record specified by the
   Exporting Process Reliability Statistics Option Template on a regular
   basis or based on some export policy.  This periodicity or export
   policy SHOULD be configurable.




(*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id
1. there is a meteringProcessId in IPFIX IANA while there is no cache id

meteringProcessId should do the job.

2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId?
    [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
    From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process.
    If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below

See reply to Pauls mail.

Regards,
Gerhard

4.3.  Cache Class

    +-----------------------------------+
    | Cache                             |
    +-----------------------------------+        1 +------------------+
    | name                              |<>--------| immediateCache/  |
    | dataRecords {readOnly}            |          | timeoutCache/    |
    | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
    |                                   |          | permanentCache   |
    |                                   |          +------------------+
    |                                   |
    |                                   |     0..* +------------------+
    |                                   |--------->| ExportingProcess |
    +-----------------------------------+          +------------------+

                          Figure 12: Cache class
What do you think? Do you see another way?

Regards, Paul & Benoit.


_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
--------------060900060009020500020603-- From muenz@net.in.tum.de Wed Sep 21 12:44:17 2011 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 3C0FF11E8127 for ; Wed, 21 Sep 2011 12:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 Pfbzxz9c3oVw for ; Wed, 21 Sep 2011 12:44:16 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 92DC611E811B for ; Wed, 21 Sep 2011 12:44:08 -0700 (PDT) Received: from [192.168.2.26] (g229030004.adsl.alicedsl.de [92.229.30.4]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 09AA2208C799; Wed, 21 Sep 2011 21:46:38 +0200 (CEST) Message-ID: <4E7A3F0A.102@net.in.tum.de> Date: Wed, 21 Sep 2011 21:46:18 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Paul Aitken References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E78F855.3070800@cisco.com> In-Reply-To: <4E78F855.3070800@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] RFC5101: time first flow dropped and time last flow dropped 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, 21 Sep 2011 19:44:17 -0000 Dear all, On 20.09.2011 22:32, Paul Aitken wrote: > Benoit, > >> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should >> be the value in meteringProcessId? >> [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name. > > IPFIX-CONF (or any configurer) wouldn't set the process ID; it's read-only. > > The configurer would create the process (technically, add the config > which causes the process to be created by the OS), then could be told > (or could discover) what the process ID is. > The cache name could be used to relate the given config to the process ID. Correct. In general, IDs cannot be considered to be configurable. >> From figure 1 and 2, it seems that there is a one to one matching >> between the cache and the metering process. >> If this is the case, a solution could be to add a meteringProcess >> inside the cache in the figure 12 in [IPFIX-CONF] below > > Do you mean, a "meteringProcessId" (IANA #144) as a read-only property? > > And also an "exportingProcessId" (IANA #145) as a read-only property in > the ExportingProcess? I'm not sure about the one-to-one relationship between Metering Process and Cache. On purpose, IPFIX-CONF does not make a statement because it is not an architectural document. A Metering Process may have multiple Caches. But I do not think that a Cache would belong to multiple Metering Process. So, there is only one meteringProcessId which is associated with a Cache. We do not have selectorId, exportingProcessId, and meteringProcessId in the configuration data model. If we think about adding meteringProcessId, it may be worth thinking about the other IDs as well. I do not see a problem if these are defined as state parameters (e.g. read-only). selectorId is a bit different because the scope is OD, not IPFIX device. Therefore, the same ID value may appear for different Selectors of the same device. Gerhard From paitken@cisco.com Wed Sep 21 14:16:01 2011 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 22CC211E80BA for ; Wed, 21 Sep 2011 14:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 fRA-6GCavYgM for ; Wed, 21 Sep 2011 14:16:00 -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 B2DBF11E814D for ; Wed, 21 Sep 2011 14:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1669; q=dns/txt; s=iport; t=1316639909; x=1317849509; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=04iK64YMXVhkX+GGUiJnekrjwBzxSHEYJYeXg8kblGY=; b=S3LYt2MLs+jmAKZ/cmKN3GuhDIQsz0fWxJU0bZZPeY7hbtugJlwAlglg yYRlsg1Eb4FpoV5YviEE4nsYPqZ6ziiB3ASJyAgkm33iWU68uHoTuac/1 r/peIWE2A7LwsXgQhP1dNj8xxhEM+S6btPq3DFvgDrgLp9MJml+t/GwlP Y=; X-IronPort-AV: E=Sophos;i="4.68,419,1312156800"; d="scan'208";a="116526282" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 21 Sep 2011 21:18:28 +0000 Received: from [10.61.83.105] (ams3-vpn-dhcp4970.cisco.com [10.61.83.105]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8LLISZP000889; Wed, 21 Sep 2011 21:18:28 GMT Message-ID: <4E7A54A3.6020509@cisco.com> Date: Wed, 21 Sep 2011 22:18:27 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Gerhard Muenz References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E78F855.3070800@cisco.com> <4E7A3F0A.102@net.in.tum.de> In-Reply-To: <4E7A3F0A.102@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 21 Sep 2011 21:16:01 -0000 Gerhard, >>> between the cache and the metering process. >>> If this is the case, a solution could be to add a meteringProcess >>> inside the cache in the figure 12 in [IPFIX-CONF] below >> >> Do you mean, a "meteringProcessId" (IANA #144) as a read-only property? >> >> And also an "exportingProcessId" (IANA #145) as a read-only property in >> the ExportingProcess? > > From figure 1 and 2, it seems that there is a one to one matching > > I'm not sure about the one-to-one relationship between Metering > Process and Cache. On purpose, IPFIX-CONF does not make a statement > because it is not an architectural document. A Metering Process may > have multiple Caches. But I do not think that a Cache would belong to > multiple Metering Process. So, there is only one meteringProcessId > which is associated with a Cache. Can you see anywhere in the IPFIX documents which shows the relationship between a Metering Process and cache(s) ? I don't see "cache" in RFC5101 (IPFIX PROTO) or RFC5470 (IPFIX ARCH). However, Figures 1 and 2 of IPFIX CONF show a Metering Process with only one cache. > > We do not have selectorId, exportingProcessId, and meteringProcessId > in the configuration data model. If we think about adding > meteringProcessId, it may be worth thinking about the other IDs as well. Definitely. Thanks, P. > I do not see a problem if these are defined as state parameters (e.g. > read-only). > > selectorId is a bit different because the scope is OD, not IPFIX > device. Therefore, the same ID value may appear for different > Selectors of the same device. > > Gerhard From bclaise@cisco.com Wed Sep 21 15:50:42 2011 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 2D4681F0D0B for ; Wed, 21 Sep 2011 15:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.118, 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 ak55aP3OU9+N for ; Wed, 21 Sep 2011 15:50:40 -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 2F9141F0CF9 for ; Wed, 21 Sep 2011 15:50:35 -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 p8LMr3V4007458; Thu, 22 Sep 2011 00:53:03 +0200 (CEST) Received: from [10.55.88.40] (dhcp-10-55-88-40.cisco.com [10.55.88.40]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8LMqvgU029092; Thu, 22 Sep 2011 00:52:58 +0200 (CEST) Message-ID: <4E7A6AC9.9000604@cisco.com> Date: Thu, 22 Sep 2011 00:52:57 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Andrew Feren References: <20110920103441.5003.50588.idtracker@ietfa.amsl.com> <4E786FD4.2010901@cisco.com> <4E7A2BA2.5000206@plixer.com> In-Reply-To: <4E7A2BA2.5000206@plixer.com> Content-Type: multipart/alternative; boundary="------------030202010000080306080202" Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: New Version Notification for draft-claise-ipfix-protocol-rfc5101bis-00.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: Wed, 21 Sep 2011 22:50:42 -0000 This is a multi-part message in MIME format. --------------030202010000080306080202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andrew, Many thanks for double checking. Now corrected in my temp version. Regards, Benoit. > > In new version (page 34) > "Withdrawa Message(s) before reusing them." > should be > "Withdrawal Message(s) before reusing them." > > New version (A.4.3 page 58) > changes > (41) "exportedPacketCount" to "exportedMessageTotalCount" > (42) "exportedFlowCount" to "exportedFlowRecordTotalCount" > > but then uses "exportedFlowRecordTotalCount" for both 41 and 42 in the > diagram of the options template. > > > ... Enterprise Number |0| exportedFlowRecordTotalCo.=41| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| > > should read as follows > > ... Enterprise Number |0|exportedMessageTotalCount=41 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| > > -Andrew > > On 09/20/2011 06:49 AM, Benoit Claise wrote: >> Dear all, >> >> Here is a new draft, to advance RFC 5101 to the next stage of >> standardization on the standards track, as foreseen by the future >> charter. >> >> DONE: >> Errata ID: 1655 (technical) >> Errata ID: 2791 (technical) >> Errata ID: 2814 (editorial) >> Errata ID: 1818 (editorial) >> Errata ID: 2792 (editorial) >> Errata ID: 2888 (editorial) >> Errata ID: 2889 (editorial) >> Errata ID: 2890 (editorial) >> Errata ID: 2891 (editorial) >> Errata ID: 2892 (editorial) >> Errata ID: 2903 (editorial) >> Errata ID: 2761 (editorial) >> Errata ID: 2762 (editorial) >> Errata ID: 2763 (editorial) >> Errata ID: 2764 (editorial) >> Errata ID: 2852 (editorial) >> Errata ID: 2857 (editorial) >> >> Section 8: "a new sampling rate" has been removed from the list of >> examples that requires a new Template. >> >> If the measurement parameters change such that a new Template is >> required, the Template MUST be withdrawn (using a Template Withdraw >> Message and a new Template definition) or an unused Template ID MUST >> be used. Examples of the measurement changes are: a new sampling >> rate, a new Flow expiration process, a new filtering definition, etc. >> >> Updated the references >> >> Updated the "Document overview" section. >> >> Template and UDP: included the proposal at >> http://www.ietf.org/mail-archive/web/ipfix/current/msg06051.html >> >> >> TO DO: >> "time first flow dropped" and "time last flow dropped" >> inconsistency. See the discussion on the list. >> Replace the RFC5102 by RFC5102bis, when the draft will be posted. >> Replace the RFC5815 by RFC5815bis, when the draft will be posted. >> NTP RFC 1305 is obsoleted by RFC5905. Check if the format is >> the similar before updating the reference. >> IDNA RFC 3490 is obsoleted by RFC5890 and RFC5891. Double-check >> >> Did I miss anything, which is within the boundary of what we can >> change for the next level of standardization? >> >> For your convenience, a diff between RFC5101 and this draft is included. >> >> Regards, Benoit. >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-claise-ipfix-protocol-rfc5101bis-00.txt >> Date: Tue, 20 Sep 2011 03:34:41 -0700 >> From: internet-drafts@ietf.org >> To: bclaise@cisco.com >> CC: bclaise@cisco.com >> >> >> >> A new version of I-D, draft-claise-ipfix-protocol-rfc5101bis-00.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. >> >> Filename: draft-claise-ipfix-protocol-rfc5101bis >> Revision: 00 >> Title: Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information >> Creation date: 2011-09-20 >> WG ID: Individual Submission >> Number of pages: 66 >> >> Abstract: >> This document specifies the IP Flow Information Export (IPFIX) >> protocol that serves for transmitting IP Traffic Flow information >> over the network. In order to transmit IP Traffic Flow information >> from an Exporting Process to an information Collecting Process, a >> common representation of flow data and a standard means of >> communicating them is required. This document describes how the >> IPFIX Data and 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 IETF Secretariat >> >> >> _______________________________________________ >> 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 --------------030202010000080306080202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Andrew,

Many thanks for double checking.
Now corrected in my temp version.

Regards, Benoit.

In new version (page 34)
"Withdrawa Message(s) before reusing them."
should be
"Withdrawal Message(s) before reusing them."

New version (A.4.3 page 58)
changes
(41) "exportedPacketCount" to "exportedMessageTotalCount"
(42) "exportedFlowCount" to "exportedFlowRecordTotalCount"

but then uses "exportedFlowRecordTotalCount" for both 41 and 42 in the diagram of the options template.


 ...       Enterprise Number      |0| exportedFlowRecordTotalCo.=41|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       Field Length = 2        |0|exportedFlowRecordTotalCo.=42|

should read as follows

 ...       Enterprise Number      |0|exportedMessageTotalCount=41 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       Field Length = 2        |0|exportedFlowRecordTotalCo.=42|

-Andrew

On 09/20/2011 06:49 AM, Benoit Claise wrote:
Dear all,

Here is a new draft, to advance RFC 5101 to the next stage of standardization on the standards track, as foreseen by the future charter.

DONE:
      Errata ID: 1655 (technical)
      Errata ID: 2791 (technical)
      Errata ID: 2814 (editorial)
      Errata ID: 1818 (editorial)
      Errata ID: 2792 (editorial)
      Errata ID: 2888 (editorial)
      Errata ID: 2889 (editorial)
      Errata ID: 2890 (editorial)
      Errata ID: 2891 (editorial)
      Errata ID: 2892 (editorial)
      Errata ID: 2903 (editorial)
      Errata ID: 2761 (editorial)
      Errata ID: 2762 (editorial)
      Errata ID: 2763 (editorial)
      Errata ID: 2764 (editorial)
      Errata ID: 2852 (editorial)
      Errata ID: 2857 (editorial)

      Section 8: "a new sampling rate" has been removed from the list of
   examples that requires a new Template.

      If the measurement parameters change such that a new Template is 
   required, the Template MUST be withdrawn (using a Template Withdraw 
   Message and a new Template definition) or an unused Template ID MUST
    be used.  Examples of the measurement changes are: a new sampling 
   rate, a new Flow expiration process, a new filtering definition, etc.

      Updated the references

      Updated the "Document overview" section.

      Template and UDP: included the proposal at
   http://www.ietf.org/mail-archive/web/ipfix/current/msg06051.html


TO DO:
      "time first flow dropped" and "time last flow dropped" inconsistency. See the discussion on the list.
      Replace the RFC5102 by RFC5102bis, when the draft will be posted.
      Replace the RFC5815 by RFC5815bis, when the draft will be posted.
      NTP RFC 1305 is obsoleted by RFC5905. Check if the format is the similar before updating the reference.
      IDNA RFC 3490 is obsoleted by RFC5890 and RFC5891. Double-check

Did I miss anything, which is within the boundary of what we can change for the next level of standardization?

For your convenience, a diff between RFC5101 and this draft is included.

Regards, Benoit.

-------- Original Message --------
Subject: New Version Notification for draft-claise-ipfix-protocol-rfc5101bis-00.txt
Date: Tue, 20 Sep 2011 03:34:41 -0700
From: internet-drafts@ietf.org
To: bclaise@cisco.com
CC: bclaise@cisco.com 


A new version of I-D, draft-claise-ipfix-protocol-rfc5101bis-00.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-ipfix-protocol-rfc5101bis
Revision:	 00
Title:		 Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
Creation date:	 2011-09-20
WG ID:		 Individual Submission
Number of pages: 66

Abstract:
   This document specifies the IP Flow Information Export (IPFIX)
   protocol that serves for transmitting IP Traffic Flow information
   over the network.  In order to transmit IP Traffic Flow information
   from an Exporting Process to an information Collecting Process, a
   common representation of flow data and a standard means of
   communicating them is required.  This document describes how the
   IPFIX Data and 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 IETF Secretariat



_______________________________________________
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

--------------030202010000080306080202-- From bclaise@cisco.com Wed Sep 21 15:56:24 2011 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 5F3AF1F0D1C for ; Wed, 21 Sep 2011 15:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 WaUgAulHcvNF for ; Wed, 21 Sep 2011 15:56:23 -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 887A01F0CF9 for ; Wed, 21 Sep 2011 15:56:23 -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 p8LMwqqC008056; Thu, 22 Sep 2011 00:58:52 +0200 (CEST) Received: from [10.55.88.40] (dhcp-10-55-88-40.cisco.com [10.55.88.40]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8LMwcbM001331; Thu, 22 Sep 2011 00:58:38 +0200 (CEST) Message-ID: <4E7A6C1D.2010000@cisco.com> Date: Thu, 22 Sep 2011 00:58:37 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Gerhard Muenz References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E78F855.3070800@cisco.com> <4E7A3F0A.102@net.in.tum.de> In-Reply-To: <4E7A3F0A.102@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] RFC5101: time first flow dropped and time last flow dropped 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, 21 Sep 2011 22:56:24 -0000 Hi Gerhard, > > Dear all, > > On 20.09.2011 22:32, Paul Aitken wrote: >> Benoit, >> >>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should >>> be the value in meteringProcessId? >>> [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache >>> name. >> >> IPFIX-CONF (or any configurer) wouldn't set the process ID; it's >> read-only. >> >> The configurer would create the process (technically, add the config >> which causes the process to be created by the OS), then could be told >> (or could discover) what the process ID is. >> The cache name could be used to relate the given config to the >> process ID. > > Correct. In general, IDs cannot be considered to be configurable. > >>> From figure 1 and 2, it seems that there is a one to one matching >>> between the cache and the metering process. >>> If this is the case, a solution could be to add a meteringProcess >>> inside the cache in the figure 12 in [IPFIX-CONF] below >> >> Do you mean, a "meteringProcessId" (IANA #144) as a read-only property? >> >> And also an "exportingProcessId" (IANA #145) as a read-only property in >> the ExportingProcess? > > I'm not sure about the one-to-one relationship between Metering > Process and Cache. On purpose, IPFIX-CONF does not make a statement > because it is not an architectural document. A Metering Process may > have multiple Caches. But I do not think that a Cache would belong to > multiple Metering Process. So, there is only one meteringProcessId > which is associated with a Cache. > > We do not have selectorId, exportingProcessId, and meteringProcessId > in the configuration data model. If we think about adding > meteringProcessId, it may be worth thinking about the other IDs as well. > > I do not see a problem if these are defined as state parameters (e.g. > read-only). Great. I propose to add them in the AUTH48 process. Regards, Benoit. > > selectorId is a bit different because the scope is OD, not IPFIX > device. Therefore, the same ID value may appear for different > Selectors of the same device. > > Gerhard From bclaise@cisco.com Wed Sep 21 16:09:00 2011 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 9C6EF21F8B4A for ; Wed, 21 Sep 2011 16:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.116, 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 J0kimkq6MMbW for ; Wed, 21 Sep 2011 16:08:59 -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 D0D4521F8B06 for ; Wed, 21 Sep 2011 16:08:58 -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 p8LNBRhb009347; Thu, 22 Sep 2011 01:11:27 +0200 (CEST) Received: from [10.55.88.40] (dhcp-10-55-88-40.cisco.com [10.55.88.40]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8LNBNUg007976; Thu, 22 Sep 2011 01:11:23 +0200 (CEST) Message-ID: <4E7A6F1B.5010600@cisco.com> Date: Thu, 22 Sep 2011 01:11:23 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Gerhard Muenz References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> In-Reply-To: <4E7A397B.3080802@net.in.tum.de> Content-Type: multipart/alternative; boundary="------------070508000000060203000802" Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 21 Sep 2011 23:09:00 -0000 This is a multi-part message in MIME format. --------------070508000000060203000802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Gerhard, Thanks for your reply. See in line. > > Hi Benoit, > > See comments inline. > > On 20.09.2011 16:19, Benoit Claise wrote: >> Dear all, >> >> [this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt, >> TO DO -> "time first flow dropped" and "time last flow dropped" >> inconsistency. See the discussion on the list.] >> >> Paul Aitken discovered this issue., >> >> From [RFC5101], section 4.3. The Exporting Process Reliability >> Statistics Option Template >> >> time first flow dropped >> The timestamp of the first _Flow _was dropped by >> the Metering Process. For this timestamp, any >> of the "flowStart" timestamp Information >> Elements flowStartMilliseconds, >> flowStartMicroseconds, flowStartNanoseconds, and >> flowStartDeltaMicroseconds can be used. >> >> time last flow dropped >> The timestamp of the last _IP packet_ that was >> ignored by the Metering Process. For this >> timestamp, any of the "flowEnd" timestamp >> Information Elements flowEndMilliseconds, >> flowEndMicroseconds, flowEndNanoseconds, and >> flowEndDeltaMicroseconds can be used. >> >> >> Firstly, these definitions are inconsistent since the names and the >> first definition say "flow" while the second definition says "IP >> packet". Obviously "IP packet" != "flow" :-o >> >> Secondly, "The timestamp of the first Flow was dropped by the >> Metering Process." is bad English: at least it's missing "that". >> >> Thirdly, the section 4.2 doesn't take into account a metering process >> id. Indeed, what if we have multiple caches on the exporter? >> >> Here is a proposal for 4.2 and 4.3. The underlined parts are new >> >> >> 4.2. The Metering Process Reliability Statistics Option Template >> >> >> >> The Metering Process Reliability Option Template specifies the >> structure of a Data Record for reporting lack of reliability in the >> Metering Process. It SHOULD contain the following Information >> Elements that are defined in [RFC5102 ]: >> >> observationDomainId >> An identifier of an Observation Domain that >> is locally unique to the Exporting Process. >> This Information Element MUST be defined as a >> Scope Field. >> >> >> _ meteringProcessId (*) >> The identifier of the Metering Process for >> which lack of reliability is reported. There >> This Information Element MUST be defined as a >> Scope Field._ >> >> ignoredPacketTotalCount >> The total number of IP packets that the >> Metering Process did not process. >> >> ignoredOctetTotalCount >> The total number of octets in observed IP >> packets that the Metering Process did not >> process. >> >> time first_packet_ignored >> The timestamp of the first IP packet that was >> ignored by the Metering Process. For this >> timestamp, any of the "flowStart" timestamp >> Information Elements flowStartMilliseconds, >> flowStartMicroseconds, flowStartNanoseconds, >> and flowStartDeltaMicroseconds can be used. >> >> time last_packet_ignored >> The timestamp of the last IP packet that was >> ignored by the Metering Process. For this >> timestamp, any of the "flowEnd" timestamp >> Information Elements flowEndMilliseconds, >> flowEndMicroseconds, flowEndNanoseconds, and >> flowEndDeltaMicroseconds can be used. > > I do not find these IEs in RFC5102. Which ones? flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds There are in http://www.iana.org/assignments/ipfix/ipfix.xml However, re-reading time first_packet_ignored The timestamp of the first IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowStart" timestamp Information Elements flowStartMilliseconds, flowStartMicroseconds, flowStartNanoseconds, and flowStartDeltaMicroseconds can be used. time last_packet_ignored The timestamp of the last IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowEnd" timestamp Information Elements flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds can be used. And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd" timestamp IE, I now believe that we should be using this series of IEs 322 observationTimeSeconds 323 observationTimeMilliseconds 324 observationTimeMicroseconds 325 observationTimeNanoseconds > >> >> 4.3. The Exporting Process Reliability Statistics Option Template >> >> >> The Exporting Process Reliability Option Template specifies the >> structure of a Data Record for reporting lack of reliability in the >> Exporting process. It SHOULD contain the following Information >> Elements that are defined in [RFC5102 ]: >> >> Exporting Process ID >> The identifier of the Exporting Process for >> which lack of reliability is reported. There >> are three Information Elements specified in >> [RFC5102 ] that can be used for this purpose: >> exporterIPv4Address, exporterIPv6Address, or >> exportingProcessId. This Information Element >> MUST be defined as a Scope Field. >> >> notSentFlowTotalCount >> The total number of Flows that were generated by >> the Metering Process and dropped by the Metering >> Process or by the Exporting Process instead of >> being sent to the Collecting Process. >> >> notSentPacketTotalCount >> The total number of packets in Flow Records that >> were generated by the Metering Process and >> dropped by the Metering Process or by the >> Exporting Process instead of being sent to the >> Collecting Process. >> >> notSentOctetTotalCount >> The total number of octets in packets in Flow >> Records that were generated by the Metering >> Process and dropped by the Metering Process or >> by the Exporting Process instead of being sent >> to the Collecting Process. >> >> time first flow dropped >> _ The time at which the first Flow Record was dropped by >> the__Exporting Process._ For this timestamp, any >> of the "flowStart" timestamp Information >> Elements flowStartMilliseconds, >> flowStartMicroseconds, flowStartNanoseconds, and >> flowStartDeltaMicroseconds can be used. >> >> time last flow dropped >> _The time at which the last Flow Record was >> dropped by the Exporting Process_. For this >> timestamp, any of the "flowEnd" timestamp >> Information Elements flowEndMilliseconds, >> flowEndMicroseconds, flowEndNanoseconds, and >> flowEndDeltaMicroseconds can be used. > > Again, I do not find these IEs in RFC5102. Same remark, I believe we should be using for the two previous IEs 322 observationTimeSeconds 323 observationTimeMilliseconds 324 observationTimeMicroseconds 325 observationTimeNanoseconds Regards, Benoit. > >> The Exporting Process SHOULD export the Data Record specified by the >> Exporting Process Reliability Statistics Option Template on a regular >> basis or based on some export policy. This periodicity or export >> policy SHOULD be configurable. >> >> >> >> >> (*) regarding the meteringProcessId, we were hesitating between the >> meteringProcessId and the cache id >> 1. there is a meteringProcessId in IPFIX IANA while there is no cache id > > meteringProcessId should do the job. > >> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should >> be the value in meteringProcessId? >> [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name. >> From figure 1 and 2, it seems that there is a one to one matching >> between the cache and the metering process. >> If this is the case, a solution could be to add a meteringProcess >> inside the cache in the figure 12 in [IPFIX-CONF] below > > See reply to Pauls mail. > > Regards, > Gerhard > >> >> 4.3. Cache Class >> >> >> +-----------------------------------+ >> | Cache | >> +-----------------------------------+ 1 +------------------+ >> | name |<>--------| immediateCache/ | >> | dataRecords {readOnly} | | timeoutCache/ | >> | cacheDiscontinuityTime {readOnly} | | naturalCache/ | >> | | | permanentCache | >> | | +------------------+ >> | | >> | | 0..* +------------------+ >> | |--------->| ExportingProcess | >> +-----------------------------------+ +------------------+ >> >> Figure 12: Cache class >> What do you think? Do you see another way? >> >> Regards, Paul & Benoit. >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix --------------070508000000060203000802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Gerhard,

Thanks for your reply.
See in line.

Hi Benoit,

See comments inline.

On 20.09.2011 16:19, Benoit Claise wrote:
Dear all,

[this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO DO -> "time first flow dropped" and "time last flow dropped" inconsistency.  See the discussion on the list.]

Paul Aitken discovered this issue.,

From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template

time first flow dropped
                        The timestamp of the first Flow was dropped by
                        the Metering Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

time last flow dropped
                        The timestamp of the last IP packet that was
                        ignored by the Metering Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.


Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o

Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".

Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter?

Here is a proposal for 4.2 and 4.3. The underlined parts are new

4.2.  The Metering Process Reliability Statistics Option Template


   The Metering Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.

    
   meteringProcessId (*)
                           The identifier of the Metering Process for
                           which lack of reliability is reported.  There
                           This Information Element MUST be defined as a 
                           Scope Field.

   ignoredPacketTotalCount
                           The total number of IP packets that the
                           Metering Process did not process.

   ignoredOctetTotalCount
                           The total number of octets in observed IP
                           packets that the Metering Process did not
                           process.

   time first packet ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last packet ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.

I do not find these IEs in RFC5102.
Which ones?  flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds
There are in http://www.iana.org/assignments/ipfix/ipfix.xml
However, re-reading 
   time first packet ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last packet ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.
And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd" timestamp IE,
I now believe that we should be using this series of IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds




4.3.  The Exporting Process Reliability Statistics Option Template

   The Exporting Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Exporting process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.

   notSentFlowTotalCount
                        The total number of Flows that were generated by
                        the Metering Process and dropped by the Metering
                        Process or by the Exporting Process instead of
                        being sent to the Collecting Process.

   notSentPacketTotalCount
                        The total number of packets in Flow Records that
                        were generated by the Metering Process and
                        dropped by the Metering Process or by the
                        Exporting Process instead of being sent to the
                        Collecting Process.

   notSentOctetTotalCount
                        The total number of octets in packets in Flow
                        Records that were generated by the Metering
                        Process and dropped by the Metering Process or
                        by the Exporting Process instead of being sent
                        to the Collecting Process.

   time first flow dropped
                        The time at which the first Flow Record was dropped by
                        the Exporting Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

   time last flow dropped
                        The time at which the last Flow Record was
                        dropped by the Exporting Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.

Again, I do not find these IEs in RFC5102.
Same remark, I believe we should be using for the two previous IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds
Regards, Benoit.

   The Exporting Process SHOULD export the Data Record specified by the
   Exporting Process Reliability Statistics Option Template on a regular
   basis or based on some export policy.  This periodicity or export
   policy SHOULD be configurable.




(*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id
1. there is a meteringProcessId in IPFIX IANA while there is no cache id

meteringProcessId should do the job.

2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId?
    [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
    From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process.
    If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below

See reply to Pauls mail.

Regards,
Gerhard

4.3.  Cache Class

    +-----------------------------------+
    | Cache                             |
    +-----------------------------------+        1 +------------------+
    | name                              |<>--------| immediateCache/  |
    | dataRecords {readOnly}            |          | timeoutCache/    |
    | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
    |                                   |          | permanentCache   |
    |                                   |          +------------------+
    |                                   |
    |                                   |     0..* +------------------+
    |                                   |--------->| ExportingProcess |
    +-----------------------------------+          +------------------+

                          Figure 12: Cache class
What do you think? Do you see another way?

Regards, Paul & Benoit.


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

--------------070508000000060203000802-- From andrewf@plixer.com Wed Sep 21 19:47:12 2011 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 9071021F8B12 for ; Wed, 21 Sep 2011 19:47:12 -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 QmoGSWV0rACK for ; Wed, 21 Sep 2011 19:47:11 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 99EF221F8B18 for ; Wed, 21 Sep 2011 19:47:10 -0700 (PDT) Received: from [192.168.1.25] ([70.109.142.16]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Sep 2011 22:49:38 -0400 Message-ID: <4E7AA240.4020506@plixer.com> Date: Wed, 21 Sep 2011 22:49:36 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: ipfix@ietf.org References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> In-Reply-To: <4E7A6F1B.5010600@cisco.com> Content-Type: multipart/alternative; boundary="------------040609040606070200030107" X-OriginalArrivalTime: 22 Sep 2011 02:49:38.0489 (UTC) FILETIME=[451CEA90:01CC78D2] Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 22 Sep 2011 02:47:12 -0000 This is a multi-part message in MIME format. --------------040609040606070200030107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Benoit, I had the same thought about using 322 observationTimeSeconds 323 observationTimeMilliseconds 324 observationTimeMicroseconds 325 observationTimeNanoseconds The problem is that you need two timestamps in the same record (first and last). How does that work with the above? -Andrew On 09/21/2011 07:11 PM, Benoit Claise wrote: > Hi Gerhard, > > Thanks for your reply. > See in line. >> >> Hi Benoit, >> >> See comments inline. >> >> On 20.09.2011 16:19, Benoit Claise wrote: >>> Dear all, >>> >>> [this email addresses >>> draft-claise-ipfix-protocol-rfc5101bis-00.txt, TO DO -> "time first >>> flow dropped" and "time last flow dropped" inconsistency. See the >>> discussion on the list.] >>> >>> Paul Aitken discovered this issue., >>> >>> From [RFC5101], section 4.3. The Exporting Process Reliability >>> Statistics Option Template >>> >>> time first flow dropped >>> The timestamp of the first _Flow _was >>> dropped by >>> the Metering Process. For this timestamp, any >>> of the "flowStart" timestamp Information >>> Elements flowStartMilliseconds, >>> flowStartMicroseconds, flowStartNanoseconds, >>> and >>> flowStartDeltaMicroseconds can be used. >>> >>> time last flow dropped >>> The timestamp of the last _IP packet_ that was >>> ignored by the Metering Process. For this >>> timestamp, any of the "flowEnd" timestamp >>> Information Elements flowEndMilliseconds, >>> flowEndMicroseconds, flowEndNanoseconds, and >>> flowEndDeltaMicroseconds can be used. >>> >>> >>> Firstly, these definitions are inconsistent since the names and the >>> first definition say "flow" while the second definition says "IP >>> packet". Obviously "IP packet" != "flow" :-o >>> >>> Secondly, "The timestamp of the first Flow was dropped by the >>> Metering Process." is bad English: at least it's missing "that". >>> >>> Thirdly, the section 4.2 doesn't take into account a metering >>> process id. Indeed, what if we have multiple caches on the exporter? >>> >>> Here is a proposal for 4.2 and 4.3. The underlined parts are new >>> >>> >>> 4.2. The Metering Process Reliability Statistics Option Template >>> >>> >>> >>> The Metering Process Reliability Option Template specifies the >>> structure of a Data Record for reporting lack of reliability in the >>> Metering Process. It SHOULD contain the following Information >>> Elements that are defined in [RFC5102 ]: >>> >>> observationDomainId >>> An identifier of an Observation Domain that >>> is locally unique to the Exporting Process. >>> This Information Element MUST be defined as a >>> Scope Field. >>> >>> >>> _ meteringProcessId (*) >>> The identifier of the Metering Process for >>> which lack of reliability is reported. There >>> This Information Element MUST be defined as a >>> Scope Field._ >>> >>> ignoredPacketTotalCount >>> The total number of IP packets that the >>> Metering Process did not process. >>> >>> ignoredOctetTotalCount >>> The total number of octets in observed IP >>> packets that the Metering Process did not >>> process. >>> >>> time first _packet _ignored >>> The timestamp of the first IP packet that was >>> ignored by the Metering Process. For this >>> timestamp, any of the "flowStart" timestamp >>> Information Elements flowStartMilliseconds, >>> flowStartMicroseconds, flowStartNanoseconds, >>> and flowStartDeltaMicroseconds can be used. >>> >>> time last _packet _ignored >>> The timestamp of the last IP packet that was >>> ignored by the Metering Process. For this >>> timestamp, any of the "flowEnd" timestamp >>> Information Elements flowEndMilliseconds, >>> flowEndMicroseconds, flowEndNanoseconds, and >>> flowEndDeltaMicroseconds can be used. >> >> I do not find these IEs in RFC5102. > Which ones? flowEndMilliseconds, flowEndMicroseconds, > flowEndNanoseconds, and flowEndDeltaMicroseconds > There are in http://www.iana.org/assignments/ipfix/ipfix.xml > However, re-reading > time first _packet _ignored > The timestamp of the first IP packet that was > ignored by the Metering Process. For this > timestamp, any of the "flowStart" timestamp > Information Elements flowStartMilliseconds, > flowStartMicroseconds, flowStartNanoseconds, > and flowStartDeltaMicroseconds can be used. > > time last _packet _ignored > The timestamp of the last IP packet that was > ignored by the Metering Process. For this > timestamp, any of the "flowEnd" timestamp > Information Elements flowEndMilliseconds, > flowEndMicroseconds, flowEndNanoseconds, and > flowEndDeltaMicroseconds can be used. > And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd" > timestamp IE, > I now believe that we should be using this series of IEs > > 322 observationTimeSeconds > 323 observationTimeMilliseconds > 324 observationTimeMicroseconds > 325 observationTimeNanoseconds > > >> >>> 4.3. The Exporting Process Reliability Statistics Option Template >>> >>> >>> The Exporting Process Reliability Option Template specifies the >>> structure of a Data Record for reporting lack of reliability in the >>> Exporting process. It SHOULD contain the following Information >>> Elements that are defined in [RFC5102 ]: >>> >>> Exporting Process ID >>> The identifier of the Exporting Process for >>> which lack of reliability is reported. There >>> are three Information Elements specified in >>> [RFC5102 ] that can be used for this purpose: >>> exporterIPv4Address, exporterIPv6Address, or >>> exportingProcessId. This Information Element >>> MUST be defined as a Scope Field. >>> >>> notSentFlowTotalCount >>> The total number of Flows that were generated by >>> the Metering Process and dropped by the Metering >>> Process or by the Exporting Process instead of >>> being sent to the Collecting Process. >>> >>> notSentPacketTotalCount >>> The total number of packets in Flow Records that >>> were generated by the Metering Process and >>> dropped by the Metering Process or by the >>> Exporting Process instead of being sent to the >>> Collecting Process. >>> >>> notSentOctetTotalCount >>> The total number of octets in packets in Flow >>> Records that were generated by the Metering >>> Process and dropped by the Metering Process or >>> by the Exporting Process instead of being sent >>> to the Collecting Process. >>> >>> time first flow dropped >>> _ The time at which the first Flow Record was dropped by >>> the __Exporting Process._ For this timestamp, any >>> of the "flowStart" timestamp Information >>> Elements flowStartMilliseconds, >>> flowStartMicroseconds, flowStartNanoseconds, and >>> flowStartDeltaMicroseconds can be used. >>> >>> time last flow dropped >>> _The time at which the last Flow Record was >>> dropped by the Exporting Process_. For this >>> timestamp, any of the "flowEnd" timestamp >>> Information Elements flowEndMilliseconds, >>> flowEndMicroseconds, flowEndNanoseconds, and >>> flowEndDeltaMicroseconds can be used. >> >> Again, I do not find these IEs in RFC5102. > Same remark, I believe we should be using for the two previous IEs > > 322 observationTimeSeconds > 323 observationTimeMilliseconds > 324 observationTimeMicroseconds > 325 observationTimeNanoseconds > > Regards, Benoit. >> >>> The Exporting Process SHOULD export the Data Record specified by the >>> Exporting Process Reliability Statistics Option Template on a regular >>> basis or based on some export policy. This periodicity or export >>> policy SHOULD be configurable. >>> >>> >>> >>> >>> (*) regarding the meteringProcessId, we were hesitating between the >>> meteringProcessId and the cache id >>> 1. there is a meteringProcessId in IPFIX IANA while there is no cache id >> >> meteringProcessId should do the job. >> >>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what >>> should be the value in meteringProcessId? >>> [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache >>> name. >>> From figure 1 and 2, it seems that there is a one to one >>> matching between the cache and the metering process. >>> If this is the case, a solution could be to add a >>> meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below >> >> See reply to Pauls mail. >> >> Regards, >> Gerhard >> >>> >>> 4.3. Cache Class >>> >>> >>> +-----------------------------------+ >>> | Cache | >>> +-----------------------------------+ 1 +------------------+ >>> | name |<>--------| immediateCache/ | >>> | dataRecords {readOnly} | | timeoutCache/ | >>> | cacheDiscontinuityTime {readOnly} | | naturalCache/ | >>> | | | permanentCache | >>> | | +------------------+ >>> | | >>> | | 0..* +------------------+ >>> | |--------->| ExportingProcess | >>> +-----------------------------------+ +------------------+ >>> >>> Figure 12: Cache class >>> What do you think? Do you see another way? >>> >>> Regards, Paul & Benoit. >>> >>> >>> _______________________________________________ >>> 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 --------------040609040606070200030107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Benoit,

I had the same thought about using

322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds

The problem is that you need two timestamps in the same record (first and last).  How does that work with the above?

-Andrew

On 09/21/2011 07:11 PM, Benoit Claise wrote:
Hi Gerhard,

Thanks for your reply.
See in line.

Hi Benoit,

See comments inline.

On 20.09.2011 16:19, Benoit Claise wrote:
Dear all,

[this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO DO -> "time first flow dropped" and "time last flow dropped" inconsistency.  See the discussion on the list.]

Paul Aitken discovered this issue.,

From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template

time first flow dropped
                        The timestamp of the first Flow was dropped by
                        the Metering Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

time last flow dropped
                        The timestamp of the last IP packet that was
                        ignored by the Metering Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.


Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o

Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".

Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter?

Here is a proposal for 4.2 and 4.3. The underlined parts are new

4.2.  The Metering Process Reliability Statistics Option Template


   The Metering Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.

    
   meteringProcessId (*)
                           The identifier of the Metering Process for
                           which lack of reliability is reported.  There
                           This Information Element MUST be defined as a 
                           Scope Field.

   ignoredPacketTotalCount
                           The total number of IP packets that the
                           Metering Process did not process.

   ignoredOctetTotalCount
                           The total number of octets in observed IP
                           packets that the Metering Process did not
                           process.

   time first packet ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last packet ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.

I do not find these IEs in RFC5102.
Which ones?  flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds
There are in http://www.iana.org/assignments/ipfix/ipfix.xml
However, re-reading 
   time first packet ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last packet ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.
And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd" timestamp IE,
I now believe that we should be using this series of IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds


4.3.  The Exporting Process Reliability Statistics Option Template

   The Exporting Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Exporting process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.

   notSentFlowTotalCount
                        The total number of Flows that were generated by
                        the Metering Process and dropped by the Metering
                        Process or by the Exporting Process instead of
                        being sent to the Collecting Process.

   notSentPacketTotalCount
                        The total number of packets in Flow Records that
                        were generated by the Metering Process and
                        dropped by the Metering Process or by the
                        Exporting Process instead of being sent to the
                        Collecting Process.

   notSentOctetTotalCount
                        The total number of octets in packets in Flow
                        Records that were generated by the Metering
                        Process and dropped by the Metering Process or
                        by the Exporting Process instead of being sent
                        to the Collecting Process.

   time first flow dropped
                        The time at which the first Flow Record was dropped by
                        the Exporting Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

   time last flow dropped
                        The time at which the last Flow Record was
                        dropped by the Exporting Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.

Again, I do not find these IEs in RFC5102.
Same remark, I believe we should be using for the two previous IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds
Regards, Benoit.

   The Exporting Process SHOULD export the Data Record specified by the
   Exporting Process Reliability Statistics Option Template on a regular
   basis or based on some export policy.  This periodicity or export
   policy SHOULD be configurable.




(*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id
1. there is a meteringProcessId in IPFIX IANA while there is no cache id

meteringProcessId should do the job.

2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId?
    [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
    From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process.
    If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below

See reply to Pauls mail.

Regards,
Gerhard

4.3.  Cache Class

    +-----------------------------------+
    | Cache                             |
    +-----------------------------------+        1 +------------------+
    | name                              |<>--------| immediateCache/  |
    | dataRecords {readOnly}            |          | timeoutCache/    |
    | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
    |                                   |          | permanentCache   |
    |                                   |          +------------------+
    |                                   |
    |                                   |     0..* +------------------+
    |                                   |--------->| ExportingProcess |
    +-----------------------------------+          +------------------+

                          Figure 12: Cache class
What do you think? Do you see another way?

Regards, Paul & Benoit.


_______________________________________________
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

--------------040609040606070200030107-- From bclaise@cisco.com Thu Sep 22 00:52:30 2011 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 784F921F8B04 for ; Thu, 22 Sep 2011 00:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] 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 BvhO3R6VRxNL for ; Thu, 22 Sep 2011 00:52:29 -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 7912921F8B03 for ; Thu, 22 Sep 2011 00:52:28 -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 p8M7sw9H004629; Thu, 22 Sep 2011 09:54:58 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8M7svIj000179; Thu, 22 Sep 2011 09:54:57 +0200 (CEST) Message-ID: <4E7AE9D1.9090002@cisco.com> Date: Thu, 22 Sep 2011 09:54:57 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Andrew Feren References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> <4E7AA240.4020506@plixer.com> In-Reply-To: <4E7AA240.4020506@plixer.com> Content-Type: multipart/alternative; boundary="------------090708070501080602080800" Cc: ipfix@ietf.org Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 22 Sep 2011 07:52:30 -0000 This is a multi-part message in MIME format. --------------090708070501080602080800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Andrew, > Hi Benoit, > > I had the same thought about using > > 322 observationTimeSeconds > 323 observationTimeMilliseconds > 324 observationTimeMicroseconds > 325 observationTimeNanoseconds > > The problem is that you need two timestamps in the same record (first > and last). How does that work with the above? Excellent question. We debated this question with Paul Aitken recently. Let me rephrase the question slightly differently: how does the collector determine that this is a "The Metering Process Reliability Statistics Options Template", and understands the semantic of the two counters? Well. Two solutions: 1. we duplicate all the IEs to have the exact correct semantic. ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] ... and potentially some more such as pre|post This brings multiple new dimensions to IE and will lead to an explosion of IEs if we want to cover all the case 2. the collector tests the possible combination of IE in the Options Template Record. For example, if the collector sees such an Options Template Record, it knows that this a "The Metering Process Reliability Statistics Options Template" observationDomainId (scope) meteringProcessId (scope)_ _ ignoredPacketTotalCount ignoredOctetTotalCount observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds While the solution 2 is not perfect, this was the chosen track. Does it make sense? Regards, Benoit > > -Andrew > > On 09/21/2011 07:11 PM, Benoit Claise wrote: >> Hi Gerhard, >> >> Thanks for your reply. >> See in line. >>> >>> Hi Benoit, >>> >>> See comments inline. >>> >>> On 20.09.2011 16:19, Benoit Claise wrote: >>>> Dear all, >>>> >>>> [this email addresses >>>> draft-claise-ipfix-protocol-rfc5101bis-00.txt, TO DO -> "time >>>> first flow dropped" and "time last flow dropped" inconsistency. >>>> See the discussion on the list.] >>>> >>>> Paul Aitken discovered this issue., >>>> >>>> From [RFC5101], section 4.3. The Exporting Process Reliability >>>> Statistics Option Template >>>> >>>> time first flow dropped >>>> The timestamp of the first _Flow _was >>>> dropped by >>>> the Metering Process. For this timestamp, any >>>> of the "flowStart" timestamp Information >>>> Elements flowStartMilliseconds, >>>> flowStartMicroseconds, >>>> flowStartNanoseconds, and >>>> flowStartDeltaMicroseconds can be used. >>>> >>>> time last flow dropped >>>> The timestamp of the last _IP packet_ that was >>>> ignored by the Metering Process. For this >>>> timestamp, any of the "flowEnd" timestamp >>>> Information Elements flowEndMilliseconds, >>>> flowEndMicroseconds, flowEndNanoseconds, and >>>> flowEndDeltaMicroseconds can be used. >>>> >>>> >>>> Firstly, these definitions are inconsistent since the names and the >>>> first definition say "flow" while the second definition says "IP >>>> packet". Obviously "IP packet" != "flow" :-o >>>> >>>> Secondly, "The timestamp of the first Flow was dropped by the >>>> Metering Process." is bad English: at least it's missing "that". >>>> >>>> Thirdly, the section 4.2 doesn't take into account a metering >>>> process id. Indeed, what if we have multiple caches on the exporter? >>>> >>>> Here is a proposal for 4.2 and 4.3. The underlined parts are new >>>> >>>> >>>> 4.2. The Metering Process Reliability Statistics Option Template >>>> >>>> >>>> >>>> The Metering Process Reliability Option Template specifies the >>>> structure of a Data Record for reporting lack of reliability in the >>>> Metering Process. It SHOULD contain the following Information >>>> Elements that are defined in [RFC5102 ]: >>>> >>>> observationDomainId >>>> An identifier of an Observation Domain that >>>> is locally unique to the Exporting Process. >>>> This Information Element MUST be defined as a >>>> Scope Field. >>>> >>>> >>>> _ meteringProcessId (*) >>>> The identifier of the Metering Process for >>>> which lack of reliability is reported. There >>>> This Information Element MUST be defined as a >>>> Scope Field._ >>>> >>>> ignoredPacketTotalCount >>>> The total number of IP packets that the >>>> Metering Process did not process. >>>> >>>> ignoredOctetTotalCount >>>> The total number of octets in observed IP >>>> packets that the Metering Process did not >>>> process. >>>> >>>> time first_packet_ignored >>>> The timestamp of the first IP packet that was >>>> ignored by the Metering Process. For this >>>> timestamp, any of the "flowStart" timestamp >>>> Information Elements flowStartMilliseconds, >>>> flowStartMicroseconds, flowStartNanoseconds, >>>> and flowStartDeltaMicroseconds can be used. >>>> >>>> time last_packet_ignored >>>> The timestamp of the last IP packet that was >>>> ignored by the Metering Process. For this >>>> timestamp, any of the "flowEnd" timestamp >>>> Information Elements flowEndMilliseconds, >>>> flowEndMicroseconds, flowEndNanoseconds, and >>>> flowEndDeltaMicroseconds can be used. >>> >>> I do not find these IEs in RFC5102. >> Which ones? flowEndMilliseconds, flowEndMicroseconds, >> flowEndNanoseconds, and flowEndDeltaMicroseconds >> There are in http://www.iana.org/assignments/ipfix/ipfix.xml >> However, re-reading >> time first_packet_ignored >> The timestamp of the first IP packet that was >> ignored by the Metering Process. For this >> timestamp, any of the "flowStart" timestamp >> Information Elements flowStartMilliseconds, >> flowStartMicroseconds, flowStartNanoseconds, >> and flowStartDeltaMicroseconds can be used. >> >> time last_packet_ignored >> The timestamp of the last IP packet that was >> ignored by the Metering Process. For this >> timestamp, any of the "flowEnd" timestamp >> Information Elements flowEndMilliseconds, >> flowEndMicroseconds, flowEndNanoseconds, and >> flowEndDeltaMicroseconds can be used. >> And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd" >> timestamp IE, >> I now believe that we should be using this series of IEs >> >> 322 observationTimeSeconds >> 323 observationTimeMilliseconds >> 324 observationTimeMicroseconds >> 325 observationTimeNanoseconds >> >> >>> >>>> 4.3. The Exporting Process Reliability Statistics Option Template >>>> >>>> >>>> The Exporting Process Reliability Option Template specifies the >>>> structure of a Data Record for reporting lack of reliability in the >>>> Exporting process. It SHOULD contain the following Information >>>> Elements that are defined in [RFC5102 ]: >>>> >>>> Exporting Process ID >>>> The identifier of the Exporting Process for >>>> which lack of reliability is reported. There >>>> are three Information Elements specified in >>>> [RFC5102 ] that can be used for this purpose: >>>> exporterIPv4Address, exporterIPv6Address, or >>>> exportingProcessId. This Information Element >>>> MUST be defined as a Scope Field. >>>> >>>> notSentFlowTotalCount >>>> The total number of Flows that were generated by >>>> the Metering Process and dropped by the Metering >>>> Process or by the Exporting Process instead of >>>> being sent to the Collecting Process. >>>> >>>> notSentPacketTotalCount >>>> The total number of packets in Flow Records that >>>> were generated by the Metering Process and >>>> dropped by the Metering Process or by the >>>> Exporting Process instead of being sent to the >>>> Collecting Process. >>>> >>>> notSentOctetTotalCount >>>> The total number of octets in packets in Flow >>>> Records that were generated by the Metering >>>> Process and dropped by the Metering Process or >>>> by the Exporting Process instead of being sent >>>> to the Collecting Process. >>>> >>>> time first flow dropped >>>> _ The time at which the first Flow Record was dropped by >>>> the__Exporting Process._ For this timestamp, any >>>> of the "flowStart" timestamp Information >>>> Elements flowStartMilliseconds, >>>> flowStartMicroseconds, flowStartNanoseconds, and >>>> flowStartDeltaMicroseconds can be used. >>>> >>>> time last flow dropped >>>> _The time at which the last Flow Record was >>>> dropped by the Exporting Process_. For this >>>> timestamp, any of the "flowEnd" timestamp >>>> Information Elements flowEndMilliseconds, >>>> flowEndMicroseconds, flowEndNanoseconds, and >>>> flowEndDeltaMicroseconds can be used. >>> >>> Again, I do not find these IEs in RFC5102. >> Same remark, I believe we should be using for the two previous IEs >> >> 322 observationTimeSeconds >> 323 observationTimeMilliseconds >> 324 observationTimeMicroseconds >> 325 observationTimeNanoseconds >> >> Regards, Benoit. >>> >>>> The Exporting Process SHOULD export the Data Record specified by the >>>> Exporting Process Reliability Statistics Option Template on a regular >>>> basis or based on some export policy. This periodicity or export >>>> policy SHOULD be configurable. >>>> >>>> >>>> >>>> >>>> (*) regarding the meteringProcessId, we were hesitating between the >>>> meteringProcessId and the cache id >>>> 1. there is a meteringProcessId in IPFIX IANA while there is no >>>> cache id >>> >>> meteringProcessId should do the job. >>> >>>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what >>>> should be the value in meteringProcessId? >>>> [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache >>>> name. >>>> From figure 1 and 2, it seems that there is a one to one >>>> matching between the cache and the metering process. >>>> If this is the case, a solution could be to add a >>>> meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below >>> >>> See reply to Pauls mail. >>> >>> Regards, >>> Gerhard >>> >>>> >>>> 4.3. Cache Class >>>> >>>> >>>> +-----------------------------------+ >>>> | Cache | >>>> +-----------------------------------+ 1 +------------------+ >>>> | name |<>--------| immediateCache/ | >>>> | dataRecords {readOnly} | | timeoutCache/ | >>>> | cacheDiscontinuityTime {readOnly} | | naturalCache/ | >>>> | | | permanentCache | >>>> | | +------------------+ >>>> | | >>>> | | 0..* +------------------+ >>>> | |--------->| ExportingProcess | >>>> +-----------------------------------+ +------------------+ >>>> >>>> Figure 12: Cache class >>>> What do you think? Do you see another way? >>>> >>>> Regards, Paul & Benoit. >>>> >>>> >>>> _______________________________________________ >>>> 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 --------------090708070501080602080800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Andrew,
Hi Benoit,

I had the same thought about using

322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds

The problem is that you need two timestamps in the same record (first and last).  How does that work with the above?
Excellent question. We debated this question with Paul Aitken recently.
Let me rephrase the question slightly differently: how does the collector determine that this is a "The Metering Process Reliability Statistics Options Template", and understands the semantic of the two counters?
Well. Two solutions:
1. we duplicate all the IEs to have the exact correct semantic.
    ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] ... and potentially some more such as pre|post
    This brings multiple new dimensions to IE and will lead to an explosion of IEs if we want to cover all the case
2. the collector tests the possible combination of IE in the Options Template Record.
    For example, if the collector sees such an Options Template Record, it knows that this a "The Metering Process Reliability Statistics Options Template" 
  observationDomainId (scope)
  meteringProcessId (scope)
  ignoredPacketTotalCount
  ignoredOctetTotalCount
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
While the solution 2 is not perfect, this was the chosen track.

Does it make sense?

Regards, Benoit

-Andrew

On 09/21/2011 07:11 PM, Benoit Claise wrote:
Hi Gerhard,

Thanks for your reply.
See in line.

Hi Benoit,

See comments inline.

On 20.09.2011 16:19, Benoit Claise wrote:
Dear all,

[this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO DO -> "time first flow dropped" and "time last flow dropped" inconsistency.  See the discussion on the list.]

Paul Aitken discovered this issue.,

From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template

time first flow dropped
                        The timestamp of the first Flow was dropped by
                        the Metering Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

time last flow dropped
                        The timestamp of the last IP packet that was
                        ignored by the Metering Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.


Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o

Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".

Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter?

Here is a proposal for 4.2 and 4.3. The underlined parts are new

4.2.  The Metering Process Reliability Statistics Option Template


   The Metering Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.

    
   meteringProcessId (*)
                           The identifier of the Metering Process for
                           which lack of reliability is reported.  There
                           This Information Element MUST be defined as a 
                           Scope Field.

   ignoredPacketTotalCount
                           The total number of IP packets that the
                           Metering Process did not process.

   ignoredOctetTotalCount
                           The total number of octets in observed IP
                           packets that the Metering Process did not
                           process.

   time first packet ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last packet ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.

I do not find these IEs in RFC5102.
Which ones?  flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds
There are in http://www.iana.org/assignments/ipfix/ipfix.xml
However, re-reading 
   time first packet ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last packet ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.
And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd" timestamp IE,
I now believe that we should be using this series of IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds


4.3.  The Exporting Process Reliability Statistics Option Template

   The Exporting Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Exporting process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.

   notSentFlowTotalCount
                        The total number of Flows that were generated by
                        the Metering Process and dropped by the Metering
                        Process or by the Exporting Process instead of
                        being sent to the Collecting Process.

   notSentPacketTotalCount
                        The total number of packets in Flow Records that
                        were generated by the Metering Process and
                        dropped by the Metering Process or by the
                        Exporting Process instead of being sent to the
                        Collecting Process.

   notSentOctetTotalCount
                        The total number of octets in packets in Flow
                        Records that were generated by the Metering
                        Process and dropped by the Metering Process or
                        by the Exporting Process instead of being sent
                        to the Collecting Process.

   time first flow dropped
                        The time at which the first Flow Record was dropped by
                        the Exporting Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

   time last flow dropped
                        The time at which the last Flow Record was
                        dropped by the Exporting Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.

Again, I do not find these IEs in RFC5102.
Same remark, I believe we should be using for the two previous IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds
Regards, Benoit.

   The Exporting Process SHOULD export the Data Record specified by the
   Exporting Process Reliability Statistics Option Template on a regular
   basis or based on some export policy.  This periodicity or export
   policy SHOULD be configurable.




(*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id
1. there is a meteringProcessId in IPFIX IANA while there is no cache id

meteringProcessId should do the job.

2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId?
    [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
    From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process.
    If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below

See reply to Pauls mail.

Regards,
Gerhard

4.3.  Cache Class

    +-----------------------------------+
    | Cache                             |
    +-----------------------------------+        1 +------------------+
    | name                              |<>--------| immediateCache/  |
    | dataRecords {readOnly}            |          | timeoutCache/    |
    | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
    |                                   |          | permanentCache   |
    |                                   |          +------------------+
    |                                   |
    |                                   |     0..* +------------------+
    |                                   |--------->| ExportingProcess |
    +-----------------------------------+          +------------------+

                          Figure 12: Cache class
What do you think? Do you see another way?

Regards, Paul & Benoit.


_______________________________________________
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

--------------090708070501080602080800-- From muenz@net.in.tum.de Thu Sep 22 05:17:25 2011 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 2254421F8C16 for ; Thu, 22 Sep 2011 05:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 QCj4eeSjt2eF for ; Thu, 22 Sep 2011 05:17:24 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 115CE21F8770 for ; Thu, 22 Sep 2011 05:17:23 -0700 (PDT) Received: by mail.net.in.tum.de (Postfix, from userid 81) id 658DB201B438; Thu, 22 Sep 2011 14:20:02 +0200 (CEST) To: Benoit Claise X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 22 Sep 2011 14:20:02 +0200 From: Gerhard Muenz In-Reply-To: <4E7A6F1B.5010600@cisco.com> References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> Message-ID: X-Sender: muenz@net.in.tum.de User-Agent: Roundcube Webmail/0.5.4 Cc: ipfix@ietf.org Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 22 Sep 2011 12:17:25 -0000 Hi Benoit, You are right. I was confused because "time first packet ignored" is not an IE name. Regards, Gerhard On Thu, 22 Sep 2011 01:11:23 +0200, Benoit Claise wrote: > Hi Gerhard, > > Thanks for your reply. > See in line. > >> Hi Benoit, >> >> See comments inline. >> >> On 20.09.2011 16:19, Benoit Claise wrote: >> >>> Dear all, >>> >>> [this email addresses >>> draft-claise-ipfix-protocol-rfc5101bis-00.txt, TO DO -> "time >>> first flow dropped" and "time last flow dropped" inconsistency. >>> See the discussion on the list.] >>> >>> Paul Aitken discovered this issue., >>> >>> From [RFC5101], section 4.3. The Exporting Process Reliability >>> Statistics Option Template >>> >>> time first flow dropped >>> The timestamp of the first Flow was dropped by >>> the Metering Process. For this timestamp, any >>> of the "flowStart" timestamp Information >>> Elements flowStartMilliseconds, >>> flowStartMicroseconds, flowStartNanoseconds, and >>> flowStartDeltaMicroseconds can be used. >>> >>> time last flow dropped >>> The timestamp of the last IP packet that was >>> ignored by the Metering Process. For this >>> timestamp, any of the "flowEnd" timestamp >>> Information Elements flowEndMilliseconds, >>> flowEndMicroseconds, flowEndNanoseconds, and >>> flowEndDeltaMicroseconds can be used. >>> >>> Firstly, these definitions are inconsistent since the names and >>> the first definition say "flow" while the second definition says >>> "IP packet". Obviously "IP packet" != "flow" :-o >>> >>> Secondly, "The timestamp of the first Flow was dropped by the >>> Metering Process." is bad English: at least it's missing "that". >>> >>> Thirdly, the section 4.2 doesn't take into account a metering >>> process id. Indeed, what if we have multiple caches on the >>> exporter? >>> >>> Here is a proposal for 4.2 and 4.3. The underlined parts are new >>> >>> 4.2. THE METERING PROCESS RELIABILITY STATISTICS OPTION TEMPLATE >>> >>> The Metering Process Reliability Option Template specifies the >>> structure of a Data Record for reporting lack of reliability in >>> the >>> Metering Process. It SHOULD contain the following Information >>> Elements that are defined in [RFC5102 [1]]: >>> >>> observationDomainId >>> An identifier of an Observation Domain that >>> is locally unique to the Exporting Process. >>> This Information Element MUST be defined as a >>> Scope Field. >>> >>> meteringProcessId (*) >>> The identifier of the Metering Process for >>> which lack of reliability is reported. There >>> This Information Element MUST be defined as a >>> Scope Field. >>> >>> ignoredPacketTotalCount >>> The total number of IP packets that the >>> Metering Process did not process. >>> >>> ignoredOctetTotalCount >>> The total number of octets in observed IP >>> packets that the Metering Process did not >>> process. >>> >>> time first packet ignored >>> The timestamp of the first IP packet that was >>> ignored by the Metering Process. For this >>> timestamp, any of the "flowStart" timestamp >>> Information Elements flowStartMilliseconds, >>> flowStartMicroseconds, flowStartNanoseconds, >>> and flowStartDeltaMicroseconds can be used. >>> >>> time last packet ignored >>> The timestamp of the last IP packet that was >>> ignored by the Metering Process. For this >>> timestamp, any of the "flowEnd" timestamp >>> Information Elements flowEndMilliseconds, >>> flowEndMicroseconds, flowEndNanoseconds, and >>> flowEndDeltaMicroseconds can be used. >> >> I do not find these IEs in RFC5102. > Which ones? flowEndMilliseconds, flowEndMicroseconds, > flowEndNanoseconds, and flowEndDeltaMicroseconds > There are in http://www.iana.org/assignments/ipfix/ipfix.xml [2] > However, re-reading > > time first packet ignored > The timestamp of the first IP packet that was > ignored by the Metering Process. For this > timestamp, any of the "flowStart" timestamp > Information Elements flowStartMilliseconds, > flowStartMicroseconds, flowStartNanoseconds, > and flowStartDeltaMicroseconds can be used. > > time last packet ignored > The timestamp of the last IP packet that was > ignored by the Metering Process. For this > timestamp, any of the "flowEnd" timestamp > Information Elements flowEndMilliseconds, > flowEndMicroseconds, flowEndNanoseconds, and > flowEndDeltaMicroseconds can be used. > And http://www.iana.org/assignments/ipfix/ipfix.xml [3] for the > "flowEnd" timestamp IE, > I now believe that we should be using this series of IEs > >> 322 observationTimeSeconds >> 323 observationTimeMilliseconds >> 324 observationTimeMicroseconds >> 325 observationTimeNanoseconds > > 4.3. THE EXPORTING PROCESS RELIABILITY STATISTICS OPTION TEMPLATE > > The Exporting Process Reliability Option Template specifies the > structure of a Data Record for reporting lack of reliability in the > Exporting process. It SHOULD contain the following Information > Elements that are defined in [RFC5102 [4]]: > > Exporting Process ID > The identifier of the Exporting Process for > which lack of reliability is reported. There > are three Information Elements specified in > [RFC5102 [5]] that can be used for this purpose: > exporterIPv4Address, exporterIPv6Address, or > exportingProcessId. This Information Element > MUST be defined as a Scope Field. > > notSentFlowTotalCount > The total number of Flows that were generated by > the Metering Process and dropped by the Metering > Process or by the Exporting Process instead of > being sent to the Collecting Process. > > notSentPacketTotalCount > The total number of packets in Flow Records that > were generated by the Metering Process and > dropped by the Metering Process or by the > Exporting Process instead of being sent to the > Collecting Process. > > notSentOctetTotalCount > The total number of octets in packets in Flow > Records that were generated by the Metering > Process and dropped by the Metering Process or > by the Exporting Process instead of being sent > to the Collecting Process. > > time first flow dropped > The time at which the first Flow Record was dropped by > the Exporting Process. For this timestamp, any > of the "flowStart" timestamp Information > Elements flowStartMilliseconds, > > flowStartDeltaMicroseconds can be used. time last flow dropped The >> time at which the last Flow Record was dropped by the Exporting >> Process. For this timestamp, any of the "flowEnd" timestamp >> Information Elements flowEndMilliseconds, flowEndMicroseconds, >> flowEndNanoseconds, and flowEndDeltaMicroseconds can be used. >> Again, I do not find these IEs in RFC5102. >> Same remark, I believe we should be using for the two previous IEs >> >>> 322 observationTimeSeconds >>> 323 observationTimeMilliseconds >>> 324 observationTimeMicroseconds >>> 325 observationTimeNanoseconds >> Regards, Benoit. >> >> The Exporting Process SHOULD export the Data Record specified by >> the >> Exporting Process Reliability Statistics Option Template on a >> regular >> basis or based on some export policy. This periodicity or export >> policy SHOULD be configurable. >> >> (*) regarding the meteringProcessId, we were hesitating between the >> meteringProcessId and the cache id >> 1. there is a meteringProcessId in IPFIX IANA while there is no >> cache id >> >> meteringProcessId should do the job. >> >> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what >> should be the value in meteringProcessId? >> [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache >> name. >> From figure 1 and 2, it seems that there is a one to one matching >> between the cache and the metering process. >> If this is the case, a solution could be to add a meteringProcess >> inside the cache in the figure 12 in [IPFIX-CONF] below >> >> See reply to Pauls mail. >> >> Regards, >> Gerhard >> >> 4.3. CACHE CLASS >> >> +-----------------------------------+ | Cache | >> +-----------------------------------+ 1 +------------------+ | name >> |--------| immediateCache/ | | dataRecords {readOnly} | | >> timeoutCache/ | | cacheDiscontinuityTime {readOnly} | | >> naturalCache/ | | | | permanentCache | | | +------------------+ | | >> | > | 0..* +------------------+ | |--------->| ExportingProcess | > +-----------------------------------+ +----------------- > >> Figure 12: Cache class What do you think? Do you see another way? >> >> Regards, Paul & Benoit. > br> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org [6] > https://www.ietf.org/mailman/listinfo/ipfix [7] > >> > > > Links: > ------ > [1] http://tools.ietf.org/html/rfc5102 > [2] http://www.iana.org/assignments/ipfix/ipfix.xml > [3] http://www.iana.org/assignments/ipfix/ipfix.xml > [4] http://tools.ietf.org/html/rfc5102 > [5] http://tools.ietf.org/html/rfc5102 > [6] mailto:IPFIX@ietf.org > [7] https://www.ietf.org/mailman/listinfo/ipfix From andrewf@plixer.com Fri Sep 23 14:04:32 2011 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 B82CF21F8CB6 for ; Fri, 23 Sep 2011 14:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] 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 lPyRZcGpskdl for ; Fri, 23 Sep 2011 14:04:31 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id A847121F8CC3 for ; Fri, 23 Sep 2011 14:04:30 -0700 (PDT) Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Sep 2011 17:07:05 -0400 Message-ID: <4E7CF4F8.8060405@plixer.com> Date: Fri, 23 Sep 2011 17:07:04 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110921 Thunderbird/9.0a1 MIME-Version: 1.0 To: Benoit Claise References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> <4E7AA240.4020506@plixer.com> <4E7AE9D1.9090002@cisco.com> In-Reply-To: <4E7AE9D1.9090002@cisco.com> Content-Type: multipart/alternative; boundary="------------050902000004070706060605" X-OriginalArrivalTime: 23 Sep 2011 21:07:05.0355 (UTC) FILETIME=[BF510DB0:01CC7A34] Cc: ipfix@ietf.org Subject: Re: [IPFIX] [SPAM I AM] Re: RFC5101: time first flow dropped and time last flow dropped 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: Fri, 23 Sep 2011 21:04:32 -0000 This is a multi-part message in MIME format. --------------050902000004070706060605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yes, this makes sense. I gave this some thought and I don't have a better suggestion. I also agree that even though the flow[Start|End]* collection of IEs conveniently has one IE for both first and last, observationTime* is the more correct choice here. -Andrew On 09/22/2011 03:54 AM, Benoit Claise wrote: > Hi Andrew, >> Hi Benoit, >> >> I had the same thought about using >> >> 322 observationTimeSeconds >> 323 observationTimeMilliseconds >> 324 observationTimeMicroseconds >> 325 observationTimeNanoseconds >> >> The problem is that you need two timestamps in the same record (first >> and last). How does that work with the above? > Excellent question. We debated this question with Paul Aitken recently. > Let me rephrase the question slightly differently: how does the > collector determine that this is a "The Metering Process Reliability > Statistics Options Template", and understands the semantic of the two > counters? > Well. Two solutions: > 1. we duplicate all the IEs to have the exact correct semantic. > > ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] > ... and potentially some more such as pre|post > This brings multiple new dimensions to IE and will lead to an > explosion of IEs if we want to cover all the case > 2. the collector tests the possible combination of IE in the Options > Template Record. > For example, if the collector sees such an Options Template > Record, it knows that this a "The Metering Process Reliability > Statistics Options Template" > observationDomainId (scope) > meteringProcessId (scope)_ > _ ignoredPacketTotalCount > ignoredOctetTotalCount > observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds > observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds > > While the solution 2 is not perfect, this was the chosen track. > > Does it make sense? > > Regards, Benoit >> >> -Andrew >> >> On 09/21/2011 07:11 PM, Benoit Claise wrote: >>> Hi Gerhard, >>> >>> Thanks for your reply. >>> See in line. >>>> >>>> Hi Benoit, >>>> >>>> See comments inline. >>>> >>>> On 20.09.2011 16:19, Benoit Claise wrote: >>>>> Dear all, >>>>> >>>>> [this email addresses >>>>> draft-claise-ipfix-protocol-rfc5101bis-00.txt, TO DO -> "time >>>>> first flow dropped" and "time last flow dropped" inconsistency. >>>>> See the discussion on the list.] >>>>> >>>>> Paul Aitken discovered this issue., >>>>> >>>>> From [RFC5101], section 4.3. The Exporting Process Reliability >>>>> Statistics Option Template >>>>> >>>>> time first flow dropped >>>>> The timestamp of the first _Flow _was >>>>> dropped by >>>>> the Metering Process. For this timestamp, >>>>> any >>>>> of the "flowStart" timestamp Information >>>>> Elements flowStartMilliseconds, >>>>> flowStartMicroseconds, >>>>> flowStartNanoseconds, and >>>>> flowStartDeltaMicroseconds can be used. >>>>> >>>>> time last flow dropped >>>>> The timestamp of the last _IP packet_ that >>>>> was >>>>> ignored by the Metering Process. For this >>>>> timestamp, any of the "flowEnd" timestamp >>>>> Information Elements flowEndMilliseconds, >>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>> flowEndDeltaMicroseconds can be used. >>>>> >>>>> >>>>> Firstly, these definitions are inconsistent since the names and >>>>> the first definition say "flow" while the second definition says >>>>> "IP packet". Obviously "IP packet" != "flow" :-o >>>>> >>>>> Secondly, "The timestamp of the first Flow was dropped by the >>>>> Metering Process." is bad English: at least it's missing "that". >>>>> >>>>> Thirdly, the section 4.2 doesn't take into account a metering >>>>> process id. Indeed, what if we have multiple caches on the exporter? >>>>> >>>>> Here is a proposal for 4.2 and 4.3. The underlined parts are new >>>>> >>>>> >>>>> 4.2. The Metering Process Reliability Statistics Option Template >>>>> >>>>> >>>>> >>>>> The Metering Process Reliability Option Template specifies the >>>>> structure of a Data Record for reporting lack of reliability in the >>>>> Metering Process. It SHOULD contain the following Information >>>>> Elements that are defined in [RFC5102 ]: >>>>> >>>>> observationDomainId >>>>> An identifier of an Observation Domain that >>>>> is locally unique to the Exporting Process. >>>>> This Information Element MUST be defined as a >>>>> Scope Field. >>>>> >>>>> >>>>> _ meteringProcessId (*) >>>>> The identifier of the Metering Process for >>>>> which lack of reliability is reported. There >>>>> This Information Element MUST be defined as a >>>>> Scope Field._ >>>>> >>>>> ignoredPacketTotalCount >>>>> The total number of IP packets that the >>>>> Metering Process did not process. >>>>> >>>>> ignoredOctetTotalCount >>>>> The total number of octets in observed IP >>>>> packets that the Metering Process did not >>>>> process. >>>>> >>>>> time first_packet_ignored >>>>> The timestamp of the first IP packet that was >>>>> ignored by the Metering Process. For this >>>>> timestamp, any of the "flowStart" timestamp >>>>> Information Elements flowStartMilliseconds, >>>>> flowStartMicroseconds, flowStartNanoseconds, >>>>> and flowStartDeltaMicroseconds can be used. >>>>> >>>>> time last_packet_ignored >>>>> The timestamp of the last IP packet that was >>>>> ignored by the Metering Process. For this >>>>> timestamp, any of the "flowEnd" timestamp >>>>> Information Elements flowEndMilliseconds, >>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>> flowEndDeltaMicroseconds can be used. >>>> >>>> I do not find these IEs in RFC5102. >>> Which ones? flowEndMilliseconds, flowEndMicroseconds, >>> flowEndNanoseconds, and flowEndDeltaMicroseconds >>> There are in http://www.iana.org/assignments/ipfix/ipfix.xml >>> However, re-reading >>> time first_packet_ignored >>> The timestamp of the first IP packet that was >>> ignored by the Metering Process. For this >>> timestamp, any of the "flowStart" timestamp >>> Information Elements flowStartMilliseconds, >>> flowStartMicroseconds, flowStartNanoseconds, >>> and flowStartDeltaMicroseconds can be used. >>> >>> time last_packet_ignored >>> The timestamp of the last IP packet that was >>> ignored by the Metering Process. For this >>> timestamp, any of the "flowEnd" timestamp >>> Information Elements flowEndMilliseconds, >>> flowEndMicroseconds, flowEndNanoseconds, and >>> flowEndDeltaMicroseconds can be used. >>> And http://www.iana.org/assignments/ipfix/ipfix.xml for the >>> "flowEnd" timestamp IE, >>> I now believe that we should be using this series of IEs >>> >>> 322 observationTimeSeconds >>> 323 observationTimeMilliseconds >>> 324 observationTimeMicroseconds >>> 325 observationTimeNanoseconds >>> >>> >>>> >>>>> 4.3. The Exporting Process Reliability Statistics Option >>>>> Template >>>>> >>>>> >>>>> The Exporting Process Reliability Option Template specifies the >>>>> structure of a Data Record for reporting lack of reliability in the >>>>> Exporting process. It SHOULD contain the following Information >>>>> Elements that are defined in [RFC5102 ]: >>>>> >>>>> Exporting Process ID >>>>> The identifier of the Exporting Process for >>>>> which lack of reliability is reported. There >>>>> are three Information Elements specified in >>>>> [RFC5102 ] that can be used for this purpose: >>>>> exporterIPv4Address, exporterIPv6Address, or >>>>> exportingProcessId. This Information Element >>>>> MUST be defined as a Scope Field. >>>>> >>>>> notSentFlowTotalCount >>>>> The total number of Flows that were generated by >>>>> the Metering Process and dropped by the Metering >>>>> Process or by the Exporting Process instead of >>>>> being sent to the Collecting Process. >>>>> >>>>> notSentPacketTotalCount >>>>> The total number of packets in Flow Records that >>>>> were generated by the Metering Process and >>>>> dropped by the Metering Process or by the >>>>> Exporting Process instead of being sent to the >>>>> Collecting Process. >>>>> >>>>> notSentOctetTotalCount >>>>> The total number of octets in packets in Flow >>>>> Records that were generated by the Metering >>>>> Process and dropped by the Metering Process or >>>>> by the Exporting Process instead of being sent >>>>> to the Collecting Process. >>>>> >>>>> time first flow dropped >>>>> _ The time at which the first Flow Record was dropped by >>>>> the__Exporting Process._ For this timestamp, any >>>>> of the "flowStart" timestamp Information >>>>> Elements flowStartMilliseconds, >>>>> flowStartMicroseconds, flowStartNanoseconds, and >>>>> flowStartDeltaMicroseconds can be used. >>>>> >>>>> time last flow dropped >>>>> _The time at which the last Flow Record was >>>>> dropped by the Exporting Process_. For this >>>>> timestamp, any of the "flowEnd" timestamp >>>>> Information Elements flowEndMilliseconds, >>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>> flowEndDeltaMicroseconds can be used. >>>> >>>> Again, I do not find these IEs in RFC5102. >>> Same remark, I believe we should be using for the two previous IEs >>> >>> 322 observationTimeSeconds >>> 323 observationTimeMilliseconds >>> 324 observationTimeMicroseconds >>> 325 observationTimeNanoseconds >>> >>> Regards, Benoit. >>>> >>>>> The Exporting Process SHOULD export the Data Record specified by the >>>>> Exporting Process Reliability Statistics Option Template on a regular >>>>> basis or based on some export policy. This periodicity or export >>>>> policy SHOULD be configurable. >>>>> >>>>> >>>>> >>>>> >>>>> (*) regarding the meteringProcessId, we were hesitating between >>>>> the meteringProcessId and the cache id >>>>> 1. there is a meteringProcessId in IPFIX IANA while there is no >>>>> cache id >>>> >>>> meteringProcessId should do the job. >>>> >>>>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what >>>>> should be the value in meteringProcessId? >>>>> [IPFIX-CONF] doesn't mention the meteringProcessId, but a >>>>> cache name. >>>>> From figure 1 and 2, it seems that there is a one to one >>>>> matching between the cache and the metering process. >>>>> If this is the case, a solution could be to add a >>>>> meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] >>>>> below >>>> >>>> See reply to Pauls mail. >>>> >>>> Regards, >>>> Gerhard >>>> >>>>> >>>>> 4.3. Cache Class >>>>> >>>>> >>>>> +-----------------------------------+ >>>>> | Cache | >>>>> +-----------------------------------+ 1 +------------------+ >>>>> | name |<>--------| immediateCache/ | >>>>> | dataRecords {readOnly} | | timeoutCache/ | >>>>> | cacheDiscontinuityTime {readOnly} | | naturalCache/ | >>>>> | | | permanentCache | >>>>> | | +------------------+ >>>>> | | >>>>> | | 0..* +------------------+ >>>>> | |--------->| ExportingProcess | >>>>> +-----------------------------------+ +------------------+ >>>>> >>>>> Figure 12: Cache class >>>>> What do you think? Do you see another way? >>>>> >>>>> Regards, Paul & Benoit. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > --------------050902000004070706060605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes, this makes sense.

I gave this some thought and I don't have a better suggestion.  I also agree that even though the flow[Start|End]* collection of IEs conveniently has one IE for both first and last, observationTime* is the more correct choice here.

-Andrew

On 09/22/2011 03:54 AM, Benoit Claise wrote:
Hi Andrew,
Hi Benoit,

I had the same thought about using

322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds

The problem is that you need two timestamps in the same record (first and last).  How does that work with the above?
Excellent question. We debated this question with Paul Aitken recently.
Let me rephrase the question slightly differently: how does the collector determine that this is a "The Metering Process Reliability Statistics Options Template", and understands the semantic of the two counters?
Well. Two solutions:
1. we duplicate all the IEs to have the exact correct semantic.
    ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] ... and potentially some more such as pre|post
    This brings multiple new dimensions to IE and will lead to an explosion of IEs if we want to cover all the case
2. the collector tests the possible combination of IE in the Options Template Record.
    For example, if the collector sees such an Options Template Record, it knows that this a "The Metering Process Reliability Statistics Options Template" 
  observationDomainId (scope)
  meteringProcessId (scope)
  ignoredPacketTotalCount
  ignoredOctetTotalCount
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
While the solution 2 is not perfect, this was the chosen track.

Does it make sense?

Regards, Benoit

-Andrew

On 09/21/2011 07:11 PM, Benoit Claise wrote:
Hi Gerhard,

Thanks for your reply.
See in line.

Hi Benoit,

See comments inline.

On 20.09.2011 16:19, Benoit Claise wrote:
Dear all,

[this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO DO -> "time first flow dropped" and "time last flow dropped" inconsistency.  See the discussion on the list.]

Paul Aitken discovered this issue.,

From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template

time first flow dropped
                        The timestamp of the first Flow was dropped by
                        the Metering Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

time last flow dropped
                        The timestamp of the last IP packet that was
                        ignored by the Metering Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.


Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o

Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".

Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter?

Here is a proposal for 4.2 and 4.3. The underlined parts are new

4.2.  The Metering Process Reliability Statistics Option Template


   The Metering Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.

    
   meteringProcessId (*)
                           The identifier of the Metering Process for
                           which lack of reliability is reported.  There
                           This Information Element MUST be defined as a 
                           Scope Field.

   ignoredPacketTotalCount
                           The total number of IP packets that the
                           Metering Process did not process.

   ignoredOctetTotalCount
                           The total number of octets in observed IP
                           packets that the Metering Process did not
                           process.

   time first packet ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last packet ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.

I do not find these IEs in RFC5102.
Which ones?  flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds
There are in http://www.iana.org/assignments/ipfix/ipfix.xml
However, re-reading 
   time first packet ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last packet ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.
And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd" timestamp IE,
I now believe that we should be using this series of IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds


4.3.  The Exporting Process Reliability Statistics Option Template

   The Exporting Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Exporting process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.

   notSentFlowTotalCount
                        The total number of Flows that were generated by
                        the Metering Process and dropped by the Metering
                        Process or by the Exporting Process instead of
                        being sent to the Collecting Process.

   notSentPacketTotalCount
                        The total number of packets in Flow Records that
                        were generated by the Metering Process and
                        dropped by the Metering Process or by the
                        Exporting Process instead of being sent to the
                        Collecting Process.

   notSentOctetTotalCount
                        The total number of octets in packets in Flow
                        Records that were generated by the Metering
                        Process and dropped by the Metering Process or
                        by the Exporting Process instead of being sent
                        to the Collecting Process.

   time first flow dropped
                        The time at which the first Flow Record was dropped by
                        the Exporting Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

   time last flow dropped
                        The time at which the last Flow Record was
                        dropped by the Exporting Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.

Again, I do not find these IEs in RFC5102.
Same remark, I believe we should be using for the two previous IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds
Regards, Benoit.

   The Exporting Process SHOULD export the Data Record specified by the
   Exporting Process Reliability Statistics Option Template on a regular
   basis or based on some export policy.  This periodicity or export
   policy SHOULD be configurable.




(*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id
1. there is a meteringProcessId in IPFIX IANA while there is no cache id

meteringProcessId should do the job.

2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId?
    [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
    From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process.
    If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below

See reply to Pauls mail.

Regards,
Gerhard

4.3.  Cache Class

    +-----------------------------------+
    | Cache                             |
    +-----------------------------------+        1 +------------------+
    | name                              |<>--------| immediateCache/  |
    | dataRecords {readOnly}            |          | timeoutCache/    |
    | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
    |                                   |          | permanentCache   |
    |                                   |          +------------------+
    |                                   |
    |                                   |     0..* +------------------+
    |                                   |--------->| ExportingProcess |
    +-----------------------------------+          +------------------+

                          Figure 12: Cache class
What do you think? Do you see another way?

Regards, Paul & Benoit.


_______________________________________________
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


--------------050902000004070706060605-- From paitken@cisco.com Mon Sep 26 05:07:22 2011 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 437DF21F86AA for ; Mon, 26 Sep 2011 05:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.543 X-Spam-Level: X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.054, 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 ASsVvJEZS5Fx for ; Mon, 26 Sep 2011 05:07:21 -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 4EDD421F86A5 for ; Mon, 26 Sep 2011 05:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=3770; q=dns/txt; s=iport; t=1317039004; x=1318248604; h=message-id:date:from:mime-version:to:cc:subject; bh=VGK/tvtyNo6vU5DfAwCjM6Tpk+0GPTON3bkfbqh330E=; b=BDuUv73K/OMPsr2eTQ1Ymq+xreITxVhFC1CEEROU6H1/lNOU/rc3V5f7 XZcW5+uHt+7ETvxWWKjQF5/pzQ6LRWL/qrWcTmAse75xkoprij7QQ+HB/ iCz/JZ6sONfECwcCPwew3Fl4G/O/tdOAHNWv97D/nDbHpX+TscrjYWQ2e g=; X-IronPort-AV: E=Sophos;i="4.68,444,1312156800"; d="scan'208,217";a="56209625" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 26 Sep 2011 12:10:00 +0000 Received: from [144.254.153.24] (dhcp-144-254-153-24.cisco.com [144.254.153.24]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8QCA0j8028321; Mon, 26 Sep 2011 12:10:00 GMT Message-ID: <4E806B91.7000301@cisco.com> Date: Mon, 26 Sep 2011 13:09:53 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: "Benoit Claise (bclaise)" Content-Type: multipart/alternative; boundary="------------030104020901030105080308" Cc: IETF IPFIX Working Group Subject: [IPFIX] multiple export streams 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, 26 Sep 2011 12:07:22 -0000 This is a multi-part message in MIME format. --------------030104020901030105080308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Benoit, All, I just submitted a new errata for NFv9 (RFC 3954), to clarify that the source port should be used to differentiate between multiple export streams coming from a single device: http://www.rfc-editor.org/errata_search.php?rfc=3954&eid=2979 While doing this, I noticed another subtle difference between NFv9 and IPFIX: 3954 says that these fields should be used to separate multiple streams from the same Exporter: NetFlow Collectors SHOULD use the combination of the source IP address and the Source ID field to separate different export streams originatingfrom the same Exporter. (NB Exporter = "A device ... with the NetFlow services enabled".) Whereas 5101 limits to multiple streams from the same Exporting Process: Collecting Processes SHOULD use the Transport Session and the Observation Domain ID field to separate different export streams originatingfrom the same Exporting Process. - which fails to explain how to differentiate export streams from multiple EPs in a single device. I think 5101 should also say, "from the same Exporter.", which in 5101 is defined as: A device that hosts one or more Exporting Processes is termed an Exporter. Can you take care of this in 5101bis? Shall I open another errata? Thanks, P. --------------030104020901030105080308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Benoit, All,

I just submitted a new errata for NFv9 (RFC 3954), to clarify that the source port should be used to differentiate between multiple export streams coming from a single device:

http://www.rfc-editor.org/errata_search.php?rfc=3954&eid=2979


While doing this, I noticed another subtle difference between NFv9 and IPFIX:

3954 says that these fields should be used to separate multiple streams from the same Exporter:

         NetFlow Collectors SHOULD use the combination of the source IP
         address and the Source ID field to separate different export
         streams originating from the same Exporter.

(NB Exporter = "A device ... with the NetFlow services enabled".)

Whereas 5101 limits to multiple streams from the same Exporting Process:

      Collecting Processes SHOULD use the Transport Session and the
      Observation Domain ID field to separate different export streams
      originating from the same Exporting Process.

- which fails to explain how to differentiate export streams from multiple EPs in a single device.

I think 5101 should also say, "from the same Exporter.", which in 5101 is defined as:
      A device that hosts one or more Exporting Processes is termed an Exporter.

Can you take care of this in 5101bis? Shall I open another errata?

Thanks,
P.
--------------030104020901030105080308-- From bclaise@cisco.com Mon Sep 26 06:13:09 2011 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 9494021F8A69 for ; Mon, 26 Sep 2011 06:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.117, 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 01inrMfxyenq for ; Mon, 26 Sep 2011 06:13:09 -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 1D4A321F8A35 for ; Mon, 26 Sep 2011 06:13:07 -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 p8QDFltq013320; Mon, 26 Sep 2011 15:15:47 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8QDFgrT006556; Mon, 26 Sep 2011 15:15:42 +0200 (CEST) Message-ID: <4E807AFE.8010604@cisco.com> Date: Mon, 26 Sep 2011 15:15:42 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20110926130703.4979.26742.idtracker@ietfa.amsl.com> In-Reply-To: <20110926130703.4979.26742.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110926130703.4979.26742.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030208010200020905050902" Cc: Thomas Dietz Subject: [IPFIX] Fwd: New Version Notification for draft-claise-ipfix-protocol-rfc5101bis-01.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: Mon, 26 Sep 2011 13:13:09 -0000 This is a multi-part message in MIME format. --------------030208010200020905050902 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Trying to close on the recent discussion on the mailing list, I posted a new draft, including the feedback from everybody. Please review and comment. The diffs are at: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-claise-ipfix-protocol-rfc5101bis-01.txt Note that there is this pending AUTH48 changes for [IPFIX-CONF]: the addition of selectorId, exportingProcessId, and meteringProcessId in the configuration data model, as state parameters, i.e. read-only. Only 2 to-do items, as far as I can tell: - NTP RFC 1305 is obsoleted by RFC5905. Check if the format is the similar before updating the reference. - Resolution to the template lifetime mechanism for UDP Regards, Benoit -------- Original Message -------- Subject: New Version Notification for draft-claise-ipfix-protocol-rfc5101bis-01.txt Date: Mon, 26 Sep 2011 06:07:03 -0700 From: internet-drafts@ietf.org To: bclaise@cisco.com CC: bclaise@cisco.com A new version of I-D, draft-claise-ipfix-protocol-rfc5101bis-01.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. Filename: draft-claise-ipfix-protocol-rfc5101bis Revision: 01 Title: Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Creation date: 2011-09-26 WG ID: Individual Submission Number of pages: 69 Abstract: This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and 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 IETF Secretariat --------------030208010200020905050902 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear all,

Trying to close on the recent discussion on the mailing list, I posted a new draft, including the feedback from everybody.
Please review and comment. The diffs are at: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-claise-ipfix-protocol-rfc5101bis-01.txt

Note that there is this pending AUTH48 changes for [IPFIX-CONF]: the addition of selectorId, exportingProcessId, and meteringProcessId in the configuration data model, as state parameters, i.e. read-only.

Only 2 to-do items, as far as I can tell:
- NTP RFC 1305 is obsoleted by RFC5905. Check if the format is the similar before updating the reference.
- Resolution to the template lifetime mechanism for UDP

Regards, Benoit

-------- Original Message --------
Subject: New Version Notification for draft-claise-ipfix-protocol-rfc5101bis-01.txt
Date: Mon, 26 Sep 2011 06:07:03 -0700
From: internet-drafts@ietf.org
To: bclaise@cisco.com
CC: bclaise@cisco.com 


A new version of I-D, draft-claise-ipfix-protocol-rfc5101bis-01.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-ipfix-protocol-rfc5101bis
Revision:	 01
Title:		 Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
Creation date:	 2011-09-26
WG ID:		 Individual Submission
Number of pages: 69

Abstract:
   This document specifies the IP Flow Information Export (IPFIX)
   protocol that serves for transmitting IP Traffic Flow information
   over the network.  In order to transmit IP Traffic Flow information
   from an Exporting Process to an information Collecting Process, a
   common representation of flow data and a standard means of
   communicating them is required.  This document describes how the
   IPFIX Data and 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 IETF Secretariat
--------------030208010200020905050902-- From bclaise@cisco.com Mon Sep 26 06:24:24 2011 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 6B0C621F8C50 for ; Mon, 26 Sep 2011 06:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.116, 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 McWHX9iJDDx4 for ; Mon, 26 Sep 2011 06:24:23 -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 87CBB21F8C46 for ; Mon, 26 Sep 2011 06:24:23 -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 p8QDR5Yp014544 for ; Mon, 26 Sep 2011 15:27:05 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8QDR5RY019302; Mon, 26 Sep 2011 15:27:05 +0200 (CEST) Message-ID: <4E807DA8.40209@cisco.com> Date: Mon, 26 Sep 2011 15:27:05 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Paul Aitken References: <4E806B91.7000301@cisco.com> In-Reply-To: <4E806B91.7000301@cisco.com> Content-Type: multipart/alternative; boundary="------------010207040105030009040401" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] multiple export streams 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, 26 Sep 2011 13:24:24 -0000 This is a multi-part message in MIME format. --------------010207040105030009040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Paul, As we discussed off line, that makes sense. Inserted in my temp version of RFC5101bis. Regards, Benoit. > Benoit, All, > > I just submitted a new errata for NFv9 (RFC 3954), to clarify that the > source port should be used to differentiate between multiple export > streams coming from a single device: > > http://www.rfc-editor.org/errata_search.php?rfc=3954&eid=2979 > > > While doing this, I noticed another subtle difference between NFv9 and > IPFIX: > > 3954 says that these fields should be used to separate multiple > streams from the same Exporter: > > NetFlow Collectors SHOULD use the combination of the source IP > address and the Source ID field to separate different export > streams originatingfrom the same Exporter. > > (NB Exporter = "A device ... with the NetFlow services enabled".) > > Whereas 5101 limits to multiple streams from the same Exporting Process: > > Collecting Processes SHOULD use the Transport Session and the > Observation Domain ID field to separate different export streams > originatingfrom the same Exporting Process. > > - which fails to explain how to differentiate export streams from > multiple EPs in a single device. > > I think 5101 should also say, "from the same Exporter.", which in 5101 > is defined as: > A device that hosts one or more Exporting Processes is termed an Exporter. > > Can you take care of this in 5101bis? Shall I open another errata? > > Thanks, > P. --------------010207040105030009040401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Paul,

As we discussed off line, that makes sense.
Inserted in my temp version of RFC5101bis.

Regards, Benoit.
Benoit, All,

I just submitted a new errata for NFv9 (RFC 3954), to clarify that the source port should be used to differentiate between multiple export streams coming from a single device:

http://www.rfc-editor.org/errata_search.php?rfc=3954&eid=2979


While doing this, I noticed another subtle difference between NFv9 and IPFIX:

3954 says that these fields should be used to separate multiple streams from the same Exporter:

         NetFlow Collectors SHOULD use the combination of the source IP
         address and the Source ID field to separate different export
         streams originating from the same Exporter.

(NB Exporter = "A device ... with the NetFlow services enabled".)

Whereas 5101 limits to multiple streams from the same Exporting Process:

      Collecting Processes SHOULD use the Transport Session and the
      Observation Domain ID field to separate different export streams
      originating from the same Exporting Process.

- which fails to explain how to differentiate export streams from multiple EPs in a single device.

I think 5101 should also say, "from the same Exporter.", which in 5101 is defined as:
      A device that hosts one or more Exporting Processes is termed an Exporter.

Can you take care of this in 5101bis? Shall I open another errata?

Thanks,
P.

--------------010207040105030009040401-- From andrewf@plixer.com Mon Sep 26 06:47:47 2011 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 C7CA921F8B7C for ; Mon, 26 Sep 2011 06:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Omzk7ttfbjva for ; Mon, 26 Sep 2011 06:47:47 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 2817F21F8B79 for ; Mon, 26 Sep 2011 06:47:46 -0700 (PDT) Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 09:50:29 -0400 Message-ID: <4E808325.4010406@plixer.com> Date: Mon, 26 Sep 2011 09:50:29 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110921 Thunderbird/9.0a1 MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: multipart/alternative; boundary="------------040609030602010801060604" X-OriginalArrivalTime: 26 Sep 2011 13:50:29.0198 (UTC) FILETIME=[406DF6E0:01CC7C53] Subject: [IPFIX] Clarifying some wording in 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: Mon, 26 Sep 2011 13:47:47 -0000 This is a multi-part message in MIME format. --------------040609030602010801060604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The discussion about timestamps in "The Metering Process Reliability Statistics Options Template" has me rereading RFCs. The following sentence in RFC 5101 section 9 doesn't parse. The Collector MUST support the use of Templates containing multiple occurrences of _the similar_ Information Elements. Should this read something more like The Collector MUST support the use of Templates containing multiple occurrences of _identical_ Information Elements. or The Collector MUST support the use of Templates containing multiple occurrences of _the same_ Information Elements. or The Collector MUST support the use of Templates containing multiple occurrences of _similar_ Information Elements. In the last case what does "similar" mean and why does it need a MUST or even to be stated at all? Is this something we can fix in 5101bis? -Andrew --------------040609030602010801060604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The discussion about timestamps in "The Metering Process Reliability Statistics Options Template" has me rereading RFCs.

The following sentence in RFC 5101 section 9 doesn't parse.

   The Collector MUST support the use of Templates containing multiple
   occurrences of the similar Information Elements.

Should this read something more like

   The Collector MUST support the use of Templates containing multiple
   occurrences of identical Information Elements.

or

   The Collector MUST support the use of Templates containing multiple
   occurrences of the same Information Elements.

or

   The Collector MUST support the use of Templates containing multiple
   occurrences of similar Information Elements.

In the last case what does "similar" mean and why does it need a MUST or even to be stated at all?

Is this something we can fix in 5101bis?

-Andrew
--------------040609030602010801060604-- From trammell@tik.ee.ethz.ch Mon Sep 26 06:52:05 2011 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 43F9B21F8B2F for ; Mon, 26 Sep 2011 06:52:05 -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=[AWL=0.000, 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 sKa20Twbs-US for ; Mon, 26 Sep 2011 06:52: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 70AD721F8AFC for ; Mon, 26 Sep 2011 06:52:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A10C9D9304; Mon, 26 Sep 2011 15:54:45 +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 m2uEFHOXpwtH; Mon, 26 Sep 2011 15:54:45 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (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 3C121D9302; Mon, 26 Sep 2011 15:54:45 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4E808325.4010406@plixer.com> Date: Mon, 26 Sep 2011 15:54:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6CD0B135-9FB2-41A6-8186-8BAACF2EAF2D@tik.ee.ethz.ch> References: <4E808325.4010406@plixer.com> To: Andrew Feren X-Mailer: Apple Mail (2.1084) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Clarifying some wording in 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: Mon, 26 Sep 2011 13:52:05 -0000 Hi, Andrew, I always read it as meaning the first of your alternatives. Cheers,=20 Brian On Sep 26, 2011, at 3:50 PM, Andrew Feren wrote: > The discussion about timestamps in "The Metering Process Reliability = Statistics Options Template" has me rereading RFCs. >=20 > The following sentence in RFC 5101 section 9 doesn't parse. >=20 > The Collector MUST support the use of Templates containing multiple > occurrences of the similar Information Elements. >=20 > Should this read something more like >=20 > The Collector MUST support the use of Templates containing multiple > occurrences of identical Information Elements. >=20 > or=20 >=20 > The Collector MUST support the use of Templates containing multiple > occurrences of the same Information Elements. >=20 > or=20 >=20 > The Collector MUST support the use of Templates containing multiple > occurrences of similar Information Elements. >=20 > In the last case what does "similar" mean and why does it need a MUST = or even to be stated at all? >=20 > Is this something we can fix in 5101bis? >=20 > -Andrew > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From andrewf@plixer.com Mon Sep 26 06:54:31 2011 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 2767621F8C93 for ; Mon, 26 Sep 2011 06:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 A46MDtMqY7Uj for ; Mon, 26 Sep 2011 06:54:30 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 8C66021F8C70 for ; Mon, 26 Sep 2011 06:54:30 -0700 (PDT) Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 09:57:13 -0400 Message-ID: <4E8084B9.2060604@plixer.com> Date: Mon, 26 Sep 2011 09:57:13 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110921 Thunderbird/9.0a1 MIME-Version: 1.0 To: ipfix@ietf.org References: <4E808325.4010406@plixer.com> <6CD0B135-9FB2-41A6-8186-8BAACF2EAF2D@tik.ee.ethz.ch> In-Reply-To: <6CD0B135-9FB2-41A6-8186-8BAACF2EAF2D@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2011 13:57:13.0188 (UTC) FILETIME=[3139F240:01CC7C54] Subject: Re: [IPFIX] Clarifying some wording in 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: Mon, 26 Sep 2011 13:54:31 -0000 Me too, but if that is what it means maybe that is what we should say. :-) -Andrew On 09/26/2011 09:54 AM, Brian Trammell wrote: > Hi, Andrew, > > I always read it as meaning the first of your alternatives. > > Cheers, > > Brian > > > On Sep 26, 2011, at 3:50 PM, Andrew Feren wrote: > >> The discussion about timestamps in "The Metering Process Reliability Statistics Options Template" has me rereading RFCs. >> >> The following sentence in RFC 5101 section 9 doesn't parse. >> >> The Collector MUST support the use of Templates containing multiple >> occurrences of the similar Information Elements. >> >> Should this read something more like >> >> The Collector MUST support the use of Templates containing multiple >> occurrences of identical Information Elements. >> >> or >> >> The Collector MUST support the use of Templates containing multiple >> occurrences of the same Information Elements. >> >> or >> >> The Collector MUST support the use of Templates containing multiple >> occurrences of similar Information Elements. >> >> In the last case what does "similar" mean and why does it need a MUST or even to be stated at all? >> >> Is this something we can fix in 5101bis? >> >> -Andrew >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Mon Sep 26 06:56:17 2011 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 4DF4D21F8CB4 for ; Mon, 26 Sep 2011 06:56:17 -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 7BveyqYNTxOs for ; Mon, 26 Sep 2011 06:56:16 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A940021F8C93 for ; Mon, 26 Sep 2011 06:56:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0C524D9309; Mon, 26 Sep 2011 15:58:59 +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 YrsXCSjPQLGS; Mon, 26 Sep 2011 15:58:58 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (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 CEC6AD9302; Mon, 26 Sep 2011 15:58:58 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4E8084B9.2060604@plixer.com> Date: Mon, 26 Sep 2011 15:58:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7818459A-39CC-4B65-91A0-46DF934C62F4@tik.ee.ethz.ch> References: <4E808325.4010406@plixer.com> <6CD0B135-9FB2-41A6-8186-8BAACF2EAF2D@tik.ee.ethz.ch> <4E8084B9.2060604@plixer.com> To: Andrew Feren X-Mailer: Apple Mail (2.1084) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Clarifying some wording in 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: Mon, 26 Sep 2011 13:56:17 -0000 Absolutely.=20 Benoit, is the correct thing to do here for Andrew to file an editorial = erratum? Cheers, Brian On Sep 26, 2011, at 3:57 PM, Andrew Feren wrote: > Me too, but if that is what it means maybe that is what we should say. = :-) >=20 > -Andrew >=20 > On 09/26/2011 09:54 AM, Brian Trammell wrote: >> Hi, Andrew, >>=20 >> I always read it as meaning the first of your alternatives. >>=20 >> Cheers, >>=20 >> Brian >>=20 >>=20 >> On Sep 26, 2011, at 3:50 PM, Andrew Feren wrote: >>=20 >>> The discussion about timestamps in "The Metering Process Reliability = Statistics Options Template" has me rereading RFCs. >>>=20 >>> The following sentence in RFC 5101 section 9 doesn't parse. >>>=20 >>> The Collector MUST support the use of Templates containing = multiple >>> occurrences of the similar Information Elements. >>>=20 >>> Should this read something more like >>>=20 >>> The Collector MUST support the use of Templates containing = multiple >>> occurrences of identical Information Elements. >>>=20 >>> or >>>=20 >>> The Collector MUST support the use of Templates containing = multiple >>> occurrences of the same Information Elements. >>>=20 >>> or >>>=20 >>> The Collector MUST support the use of Templates containing = multiple >>> occurrences of similar Information Elements. >>>=20 >>> In the last case what does "similar" mean and why does it need a = MUST or even to be stated at all? >>>=20 >>> Is this something we can fix in 5101bis? >>>=20 >>> -Andrew >>> _______________________________________________ >>> 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 trammell@tik.ee.ethz.ch Mon Sep 26 09:16:16 2011 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 4D75421F8D1A for ; Mon, 26 Sep 2011 09:16:16 -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=[AWL=0.000, 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 AWCzzH2Ko599 for ; Mon, 26 Sep 2011 09:16:15 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF8321F8D08 for ; Mon, 26 Sep 2011 09:16:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0E3EBD930C for ; Mon, 26 Sep 2011 18:18:57 +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 LAuHQ4iWgHrv for ; Mon, 26 Sep 2011 18:18:56 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (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 D7E87D9302 for ; Mon, 26 Sep 2011 18:18:56 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Sep 2011 18:18:56 +0200 References: <20110926154143.26306.85729.idtracker@ietfa.amsl.com> To: IETF IPFIX Working Group Message-Id: <8E8FD428-34D1-4632-9BF0-5CB283EC000B@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-a9n-04.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: Mon, 26 Sep 2011 16:16:16 -0000 Greetings, all, chairs, We've posted a new individual revision of the aggregation draft. This = revision adds some discussion around specific corner cases, and edits to = terminology and capitalization; it is in the opinion of the authors, = ready. We're just waiting on a charter at this point. :) Comments are of course welcome.=20 Best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Date: September 26, 2011 5:41:43 PM GMT+02:00 > To: trammell@tik.ee.ethz.ch > Cc: bclaise@cisco.com, arno@wagner.name, trammell@tik.ee.ethz.ch > Subject: New Version Notification for draft-trammell-ipfix-a9n-04.txt >=20 > A new version of I-D, draft-trammell-ipfix-a9n-04.txt has been = successfully submitted by Brian Trammell and posted to the IETF = repository. >=20 > Filename: draft-trammell-ipfix-a9n > Revision: 04 > Title: Flow Aggregation for the IP Flow Information = Export (IPFIX) Protocol > Creation date: 2011-09-26 > WG ID: Individual Submission > Number of pages: 46 >=20 > Abstract: > This document describes the export of aggregated Flow information > using IPFIX. An Aggregated Flow is essentially an IPFIX Flow > representing packets from multiple Original Flows sharing some set = of > common properties. The document describes Aggregated Flow export > within the framework of IPFIX Mediators and defines an = interoperable, > implementation-independent method for Aggregated Flow export. >=20 >=20 >=20 >=20 > The IETF Secretariat From trammell@tik.ee.ethz.ch Tue Sep 27 09:12:52 2011 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 BA71321F8B52 for ; Tue, 27 Sep 2011 09:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.295 X-Spam-Level: X-Spam-Status: No, score=-6.295 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 4xPM1hFayL2R for ; Tue, 27 Sep 2011 09:12:50 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 05F0C21F8C13 for ; Tue, 27 Sep 2011 09:12:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 52F10D930D; Tue, 27 Sep 2011 18:15:34 +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 wUkhE4iII0vH; Tue, 27 Sep 2011 18:15:34 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (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 B8CCDD9300; Tue, 27 Sep 2011 18:15:33 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4E7CF4F8.8060405@plixer.com> Date: Tue, 27 Sep 2011 18:15:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> <4E7AA240.4020506@plixer.com> <4E7AE9D1.9090002@cisco.com> <4E7CF4F8.8060405@plixer.com> To: Andrew Feren X-Mailer: Apple Mail (2.1084) Cc: ipfix@ietf.org Subject: Re: [IPFIX] [SPAM I AM] Re: RFC5101: time first flow dropped and time last flow dropped 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, 27 Sep 2011 16:12:52 -0000 Greetings, all, This is a little bit of an abuse of the ordering of IEs, in my opinion, = and of the general rule that only IEs, and the scope in which they are = defined, carry semantics. Even for templates which are defined within = Standards Track RFCs, the records defined by the template should be = decipherable without reference to the RFC. Put another way, we should = not define magical templates, and this template as proposed looks pretty = magical. Without reading the text of this thread, and following basically = everything we've ever said about multiple IEs in a record, I would = interpret a record matching this template as follows: For the metering process A and observation domain B: N packets were ignored; these contained a total of M octets. The first observation at this metering process was at time T0. The second observation at this metering process was at time T1. This is quite far from the stated intention. I would strongly suggest = that we not so lightly give up on "templates should be unambiguously = understandable" requirement, even if the exception itself lives in the = core protocol document. I would suggest, if you want to do a multiple IE solution here, you = define something like missingObservationWindowEdge, and have two of = them: observationDomainId {scope} meteringProcessId {scope} ignoredPacketTotalCount ignoredOctetTotalCount missingObservationWindowEdge missingObservationWindowEdge This has the advantage that you can have a long basicList of window = edges in order to define multiple missing observation windows; each edge = pair is a loss window.=20 Seconds suffice for these, I think. You might want to do one in = milliseconds. But if you have the resources to calculate your packet = loss window to nanosecond precision without having the resources to not = lose packets, I humbly submit you've picked the wrong engineering = tradeoffs. :) Best regards, Brian On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote: > Yes, this makes sense. >=20 > I gave this some thought and I don't have a better suggestion. I also = agree that even though the flow[Start|End]* collection of IEs = conveniently has one IE for both first and last, observationTime* is the = more correct choice here. >=20 > -Andrew >=20 > On 09/22/2011 03:54 AM, Benoit Claise wrote: >> Hi Andrew, >>> Hi Benoit, >>>=20 >>> I had the same thought about using >>>=20 >>> 322 observationTimeSeconds >>> 323 observationTimeMilliseconds >>> 324 observationTimeMicroseconds >>> 325 observationTimeNanoseconds >>>=20 >>> The problem is that you need two timestamps in the same record = (first and last). How does that work with the above? >> Excellent question. We debated this question with Paul Aitken = recently. >> Let me rephrase the question slightly differently: how does the = collector determine that this is a "The Metering Process Reliability = Statistics Options Template", and understands the semantic of the two = counters? >> Well. Two solutions: >> 1. we duplicate all the IEs to have the exact correct semantic.=20 >> = ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds= |Nanoseconds] ... and potentially some more such as pre|post >> This brings multiple new dimensions to IE and will lead to an = explosion of IEs if we want to cover all the case >> 2. the collector tests the possible combination of IE in the Options = Template Record. >> For example, if the collector sees such an Options Template = Record, it knows that this a "The Metering Process Reliability = Statistics Options Template" >> observationDomainId (scope) >> meteringProcessId (scope) >>=20 >> ignoredPacketTotalCount >> ignoredOctetTotalCount >> observationTimeSeconds | observationTimeMilliseconds | = observationTimeMicroseconds | observationTimeNanoseconds >> observationTimeSeconds | observationTimeMilliseconds | = observationTimeMicroseconds | observationTimeNanoseconds >>=20 >>=20 >> While the solution 2 is not perfect, this was the chosen track. >>=20 >> Does it make sense? >>=20 >> Regards, Benoit >>>=20 >>> -Andrew >>>=20 >>> On 09/21/2011 07:11 PM, Benoit Claise wrote: >>>> Hi Gerhard, >>>>=20 >>>> Thanks for your reply. >>>> See in line. >>>>>=20 >>>>> Hi Benoit, >>>>>=20 >>>>> See comments inline. >>>>>=20 >>>>> On 20.09.2011 16:19, Benoit Claise wrote: >>>>>> Dear all, >>>>>>=20 >>>>>> [this email addresses = draft-claise-ipfix-protocol-rfc5101bis-00.txt, TO DO -> "time first = flow dropped" and "time last flow dropped" inconsistency. See the = discussion on the list.] >>>>>>=20 >>>>>> Paul Aitken discovered this issue., >>>>>>=20 >>>>>> =46rom [RFC5101], section 4.3. The Exporting Process Reliability = Statistics Option Template >>>>>>=20 >>>>>> time first flow dropped=20 >>>>>> The timestamp of the first Flow was = dropped by=20 >>>>>> the Metering Process. For this = timestamp, any=20 >>>>>> of the "flowStart" timestamp Information=20= >>>>>> Elements flowStartMilliseconds,=20 >>>>>> flowStartMicroseconds, = flowStartNanoseconds, and=20 >>>>>> flowStartDeltaMicroseconds can be used.=20= >>>>>>=20 >>>>>> time last flow dropped=20 >>>>>> The timestamp of the last IP packet that = was=20 >>>>>> ignored by the Metering Process. For = this=20 >>>>>> timestamp, any of the "flowEnd" timestamp=20= >>>>>> Information Elements flowEndMilliseconds,=20= >>>>>> flowEndMicroseconds, flowEndNanoseconds, = and=20 >>>>>> flowEndDeltaMicroseconds can be used.=20 >>>>>>=20 >>>>>>=20 >>>>>> Firstly, these definitions are inconsistent since the names and = the first definition say "flow" while the second definition says "IP = packet". Obviously "IP packet" !=3D "flow" :-o=20 >>>>>>=20 >>>>>> Secondly, "The timestamp of the first Flow was dropped by the = Metering Process." is bad English: at least it's missing "that".=20 >>>>>>=20 >>>>>> Thirdly, the section 4.2 doesn't take into account a metering = process id. Indeed, what if we have multiple caches on the exporter? >>>>>>=20 >>>>>> Here is a proposal for 4.2 and 4.3. The underlined parts are new >>>>>>=20 >>>>>> 4.2. The Metering Process Reliability Statistics Option Template >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The Metering Process Reliability Option Template specifies the >>>>>> structure of a Data Record for reporting lack of reliability = in the >>>>>> Metering Process. It SHOULD contain the following Information >>>>>> Elements that are defined in [ >>>>>> RFC5102 >>>>>> ]: >>>>>>=20 >>>>>> observationDomainId >>>>>> An identifier of an Observation Domain = that >>>>>> is locally unique to the Exporting = Process. >>>>>> This Information Element MUST be = defined as a >>>>>> Scope Field. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> meteringProcessId (*) >>>>>> The identifier of the Metering Process = for >>>>>> which lack of reliability is reported. = There >>>>>> This Information Element MUST be = defined as a=20 >>>>>> Scope Field. >>>>>>=20 >>>>>>=20 >>>>>> ignoredPacketTotalCount >>>>>> The total number of IP packets that = the >>>>>> Metering Process did not process. >>>>>>=20 >>>>>> ignoredOctetTotalCount >>>>>> The total number of octets in observed = IP >>>>>> packets that the Metering Process did = not >>>>>> process. >>>>>>=20 >>>>>> time first=20 >>>>>> packet=20 >>>>>> ignored >>>>>> The timestamp of the first IP packet = that was >>>>>> ignored by the Metering Process. For = this >>>>>> timestamp, any of the "flowStart" = timestamp >>>>>> Information Elements = flowStartMilliseconds, >>>>>> flowStartMicroseconds, = flowStartNanoseconds, >>>>>> and flowStartDeltaMicroseconds can be = used. >>>>>>=20 >>>>>> time last=20 >>>>>> packet=20 >>>>>> ignored >>>>>> The timestamp of the last IP packet = that was >>>>>> ignored by the Metering Process. For = this >>>>>> timestamp, any of the "flowEnd" = timestamp >>>>>> Information Elements = flowEndMilliseconds, >>>>>> flowEndMicroseconds, = flowEndNanoseconds, and >>>>>> flowEndDeltaMicroseconds can be used. >>>>>>=20 >>>>>=20 >>>>> I do not find these IEs in RFC5102.=20 >>>> Which ones? flowEndMilliseconds, flowEndMicroseconds, = flowEndNanoseconds, and flowEndDeltaMicroseconds >>>> There are in http://www.iana.org/assignments/ipfix/ipfix.xml >>>> However, re-reading=20 >>>> time first packet=20 >>>> ignored >>>> The timestamp of the first IP packet = that was >>>> ignored by the Metering Process. For = this >>>> timestamp, any of the "flowStart" = timestamp >>>> Information Elements = flowStartMilliseconds, >>>> flowStartMicroseconds, = flowStartNanoseconds, >>>> and flowStartDeltaMicroseconds can be = used. >>>>=20 >>>> time last=20 >>>> packet=20 >>>> ignored >>>> The timestamp of the last IP packet that = was >>>> ignored by the Metering Process. For = this >>>> timestamp, any of the "flowEnd" = timestamp >>>> Information Elements = flowEndMilliseconds, >>>> flowEndMicroseconds, flowEndNanoseconds, = and >>>> flowEndDeltaMicroseconds can be used. >>>>=20 >>>> And http://www.iana.org/assignments/ipfix/ipfix.xml for the = "flowEnd" timestamp IE, >>>> I now believe that we should be using this series of IEs >>>> 322 observationTimeSeconds >>>> 323 observationTimeMilliseconds >>>> 324 observationTimeMicroseconds >>>> 325 observationTimeNanoseconds >>>>=20 >>>>>=20 >>>>>> 4.3. The Exporting Process Reliability Statistics Option = Template >>>>>>=20 >>>>>>=20 >>>>>> The Exporting Process Reliability Option Template specifies = the >>>>>> structure of a Data Record for reporting lack of reliability = in the >>>>>> Exporting process. It SHOULD contain the following = Information >>>>>> Elements that are defined in [ >>>>>> RFC5102 >>>>>> ]: >>>>>>=20 >>>>>> Exporting Process ID >>>>>> The identifier of the Exporting Process = for >>>>>> which lack of reliability is reported. = There >>>>>> are three Information Elements specified = in >>>>>> [ >>>>>> RFC5102 >>>>>> ] that can be used for this purpose: >>>>>> exporterIPv4Address, exporterIPv6Address, = or >>>>>> exportingProcessId. This Information = Element >>>>>> MUST be defined as a Scope Field. >>>>>>=20 >>>>>> notSentFlowTotalCount >>>>>> The total number of Flows that were = generated by >>>>>> the Metering Process and dropped by the = Metering >>>>>> Process or by the Exporting Process = instead of >>>>>> being sent to the Collecting Process. >>>>>>=20 >>>>>> notSentPacketTotalCount >>>>>> The total number of packets in Flow = Records that >>>>>> were generated by the Metering Process = and >>>>>> dropped by the Metering Process or by the >>>>>> Exporting Process instead of being sent = to the >>>>>> Collecting Process. >>>>>>=20 >>>>>> notSentOctetTotalCount >>>>>> The total number of octets in packets in = Flow >>>>>> Records that were generated by the = Metering >>>>>> Process and dropped by the Metering = Process or >>>>>> by the Exporting Process instead of being = sent >>>>>> to the Collecting Process. >>>>>>=20 >>>>>> time first flow dropped >>>>>> =20 >>>>>> The time at which the first Flow Record was = dropped by >>>>>> the=20 >>>>>> Exporting Process. >>>>>> For this timestamp, any >>>>>> of the "flowStart" timestamp Information >>>>>> Elements flowStartMilliseconds, >>>>>> flowStartMicroseconds, = flowStartNanoseconds, and >>>>>> flowStartDeltaMicroseconds can be used. >>>>>>=20 >>>>>> time last flow dropped >>>>>> =20 >>>>>> The time at which the last Flow Record was >>>>>> dropped by the Exporting Process >>>>>> . For this >>>>>> timestamp, any of the "flowEnd" timestamp >>>>>> Information Elements flowEndMilliseconds, >>>>>> flowEndMicroseconds, flowEndNanoseconds, = and >>>>>> flowEndDeltaMicroseconds can be used. >>>>>>=20 >>>>>=20 >>>>> Again, I do not find these IEs in RFC5102.=20 >>>> Same remark, I believe we should be using for the two previous IEs >>>> 322 observationTimeSeconds >>>> 323 observationTimeMilliseconds >>>> 324 observationTimeMicroseconds >>>> 325 observationTimeNanoseconds >>>> Regards, Benoit. >>>>>=20 >>>>>> The Exporting Process SHOULD export the Data Record specified = by the >>>>>> Exporting Process Reliability Statistics Option Template on a = regular >>>>>> basis or based on some export policy. This periodicity or = export >>>>>> policy SHOULD be configurable. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> (*) regarding the meteringProcessId, we were hesitating between = the meteringProcessId and the cache id >>>>>> 1. there is a meteringProcessId in IPFIX IANA while there is no = cache id >>>>>=20 >>>>> meteringProcessId should do the job. >>>>>=20 >>>>>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what = should be the value in meteringProcessId? >>>>>> [IPFIX-CONF] doesn't mention the meteringProcessId, but a = cache name. >>>>>> =46rom figure 1 and 2, it seems that there is a one to one = matching between the cache and the metering process. >>>>>> If this is the case, a solution could be to add a = meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below >>>>>=20 >>>>> See reply to Pauls mail. >>>>>=20 >>>>> Regards, >>>>> Gerhard >>>>>=20 >>>>>> 4.3. Cache Class >>>>>>=20 >>>>>>=20 >>>>>> +-----------------------------------+ >>>>>> | Cache | >>>>>> +-----------------------------------+ 1 = +------------------+ >>>>>> | name |<>--------| = immediateCache/ | >>>>>> | dataRecords {readOnly} | | = timeoutCache/ | >>>>>> | cacheDiscontinuityTime {readOnly} | | = naturalCache/ | >>>>>> | | | = permanentCache | >>>>>> | | = +------------------+ >>>>>> | | >>>>>> | | 0..* = +------------------+ >>>>>> | |--------->| = ExportingProcess | >>>>>> +-----------------------------------+ = +------------------+ >>>>>>=20 >>>>>> Figure 12: Cache class >>>>>>=20 >>>>>> What do you think? Do you see another way? >>>>>>=20 >>>>>> Regards, Paul & Benoit. >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> IPFIX mailing list >>>>>>=20 >>>>>> IPFIX@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> IPFIX mailing list >>>>=20 >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>>=20 >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From andrewf@plixer.com Tue Sep 27 10:27:21 2011 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 0B0DF21F8E6F for ; Tue, 27 Sep 2011 10:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] 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 2905orFWb0aU for ; Tue, 27 Sep 2011 10:27:19 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 810DF21F8E65 for ; Tue, 27 Sep 2011 10:27:18 -0700 (PDT) Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 13:30:03 -0400 Message-ID: <4E82081B.8040806@plixer.com> Date: Tue, 27 Sep 2011 13:30:03 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110921 Thunderbird/9.0a1 MIME-Version: 1.0 To: Brian Trammell References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> <4E7AA240.4020506@plixer.com> <4E7AE9D1.9090002@cisco.com> <4E7CF4F8.8060405@plixer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Sep 2011 17:30:03.0327 (UTC) FILETIME=[173C44F0:01CC7D3B] Cc: ipfix@ietf.org Subject: Re: [IPFIX] [SPAM I AM] Re: RFC5101: time first flow dropped and time last flow dropped 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, 27 Sep 2011 17:27:21 -0000 Hi Brian, Well stated. Additional comments inline On 09/27/2011 12:15 PM, Brian Trammell wrote: > Greetings, all, > > This is a little bit of an abuse of the ordering of IEs, in my opinion, and of the general rule that only IEs, and the scope in which they are defined, carry semantics. Even for templates which are defined within Standards Track RFCs, the records defined by the template should be decipherable without reference to the RFC. Put another way, we should not define magical templates, and this template as proposed looks pretty magical. Yes, a black magic sort of magical. We have been discussing this proposed change in the office and coming to the same conclusion. > Without reading the text of this thread, and following basically everything we've ever said about multiple IEs in a record, I would interpret a record matching this template as follows: > > For the metering process A and observation domain B: > N packets were ignored; these contained a total of M octets. > The first observation at this metering process was at time T0. > The second observation at this metering process was at time T1. This was exactly how I interpreted this template until I read the updated draft and saw the bit about "the Collecting Process MUST determine which is the oldest and the most recent timestamp in order the determine the right semantic ...." > This is quite far from the stated intention. I would strongly suggest that we not so lightly give up on "templates should be unambiguously understandable" requirement, even if the exception itself lives in the core protocol document. > > I would suggest, if you want to do a multiple IE solution here, you define something like missingObservationWindowEdge, and have two of them: > > observationDomainId {scope} > meteringProcessId {scope} > ignoredPacketTotalCount > ignoredOctetTotalCount > missingObservationWindowEdge > missingObservationWindowEdge > > This has the advantage that you can have a long basicList of window edges in order to define multiple missing observation windows; each edge pair is a loss window. I like this suggestion, and I have a few additional thoughts. Perhaps the basic list of edge times should either be limited to only one pair or the ignored*TotalCount IEs needs to be in a basiclist with N entries too. How about observationWindowEdge instead (no "missing") to be more generally useful. I think a list of time edges also works neatly when sending this template at regular intervals (which SHOULD be done). When the ignored*TotalCount IEs are zero, an empty list makes sense for edge times. > Seconds suffice for these, I think. You might want to do one in milliseconds. But if you have the resources to calculate your packet loss window to nanosecond precision without having the resources to not lose packets, I humbly submit you've picked the wrong engineering tradeoffs. :) Unless window edge isn't defined specifically for "missing" values. Then the higher precision timestamps might have some use. -Andrew > > Best regards, > > Brian > > On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote: > >> Yes, this makes sense. >> >> I gave this some thought and I don't have a better suggestion. I also agree that even though the flow[Start|End]* collection of IEs conveniently has one IE for both first and last, observationTime* is the more correct choice here. >> >> -Andrew >> >> On 09/22/2011 03:54 AM, Benoit Claise wrote: >>> Hi Andrew, >>>> Hi Benoit, >>>> >>>> I had the same thought about using >>>> >>>> 322 observationTimeSeconds >>>> 323 observationTimeMilliseconds >>>> 324 observationTimeMicroseconds >>>> 325 observationTimeNanoseconds >>>> >>>> The problem is that you need two timestamps in the same record (first and last). How does that work with the above? >>> Excellent question. We debated this question with Paul Aitken recently. >>> Let me rephrase the question slightly differently: how does the collector determine that this is a "The Metering Process Reliability Statistics Options Template", and understands the semantic of the two counters? >>> Well. Two solutions: >>> 1. we duplicate all the IEs to have the exact correct semantic. >>> ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] ... and potentially some more such as pre|post >>> This brings multiple new dimensions to IE and will lead to an explosion of IEs if we want to cover all the case >>> 2. the collector tests the possible combination of IE in the Options Template Record. >>> For example, if the collector sees such an Options Template Record, it knows that this a "The Metering Process Reliability Statistics Options Template" >>> observationDomainId (scope) >>> meteringProcessId (scope) >>> >>> ignoredPacketTotalCount >>> ignoredOctetTotalCount >>> observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds >>> observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds >>> >>> >>> While the solution 2 is not perfect, this was the chosen track. >>> >>> Does it make sense? >>> >>> Regards, Benoit >>>> -Andrew >>>> >>>> On 09/21/2011 07:11 PM, Benoit Claise wrote: >>>>> Hi Gerhard, >>>>> >>>>> Thanks for your reply. >>>>> See in line. >>>>>> Hi Benoit, >>>>>> >>>>>> See comments inline. >>>>>> >>>>>> On 20.09.2011 16:19, Benoit Claise wrote: >>>>>>> Dear all, >>>>>>> >>>>>>> [this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt, TO DO -> "time first flow dropped" and "time last flow dropped" inconsistency. See the discussion on the list.] >>>>>>> >>>>>>> Paul Aitken discovered this issue., >>>>>>> >>>>>>> From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template >>>>>>> >>>>>>> time first flow dropped >>>>>>> The timestamp of the first Flow was dropped by >>>>>>> the Metering Process. For this timestamp, any >>>>>>> of the "flowStart" timestamp Information >>>>>>> Elements flowStartMilliseconds, >>>>>>> flowStartMicroseconds, flowStartNanoseconds, and >>>>>>> flowStartDeltaMicroseconds can be used. >>>>>>> >>>>>>> time last flow dropped >>>>>>> The timestamp of the last IP packet that was >>>>>>> ignored by the Metering Process. For this >>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>> Information Elements flowEndMilliseconds, >>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>> >>>>>>> >>>>>>> Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o >>>>>>> >>>>>>> Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that". >>>>>>> >>>>>>> Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter? >>>>>>> >>>>>>> Here is a proposal for 4.2 and 4.3. The underlined parts are new >>>>>>> >>>>>>> 4.2. The Metering Process Reliability Statistics Option Template >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Metering Process Reliability Option Template specifies the >>>>>>> structure of a Data Record for reporting lack of reliability in the >>>>>>> Metering Process. It SHOULD contain the following Information >>>>>>> Elements that are defined in [ >>>>>>> RFC5102 >>>>>>> ]: >>>>>>> >>>>>>> observationDomainId >>>>>>> An identifier of an Observation Domain that >>>>>>> is locally unique to the Exporting Process. >>>>>>> This Information Element MUST be defined as a >>>>>>> Scope Field. >>>>>>> >>>>>>> >>>>>>> >>>>>>> meteringProcessId (*) >>>>>>> The identifier of the Metering Process for >>>>>>> which lack of reliability is reported. There >>>>>>> This Information Element MUST be defined as a >>>>>>> Scope Field. >>>>>>> >>>>>>> >>>>>>> ignoredPacketTotalCount >>>>>>> The total number of IP packets that the >>>>>>> Metering Process did not process. >>>>>>> >>>>>>> ignoredOctetTotalCount >>>>>>> The total number of octets in observed IP >>>>>>> packets that the Metering Process did not >>>>>>> process. >>>>>>> >>>>>>> time first >>>>>>> packet >>>>>>> ignored >>>>>>> The timestamp of the first IP packet that was >>>>>>> ignored by the Metering Process. For this >>>>>>> timestamp, any of the "flowStart" timestamp >>>>>>> Information Elements flowStartMilliseconds, >>>>>>> flowStartMicroseconds, flowStartNanoseconds, >>>>>>> and flowStartDeltaMicroseconds can be used. >>>>>>> >>>>>>> time last >>>>>>> packet >>>>>>> ignored >>>>>>> The timestamp of the last IP packet that was >>>>>>> ignored by the Metering Process. For this >>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>> Information Elements flowEndMilliseconds, >>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>> >>>>>> I do not find these IEs in RFC5102. >>>>> Which ones? flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds >>>>> There are in http://www.iana.org/assignments/ipfix/ipfix.xml >>>>> However, re-reading >>>>> time first packet >>>>> ignored >>>>> The timestamp of the first IP packet that was >>>>> ignored by the Metering Process. For this >>>>> timestamp, any of the "flowStart" timestamp >>>>> Information Elements flowStartMilliseconds, >>>>> flowStartMicroseconds, flowStartNanoseconds, >>>>> and flowStartDeltaMicroseconds can be used. >>>>> >>>>> time last >>>>> packet >>>>> ignored >>>>> The timestamp of the last IP packet that was >>>>> ignored by the Metering Process. For this >>>>> timestamp, any of the "flowEnd" timestamp >>>>> Information Elements flowEndMilliseconds, >>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>> flowEndDeltaMicroseconds can be used. >>>>> >>>>> And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd" timestamp IE, >>>>> I now believe that we should be using this series of IEs >>>>> 322 observationTimeSeconds >>>>> 323 observationTimeMilliseconds >>>>> 324 observationTimeMicroseconds >>>>> 325 observationTimeNanoseconds >>>>> >>>>>>> 4.3. The Exporting Process Reliability Statistics Option Template >>>>>>> >>>>>>> >>>>>>> The Exporting Process Reliability Option Template specifies the >>>>>>> structure of a Data Record for reporting lack of reliability in the >>>>>>> Exporting process. It SHOULD contain the following Information >>>>>>> Elements that are defined in [ >>>>>>> RFC5102 >>>>>>> ]: >>>>>>> >>>>>>> Exporting Process ID >>>>>>> The identifier of the Exporting Process for >>>>>>> which lack of reliability is reported. There >>>>>>> are three Information Elements specified in >>>>>>> [ >>>>>>> RFC5102 >>>>>>> ] that can be used for this purpose: >>>>>>> exporterIPv4Address, exporterIPv6Address, or >>>>>>> exportingProcessId. This Information Element >>>>>>> MUST be defined as a Scope Field. >>>>>>> >>>>>>> notSentFlowTotalCount >>>>>>> The total number of Flows that were generated by >>>>>>> the Metering Process and dropped by the Metering >>>>>>> Process or by the Exporting Process instead of >>>>>>> being sent to the Collecting Process. >>>>>>> >>>>>>> notSentPacketTotalCount >>>>>>> The total number of packets in Flow Records that >>>>>>> were generated by the Metering Process and >>>>>>> dropped by the Metering Process or by the >>>>>>> Exporting Process instead of being sent to the >>>>>>> Collecting Process. >>>>>>> >>>>>>> notSentOctetTotalCount >>>>>>> The total number of octets in packets in Flow >>>>>>> Records that were generated by the Metering >>>>>>> Process and dropped by the Metering Process or >>>>>>> by the Exporting Process instead of being sent >>>>>>> to the Collecting Process. >>>>>>> >>>>>>> time first flow dropped >>>>>>> >>>>>>> The time at which the first Flow Record was dropped by >>>>>>> the >>>>>>> Exporting Process. >>>>>>> For this timestamp, any >>>>>>> of the "flowStart" timestamp Information >>>>>>> Elements flowStartMilliseconds, >>>>>>> flowStartMicroseconds, flowStartNanoseconds, and >>>>>>> flowStartDeltaMicroseconds can be used. >>>>>>> >>>>>>> time last flow dropped >>>>>>> >>>>>>> The time at which the last Flow Record was >>>>>>> dropped by the Exporting Process >>>>>>> . For this >>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>> Information Elements flowEndMilliseconds, >>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>> >>>>>> Again, I do not find these IEs in RFC5102. >>>>> Same remark, I believe we should be using for the two previous IEs >>>>> 322 observationTimeSeconds >>>>> 323 observationTimeMilliseconds >>>>> 324 observationTimeMicroseconds >>>>> 325 observationTimeNanoseconds >>>>> Regards, Benoit. >>>>>>> The Exporting Process SHOULD export the Data Record specified by the >>>>>>> Exporting Process Reliability Statistics Option Template on a regular >>>>>>> basis or based on some export policy. This periodicity or export >>>>>>> policy SHOULD be configurable. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> (*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id >>>>>>> 1. there is a meteringProcessId in IPFIX IANA while there is no cache id >>>>>> meteringProcessId should do the job. >>>>>> >>>>>>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId? >>>>>>> [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name. >>>>>>> From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process. >>>>>>> If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below >>>>>> See reply to Pauls mail. >>>>>> >>>>>> Regards, >>>>>> Gerhard >>>>>> >>>>>>> 4.3. Cache Class >>>>>>> >>>>>>> >>>>>>> +-----------------------------------+ >>>>>>> | Cache | >>>>>>> +-----------------------------------+ 1 +------------------+ >>>>>>> | name |<>--------| immediateCache/ | >>>>>>> | dataRecords {readOnly} | | timeoutCache/ | >>>>>>> | cacheDiscontinuityTime {readOnly} | | naturalCache/ | >>>>>>> | | | permanentCache | >>>>>>> | | +------------------+ >>>>>>> | | >>>>>>> | | 0..* +------------------+ >>>>>>> | |--------->| ExportingProcess | >>>>>>> +-----------------------------------+ +------------------+ >>>>>>> >>>>>>> Figure 12: Cache class >>>>>>> >>>>>>> What do you think? Do you see another way? >>>>>>> >>>>>>> Regards, Paul& Benoit. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Tue Sep 27 13:22:43 2011 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 C047C21F8FD1 for ; Tue, 27 Sep 2011 13:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_75=0.6, 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 73XKVT1F+U-7 for ; Tue, 27 Sep 2011 13:22:42 -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 3DD2B21F8F11 for ; Tue, 27 Sep 2011 13:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=21749; q=dns/txt; s=iport; t=1317155128; x=1318364728; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9wNbK2DEErztTTqcl48l5lRRTUvsVUhHxs+runAteqg=; b=HDVklaXrza5z4wRmBXToKjDFXsIXk8oFiPeqEvDyyB54i3MJtRPDNj3B XMXl9PqFtPeUL0runBiiSlAYnA4/wKakPw/Hlt1RBHONK3zHxf8WujRoW qh8qj3T9X/Yedn3Yjx8zpVJTptC+mRcz+qzw50+xcqiPnU5xZ2btSg7Us A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAQxgk5Io8UR/2dsb2JhbABBqAF4gVMBAQEBAwEBAQ8BFBE2CgEQCxgJDAoPCQMCAQIBFTAGDQEFAgEBBRIHh1ybQgGeLIN0gxcEk1KFIowT X-IronPort-AV: E=Sophos;i="4.68,451,1312156800"; d="scan'208";a="117515190" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 27 Sep 2011 20:25:25 +0000 Received: from [10.61.89.32] (ams3-vpn-dhcp6433.cisco.com [10.61.89.32]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8RKPMYr019177; Tue, 27 Sep 2011 20:25:22 GMT Message-ID: <4E823130.6000505@cisco.com> Date: Tue, 27 Sep 2011 21:25:20 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Andrew Feren References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> <4E7AA240.4020506@plixer.com> <4E7AE9D1.9090002@cisco.com> <4E7CF4F8.8060405@plixer.com> <4E82081B.8040806@plixer.com> In-Reply-To: <4E82081B.8040806@plixer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 27 Sep 2011 20:22:43 -0000 Andrew, Brian, How do you know that the received template is a MPRSO? - must the fields be exactly in the specified order and no other combination in order to be a valid MPRSO? - how do you know which of the observationTime* elements (or missingObservationWindowEdge elements) is the first and which is the last? - only from their position in the template (so, field order and position are crucial) - by comparing them (so field order and position aren't important) Suppose a mediator adds, removes, or re-orders the fields. - does this invalidate the MPRSO? - how does a mediator know not to do this? - how does the collector cope if a mediator does? The change to "missingObservationWindowEdge" is simply a rename of observationTime. I don't see that it adds anything. A long basicList isn't the right solution because - various list lengths mean there are multiple possible templates making the detection of the MPRSO a little more difficult ie, it's no longer a fixed template, nor a combination of a few possibilities, but a great many different possible templates. - there are two different semantics for the start and end of the window, so it's actually an ordered list of pairs ie a subTemplateList. Lists can have zero elements. However, if you want to report that nothing was lost, the ignored*Count = 0 report should indicate the start and end of the 100% period. A list length of zero doesn't tell when stuff was or was not lost - so it's of limited usefulness, unless perhaps as a total figure? Again, see questions above about what is / is not a valid MPRSO. Thanks, P. On 27/09/11 18:30, Andrew Feren wrote: > Hi Brian, > > Well stated. > > Additional comments inline > > On 09/27/2011 12:15 PM, Brian Trammell wrote: >> Greetings, all, >> >> This is a little bit of an abuse of the ordering of IEs, in my >> opinion, and of the general rule that only IEs, and the scope in >> which they are defined, carry semantics. Even for templates which are >> defined within Standards Track RFCs, the records defined by the >> template should be decipherable without reference to the RFC. Put >> another way, we should not define magical templates, and this >> template as proposed looks pretty magical. > Yes, a black magic sort of magical. We have been discussing this > proposed change in the office and coming to the same conclusion. >> Without reading the text of this thread, and following basically >> everything we've ever said about multiple IEs in a record, I would >> interpret a record matching this template as follows: >> >> For the metering process A and observation domain B: >> N packets were ignored; these contained a total of M octets. >> The first observation at this metering process was at time T0. >> The second observation at this metering process was at time T1. > This was exactly how I interpreted this template until I read the > updated draft and saw the bit about "the Collecting Process MUST > determine which is the oldest and the most recent timestamp in order > the determine the right semantic ...." > >> This is quite far from the stated intention. I would strongly suggest >> that we not so lightly give up on "templates should be unambiguously >> understandable" requirement, even if the exception itself lives in >> the core protocol document. >> >> I would suggest, if you want to do a multiple IE solution here, you >> define something like missingObservationWindowEdge, and have two of >> them: >> >> observationDomainId {scope} >> meteringProcessId {scope} >> ignoredPacketTotalCount >> ignoredOctetTotalCount >> missingObservationWindowEdge >> missingObservationWindowEdge >> >> This has the advantage that you can have a long basicList of window >> edges in order to define multiple missing observation windows; each >> edge pair is a loss window. > I like this suggestion, and I have a few additional thoughts. > > Perhaps the basic list of edge times should either be limited to only > one pair or the ignored*TotalCount IEs needs to be in a basiclist with > N entries too. > > How about observationWindowEdge instead (no "missing") to be more > generally useful. > > I think a list of time edges also works neatly when sending this > template at regular intervals (which SHOULD be done). When the > ignored*TotalCount IEs are zero, an empty list makes sense for edge > times. > > >> Seconds suffice for these, I think. You might want to do one in >> milliseconds. But if you have the resources to calculate your packet >> loss window to nanosecond precision without having the resources to >> not lose packets, I humbly submit you've picked the wrong engineering >> tradeoffs. :) > Unless window edge isn't defined specifically for "missing" values. > Then the higher precision timestamps might have some use. > > -Andrew >> >> Best regards, >> >> Brian >> >> On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote: >> >>> Yes, this makes sense. >>> >>> I gave this some thought and I don't have a better suggestion. I >>> also agree that even though the flow[Start|End]* collection of IEs >>> conveniently has one IE for both first and last, observationTime* is >>> the more correct choice here. >>> >>> -Andrew >>> >>> On 09/22/2011 03:54 AM, Benoit Claise wrote: >>>> Hi Andrew, >>>>> Hi Benoit, >>>>> >>>>> I had the same thought about using >>>>> >>>>> 322 observationTimeSeconds >>>>> 323 observationTimeMilliseconds >>>>> 324 observationTimeMicroseconds >>>>> 325 observationTimeNanoseconds >>>>> >>>>> The problem is that you need two timestamps in the same record >>>>> (first and last). How does that work with the above? >>>> Excellent question. We debated this question with Paul Aitken >>>> recently. >>>> Let me rephrase the question slightly differently: how does the >>>> collector determine that this is a "The Metering Process >>>> Reliability Statistics Options Template", and understands the >>>> semantic of the two counters? >>>> Well. Two solutions: >>>> 1. we duplicate all the IEs to have the exact correct semantic. >>>> >>>> ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] >>>> ... and potentially some more such as pre|post >>>> This brings multiple new dimensions to IE and will lead to an >>>> explosion of IEs if we want to cover all the case >>>> 2. the collector tests the possible combination of IE in the >>>> Options Template Record. >>>> For example, if the collector sees such an Options Template >>>> Record, it knows that this a "The Metering Process Reliability >>>> Statistics Options Template" >>>> observationDomainId (scope) >>>> meteringProcessId (scope) >>>> >>>> ignoredPacketTotalCount >>>> ignoredOctetTotalCount >>>> observationTimeSeconds | observationTimeMilliseconds | >>>> observationTimeMicroseconds | observationTimeNanoseconds >>>> observationTimeSeconds | observationTimeMilliseconds | >>>> observationTimeMicroseconds | observationTimeNanoseconds >>>> >>>> >>>> While the solution 2 is not perfect, this was the chosen track. >>>> >>>> Does it make sense? >>>> >>>> Regards, Benoit >>>>> -Andrew >>>>> >>>>> On 09/21/2011 07:11 PM, Benoit Claise wrote: >>>>>> Hi Gerhard, >>>>>> >>>>>> Thanks for your reply. >>>>>> See in line. >>>>>>> Hi Benoit, >>>>>>> >>>>>>> See comments inline. >>>>>>> >>>>>>> On 20.09.2011 16:19, Benoit Claise wrote: >>>>>>>> Dear all, >>>>>>>> >>>>>>>> [this email addresses >>>>>>>> draft-claise-ipfix-protocol-rfc5101bis-00.txt, TO DO -> "time >>>>>>>> first flow dropped" and "time last flow dropped" >>>>>>>> inconsistency. See the discussion on the list.] >>>>>>>> >>>>>>>> Paul Aitken discovered this issue., >>>>>>>> >>>>>>>> From [RFC5101], section 4.3. The Exporting Process Reliability >>>>>>>> Statistics Option Template >>>>>>>> >>>>>>>> time first flow dropped >>>>>>>> The timestamp of the first Flow was >>>>>>>> dropped by >>>>>>>> the Metering Process. For this >>>>>>>> timestamp, any >>>>>>>> of the "flowStart" timestamp Information >>>>>>>> Elements flowStartMilliseconds, >>>>>>>> flowStartMicroseconds, >>>>>>>> flowStartNanoseconds, and >>>>>>>> flowStartDeltaMicroseconds can be used. >>>>>>>> >>>>>>>> time last flow dropped >>>>>>>> The timestamp of the last IP packet >>>>>>>> that was >>>>>>>> ignored by the Metering Process. For >>>>>>>> this >>>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>>> Information Elements flowEndMilliseconds, >>>>>>>> flowEndMicroseconds, >>>>>>>> flowEndNanoseconds, and >>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>> >>>>>>>> >>>>>>>> Firstly, these definitions are inconsistent since the names and >>>>>>>> the first definition say "flow" while the second definition >>>>>>>> says "IP packet". Obviously "IP packet" != "flow" :-o >>>>>>>> >>>>>>>> Secondly, "The timestamp of the first Flow was dropped by the >>>>>>>> Metering Process." is bad English: at least it's missing "that". >>>>>>>> >>>>>>>> Thirdly, the section 4.2 doesn't take into account a metering >>>>>>>> process id. Indeed, what if we have multiple caches on the >>>>>>>> exporter? >>>>>>>> >>>>>>>> Here is a proposal for 4.2 and 4.3. The underlined parts are new >>>>>>>> >>>>>>>> 4.2. The Metering Process Reliability Statistics Option Template >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The Metering Process Reliability Option Template specifies the >>>>>>>> structure of a Data Record for reporting lack of >>>>>>>> reliability in the >>>>>>>> Metering Process. It SHOULD contain the following Information >>>>>>>> Elements that are defined in [ >>>>>>>> RFC5102 >>>>>>>> ]: >>>>>>>> >>>>>>>> observationDomainId >>>>>>>> An identifier of an Observation >>>>>>>> Domain that >>>>>>>> is locally unique to the Exporting >>>>>>>> Process. >>>>>>>> This Information Element MUST be >>>>>>>> defined as a >>>>>>>> Scope Field. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> meteringProcessId (*) >>>>>>>> The identifier of the Metering >>>>>>>> Process for >>>>>>>> which lack of reliability is >>>>>>>> reported. There >>>>>>>> This Information Element MUST be >>>>>>>> defined as a >>>>>>>> Scope Field. >>>>>>>> >>>>>>>> >>>>>>>> ignoredPacketTotalCount >>>>>>>> The total number of IP packets that >>>>>>>> the >>>>>>>> Metering Process did not process. >>>>>>>> >>>>>>>> ignoredOctetTotalCount >>>>>>>> The total number of octets in >>>>>>>> observed IP >>>>>>>> packets that the Metering Process >>>>>>>> did not >>>>>>>> process. >>>>>>>> >>>>>>>> time first >>>>>>>> packet >>>>>>>> ignored >>>>>>>> The timestamp of the first IP >>>>>>>> packet that was >>>>>>>> ignored by the Metering Process. >>>>>>>> For this >>>>>>>> timestamp, any of the "flowStart" >>>>>>>> timestamp >>>>>>>> Information Elements >>>>>>>> flowStartMilliseconds, >>>>>>>> flowStartMicroseconds, >>>>>>>> flowStartNanoseconds, >>>>>>>> and flowStartDeltaMicroseconds can >>>>>>>> be used. >>>>>>>> >>>>>>>> time last >>>>>>>> packet >>>>>>>> ignored >>>>>>>> The timestamp of the last IP packet >>>>>>>> that was >>>>>>>> ignored by the Metering Process. >>>>>>>> For this >>>>>>>> timestamp, any of the "flowEnd" >>>>>>>> timestamp >>>>>>>> Information Elements >>>>>>>> flowEndMilliseconds, >>>>>>>> flowEndMicroseconds, >>>>>>>> flowEndNanoseconds, and >>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>> >>>>>>> I do not find these IEs in RFC5102. >>>>>> Which ones? flowEndMilliseconds, flowEndMicroseconds, >>>>>> flowEndNanoseconds, and flowEndDeltaMicroseconds >>>>>> There are in http://www.iana.org/assignments/ipfix/ipfix.xml >>>>>> However, re-reading >>>>>> time first packet >>>>>> ignored >>>>>> The timestamp of the first IP packet >>>>>> that was >>>>>> ignored by the Metering Process. For >>>>>> this >>>>>> timestamp, any of the "flowStart" >>>>>> timestamp >>>>>> Information Elements >>>>>> flowStartMilliseconds, >>>>>> flowStartMicroseconds, >>>>>> flowStartNanoseconds, >>>>>> and flowStartDeltaMicroseconds can be >>>>>> used. >>>>>> >>>>>> time last >>>>>> packet >>>>>> ignored >>>>>> The timestamp of the last IP packet >>>>>> that was >>>>>> ignored by the Metering Process. For >>>>>> this >>>>>> timestamp, any of the "flowEnd" >>>>>> timestamp >>>>>> Information Elements >>>>>> flowEndMilliseconds, >>>>>> flowEndMicroseconds, >>>>>> flowEndNanoseconds, and >>>>>> flowEndDeltaMicroseconds can be used. >>>>>> >>>>>> And http://www.iana.org/assignments/ipfix/ipfix.xml for the >>>>>> "flowEnd" timestamp IE, >>>>>> I now believe that we should be using this series of IEs >>>>>> 322 observationTimeSeconds >>>>>> 323 observationTimeMilliseconds >>>>>> 324 observationTimeMicroseconds >>>>>> 325 observationTimeNanoseconds >>>>>> >>>>>>>> 4.3. The Exporting Process Reliability Statistics Option Template >>>>>>>> >>>>>>>> >>>>>>>> The Exporting Process Reliability Option Template specifies >>>>>>>> the >>>>>>>> structure of a Data Record for reporting lack of >>>>>>>> reliability in the >>>>>>>> Exporting process. It SHOULD contain the following >>>>>>>> Information >>>>>>>> Elements that are defined in [ >>>>>>>> RFC5102 >>>>>>>> ]: >>>>>>>> >>>>>>>> Exporting Process ID >>>>>>>> The identifier of the Exporting >>>>>>>> Process for >>>>>>>> which lack of reliability is >>>>>>>> reported. There >>>>>>>> are three Information Elements >>>>>>>> specified in >>>>>>>> [ >>>>>>>> RFC5102 >>>>>>>> ] that can be used for this purpose: >>>>>>>> exporterIPv4Address, >>>>>>>> exporterIPv6Address, or >>>>>>>> exportingProcessId. This Information >>>>>>>> Element >>>>>>>> MUST be defined as a Scope Field. >>>>>>>> >>>>>>>> notSentFlowTotalCount >>>>>>>> The total number of Flows that were >>>>>>>> generated by >>>>>>>> the Metering Process and dropped by >>>>>>>> the Metering >>>>>>>> Process or by the Exporting Process >>>>>>>> instead of >>>>>>>> being sent to the Collecting Process. >>>>>>>> >>>>>>>> notSentPacketTotalCount >>>>>>>> The total number of packets in Flow >>>>>>>> Records that >>>>>>>> were generated by the Metering Process >>>>>>>> and >>>>>>>> dropped by the Metering Process or by the >>>>>>>> Exporting Process instead of being >>>>>>>> sent to the >>>>>>>> Collecting Process. >>>>>>>> >>>>>>>> notSentOctetTotalCount >>>>>>>> The total number of octets in packets >>>>>>>> in Flow >>>>>>>> Records that were generated by the >>>>>>>> Metering >>>>>>>> Process and dropped by the Metering >>>>>>>> Process or >>>>>>>> by the Exporting Process instead of >>>>>>>> being sent >>>>>>>> to the Collecting Process. >>>>>>>> >>>>>>>> time first flow dropped >>>>>>>> >>>>>>>> The time at which the first Flow Record >>>>>>>> was dropped by >>>>>>>> the >>>>>>>> Exporting Process. >>>>>>>> For this timestamp, any >>>>>>>> of the "flowStart" timestamp Information >>>>>>>> Elements flowStartMilliseconds, >>>>>>>> flowStartMicroseconds, >>>>>>>> flowStartNanoseconds, and >>>>>>>> flowStartDeltaMicroseconds can be used. >>>>>>>> >>>>>>>> time last flow dropped >>>>>>>> >>>>>>>> The time at which the last Flow Record was >>>>>>>> dropped by the Exporting Process >>>>>>>> . For this >>>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>>> Information Elements flowEndMilliseconds, >>>>>>>> flowEndMicroseconds, >>>>>>>> flowEndNanoseconds, and >>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>> >>>>>>> Again, I do not find these IEs in RFC5102. >>>>>> Same remark, I believe we should be using for the two previous IEs >>>>>> 322 observationTimeSeconds >>>>>> 323 observationTimeMilliseconds >>>>>> 324 observationTimeMicroseconds >>>>>> 325 observationTimeNanoseconds >>>>>> Regards, Benoit. >>>>>>>> The Exporting Process SHOULD export the Data Record >>>>>>>> specified by the >>>>>>>> Exporting Process Reliability Statistics Option Template on >>>>>>>> a regular >>>>>>>> basis or based on some export policy. This periodicity or >>>>>>>> export >>>>>>>> policy SHOULD be configurable. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (*) regarding the meteringProcessId, we were hesitating between >>>>>>>> the meteringProcessId and the cache id >>>>>>>> 1. there is a meteringProcessId in IPFIX IANA while there is no >>>>>>>> cache id >>>>>>> meteringProcessId should do the job. >>>>>>> >>>>>>>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what >>>>>>>> should be the value in meteringProcessId? >>>>>>>> [IPFIX-CONF] doesn't mention the meteringProcessId, but a >>>>>>>> cache name. >>>>>>>> From figure 1 and 2, it seems that there is a one to one >>>>>>>> matching between the cache and the metering process. >>>>>>>> If this is the case, a solution could be to add a >>>>>>>> meteringProcess inside the cache in the figure 12 in >>>>>>>> [IPFIX-CONF] below >>>>>>> See reply to Pauls mail. >>>>>>> >>>>>>> Regards, >>>>>>> Gerhard >>>>>>> >>>>>>>> 4.3. Cache Class >>>>>>>> >>>>>>>> >>>>>>>> +-----------------------------------+ >>>>>>>> | Cache | >>>>>>>> +-----------------------------------+ 1 >>>>>>>> +------------------+ >>>>>>>> | name |<>--------| >>>>>>>> immediateCache/ | >>>>>>>> | dataRecords {readOnly} | | >>>>>>>> timeoutCache/ | >>>>>>>> | cacheDiscontinuityTime {readOnly} | | >>>>>>>> naturalCache/ | >>>>>>>> | | | >>>>>>>> permanentCache | >>>>>>>> | | >>>>>>>> +------------------+ >>>>>>>> | | >>>>>>>> | | 0..* >>>>>>>> +------------------+ >>>>>>>> | |--------->| >>>>>>>> ExportingProcess | >>>>>>>> +-----------------------------------+ >>>>>>>> +------------------+ >>>>>>>> >>>>>>>> Figure 12: Cache class >>>>>>>> >>>>>>>> What do you think? Do you see another way? >>>>>>>> >>>>>>>> Regards, Paul& Benoit. >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>> _______________________________________________ >>> 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 Tue Sep 27 14:11:13 2011 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 AA39521F8E0C for ; Tue, 27 Sep 2011 14:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_75=0.6, 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 tniaMHBtyVp4 for ; Tue, 27 Sep 2011 14:11:11 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3488A21F8F92 for ; Tue, 27 Sep 2011 14:11:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BA629D930C; Tue, 27 Sep 2011 23:13:54 +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 lcB3zGhQuKlG; Tue, 27 Sep 2011 23:13:54 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (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 7FBFED9300; Tue, 27 Sep 2011 23:13:53 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4E823130.6000505@cisco.com> Date: Tue, 27 Sep 2011 23:13:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> <4E7AA240.4020506@plixer.com> <4E7AE9D1.9090002@cisco.com> <4E7CF4F8.8060405@plixer.com> <4E82081B.8040806@plixer.com> <4E823130.6000505@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1084) Cc: ipfix@ietf.org Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 27 Sep 2011 21:11:14 -0000 Hi, Paul, all, I suppose I should state for the sake of completeness that this is the = first I've ever actually _thought_ about the MPRSO. I find the whole use = case for it rather dubious -- it presumes an MP with somehow trustworthy = knowledge about packet loss, which is never the case, and relying on = such information at the collector side for anything other than = entertainment purposes is fraught with peril -- so I saw the MAY on = section 4 in 5101, was thankful it wasn't a MUST I had to fight against = and/or simply ignore, and never looked back. That said, it does make sense to fix, since it's there. On Sep 27, 2011, at 10:25 PM, Paul Aitken wrote: > How do you know that the received template is a MPRSO? Does it matter? Seriously, what is the difference between "an MPRSO" and = "a template containing information about lost packets for a given time = interval, along with maybe some other information"? Do we actually want = to require an MP to keep time interval information for loss? Wouldn't = those resources be better deployed not losing packets in the first = place? So let's say I want to report missing packets, but don't have = information about when I lost them. Do I have to throw a timestamp in = there anyway in order for it to be "an MPRSO"? I think these are arguments against having the timestamps at all (or to = include them, with a further instruction that they are optional). > - must the fields be exactly in the specified order and no other = combination in order to be a valid MPRSO? This isn't a valid template recognition strategy in IPFIX. At least, it = hasn't been to date, and it's a bad idea to make it so. IE-Doctors = contains language meant to instruct IPFIX application authors to refrain = from specifying such magic templates. > - how do you know which of the observationTime* elements (or = missingObservationWindowEdge elements) is the first and which is the = last? > - only from their position in the template (so, field order and = position are crucial) > - by comparing them (so field order and position aren't = important) Time intervals can be treated as a special case, here, since time can = generally be assumed to go in only one direction. "The time interval = from A to B" is completely equivalent to "the time interval from B to = A", so one could argue order doesn't matter. (We don't argue that = anywhere in IPFIX, to be true. But what do I do when I get a flow with = an endTime before the startTime?) > Suppose a mediator adds, removes, or re-orders the fields. > - does this invalidate the MPRSO? > - how does a mediator know not to do this? > - how does the collector cope if a mediator does? These questions seem to apply only to the case where MPRSO is magical. = I'm trying to define it such that it isn't. > The change to "missingObservationWindowEdge" is simply a rename of = observationTime. I don't see that it adds anything. observationTime already has a meaning. "This Information Element = specifies the absolute time in seconds of an observation." In other = words, "I saw the thing I'm talking about in this record at the = specified time". It has never to date been specified in such a way that = it means "I saw the thing I'm talking about in this record at the = specified time, unless the record contains two observationTimes, in = which case I saw the thing in the time interval between those two = things". missingObservationWindowEdge means "there is missing information within = an interval described between this IE and the other identical IE in the = record". If we keep the MPRSO defined as it is (and fix it only by = dropping in , missingObservationWindowStartSeconds and = missingObservationWindowEndSeconds, since it's more IPFIXish, but there = was concern voiced in this thread about IE space explosion, so I figured = we could exploit the nature of time and cut down on the IEs required by = half. The advantage of a new IE is that it isn't overloaded, but more = importantly that it does not lead to an ambiguous interpretation of the = entire template at the collector. > A long basicList isn't the right solution because > - various list lengths mean there are multiple possible templates = making the detection of the MPRSO a little more difficult > ie, it's no longer a fixed template, nor a combination of a few = possibilities, but a great many different possible templates. > - there are two different semantics for the start and end of the = window, so it's actually an ordered list of pairs ie a subTemplateList. > Lists can have zero elements. However, if you want to report that = nothing was lost, the ignored*Count =3D 0 report should indicate the = start and end of the 100% period. A list length of zero doesn't tell = when stuff was or was not lost - so it's of limited usefulness, unless = perhaps as a total figure? Again, see questions above about what is / is = not a valid MPRSO. I withdraw my basicList comment; it was essentially just "thinking = aloud", and I didn't actually intend to include a mention of it in the = 5101bis MPRSO. 1. It doesn't really add anything to the original intent = of the MPRSO, and 2. adding it in 5101bis would cause 5101bis to have a = normative dependency on 6313, which is a terrible idea. Cheers, Brian > On 27/09/11 18:30, Andrew Feren wrote: >> Hi Brian, >>=20 >> Well stated. >>=20 >> Additional comments inline >>=20 >> On 09/27/2011 12:15 PM, Brian Trammell wrote: >>> Greetings, all, >>>=20 >>> This is a little bit of an abuse of the ordering of IEs, in my = opinion, and of the general rule that only IEs, and the scope in which = they are defined, carry semantics. Even for templates which are defined = within Standards Track RFCs, the records defined by the template should = be decipherable without reference to the RFC. Put another way, we should = not define magical templates, and this template as proposed looks pretty = magical. >> Yes, a black magic sort of magical. We have been discussing this = proposed change in the office and coming to the same conclusion. >>> Without reading the text of this thread, and following basically = everything we've ever said about multiple IEs in a record, I would = interpret a record matching this template as follows: >>>=20 >>> For the metering process A and observation domain B: >>> N packets were ignored; these contained a total of M octets. >>> The first observation at this metering process was at time T0. >>> The second observation at this metering process was at time T1. >> This was exactly how I interpreted this template until I read the = updated draft and saw the bit about "the Collecting Process MUST = determine which is the oldest and the most recent timestamp in order the = determine the right semantic ...." >>=20 >>> This is quite far from the stated intention. I would strongly = suggest that we not so lightly give up on "templates should be = unambiguously understandable" requirement, even if the exception itself = lives in the core protocol document. >>>=20 >>> I would suggest, if you want to do a multiple IE solution here, you = define something like missingObservationWindowEdge, and have two of = them: >>>=20 >>> observationDomainId {scope} >>> meteringProcessId {scope} >>> ignoredPacketTotalCount >>> ignoredOctetTotalCount >>> missingObservationWindowEdge >>> missingObservationWindowEdge >>>=20 >>> This has the advantage that you can have a long basicList of window = edges in order to define multiple missing observation windows; each edge = pair is a loss window. >> I like this suggestion, and I have a few additional thoughts. >>=20 >> Perhaps the basic list of edge times should either be limited to only = one pair or the ignored*TotalCount IEs needs to be in a basiclist with N = entries too. >>=20 >> How about observationWindowEdge instead (no "missing") to be more = generally useful. >>=20 >> I think a list of time edges also works neatly when sending this = template at regular intervals (which SHOULD be done). When the = ignored*TotalCount IEs are zero, an empty list makes sense for edge = times. >>=20 >>=20 >>> Seconds suffice for these, I think. You might want to do one in = milliseconds. But if you have the resources to calculate your packet = loss window to nanosecond precision without having the resources to not = lose packets, I humbly submit you've picked the wrong engineering = tradeoffs. :) >> Unless window edge isn't defined specifically for "missing" values. = Then the higher precision timestamps might have some use. >>=20 >> -Andrew >>>=20 >>> Best regards, >>>=20 >>> Brian >>>=20 >>> On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote: >>>=20 >>>> Yes, this makes sense. >>>>=20 >>>> I gave this some thought and I don't have a better suggestion. I = also agree that even though the flow[Start|End]* collection of IEs = conveniently has one IE for both first and last, observationTime* is the = more correct choice here. >>>>=20 >>>> -Andrew >>>>=20 >>>> On 09/22/2011 03:54 AM, Benoit Claise wrote: >>>>> Hi Andrew, >>>>>> Hi Benoit, >>>>>>=20 >>>>>> I had the same thought about using >>>>>>=20 >>>>>> 322 observationTimeSeconds >>>>>> 323 observationTimeMilliseconds >>>>>> 324 observationTimeMicroseconds >>>>>> 325 observationTimeNanoseconds >>>>>>=20 >>>>>> The problem is that you need two timestamps in the same record = (first and last). How does that work with the above? >>>>> Excellent question. We debated this question with Paul Aitken = recently. >>>>> Let me rephrase the question slightly differently: how does the = collector determine that this is a "The Metering Process Reliability = Statistics Options Template", and understands the semantic of the two = counters? >>>>> Well. Two solutions: >>>>> 1. we duplicate all the IEs to have the exact correct semantic. >>>>> = ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds= |Nanoseconds] ... and potentially some more such as pre|post >>>>> This brings multiple new dimensions to IE and will lead to an = explosion of IEs if we want to cover all the case >>>>> 2. the collector tests the possible combination of IE in the = Options Template Record. >>>>> For example, if the collector sees such an Options Template = Record, it knows that this a "The Metering Process Reliability = Statistics Options Template" >>>>> observationDomainId (scope) >>>>> meteringProcessId (scope) >>>>>=20 >>>>> ignoredPacketTotalCount >>>>> ignoredOctetTotalCount >>>>> observationTimeSeconds | observationTimeMilliseconds | = observationTimeMicroseconds | observationTimeNanoseconds >>>>> observationTimeSeconds | observationTimeMilliseconds | = observationTimeMicroseconds | observationTimeNanoseconds >>>>>=20 >>>>>=20 >>>>> While the solution 2 is not perfect, this was the chosen track. >>>>>=20 >>>>> Does it make sense? >>>>>=20 >>>>> Regards, Benoit >>>>>> -Andrew >>>>>>=20 >>>>>> On 09/21/2011 07:11 PM, Benoit Claise wrote: >>>>>>> Hi Gerhard, >>>>>>>=20 >>>>>>> Thanks for your reply. >>>>>>> See in line. >>>>>>>> Hi Benoit, >>>>>>>>=20 >>>>>>>> See comments inline. >>>>>>>>=20 >>>>>>>> On 20.09.2011 16:19, Benoit Claise wrote: >>>>>>>>> Dear all, >>>>>>>>>=20 >>>>>>>>> [this email addresses = draft-claise-ipfix-protocol-rfc5101bis-00.txt, TO DO -> "time first = flow dropped" and "time last flow dropped" inconsistency. See the = discussion on the list.] >>>>>>>>>=20 >>>>>>>>> Paul Aitken discovered this issue., >>>>>>>>>=20 >>>>>>>>> =46rom [RFC5101], section 4.3. The Exporting Process = Reliability Statistics Option Template >>>>>>>>>=20 >>>>>>>>> time first flow dropped >>>>>>>>> The timestamp of the first Flow was = dropped by >>>>>>>>> the Metering Process. For this = timestamp, any >>>>>>>>> of the "flowStart" timestamp = Information >>>>>>>>> Elements flowStartMilliseconds, >>>>>>>>> flowStartMicroseconds, = flowStartNanoseconds, and >>>>>>>>> flowStartDeltaMicroseconds can be = used. >>>>>>>>>=20 >>>>>>>>> time last flow dropped >>>>>>>>> The timestamp of the last IP packet = that was >>>>>>>>> ignored by the Metering Process. For = this >>>>>>>>> timestamp, any of the "flowEnd" = timestamp >>>>>>>>> Information Elements = flowEndMilliseconds, >>>>>>>>> flowEndMicroseconds, = flowEndNanoseconds, and >>>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Firstly, these definitions are inconsistent since the names = and the first definition say "flow" while the second definition says "IP = packet". Obviously "IP packet" !=3D "flow" :-o >>>>>>>>>=20 >>>>>>>>> Secondly, "The timestamp of the first Flow was dropped by the = Metering Process." is bad English: at least it's missing "that". >>>>>>>>>=20 >>>>>>>>> Thirdly, the section 4.2 doesn't take into account a metering = process id. Indeed, what if we have multiple caches on the exporter? >>>>>>>>>=20 >>>>>>>>> Here is a proposal for 4.2 and 4.3. The underlined parts are = new >>>>>>>>>=20 >>>>>>>>> 4.2. The Metering Process Reliability Statistics Option = Template >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The Metering Process Reliability Option Template specifies = the >>>>>>>>> structure of a Data Record for reporting lack of = reliability in the >>>>>>>>> Metering Process. It SHOULD contain the following = Information >>>>>>>>> Elements that are defined in [ >>>>>>>>> RFC5102 >>>>>>>>> ]: >>>>>>>>>=20 >>>>>>>>> observationDomainId >>>>>>>>> An identifier of an Observation = Domain that >>>>>>>>> is locally unique to the Exporting = Process. >>>>>>>>> This Information Element MUST be = defined as a >>>>>>>>> Scope Field. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> meteringProcessId (*) >>>>>>>>> The identifier of the Metering = Process for >>>>>>>>> which lack of reliability is = reported. There >>>>>>>>> This Information Element MUST be = defined as a >>>>>>>>> Scope Field. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> ignoredPacketTotalCount >>>>>>>>> The total number of IP packets that = the >>>>>>>>> Metering Process did not process. >>>>>>>>>=20 >>>>>>>>> ignoredOctetTotalCount >>>>>>>>> The total number of octets in = observed IP >>>>>>>>> packets that the Metering Process = did not >>>>>>>>> process. >>>>>>>>>=20 >>>>>>>>> time first >>>>>>>>> packet >>>>>>>>> ignored >>>>>>>>> The timestamp of the first IP = packet that was >>>>>>>>> ignored by the Metering Process. = For this >>>>>>>>> timestamp, any of the "flowStart" = timestamp >>>>>>>>> Information Elements = flowStartMilliseconds, >>>>>>>>> flowStartMicroseconds, = flowStartNanoseconds, >>>>>>>>> and flowStartDeltaMicroseconds can = be used. >>>>>>>>>=20 >>>>>>>>> time last >>>>>>>>> packet >>>>>>>>> ignored >>>>>>>>> The timestamp of the last IP packet = that was >>>>>>>>> ignored by the Metering Process. = For this >>>>>>>>> timestamp, any of the "flowEnd" = timestamp >>>>>>>>> Information Elements = flowEndMilliseconds, >>>>>>>>> flowEndMicroseconds, = flowEndNanoseconds, and >>>>>>>>> flowEndDeltaMicroseconds can be = used. >>>>>>>>>=20 >>>>>>>> I do not find these IEs in RFC5102. >>>>>>> Which ones? flowEndMilliseconds, flowEndMicroseconds, = flowEndNanoseconds, and flowEndDeltaMicroseconds >>>>>>> There are in http://www.iana.org/assignments/ipfix/ipfix.xml >>>>>>> However, re-reading >>>>>>> time first packet >>>>>>> ignored >>>>>>> The timestamp of the first IP packet = that was >>>>>>> ignored by the Metering Process. For = this >>>>>>> timestamp, any of the "flowStart" = timestamp >>>>>>> Information Elements = flowStartMilliseconds, >>>>>>> flowStartMicroseconds, = flowStartNanoseconds, >>>>>>> and flowStartDeltaMicroseconds can be = used. >>>>>>>=20 >>>>>>> time last >>>>>>> packet >>>>>>> ignored >>>>>>> The timestamp of the last IP packet = that was >>>>>>> ignored by the Metering Process. For = this >>>>>>> timestamp, any of the "flowEnd" = timestamp >>>>>>> Information Elements = flowEndMilliseconds, >>>>>>> flowEndMicroseconds, = flowEndNanoseconds, and >>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>=20 >>>>>>> And http://www.iana.org/assignments/ipfix/ipfix.xml for the = "flowEnd" timestamp IE, >>>>>>> I now believe that we should be using this series of IEs >>>>>>> 322 observationTimeSeconds >>>>>>> 323 observationTimeMilliseconds >>>>>>> 324 observationTimeMicroseconds >>>>>>> 325 observationTimeNanoseconds >>>>>>>=20 >>>>>>>>> 4.3. The Exporting Process Reliability Statistics Option = Template >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The Exporting Process Reliability Option Template specifies = the >>>>>>>>> structure of a Data Record for reporting lack of = reliability in the >>>>>>>>> Exporting process. It SHOULD contain the following = Information >>>>>>>>> Elements that are defined in [ >>>>>>>>> RFC5102 >>>>>>>>> ]: >>>>>>>>>=20 >>>>>>>>> Exporting Process ID >>>>>>>>> The identifier of the Exporting = Process for >>>>>>>>> which lack of reliability is reported. = There >>>>>>>>> are three Information Elements = specified in >>>>>>>>> [ >>>>>>>>> RFC5102 >>>>>>>>> ] that can be used for this purpose: >>>>>>>>> exporterIPv4Address, = exporterIPv6Address, or >>>>>>>>> exportingProcessId. This Information = Element >>>>>>>>> MUST be defined as a Scope Field. >>>>>>>>>=20 >>>>>>>>> notSentFlowTotalCount >>>>>>>>> The total number of Flows that were = generated by >>>>>>>>> the Metering Process and dropped by = the Metering >>>>>>>>> Process or by the Exporting Process = instead of >>>>>>>>> being sent to the Collecting Process. >>>>>>>>>=20 >>>>>>>>> notSentPacketTotalCount >>>>>>>>> The total number of packets in Flow = Records that >>>>>>>>> were generated by the Metering Process = and >>>>>>>>> dropped by the Metering Process or by = the >>>>>>>>> Exporting Process instead of being = sent to the >>>>>>>>> Collecting Process. >>>>>>>>>=20 >>>>>>>>> notSentOctetTotalCount >>>>>>>>> The total number of octets in packets = in Flow >>>>>>>>> Records that were generated by the = Metering >>>>>>>>> Process and dropped by the Metering = Process or >>>>>>>>> by the Exporting Process instead of = being sent >>>>>>>>> to the Collecting Process. >>>>>>>>>=20 >>>>>>>>> time first flow dropped >>>>>>>>>=20 >>>>>>>>> The time at which the first Flow Record = was dropped by >>>>>>>>> the >>>>>>>>> Exporting Process. >>>>>>>>> For this timestamp, any >>>>>>>>> of the "flowStart" timestamp = Information >>>>>>>>> Elements flowStartMilliseconds, >>>>>>>>> flowStartMicroseconds, = flowStartNanoseconds, and >>>>>>>>> flowStartDeltaMicroseconds can be = used. >>>>>>>>>=20 >>>>>>>>> time last flow dropped >>>>>>>>>=20 >>>>>>>>> The time at which the last Flow Record was >>>>>>>>> dropped by the Exporting Process >>>>>>>>> . For this >>>>>>>>> timestamp, any of the "flowEnd" = timestamp >>>>>>>>> Information Elements = flowEndMilliseconds, >>>>>>>>> flowEndMicroseconds, = flowEndNanoseconds, and >>>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>>>=20 >>>>>>>> Again, I do not find these IEs in RFC5102. >>>>>>> Same remark, I believe we should be using for the two previous = IEs >>>>>>> 322 observationTimeSeconds >>>>>>> 323 observationTimeMilliseconds >>>>>>> 324 observationTimeMicroseconds >>>>>>> 325 observationTimeNanoseconds >>>>>>> Regards, Benoit. >>>>>>>>> The Exporting Process SHOULD export the Data Record = specified by the >>>>>>>>> Exporting Process Reliability Statistics Option Template on = a regular >>>>>>>>> basis or based on some export policy. This periodicity or = export >>>>>>>>> policy SHOULD be configurable. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> (*) regarding the meteringProcessId, we were hesitating = between the meteringProcessId and the cache id >>>>>>>>> 1. there is a meteringProcessId in IPFIX IANA while there is = no cache id >>>>>>>> meteringProcessId should do the job. >>>>>>>>=20 >>>>>>>>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what = should be the value in meteringProcessId? >>>>>>>>> [IPFIX-CONF] doesn't mention the meteringProcessId, but a = cache name. >>>>>>>>> =46rom figure 1 and 2, it seems that there is a one to one = matching between the cache and the metering process. >>>>>>>>> If this is the case, a solution could be to add a = meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below >>>>>>>> See reply to Pauls mail. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Gerhard >>>>>>>>=20 >>>>>>>>> 4.3. Cache Class >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> +-----------------------------------+ >>>>>>>>> | Cache | >>>>>>>>> +-----------------------------------+ 1 = +------------------+ >>>>>>>>> | name |<>--------| = immediateCache/ | >>>>>>>>> | dataRecords {readOnly} | | = timeoutCache/ | >>>>>>>>> | cacheDiscontinuityTime {readOnly} | | = naturalCache/ | >>>>>>>>> | | | = permanentCache | >>>>>>>>> | | = +------------------+ >>>>>>>>> | | >>>>>>>>> | | 0..* = +------------------+ >>>>>>>>> | |--------->| = ExportingProcess | >>>>>>>>> +-----------------------------------+ = +------------------+ >>>>>>>>>=20 >>>>>>>>> Figure 12: Cache class >>>>>>>>>=20 >>>>>>>>> What do you think? Do you see another way? >>>>>>>>>=20 >>>>>>>>> Regards, Paul& Benoit. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> IPFIX mailing list >>>>>>>>>=20 >>>>>>>>> IPFIX@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> IPFIX mailing list >>>>>>>=20 >>>>>>> IPFIX@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> IPFIX mailing list >>>>>>=20 >>>>>> 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 Tue Sep 27 15:39:27 2011 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 EFE0D21F8F8C for ; Tue, 27 Sep 2011 15:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_75=0.6] 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 d7+MfBZVQaDl for ; Tue, 27 Sep 2011 15:39:26 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCC121F8EEA for ; Tue, 27 Sep 2011 15:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=26612; q=dns/txt; s=iport; t=1317163333; x=1318372933; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uNqvZKaEfzoobK1Bcx68xrwb1Lo0mvR5skofBN4sRFA=; b=Dut1wsKUgK3RqCgexdoG3T2fI5+naA3Y1ETVdl2yK2yDxBxtHeynKR0F sJkjMei/ezyJFjRANFPoABbT9evhdGkKSMR/8HbsHftthXPa27YGXf5lo /LEUjUdqzez7HVC3zAhNycgU53EMznXwW4QSfNKxywEe+t8omvK0Vk+y/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJVQgk6rRDoH/2dsb2JhbABBqAJ4gUwHAQEBAQIBAQEBDwEHDRE2CgEFCwsYCQwKDwkDAgECARUwBg0BBQIBAQUSB4dWBpscAZ4lg3SDFwSTUoUijBM X-IronPort-AV: E=Sophos;i="4.68,452,1312156800"; d="scan'208";a="4643537" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 27 Sep 2011 22:42:12 +0000 Received: from [10.61.89.32] (ams3-vpn-dhcp6433.cisco.com [10.61.89.32]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8RMg9kO017229; Tue, 27 Sep 2011 22:42:10 GMT Message-ID: <4E82513F.9020604@cisco.com> Date: Tue, 27 Sep 2011 23:42:07 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Brian Trammell References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> <4E7AA240.4020506@plixer.com> <4E7AE9D1.9090002@cisco.com> <4E7CF4F8.8060405@plixer.com> <4E82081B.8040806@plixer.com> <4E823130.6000505@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 27 Sep 2011 22:39:28 -0000 Brian, > Hi, Paul, all, > > I suppose I should state for the sake of completeness that this is the first I've ever actually _thought_ about the MPRSO. I find the whole use case for it rather dubious -- it presumes an MP with somehow trustworthy knowledge about packet loss, which is never the case, and relying on such information at the collector side for anything other than entertainment purposes is fraught with peril -- so I saw the MAY on section 4 in 5101, was thankful it wasn't a MUST I had to fight against and/or simply ignore, and never looked back. > > That said, it does make sense to fix, since it's there. > > On Sep 27, 2011, at 10:25 PM, Paul Aitken wrote: > >> How do you know that the received template is a MPRSO? > Does it matter? Seriously, what is the difference between "an MPRSO" and "a template containing information about lost packets for a given time interval, along with maybe some other information"? Do we actually want to require an MP to keep time interval information for loss? Wouldn't those resources be better deployed not losing packets in the first place? So let's say I want to report missing packets, but don't have information about when I lost them. Do I have to throw a timestamp in there anyway in order for it to be "an MPRSO"? > > I think these are arguments against having the timestamps at all (or to include them, with a further instruction that they are optional). When a MP knows that it failed to meter some packets, it must have a way of reporting this which the CP can understand correctly. So it matters in that the CP has to understand the implicit "lost traffic" semantic and potentially take action, perhaps involving reports or alarm bells. >> - must the fields be exactly in the specified order and no other combination in order to be a valid MPRSO? > This isn't a valid template recognition strategy in IPFIX. At least, it hasn't been to date, and it's a bad idea to make it so. IE-Doctors contains language meant to instruct IPFIX application authors to refrain from specifying such magic templates. Great; I'm pleased to hear it. Magic templates lead to inflexible collectors, which in turn lead to bug reports against the EP?! >> - how do you know which of the observationTime* elements (or missingObservationWindowEdge elements) is the first and which is the last? >> - only from their position in the template (so, field order and position are crucial) >> - by comparing them (so field order and position aren't important) > Time intervals can be treated as a special case, here, since time can generally be assumed to go in only one direction. "The time interval from A to B" is completely equivalent to "the time interval from B to A", so one could argue order doesn't matter. (We don't argue that anywhere in IPFIX, to be true. But what do I do when I get a flow with an endTime before the startTime?) When the timestamp wraps. The time between 11pm and 1am is 2 hours, while the time between 1am and 11pm is 22 hours. >> Suppose a mediator adds, removes, or re-orders the fields. >> - does this invalidate the MPRSO? >> - how does a mediator know not to do this? >> - how does the collector cope if a mediator does? > These questions seem to apply only to the case where MPRSO is magical. I'm trying to define it such that it isn't. I'm trying to get to the core of what constitues a valid, recognisable MPRSO. Put another way, what's the closest thing to an MPRSO that isn't an MPRSO? If I use ignoredPacketTotalCount and ignoredOctetTotalCount in another template, does it become an MPRSO? If we ignore what is and what isn't an MPRSO for the moment, how exactly should a MP tell a CP about the traffic it knows it didn't meter? >> The change to "missingObservationWindowEdge" is simply a rename of observationTime. I don't see that it adds anything. > observationTime already has a meaning. "This Information Element specifies the absolute time in seconds of an observation." In other words, "I saw the thing I'm talking about in this record at the specified time". It has never to date been specified in such a way that it means "I saw the thing I'm talking about in this record at the specified time, unless the record contains two observationTimes, in which case I saw the thing in the time interval between those two things". Then you're saying that it's invalid to have two different observationTime values in a flow record, because you can't observe an event at two different times. Thinking about it some more, I suppose this reports multiple instances of the observation with an AND semantic: I saw this at T1 AND at T2 (since other semantics don't make sense). Think if these were interfaces: the meaning would be "observed at int1 and int2", rather than "observed from int1 to int2". So I've convinced myself to agree that 2 x observationTime don't make sense. > missingObservationWindowEdge means "there is missing information within an interval described between this IE and the other identical IE in the record". If we keep the MPRSO defined as it is (and fix it only by dropping in , missingObservationWindowStartSeconds and missingObservationWindowEndSeconds, since it's more IPFIXish, but there was concern voiced in this thread about IE space explosion, so I figured we could exploit the nature of time and cut down on the IEs required by half. > > The advantage of a new IE is that it isn't overloaded, but more importantly that it does not lead to an ambiguous interpretation of the entire template at the collector. Unfortunately WindowEdge is ambiguous in the wrap case, whereas start and end aren't. >> A long basicList isn't the right solution because >> - various list lengths mean there are multiple possible templates making the detection of the MPRSO a little more difficult >> ie, it's no longer a fixed template, nor a combination of a few possibilities, but a great many different possible templates. >> - there are two different semantics for the start and end of the window, so it's actually an ordered list of pairs ie a subTemplateList. >> Lists can have zero elements. However, if you want to report that nothing was lost, the ignored*Count = 0 report should indicate the start and end of the 100% period. A list length of zero doesn't tell when stuff was or was not lost - so it's of limited usefulness, unless perhaps as a total figure? Again, see questions above about what is / is not a valid MPRSO. > I withdraw my basicList comment; it was essentially just "thinking aloud", and I didn't actually intend to include a mention of it in the 5101bis MPRSO. 1. It doesn't really add anything to the original intent of the MPRSO, and 2. adding it in 5101bis would cause 5101bis to have a normative dependency on 6313, which is a terrible idea. +1. I already discussed with Benoit about using an ordered list or STL of observationTime, and discounted it for this reason. P. >> On 27/09/11 18:30, Andrew Feren wrote: >>> Hi Brian, >>> >>> Well stated. >>> >>> Additional comments inline >>> >>> On 09/27/2011 12:15 PM, Brian Trammell wrote: >>>> Greetings, all, >>>> >>>> This is a little bit of an abuse of the ordering of IEs, in my opinion, and of the general rule that only IEs, and the scope in which they are defined, carry semantics. Even for templates which are defined within Standards Track RFCs, the records defined by the template should be decipherable without reference to the RFC. Put another way, we should not define magical templates, and this template as proposed looks pretty magical. >>> Yes, a black magic sort of magical. We have been discussing this proposed change in the office and coming to the same conclusion. >>>> Without reading the text of this thread, and following basically everything we've ever said about multiple IEs in a record, I would interpret a record matching this template as follows: >>>> >>>> For the metering process A and observation domain B: >>>> N packets were ignored; these contained a total of M octets. >>>> The first observation at this metering process was at time T0. >>>> The second observation at this metering process was at time T1. >>> This was exactly how I interpreted this template until I read the updated draft and saw the bit about "the Collecting Process MUST determine which is the oldest and the most recent timestamp in order the determine the right semantic ...." >>> >>>> This is quite far from the stated intention. I would strongly suggest that we not so lightly give up on "templates should be unambiguously understandable" requirement, even if the exception itself lives in the core protocol document. >>>> >>>> I would suggest, if you want to do a multiple IE solution here, you define something like missingObservationWindowEdge, and have two of them: >>>> >>>> observationDomainId {scope} >>>> meteringProcessId {scope} >>>> ignoredPacketTotalCount >>>> ignoredOctetTotalCount >>>> missingObservationWindowEdge >>>> missingObservationWindowEdge >>>> >>>> This has the advantage that you can have a long basicList of window edges in order to define multiple missing observation windows; each edge pair is a loss window. >>> I like this suggestion, and I have a few additional thoughts. >>> >>> Perhaps the basic list of edge times should either be limited to only one pair or the ignored*TotalCount IEs needs to be in a basiclist with N entries too. >>> >>> How about observationWindowEdge instead (no "missing") to be more generally useful. >>> >>> I think a list of time edges also works neatly when sending this template at regular intervals (which SHOULD be done). When the ignored*TotalCount IEs are zero, an empty list makes sense for edge times. >>> >>> >>>> Seconds suffice for these, I think. You might want to do one in milliseconds. But if you have the resources to calculate your packet loss window to nanosecond precision without having the resources to not lose packets, I humbly submit you've picked the wrong engineering tradeoffs. :) >>> Unless window edge isn't defined specifically for "missing" values. Then the higher precision timestamps might have some use. >>> >>> -Andrew >>>> Best regards, >>>> >>>> Brian >>>> >>>> On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote: >>>> >>>>> Yes, this makes sense. >>>>> >>>>> I gave this some thought and I don't have a better suggestion. I also agree that even though the flow[Start|End]* collection of IEs conveniently has one IE for both first and last, observationTime* is the more correct choice here. >>>>> >>>>> -Andrew >>>>> >>>>> On 09/22/2011 03:54 AM, Benoit Claise wrote: >>>>>> Hi Andrew, >>>>>>> Hi Benoit, >>>>>>> >>>>>>> I had the same thought about using >>>>>>> >>>>>>> 322 observationTimeSeconds >>>>>>> 323 observationTimeMilliseconds >>>>>>> 324 observationTimeMicroseconds >>>>>>> 325 observationTimeNanoseconds >>>>>>> >>>>>>> The problem is that you need two timestamps in the same record (first and last). How does that work with the above? >>>>>> Excellent question. We debated this question with Paul Aitken recently. >>>>>> Let me rephrase the question slightly differently: how does the collector determine that this is a "The Metering Process Reliability Statistics Options Template", and understands the semantic of the two counters? >>>>>> Well. Two solutions: >>>>>> 1. we duplicate all the IEs to have the exact correct semantic. >>>>>> ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] ... and potentially some more such as pre|post >>>>>> This brings multiple new dimensions to IE and will lead to an explosion of IEs if we want to cover all the case >>>>>> 2. the collector tests the possible combination of IE in the Options Template Record. >>>>>> For example, if the collector sees such an Options Template Record, it knows that this a "The Metering Process Reliability Statistics Options Template" >>>>>> observationDomainId (scope) >>>>>> meteringProcessId (scope) >>>>>> >>>>>> ignoredPacketTotalCount >>>>>> ignoredOctetTotalCount >>>>>> observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds >>>>>> observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds >>>>>> >>>>>> >>>>>> While the solution 2 is not perfect, this was the chosen track. >>>>>> >>>>>> Does it make sense? >>>>>> >>>>>> Regards, Benoit >>>>>>> -Andrew >>>>>>> >>>>>>> On 09/21/2011 07:11 PM, Benoit Claise wrote: >>>>>>>> Hi Gerhard, >>>>>>>> >>>>>>>> Thanks for your reply. >>>>>>>> See in line. >>>>>>>>> Hi Benoit, >>>>>>>>> >>>>>>>>> See comments inline. >>>>>>>>> >>>>>>>>> On 20.09.2011 16:19, Benoit Claise wrote: >>>>>>>>>> Dear all, >>>>>>>>>> >>>>>>>>>> [this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt, TO DO -> "time first flow dropped" and "time last flow dropped" inconsistency. See the discussion on the list.] >>>>>>>>>> >>>>>>>>>> Paul Aitken discovered this issue., >>>>>>>>>> >>>>>>>>>> From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template >>>>>>>>>> >>>>>>>>>> time first flow dropped >>>>>>>>>> The timestamp of the first Flow was dropped by >>>>>>>>>> the Metering Process. For this timestamp, any >>>>>>>>>> of the "flowStart" timestamp Information >>>>>>>>>> Elements flowStartMilliseconds, >>>>>>>>>> flowStartMicroseconds, flowStartNanoseconds, and >>>>>>>>>> flowStartDeltaMicroseconds can be used. >>>>>>>>>> >>>>>>>>>> time last flow dropped >>>>>>>>>> The timestamp of the last IP packet that was >>>>>>>>>> ignored by the Metering Process. For this >>>>>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>>>>> Information Elements flowEndMilliseconds, >>>>>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o >>>>>>>>>> >>>>>>>>>> Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that". >>>>>>>>>> >>>>>>>>>> Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter? >>>>>>>>>> >>>>>>>>>> Here is a proposal for 4.2 and 4.3. The underlined parts are new >>>>>>>>>> >>>>>>>>>> 4.2. The Metering Process Reliability Statistics Option Template >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The Metering Process Reliability Option Template specifies the >>>>>>>>>> structure of a Data Record for reporting lack of reliability in the >>>>>>>>>> Metering Process. It SHOULD contain the following Information >>>>>>>>>> Elements that are defined in [ >>>>>>>>>> RFC5102 >>>>>>>>>> ]: >>>>>>>>>> >>>>>>>>>> observationDomainId >>>>>>>>>> An identifier of an Observation Domain that >>>>>>>>>> is locally unique to the Exporting Process. >>>>>>>>>> This Information Element MUST be defined as a >>>>>>>>>> Scope Field. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> meteringProcessId (*) >>>>>>>>>> The identifier of the Metering Process for >>>>>>>>>> which lack of reliability is reported. There >>>>>>>>>> This Information Element MUST be defined as a >>>>>>>>>> Scope Field. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ignoredPacketTotalCount >>>>>>>>>> The total number of IP packets that the >>>>>>>>>> Metering Process did not process. >>>>>>>>>> >>>>>>>>>> ignoredOctetTotalCount >>>>>>>>>> The total number of octets in observed IP >>>>>>>>>> packets that the Metering Process did not >>>>>>>>>> process. >>>>>>>>>> >>>>>>>>>> time first >>>>>>>>>> packet >>>>>>>>>> ignored >>>>>>>>>> The timestamp of the first IP packet that was >>>>>>>>>> ignored by the Metering Process. For this >>>>>>>>>> timestamp, any of the "flowStart" timestamp >>>>>>>>>> Information Elements flowStartMilliseconds, >>>>>>>>>> flowStartMicroseconds, flowStartNanoseconds, >>>>>>>>>> and flowStartDeltaMicroseconds can be used. >>>>>>>>>> >>>>>>>>>> time last >>>>>>>>>> packet >>>>>>>>>> ignored >>>>>>>>>> The timestamp of the last IP packet that was >>>>>>>>>> ignored by the Metering Process. For this >>>>>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>>>>> Information Elements flowEndMilliseconds, >>>>>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>>>> >>>>>>>>> I do not find these IEs in RFC5102. >>>>>>>> Which ones? flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds >>>>>>>> There are in http://www.iana.org/assignments/ipfix/ipfix.xml >>>>>>>> However, re-reading >>>>>>>> time first packet >>>>>>>> ignored >>>>>>>> The timestamp of the first IP packet that was >>>>>>>> ignored by the Metering Process. For this >>>>>>>> timestamp, any of the "flowStart" timestamp >>>>>>>> Information Elements flowStartMilliseconds, >>>>>>>> flowStartMicroseconds, flowStartNanoseconds, >>>>>>>> and flowStartDeltaMicroseconds can be used. >>>>>>>> >>>>>>>> time last >>>>>>>> packet >>>>>>>> ignored >>>>>>>> The timestamp of the last IP packet that was >>>>>>>> ignored by the Metering Process. For this >>>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>>> Information Elements flowEndMilliseconds, >>>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>> >>>>>>>> And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd" timestamp IE, >>>>>>>> I now believe that we should be using this series of IEs >>>>>>>> 322 observationTimeSeconds >>>>>>>> 323 observationTimeMilliseconds >>>>>>>> 324 observationTimeMicroseconds >>>>>>>> 325 observationTimeNanoseconds >>>>>>>> >>>>>>>>>> 4.3. The Exporting Process Reliability Statistics Option Template >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The Exporting Process Reliability Option Template specifies the >>>>>>>>>> structure of a Data Record for reporting lack of reliability in the >>>>>>>>>> Exporting process. It SHOULD contain the following Information >>>>>>>>>> Elements that are defined in [ >>>>>>>>>> RFC5102 >>>>>>>>>> ]: >>>>>>>>>> >>>>>>>>>> Exporting Process ID >>>>>>>>>> The identifier of the Exporting Process for >>>>>>>>>> which lack of reliability is reported. There >>>>>>>>>> are three Information Elements specified in >>>>>>>>>> [ >>>>>>>>>> RFC5102 >>>>>>>>>> ] that can be used for this purpose: >>>>>>>>>> exporterIPv4Address, exporterIPv6Address, or >>>>>>>>>> exportingProcessId. This Information Element >>>>>>>>>> MUST be defined as a Scope Field. >>>>>>>>>> >>>>>>>>>> notSentFlowTotalCount >>>>>>>>>> The total number of Flows that were generated by >>>>>>>>>> the Metering Process and dropped by the Metering >>>>>>>>>> Process or by the Exporting Process instead of >>>>>>>>>> being sent to the Collecting Process. >>>>>>>>>> >>>>>>>>>> notSentPacketTotalCount >>>>>>>>>> The total number of packets in Flow Records that >>>>>>>>>> were generated by the Metering Process and >>>>>>>>>> dropped by the Metering Process or by the >>>>>>>>>> Exporting Process instead of being sent to the >>>>>>>>>> Collecting Process. >>>>>>>>>> >>>>>>>>>> notSentOctetTotalCount >>>>>>>>>> The total number of octets in packets in Flow >>>>>>>>>> Records that were generated by the Metering >>>>>>>>>> Process and dropped by the Metering Process or >>>>>>>>>> by the Exporting Process instead of being sent >>>>>>>>>> to the Collecting Process. >>>>>>>>>> >>>>>>>>>> time first flow dropped >>>>>>>>>> >>>>>>>>>> The time at which the first Flow Record was dropped by >>>>>>>>>> the >>>>>>>>>> Exporting Process. >>>>>>>>>> For this timestamp, any >>>>>>>>>> of the "flowStart" timestamp Information >>>>>>>>>> Elements flowStartMilliseconds, >>>>>>>>>> flowStartMicroseconds, flowStartNanoseconds, and >>>>>>>>>> flowStartDeltaMicroseconds can be used. >>>>>>>>>> >>>>>>>>>> time last flow dropped >>>>>>>>>> >>>>>>>>>> The time at which the last Flow Record was >>>>>>>>>> dropped by the Exporting Process >>>>>>>>>> . For this >>>>>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>>>>> Information Elements flowEndMilliseconds, >>>>>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>>>> >>>>>>>>> Again, I do not find these IEs in RFC5102. >>>>>>>> Same remark, I believe we should be using for the two previous IEs >>>>>>>> 322 observationTimeSeconds >>>>>>>> 323 observationTimeMilliseconds >>>>>>>> 324 observationTimeMicroseconds >>>>>>>> 325 observationTimeNanoseconds >>>>>>>> Regards, Benoit. >>>>>>>>>> The Exporting Process SHOULD export the Data Record specified by the >>>>>>>>>> Exporting Process Reliability Statistics Option Template on a regular >>>>>>>>>> basis or based on some export policy. This periodicity or export >>>>>>>>>> policy SHOULD be configurable. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id >>>>>>>>>> 1. there is a meteringProcessId in IPFIX IANA while there is no cache id >>>>>>>>> meteringProcessId should do the job. >>>>>>>>> >>>>>>>>>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId? >>>>>>>>>> [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name. >>>>>>>>>> From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process. >>>>>>>>>> If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below >>>>>>>>> See reply to Pauls mail. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Gerhard >>>>>>>>> >>>>>>>>>> 4.3. Cache Class >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> +-----------------------------------+ >>>>>>>>>> | Cache | >>>>>>>>>> +-----------------------------------+ 1 +------------------+ >>>>>>>>>> | name |<>--------| immediateCache/ | >>>>>>>>>> | dataRecords {readOnly} | | timeoutCache/ | >>>>>>>>>> | cacheDiscontinuityTime {readOnly} | | naturalCache/ | >>>>>>>>>> | | | permanentCache | >>>>>>>>>> | | +------------------+ >>>>>>>>>> | | >>>>>>>>>> | | 0..* +------------------+ >>>>>>>>>> | |--------->| ExportingProcess | >>>>>>>>>> +-----------------------------------+ +------------------+ >>>>>>>>>> >>>>>>>>>> Figure 12: Cache class >>>>>>>>>> >>>>>>>>>> What do you think? Do you see another way? >>>>>>>>>> >>>>>>>>>> Regards, Paul& Benoit. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>> _______________________________________________ >>>>> 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 Tue Sep 27 23:00:20 2011 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 D7C6F21F8C4A for ; Tue, 27 Sep 2011 23:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_75=0.6, 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 FEHplTRIPZD9 for ; Tue, 27 Sep 2011 23:00:18 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5B16221F8BEF for ; Tue, 27 Sep 2011 23:00:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id F3053D930B; Wed, 28 Sep 2011 08:03: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 Aj2s0pmiPcRE; Wed, 28 Sep 2011 08:03:01 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (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 1931AD9300; Wed, 28 Sep 2011 08:03:01 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4E82513F.9020604@cisco.com> Date: Wed, 28 Sep 2011 08:03:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> <4E7AA240.4020506@plixer.com> <4E7AE9D1.9090002@cisco.com> <4E7CF4F8.8060405@plixer.com> <4E82081B.8040806@plixer.com> <4E823130.6000505@cisco.com> <4E82513F.9020604@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1084) Cc: ipfix@ietf.org Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 28 Sep 2011 06:00:21 -0000 On Sep 28, 2011, at 12:42 AM, Paul Aitken wrote: > Brian, >=20 >> Hi, Paul, all, >>=20 >> I suppose I should state for the sake of completeness that this is = the first I've ever actually _thought_ about the MPRSO. I find the whole = use case for it rather dubious -- it presumes an MP with somehow = trustworthy knowledge about packet loss, which is never the case, and = relying on such information at the collector side for anything other = than entertainment purposes is fraught with peril -- so I saw the MAY on = section 4 in 5101, was thankful it wasn't a MUST I had to fight against = and/or simply ignore, and never looked back. >>=20 >> That said, it does make sense to fix, since it's there. >>=20 >> On Sep 27, 2011, at 10:25 PM, Paul Aitken wrote: >>=20 >>> How do you know that the received template is a MPRSO? >> Does it matter? Seriously, what is the difference between "an MPRSO" = and "a template containing information about lost packets for a given = time interval, along with maybe some other information"? Do we actually = want to require an MP to keep time interval information for loss? = Wouldn't those resources be better deployed not losing packets in the = first place? So let's say I want to report missing packets, but don't = have information about when I lost them. Do I have to throw a timestamp = in there anyway in order for it to be "an MPRSO"? >>=20 >> I think these are arguments against having the timestamps at all (or = to include them, with a further instruction that they are optional). >=20 > When a MP knows that it failed to meter some packets, it must have a = way of reporting this which the CP can understand correctly. So it = matters in that the CP has to understand the implicit "lost traffic" = semantic and potentially take action, perhaps involving reports or alarm = bells. That's an argument for the following template: observationDomainId {scope} meteringProcessId {scope} ignoredPacketTotalCount Which, in my opinion, is a pretty good starting point. You can add ignoredOctetTotalCount if you actually know it. Calculating = it at libpcap-based MPs like YAF, for example, would involve a little = work and generate a bad number: you only get a guess from the kernel how = many packets it dropped and no information about how big they are. You = can infer octet loss by looking at TCP sequence numbers but now we're = back to clear overengineering I think. Maybe on ASIC or FPGA based = measurement systems you get good total counters and can measure loss = subtractively... But I personally wouldn't waste the real estate on it = unless it was a hard requirement. Again, if you know the timestamps, you can add them. But for the general = case as I see it, your fidelity per IE for the template in 5101 is as = follows: perfect: observationDomainId {scope} (i hope you know this) meteringProcessId {scope} reasonably good guess: ignoredPacketTotalCount poor to fair guess: ignoredOctetTotalCount (dep. on HW support) poor to good guess: a start timestamp of indeterminate IE (dep. on HW support) an end timestamp of indeterminate IE >>> - must the fields be exactly in the specified order and no other = combination in order to be a valid MPRSO? >> This isn't a valid template recognition strategy in IPFIX. At least, = it hasn't been to date, and it's a bad idea to make it so. IE-Doctors = contains language meant to instruct IPFIX application authors to refrain = from specifying such magic templates. >=20 > Great; I'm pleased to hear it. Magic templates lead to inflexible = collectors, which in turn lead to bug reports against the EP?! >=20 >=20 >>> - how do you know which of the observationTime* elements (or = missingObservationWindowEdge elements) is the first and which is the = last? >>> - only from their position in the template (so, field order = and position are crucial) >>> - by comparing them (so field order and position aren't = important) >> Time intervals can be treated as a special case, here, since time can = generally be assumed to go in only one direction. "The time interval = from A to B" is completely equivalent to "the time interval from B to = A", so one could argue order doesn't matter. (We don't argue that = anywhere in IPFIX, to be true. But what do I do when I get a flow with = an endTime before the startTime?) >=20 > When the timestamp wraps. The time between 11pm and 1am is 2 hours, = while the time between 1am and 11pm is 22 hours. We don't have any timestamps that only carry time information. They've = all got implied dates (either based on the 1970 epoch for the UNIX-like = timestamps, or on either the NTP or the UNIX epoch for the 1305 = timestamps (we'll need to fix this in 5101bis), and there is no = specified wrapping behavior as yet. You only hit this problem in 2038, = then, and when you do, you've got bigger problems. >>> Suppose a mediator adds, removes, or re-orders the fields. >>> - does this invalidate the MPRSO? >>> - how does a mediator know not to do this? >>> - how does the collector cope if a mediator does? >> These questions seem to apply only to the case where MPRSO is = magical. I'm trying to define it such that it isn't. >=20 > I'm trying to get to the core of what constitues a valid, recognisable = MPRSO. Put another way, what's the closest thing to an MPRSO that isn't = an MPRSO? I'm saying that it doesn't matter. Sure, 5101bis should give = recommendations for the template an exporting process uses for this = information, but any time a CP sees a template that's scoped to = something that ID's an MP that contains loss counter IEs, it's an MPRSO.=20= > If I use ignoredPacketTotalCount and ignoredOctetTotalCount in another = template, does it become an MPRSO? Depends. Are you binding them to a scope that identifies a metering = process? You could also export them in a flow or "flexible flow"/flow = aggregate, at which point you're giving very detailed error information. = And the collector can infer whatever it wants about total reliability = based on _that_... > If we ignore what is and what isn't an MPRSO for the moment, how = exactly should a MP tell a CP about the traffic it knows it didn't = meter? Using something much like the MPRSO as defined by 5101... I'm just = trying to lead us away from thinking of a "bright line" between MPRSO = and not-MPRSO, because=20 >>> The change to "missingObservationWindowEdge" is simply a rename of = observationTime. I don't see that it adds anything. >> observationTime already has a meaning. "This Information Element = specifies the absolute time in seconds of an observation." In other = words, "I saw the thing I'm talking about in this record at the = specified time". It has never to date been specified in such a way that = it means "I saw the thing I'm talking about in this record at the = specified time, unless the record contains two observationTimes, in = which case I saw the thing in the time interval between those two = things". >=20 > Then you're saying that it's invalid to have two different = observationTime values in a flow record, because you can't observe an = event at two different times. Well.... yes, this is a bit ambiguous. > Thinking about it some more, I suppose this reports multiple instances = of the observation with an AND semantic: I saw this at T1 AND at T2 = (since other semantics don't make sense). > Think if these were interfaces: the meaning would be "observed at int1 = and int2", rather than "observed from int1 to int2". > So I've convinced myself to agree that 2 x observationTime don't make = sense. (I'm trying to think of cases where it would be, but I don't think any = are illustrative for this discussion...) >> missingObservationWindowEdge means "there is missing information = within an interval described between this IE and the other identical IE = in the record". If we keep the MPRSO defined as it is (and fix it only = by dropping in , missingObservationWindowStartSeconds and = missingObservationWindowEndSeconds, since it's more IPFIXish, but there = was concern voiced in this thread about IE space explosion, so I figured = we could exploit the nature of time and cut down on the IEs required by = half. >>=20 >> The advantage of a new IE is that it isn't overloaded, but more = importantly that it does not lead to an ambiguous interpretation of the = entire template at the collector. >=20 > Unfortunately WindowEdge is ambiguous in the wrap case, whereas start = and end aren't. (see above on wrapping) >=20 >>> A long basicList isn't the right solution because >>> - various list lengths mean there are multiple possible templates = making the detection of the MPRSO a little more difficult >>> ie, it's no longer a fixed template, nor a combination of a = few possibilities, but a great many different possible templates. >>> - there are two different semantics for the start and end of the = window, so it's actually an ordered list of pairs ie a subTemplateList. >>> Lists can have zero elements. However, if you want to report that = nothing was lost, the ignored*Count =3D 0 report should indicate the = start and end of the 100% period. A list length of zero doesn't tell = when stuff was or was not lost - so it's of limited usefulness, unless = perhaps as a total figure? Again, see questions above about what is / is = not a valid MPRSO. >> I withdraw my basicList comment; it was essentially just "thinking = aloud", and I didn't actually intend to include a mention of it in the = 5101bis MPRSO. 1. It doesn't really add anything to the original intent = of the MPRSO, and 2. adding it in 5101bis would cause 5101bis to have a = normative dependency on 6313, which is a terrible idea. >=20 > +1. I already discussed with Benoit about using an ordered list or STL = of observationTime, and discounted it for this reason. Yay! At least we emphatically agree on _something_. ;) Cheers, Brian >>> On 27/09/11 18:30, Andrew Feren wrote: >>>> Hi Brian, >>>>=20 >>>> Well stated. >>>>=20 >>>> Additional comments inline >>>>=20 >>>> On 09/27/2011 12:15 PM, Brian Trammell wrote: >>>>> Greetings, all, >>>>>=20 >>>>> This is a little bit of an abuse of the ordering of IEs, in my = opinion, and of the general rule that only IEs, and the scope in which = they are defined, carry semantics. Even for templates which are defined = within Standards Track RFCs, the records defined by the template should = be decipherable without reference to the RFC. Put another way, we should = not define magical templates, and this template as proposed looks pretty = magical. >>>> Yes, a black magic sort of magical. We have been discussing this = proposed change in the office and coming to the same conclusion. >>>>> Without reading the text of this thread, and following basically = everything we've ever said about multiple IEs in a record, I would = interpret a record matching this template as follows: >>>>>=20 >>>>> For the metering process A and observation domain B: >>>>> N packets were ignored; these contained a total of M octets. >>>>> The first observation at this metering process was at time T0. >>>>> The second observation at this metering process was at time T1. >>>> This was exactly how I interpreted this template until I read the = updated draft and saw the bit about "the Collecting Process MUST = determine which is the oldest and the most recent timestamp in order the = determine the right semantic ...." >>>>=20 >>>>> This is quite far from the stated intention. I would strongly = suggest that we not so lightly give up on "templates should be = unambiguously understandable" requirement, even if the exception itself = lives in the core protocol document. >>>>>=20 >>>>> I would suggest, if you want to do a multiple IE solution here, = you define something like missingObservationWindowEdge, and have two of = them: >>>>>=20 >>>>> observationDomainId {scope} >>>>> meteringProcessId {scope} >>>>> ignoredPacketTotalCount >>>>> ignoredOctetTotalCount >>>>> missingObservationWindowEdge >>>>> missingObservationWindowEdge >>>>>=20 >>>>> This has the advantage that you can have a long basicList of = window edges in order to define multiple missing observation windows; = each edge pair is a loss window. >>>> I like this suggestion, and I have a few additional thoughts. >>>>=20 >>>> Perhaps the basic list of edge times should either be limited to = only one pair or the ignored*TotalCount IEs needs to be in a basiclist = with N entries too. >>>>=20 >>>> How about observationWindowEdge instead (no "missing") to be more = generally useful. >>>>=20 >>>> I think a list of time edges also works neatly when sending this = template at regular intervals (which SHOULD be done). When the = ignored*TotalCount IEs are zero, an empty list makes sense for edge = times. >>>>=20 >>>>=20 >>>>> Seconds suffice for these, I think. You might want to do one in = milliseconds. But if you have the resources to calculate your packet = loss window to nanosecond precision without having the resources to not = lose packets, I humbly submit you've picked the wrong engineering = tradeoffs. :) >>>> Unless window edge isn't defined specifically for "missing" values. = Then the higher precision timestamps might have some use. >>>>=20 >>>> -Andrew >>>>> Best regards, >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote: >>>>>=20 >>>>>> Yes, this makes sense. >>>>>>=20 >>>>>> I gave this some thought and I don't have a better suggestion. I = also agree that even though the flow[Start|End]* collection of IEs = conveniently has one IE for both first and last, observationTime* is the = more correct choice here. >>>>>>=20 >>>>>> -Andrew >>>>>>=20 >>>>>> On 09/22/2011 03:54 AM, Benoit Claise wrote: >>>>>>> Hi Andrew, >>>>>>>> Hi Benoit, >>>>>>>>=20 >>>>>>>> I had the same thought about using >>>>>>>>=20 >>>>>>>> 322 observationTimeSeconds >>>>>>>> 323 observationTimeMilliseconds >>>>>>>> 324 observationTimeMicroseconds >>>>>>>> 325 observationTimeNanoseconds >>>>>>>>=20 >>>>>>>> The problem is that you need two timestamps in the same record = (first and last). How does that work with the above? >>>>>>> Excellent question. We debated this question with Paul Aitken = recently. >>>>>>> Let me rephrase the question slightly differently: how does the = collector determine that this is a "The Metering Process Reliability = Statistics Options Template", and understands the semantic of the two = counters? >>>>>>> Well. Two solutions: >>>>>>> 1. we duplicate all the IEs to have the exact correct semantic. >>>>>>> = ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds= |Nanoseconds] ... and potentially some more such as pre|post >>>>>>> This brings multiple new dimensions to IE and will lead to = an explosion of IEs if we want to cover all the case >>>>>>> 2. the collector tests the possible combination of IE in the = Options Template Record. >>>>>>> For example, if the collector sees such an Options Template = Record, it knows that this a "The Metering Process Reliability = Statistics Options Template" >>>>>>> observationDomainId (scope) >>>>>>> meteringProcessId (scope) >>>>>>>=20 >>>>>>> ignoredPacketTotalCount >>>>>>> ignoredOctetTotalCount >>>>>>> observationTimeSeconds | observationTimeMilliseconds | = observationTimeMicroseconds | observationTimeNanoseconds >>>>>>> observationTimeSeconds | observationTimeMilliseconds | = observationTimeMicroseconds | observationTimeNanoseconds >>>>>>>=20 >>>>>>>=20 >>>>>>> While the solution 2 is not perfect, this was the chosen track. >>>>>>>=20 >>>>>>> Does it make sense? >>>>>>>=20 >>>>>>> Regards, Benoit >>>>>>>> -Andrew >>>>>>>>=20 >>>>>>>> On 09/21/2011 07:11 PM, Benoit Claise wrote: >>>>>>>>> Hi Gerhard, >>>>>>>>>=20 >>>>>>>>> Thanks for your reply. >>>>>>>>> See in line. >>>>>>>>>> Hi Benoit, >>>>>>>>>>=20 >>>>>>>>>> See comments inline. >>>>>>>>>>=20 >>>>>>>>>> On 20.09.2011 16:19, Benoit Claise wrote: >>>>>>>>>>> Dear all, >>>>>>>>>>>=20 >>>>>>>>>>> [this email addresses = draft-claise-ipfix-protocol-rfc5101bis-00.txt, TO DO -> "time first = flow dropped" and "time last flow dropped" inconsistency. See the = discussion on the list.] >>>>>>>>>>>=20 >>>>>>>>>>> Paul Aitken discovered this issue., >>>>>>>>>>>=20 >>>>>>>>>>> =46rom [RFC5101], section 4.3. The Exporting Process = Reliability Statistics Option Template >>>>>>>>>>>=20 >>>>>>>>>>> time first flow dropped >>>>>>>>>>> The timestamp of the first Flow was = dropped by >>>>>>>>>>> the Metering Process. For this = timestamp, any >>>>>>>>>>> of the "flowStart" timestamp = Information >>>>>>>>>>> Elements flowStartMilliseconds, >>>>>>>>>>> flowStartMicroseconds, = flowStartNanoseconds, and >>>>>>>>>>> flowStartDeltaMicroseconds can be = used. >>>>>>>>>>>=20 >>>>>>>>>>> time last flow dropped >>>>>>>>>>> The timestamp of the last IP packet = that was >>>>>>>>>>> ignored by the Metering Process. = For this >>>>>>>>>>> timestamp, any of the "flowEnd" = timestamp >>>>>>>>>>> Information Elements = flowEndMilliseconds, >>>>>>>>>>> flowEndMicroseconds, = flowEndNanoseconds, and >>>>>>>>>>> flowEndDeltaMicroseconds can be = used. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Firstly, these definitions are inconsistent since the names = and the first definition say "flow" while the second definition says "IP = packet". Obviously "IP packet" !=3D "flow" :-o >>>>>>>>>>>=20 >>>>>>>>>>> Secondly, "The timestamp of the first Flow was dropped by = the Metering Process." is bad English: at least it's missing "that". >>>>>>>>>>>=20 >>>>>>>>>>> Thirdly, the section 4.2 doesn't take into account a = metering process id. Indeed, what if we have multiple caches on the = exporter? >>>>>>>>>>>=20 >>>>>>>>>>> Here is a proposal for 4.2 and 4.3. The underlined parts are = new >>>>>>>>>>>=20 >>>>>>>>>>> 4.2. The Metering Process Reliability Statistics Option = Template >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The Metering Process Reliability Option Template = specifies the >>>>>>>>>>> structure of a Data Record for reporting lack of = reliability in the >>>>>>>>>>> Metering Process. It SHOULD contain the following = Information >>>>>>>>>>> Elements that are defined in [ >>>>>>>>>>> RFC5102 >>>>>>>>>>> ]: >>>>>>>>>>>=20 >>>>>>>>>>> observationDomainId >>>>>>>>>>> An identifier of an Observation = Domain that >>>>>>>>>>> is locally unique to the = Exporting Process. >>>>>>>>>>> This Information Element MUST be = defined as a >>>>>>>>>>> Scope Field. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> meteringProcessId (*) >>>>>>>>>>> The identifier of the Metering = Process for >>>>>>>>>>> which lack of reliability is = reported. There >>>>>>>>>>> This Information Element MUST be = defined as a >>>>>>>>>>> Scope Field. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ignoredPacketTotalCount >>>>>>>>>>> The total number of IP packets = that the >>>>>>>>>>> Metering Process did not process. >>>>>>>>>>>=20 >>>>>>>>>>> ignoredOctetTotalCount >>>>>>>>>>> The total number of octets in = observed IP >>>>>>>>>>> packets that the Metering Process = did not >>>>>>>>>>> process. >>>>>>>>>>>=20 >>>>>>>>>>> time first >>>>>>>>>>> packet >>>>>>>>>>> ignored >>>>>>>>>>> The timestamp of the first IP = packet that was >>>>>>>>>>> ignored by the Metering Process. = For this >>>>>>>>>>> timestamp, any of the "flowStart" = timestamp >>>>>>>>>>> Information Elements = flowStartMilliseconds, >>>>>>>>>>> flowStartMicroseconds, = flowStartNanoseconds, >>>>>>>>>>> and flowStartDeltaMicroseconds = can be used. >>>>>>>>>>>=20 >>>>>>>>>>> time last >>>>>>>>>>> packet >>>>>>>>>>> ignored >>>>>>>>>>> The timestamp of the last IP = packet that was >>>>>>>>>>> ignored by the Metering Process. = For this >>>>>>>>>>> timestamp, any of the "flowEnd" = timestamp >>>>>>>>>>> Information Elements = flowEndMilliseconds, >>>>>>>>>>> flowEndMicroseconds, = flowEndNanoseconds, and >>>>>>>>>>> flowEndDeltaMicroseconds can be = used. >>>>>>>>>>>=20 >>>>>>>>>> I do not find these IEs in RFC5102. >>>>>>>>> Which ones? flowEndMilliseconds, flowEndMicroseconds, = flowEndNanoseconds, and flowEndDeltaMicroseconds >>>>>>>>> There are in http://www.iana.org/assignments/ipfix/ipfix.xml >>>>>>>>> However, re-reading >>>>>>>>> time first packet >>>>>>>>> ignored >>>>>>>>> The timestamp of the first IP = packet that was >>>>>>>>> ignored by the Metering Process. = For this >>>>>>>>> timestamp, any of the "flowStart" = timestamp >>>>>>>>> Information Elements = flowStartMilliseconds, >>>>>>>>> flowStartMicroseconds, = flowStartNanoseconds, >>>>>>>>> and flowStartDeltaMicroseconds can = be used. >>>>>>>>>=20 >>>>>>>>> time last >>>>>>>>> packet >>>>>>>>> ignored >>>>>>>>> The timestamp of the last IP packet = that was >>>>>>>>> ignored by the Metering Process. = For this >>>>>>>>> timestamp, any of the "flowEnd" = timestamp >>>>>>>>> Information Elements = flowEndMilliseconds, >>>>>>>>> flowEndMicroseconds, = flowEndNanoseconds, and >>>>>>>>> flowEndDeltaMicroseconds can be = used. >>>>>>>>>=20 >>>>>>>>> And http://www.iana.org/assignments/ipfix/ipfix.xml for the = "flowEnd" timestamp IE, >>>>>>>>> I now believe that we should be using this series of IEs >>>>>>>>> 322 observationTimeSeconds >>>>>>>>> 323 observationTimeMilliseconds >>>>>>>>> 324 observationTimeMicroseconds >>>>>>>>> 325 observationTimeNanoseconds >>>>>>>>>=20 >>>>>>>>>>> 4.3. The Exporting Process Reliability Statistics Option = Template >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The Exporting Process Reliability Option Template = specifies the >>>>>>>>>>> structure of a Data Record for reporting lack of = reliability in the >>>>>>>>>>> Exporting process. It SHOULD contain the following = Information >>>>>>>>>>> Elements that are defined in [ >>>>>>>>>>> RFC5102 >>>>>>>>>>> ]: >>>>>>>>>>>=20 >>>>>>>>>>> Exporting Process ID >>>>>>>>>>> The identifier of the Exporting = Process for >>>>>>>>>>> which lack of reliability is = reported. There >>>>>>>>>>> are three Information Elements = specified in >>>>>>>>>>> [ >>>>>>>>>>> RFC5102 >>>>>>>>>>> ] that can be used for this purpose: >>>>>>>>>>> exporterIPv4Address, = exporterIPv6Address, or >>>>>>>>>>> exportingProcessId. This = Information Element >>>>>>>>>>> MUST be defined as a Scope Field. >>>>>>>>>>>=20 >>>>>>>>>>> notSentFlowTotalCount >>>>>>>>>>> The total number of Flows that were = generated by >>>>>>>>>>> the Metering Process and dropped by = the Metering >>>>>>>>>>> Process or by the Exporting Process = instead of >>>>>>>>>>> being sent to the Collecting = Process. >>>>>>>>>>>=20 >>>>>>>>>>> notSentPacketTotalCount >>>>>>>>>>> The total number of packets in Flow = Records that >>>>>>>>>>> were generated by the Metering = Process and >>>>>>>>>>> dropped by the Metering Process or = by the >>>>>>>>>>> Exporting Process instead of being = sent to the >>>>>>>>>>> Collecting Process. >>>>>>>>>>>=20 >>>>>>>>>>> notSentOctetTotalCount >>>>>>>>>>> The total number of octets in = packets in Flow >>>>>>>>>>> Records that were generated by the = Metering >>>>>>>>>>> Process and dropped by the Metering = Process or >>>>>>>>>>> by the Exporting Process instead of = being sent >>>>>>>>>>> to the Collecting Process. >>>>>>>>>>>=20 >>>>>>>>>>> time first flow dropped >>>>>>>>>>>=20 >>>>>>>>>>> The time at which the first Flow = Record was dropped by >>>>>>>>>>> the >>>>>>>>>>> Exporting Process. >>>>>>>>>>> For this timestamp, any >>>>>>>>>>> of the "flowStart" timestamp = Information >>>>>>>>>>> Elements flowStartMilliseconds, >>>>>>>>>>> flowStartMicroseconds, = flowStartNanoseconds, and >>>>>>>>>>> flowStartDeltaMicroseconds can be = used. >>>>>>>>>>>=20 >>>>>>>>>>> time last flow dropped >>>>>>>>>>>=20 >>>>>>>>>>> The time at which the last Flow Record was >>>>>>>>>>> dropped by the Exporting Process >>>>>>>>>>> . For this >>>>>>>>>>> timestamp, any of the "flowEnd" = timestamp >>>>>>>>>>> Information Elements = flowEndMilliseconds, >>>>>>>>>>> flowEndMicroseconds, = flowEndNanoseconds, and >>>>>>>>>>> flowEndDeltaMicroseconds can be = used. >>>>>>>>>>>=20 >>>>>>>>>> Again, I do not find these IEs in RFC5102. >>>>>>>>> Same remark, I believe we should be using for the two previous = IEs >>>>>>>>> 322 observationTimeSeconds >>>>>>>>> 323 observationTimeMilliseconds >>>>>>>>> 324 observationTimeMicroseconds >>>>>>>>> 325 observationTimeNanoseconds >>>>>>>>> Regards, Benoit. >>>>>>>>>>> The Exporting Process SHOULD export the Data Record = specified by the >>>>>>>>>>> Exporting Process Reliability Statistics Option Template = on a regular >>>>>>>>>>> basis or based on some export policy. This periodicity = or export >>>>>>>>>>> policy SHOULD be configurable. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> (*) regarding the meteringProcessId, we were hesitating = between the meteringProcessId and the cache id >>>>>>>>>>> 1. there is a meteringProcessId in IPFIX IANA while there is = no cache id >>>>>>>>>> meteringProcessId should do the job. >>>>>>>>>>=20 >>>>>>>>>>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], = what should be the value in meteringProcessId? >>>>>>>>>>> [IPFIX-CONF] doesn't mention the meteringProcessId, but = a cache name. >>>>>>>>>>> =46rom figure 1 and 2, it seems that there is a one to = one matching between the cache and the metering process. >>>>>>>>>>> If this is the case, a solution could be to add a = meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below >>>>>>>>>> See reply to Pauls mail. >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Gerhard >>>>>>>>>>=20 >>>>>>>>>>> 4.3. Cache Class >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> +-----------------------------------+ >>>>>>>>>>> | Cache | >>>>>>>>>>> +-----------------------------------+ 1 = +------------------+ >>>>>>>>>>> | name |<>--------| = immediateCache/ | >>>>>>>>>>> | dataRecords {readOnly} | | = timeoutCache/ | >>>>>>>>>>> | cacheDiscontinuityTime {readOnly} | | = naturalCache/ | >>>>>>>>>>> | | | = permanentCache | >>>>>>>>>>> | | = +------------------+ >>>>>>>>>>> | | >>>>>>>>>>> | | 0..* = +------------------+ >>>>>>>>>>> | |--------->| = ExportingProcess | >>>>>>>>>>> +-----------------------------------+ = +------------------+ >>>>>>>>>>>=20 >>>>>>>>>>> Figure 12: Cache class >>>>>>>>>>>=20 >>>>>>>>>>> What do you think? Do you see another way? >>>>>>>>>>>=20 >>>>>>>>>>> Regards, Paul& Benoit. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> IPFIX mailing list >>>>>>>>>>>=20 >>>>>>>>>>> IPFIX@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>>>> _______________________________________________ >>>>>>>>> IPFIX mailing list >>>>>>>>>=20 >>>>>>>>> IPFIX@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> IPFIX mailing list >>>>>>>>=20 >>>>>>>> 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 Wed Sep 28 06:38:08 2011 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 1175021F8C86 for ; Wed, 28 Sep 2011 06:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 pSUX+SXPtOvK for ; Wed, 28 Sep 2011 06:38:07 -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 1765921F8876 for ; Wed, 28 Sep 2011 06:38: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 p8SDesU9000853; Wed, 28 Sep 2011 15:40:54 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8SDesxt025373; Wed, 28 Sep 2011 15:40:54 +0200 (CEST) Message-ID: <4E8323E6.8080305@cisco.com> Date: Wed, 28 Sep 2011 15:40:54 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Gerhard Muenz References: <4E6D1E73.9@net.in.tum.de> In-Reply-To: <4E6D1E73.9@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] proposal for IPFIX charter update 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, 28 Sep 2011 13:38:08 -0000 IPFIX chairs, > > Hi Juergen, > > The IPFIX configuration data model is pending because of the IPFIX and > PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of highest > priority, and a solution be published before any other new draft. I agree. Btw, where is the new charter? ;-) There is always a tendency to delay work for which there is no deadlines... Regards, Benoit. > (I already see IPFIX config being outdated by RFC5101/5102bis before > it ever becomes RFC...) > > Regards, > Gerhard > > > On 29.08.2011 06:57, Juergen Quittek wrote: >> Dear all, >> >> At our session in Quebec we discussed candidates >> for new IPFIX work items. Based on this discussion, >> Nevil and I drafted an update of our charter that >> you can find below. >> >> Please have a look at it and send us your comments. >> >> Thanks, >> >> Juergen >> >> >> IP Flow Information Export (ipfix) >> >> >> Description of Working Group >> >> >> The IPFIX working group has specified the information model (to describe >> IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX >> exporters to collectors). Several implementers have already built >> applications using the IPFIX protocol. As a result of a series of IPFIX >> interoperability testing events the WG has produced guidelines for IPFIX >> implementation and testing as well as recommendations for handling >> special cases such as bidirectional flow reporting and reducing >> redundancy in flow records. >> >> The IPFIX WG has developed a mediation framework, that defines IPFIX >> mediators for processing flow records for various purposes including >> aggregation, anonymization, etc. For configuring IPFIX devices, a YANG >> module has been developed. >> >> 1. Having a solid standardized base for IPFIX deployment and operation >> and several exiting implementations, the IPFIX WG will revisit the IPFIX >> protocol specifications (RFC 5101) and the IPFIX information element >> specification (RFC 5102) in order to advance them to draft standard. >> >> 2. For giving guidelines to developers of new IPFIX information >> elements and for better defining the process of registering new >> information elements at IANA the IPFIX WG will create an information >> element developers guideline document. >> >> 3. The export of IPFIX flow records from IPFIX mediators introduces a >> set of potential issues at the protocol level, such as the loss of >> information on the original exporter, loss of base time information, >> loss of original options template information, etc. The IPFIX WG will >> define common ways to deal with these issues, by specifying guidelines >> for the use of the IPFIX protocol on IPFIX mediators. >> >> 4. For supporting the aggregation of flow records at IPFIX mediators >> the IPFIX WG will define how to export aggregated flow information using >> IPFIX. An aggregated flow is essentially an IPFIX flow representing >> packets from multiple original Flows sharing some set of common >> properties. >> >> 5. The IPFIX WG will investigate the use of the IPFIX protocol for >> exporting >> MIB objects, avoiding the need to define new IPFIX information elements >> for existing management information base objects that are already fully >> specified. This method requires the specification of new template set >> and options template sets to allow the export of MIB objects along >> with IPFIX information elements. >> >> 6. The IPFIX MIB module (RFC 5815) defined a way to register packet >> selector functions at IANA. The WG agreed that another method would >> be preferable that requires a minor change of RFC 5815. The IPFIX WG >> will produce a new version of RFC 5815 with small modifications of >> the IANA actions and DESCRIPTION clauses in the the MIB modules. >> >> Oct 2011 Publish draft on guidelines for IE doctors >> Oct 2011 Publish draft on IPFIX use at mediators >> Oct 2011 Publish draft on intermediate aggregation >> Oct 2011 Publish draft on exporting MIB objects >> Oct 2011 Publish draft on data link IEs >> Dec 2011 Publish draft revising RFC 5101 >> Dec 2011 Publish draft revising RFC 5102 >> >> Apr 2012 Submit guidelines for IE doctors for publication as >> Informational BCP RFC >> Apr 2012 Submit draft on IPFIX use at mediators for publication as >> Standards track RFC >> Apr 2012 Submit draft on intermediate aggregation for publication as >> Standards track RFC >> Apr 2012 Submit draft on data link IEs for publication as Standards >> track RFC >> Apr 2012 Submit draft revising RFC 5101 for publication as Standards >> track RFC >> Apr 2012 Submit draft revising RFC 5102 for publication as Standards >> track RFC >> Sep 2012 Submit draft on exporting MIB objects for publication as >> Standards track RFC >> >> >> _______________________________________________ >> 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 Wed Sep 28 08:57:02 2011 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 4509621F8BD5 for ; Wed, 28 Sep 2011 08:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_75=0.6] 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 eaY-kLDQ-9A5 for ; Wed, 28 Sep 2011 08:57:00 -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 2CF8121F8C44 for ; Wed, 28 Sep 2011 08:56: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 p8SFxdHC016146; Wed, 28 Sep 2011 17:59:39 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8SFxcp4027030; Wed, 28 Sep 2011 17:59:38 +0200 (CEST) Message-ID: <4E83446A.4020003@cisco.com> Date: Wed, 28 Sep 2011 17:59:38 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Brian Trammell References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> <4E7AA240.4020506@plixer.com> <4E7AE9D1.9090002@cisco.com> <4E82081B.8040806@plixer.com> <4E823130.6000505@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 28 Sep 2011 15:57:02 -0000 Brian, > Hi, Paul, all, > > I suppose I should state for the sake of completeness that this is the first I've ever actually _thought_ about the MPRSO. I find the whole use case for it rather dubious -- it presumes an MP with somehow trustworthy knowledge about packet loss, which is never the case, Well, I can give you an example of Cisco devices, with metering in hardware, that displays the number of packets that were not taken into account, due to excessive cache collisions. Regards, Benoit. > and relying on such information at the collector side for anything other than entertainment purposes is fraught with peril -- so I saw the MAY on section 4 in 5101, was thankful it wasn't a MUST I had to fight against and/or simply ignore, and never looked back. > > That said, it does make sense to fix, since it's there. > > On Sep 27, 2011, at 10:25 PM, Paul Aitken wrote: > >> How do you know that the received template is a MPRSO? > Does it matter? Seriously, what is the difference between "an MPRSO" and "a template containing information about lost packets for a given time interval, along with maybe some other information"? Do we actually want to require an MP to keep time interval information for loss? Wouldn't those resources be better deployed not losing packets in the first place? So let's say I want to report missing packets, but don't have information about when I lost them. Do I have to throw a timestamp in there anyway in order for it to be "an MPRSO"? > > I think these are arguments against having the timestamps at all (or to include them, with a further instruction that they are optional). > >> - must the fields be exactly in the specified order and no other combination in order to be a valid MPRSO? > This isn't a valid template recognition strategy in IPFIX. At least, it hasn't been to date, and it's a bad idea to make it so. IE-Doctors contains language meant to instruct IPFIX application authors to refrain from specifying such magic templates. > >> - how do you know which of the observationTime* elements (or missingObservationWindowEdge elements) is the first and which is the last? >> - only from their position in the template (so, field order and position are crucial) >> - by comparing them (so field order and position aren't important) > Time intervals can be treated as a special case, here, since time can generally be assumed to go in only one direction. "The time interval from A to B" is completely equivalent to "the time interval from B to A", so one could argue order doesn't matter. (We don't argue that anywhere in IPFIX, to be true. But what do I do when I get a flow with an endTime before the startTime?) > >> Suppose a mediator adds, removes, or re-orders the fields. >> - does this invalidate the MPRSO? >> - how does a mediator know not to do this? >> - how does the collector cope if a mediator does? > These questions seem to apply only to the case where MPRSO is magical. I'm trying to define it such that it isn't. > >> The change to "missingObservationWindowEdge" is simply a rename of observationTime. I don't see that it adds anything. > observationTime already has a meaning. "This Information Element specifies the absolute time in seconds of an observation." In other words, "I saw the thing I'm talking about in this record at the specified time". It has never to date been specified in such a way that it means "I saw the thing I'm talking about in this record at the specified time, unless the record contains two observationTimes, in which case I saw the thing in the time interval between those two things". > > missingObservationWindowEdge means "there is missing information within an interval described between this IE and the other identical IE in the record". If we keep the MPRSO defined as it is (and fix it only by dropping in , missingObservationWindowStartSeconds and missingObservationWindowEndSeconds, since it's more IPFIXish, but there was concern voiced in this thread about IE space explosion, so I figured we could exploit the nature of time and cut down on the IEs required by half. > > The advantage of a new IE is that it isn't overloaded, but more importantly that it does not lead to an ambiguous interpretation of the entire template at the collector. > >> A long basicList isn't the right solution because >> - various list lengths mean there are multiple possible templates making the detection of the MPRSO a little more difficult >> ie, it's no longer a fixed template, nor a combination of a few possibilities, but a great many different possible templates. >> - there are two different semantics for the start and end of the window, so it's actually an ordered list of pairs ie a subTemplateList. >> Lists can have zero elements. However, if you want to report that nothing was lost, the ignored*Count = 0 report should indicate the start and end of the 100% period. A list length of zero doesn't tell when stuff was or was not lost - so it's of limited usefulness, unless perhaps as a total figure? Again, see questions above about what is / is not a valid MPRSO. > I withdraw my basicList comment; it was essentially just "thinking aloud", and I didn't actually intend to include a mention of it in the 5101bis MPRSO. 1. It doesn't really add anything to the original intent of the MPRSO, and 2. adding it in 5101bis would cause 5101bis to have a normative dependency on 6313, which is a terrible idea. > > Cheers, > > Brian > >> On 27/09/11 18:30, Andrew Feren wrote: >>> Hi Brian, >>> >>> Well stated. >>> >>> Additional comments inline >>> >>> On 09/27/2011 12:15 PM, Brian Trammell wrote: >>>> Greetings, all, >>>> >>>> This is a little bit of an abuse of the ordering of IEs, in my opinion, and of the general rule that only IEs, and the scope in which they are defined, carry semantics. Even for templates which are defined within Standards Track RFCs, the records defined by the template should be decipherable without reference to the RFC. Put another way, we should not define magical templates, and this template as proposed looks pretty magical. >>> Yes, a black magic sort of magical. We have been discussing this proposed change in the office and coming to the same conclusion. >>>> Without reading the text of this thread, and following basically everything we've ever said about multiple IEs in a record, I would interpret a record matching this template as follows: >>>> >>>> For the metering process A and observation domain B: >>>> N packets were ignored; these contained a total of M octets. >>>> The first observation at this metering process was at time T0. >>>> The second observation at this metering process was at time T1. >>> This was exactly how I interpreted this template until I read the updated draft and saw the bit about "the Collecting Process MUST determine which is the oldest and the most recent timestamp in order the determine the right semantic ...." >>> >>>> This is quite far from the stated intention. I would strongly suggest that we not so lightly give up on "templates should be unambiguously understandable" requirement, even if the exception itself lives in the core protocol document. >>>> >>>> I would suggest, if you want to do a multiple IE solution here, you define something like missingObservationWindowEdge, and have two of them: >>>> >>>> observationDomainId {scope} >>>> meteringProcessId {scope} >>>> ignoredPacketTotalCount >>>> ignoredOctetTotalCount >>>> missingObservationWindowEdge >>>> missingObservationWindowEdge >>>> >>>> This has the advantage that you can have a long basicList of window edges in order to define multiple missing observation windows; each edge pair is a loss window. >>> I like this suggestion, and I have a few additional thoughts. >>> >>> Perhaps the basic list of edge times should either be limited to only one pair or the ignored*TotalCount IEs needs to be in a basiclist with N entries too. >>> >>> How about observationWindowEdge instead (no "missing") to be more generally useful. >>> >>> I think a list of time edges also works neatly when sending this template at regular intervals (which SHOULD be done). When the ignored*TotalCount IEs are zero, an empty list makes sense for edge times. >>> >>> >>>> Seconds suffice for these, I think. You might want to do one in milliseconds. But if you have the resources to calculate your packet loss window to nanosecond precision without having the resources to not lose packets, I humbly submit you've picked the wrong engineering tradeoffs. :) >>> Unless window edge isn't defined specifically for "missing" values. Then the higher precision timestamps might have some use. >>> >>> -Andrew >>>> Best regards, >>>> >>>> Brian >>>> >>>> On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote: >>>> >>>>> Yes, this makes sense. >>>>> >>>>> I gave this some thought and I don't have a better suggestion. I also agree that even though the flow[Start|End]* collection of IEs conveniently has one IE for both first and last, observationTime* is the more correct choice here. >>>>> >>>>> -Andrew >>>>> >>>>> On 09/22/2011 03:54 AM, Benoit Claise wrote: >>>>>> Hi Andrew, >>>>>>> Hi Benoit, >>>>>>> >>>>>>> I had the same thought about using >>>>>>> >>>>>>> 322 observationTimeSeconds >>>>>>> 323 observationTimeMilliseconds >>>>>>> 324 observationTimeMicroseconds >>>>>>> 325 observationTimeNanoseconds >>>>>>> >>>>>>> The problem is that you need two timestamps in the same record (first and last). How does that work with the above? >>>>>> Excellent question. We debated this question with Paul Aitken recently. >>>>>> Let me rephrase the question slightly differently: how does the collector determine that this is a "The Metering Process Reliability Statistics Options Template", and understands the semantic of the two counters? >>>>>> Well. Two solutions: >>>>>> 1. we duplicate all the IEs to have the exact correct semantic. >>>>>> ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] ... and potentially some more such as pre|post >>>>>> This brings multiple new dimensions to IE and will lead to an explosion of IEs if we want to cover all the case >>>>>> 2. the collector tests the possible combination of IE in the Options Template Record. >>>>>> For example, if the collector sees such an Options Template Record, it knows that this a "The Metering Process Reliability Statistics Options Template" >>>>>> observationDomainId (scope) >>>>>> meteringProcessId (scope) >>>>>> >>>>>> ignoredPacketTotalCount >>>>>> ignoredOctetTotalCount >>>>>> observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds >>>>>> observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds >>>>>> >>>>>> >>>>>> While the solution 2 is not perfect, this was the chosen track. >>>>>> >>>>>> Does it make sense? >>>>>> >>>>>> Regards, Benoit >>>>>>> -Andrew >>>>>>> >>>>>>> On 09/21/2011 07:11 PM, Benoit Claise wrote: >>>>>>>> Hi Gerhard, >>>>>>>> >>>>>>>> Thanks for your reply. >>>>>>>> See in line. >>>>>>>>> Hi Benoit, >>>>>>>>> >>>>>>>>> See comments inline. >>>>>>>>> >>>>>>>>> On 20.09.2011 16:19, Benoit Claise wrote: >>>>>>>>>> Dear all, >>>>>>>>>> >>>>>>>>>> [this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt, TO DO -> "time first flow dropped" and "time last flow dropped" inconsistency. See the discussion on the list.] >>>>>>>>>> >>>>>>>>>> Paul Aitken discovered this issue., >>>>>>>>>> >>>>>>>>>> From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template >>>>>>>>>> >>>>>>>>>> time first flow dropped >>>>>>>>>> The timestamp of the first Flow was dropped by >>>>>>>>>> the Metering Process. For this timestamp, any >>>>>>>>>> of the "flowStart" timestamp Information >>>>>>>>>> Elements flowStartMilliseconds, >>>>>>>>>> flowStartMicroseconds, flowStartNanoseconds, and >>>>>>>>>> flowStartDeltaMicroseconds can be used. >>>>>>>>>> >>>>>>>>>> time last flow dropped >>>>>>>>>> The timestamp of the last IP packet that was >>>>>>>>>> ignored by the Metering Process. For this >>>>>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>>>>> Information Elements flowEndMilliseconds, >>>>>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o >>>>>>>>>> >>>>>>>>>> Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that". >>>>>>>>>> >>>>>>>>>> Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter? >>>>>>>>>> >>>>>>>>>> Here is a proposal for 4.2 and 4.3. The underlined parts are new >>>>>>>>>> >>>>>>>>>> 4.2. The Metering Process Reliability Statistics Option Template >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The Metering Process Reliability Option Template specifies the >>>>>>>>>> structure of a Data Record for reporting lack of reliability in the >>>>>>>>>> Metering Process. It SHOULD contain the following Information >>>>>>>>>> Elements that are defined in [ >>>>>>>>>> RFC5102 >>>>>>>>>> ]: >>>>>>>>>> >>>>>>>>>> observationDomainId >>>>>>>>>> An identifier of an Observation Domain that >>>>>>>>>> is locally unique to the Exporting Process. >>>>>>>>>> This Information Element MUST be defined as a >>>>>>>>>> Scope Field. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> meteringProcessId (*) >>>>>>>>>> The identifier of the Metering Process for >>>>>>>>>> which lack of reliability is reported. There >>>>>>>>>> This Information Element MUST be defined as a >>>>>>>>>> Scope Field. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ignoredPacketTotalCount >>>>>>>>>> The total number of IP packets that the >>>>>>>>>> Metering Process did not process. >>>>>>>>>> >>>>>>>>>> ignoredOctetTotalCount >>>>>>>>>> The total number of octets in observed IP >>>>>>>>>> packets that the Metering Process did not >>>>>>>>>> process. >>>>>>>>>> >>>>>>>>>> time first >>>>>>>>>> packet >>>>>>>>>> ignored >>>>>>>>>> The timestamp of the first IP packet that was >>>>>>>>>> ignored by the Metering Process. For this >>>>>>>>>> timestamp, any of the "flowStart" timestamp >>>>>>>>>> Information Elements flowStartMilliseconds, >>>>>>>>>> flowStartMicroseconds, flowStartNanoseconds, >>>>>>>>>> and flowStartDeltaMicroseconds can be used. >>>>>>>>>> >>>>>>>>>> time last >>>>>>>>>> packet >>>>>>>>>> ignored >>>>>>>>>> The timestamp of the last IP packet that was >>>>>>>>>> ignored by the Metering Process. For this >>>>>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>>>>> Information Elements flowEndMilliseconds, >>>>>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>>>> >>>>>>>>> I do not find these IEs in RFC5102. >>>>>>>> Which ones? flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds >>>>>>>> There are in http://www.iana.org/assignments/ipfix/ipfix.xml >>>>>>>> However, re-reading >>>>>>>> time first packet >>>>>>>> ignored >>>>>>>> The timestamp of the first IP packet that was >>>>>>>> ignored by the Metering Process. For this >>>>>>>> timestamp, any of the "flowStart" timestamp >>>>>>>> Information Elements flowStartMilliseconds, >>>>>>>> flowStartMicroseconds, flowStartNanoseconds, >>>>>>>> and flowStartDeltaMicroseconds can be used. >>>>>>>> >>>>>>>> time last >>>>>>>> packet >>>>>>>> ignored >>>>>>>> The timestamp of the last IP packet that was >>>>>>>> ignored by the Metering Process. For this >>>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>>> Information Elements flowEndMilliseconds, >>>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>> >>>>>>>> And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd" timestamp IE, >>>>>>>> I now believe that we should be using this series of IEs >>>>>>>> 322 observationTimeSeconds >>>>>>>> 323 observationTimeMilliseconds >>>>>>>> 324 observationTimeMicroseconds >>>>>>>> 325 observationTimeNanoseconds >>>>>>>> >>>>>>>>>> 4.3. The Exporting Process Reliability Statistics Option Template >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The Exporting Process Reliability Option Template specifies the >>>>>>>>>> structure of a Data Record for reporting lack of reliability in the >>>>>>>>>> Exporting process. It SHOULD contain the following Information >>>>>>>>>> Elements that are defined in [ >>>>>>>>>> RFC5102 >>>>>>>>>> ]: >>>>>>>>>> >>>>>>>>>> Exporting Process ID >>>>>>>>>> The identifier of the Exporting Process for >>>>>>>>>> which lack of reliability is reported. There >>>>>>>>>> are three Information Elements specified in >>>>>>>>>> [ >>>>>>>>>> RFC5102 >>>>>>>>>> ] that can be used for this purpose: >>>>>>>>>> exporterIPv4Address, exporterIPv6Address, or >>>>>>>>>> exportingProcessId. This Information Element >>>>>>>>>> MUST be defined as a Scope Field. >>>>>>>>>> >>>>>>>>>> notSentFlowTotalCount >>>>>>>>>> The total number of Flows that were generated by >>>>>>>>>> the Metering Process and dropped by the Metering >>>>>>>>>> Process or by the Exporting Process instead of >>>>>>>>>> being sent to the Collecting Process. >>>>>>>>>> >>>>>>>>>> notSentPacketTotalCount >>>>>>>>>> The total number of packets in Flow Records that >>>>>>>>>> were generated by the Metering Process and >>>>>>>>>> dropped by the Metering Process or by the >>>>>>>>>> Exporting Process instead of being sent to the >>>>>>>>>> Collecting Process. >>>>>>>>>> >>>>>>>>>> notSentOctetTotalCount >>>>>>>>>> The total number of octets in packets in Flow >>>>>>>>>> Records that were generated by the Metering >>>>>>>>>> Process and dropped by the Metering Process or >>>>>>>>>> by the Exporting Process instead of being sent >>>>>>>>>> to the Collecting Process. >>>>>>>>>> >>>>>>>>>> time first flow dropped >>>>>>>>>> >>>>>>>>>> The time at which the first Flow Record was dropped by >>>>>>>>>> the >>>>>>>>>> Exporting Process. >>>>>>>>>> For this timestamp, any >>>>>>>>>> of the "flowStart" timestamp Information >>>>>>>>>> Elements flowStartMilliseconds, >>>>>>>>>> flowStartMicroseconds, flowStartNanoseconds, and >>>>>>>>>> flowStartDeltaMicroseconds can be used. >>>>>>>>>> >>>>>>>>>> time last flow dropped >>>>>>>>>> >>>>>>>>>> The time at which the last Flow Record was >>>>>>>>>> dropped by the Exporting Process >>>>>>>>>> . For this >>>>>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>>>>> Information Elements flowEndMilliseconds, >>>>>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>>>> >>>>>>>>> Again, I do not find these IEs in RFC5102. >>>>>>>> Same remark, I believe we should be using for the two previous IEs >>>>>>>> 322 observationTimeSeconds >>>>>>>> 323 observationTimeMilliseconds >>>>>>>> 324 observationTimeMicroseconds >>>>>>>> 325 observationTimeNanoseconds >>>>>>>> Regards, Benoit. >>>>>>>>>> The Exporting Process SHOULD export the Data Record specified by the >>>>>>>>>> Exporting Process Reliability Statistics Option Template on a regular >>>>>>>>>> basis or based on some export policy. This periodicity or export >>>>>>>>>> policy SHOULD be configurable. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id >>>>>>>>>> 1. there is a meteringProcessId in IPFIX IANA while there is no cache id >>>>>>>>> meteringProcessId should do the job. >>>>>>>>> >>>>>>>>>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId? >>>>>>>>>> [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name. >>>>>>>>>> From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process. >>>>>>>>>> If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below >>>>>>>>> See reply to Pauls mail. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Gerhard >>>>>>>>> >>>>>>>>>> 4.3. Cache Class >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> +-----------------------------------+ >>>>>>>>>> | Cache | >>>>>>>>>> +-----------------------------------+ 1 +------------------+ >>>>>>>>>> | name |<>--------| immediateCache/ | >>>>>>>>>> | dataRecords {readOnly} | | timeoutCache/ | >>>>>>>>>> | cacheDiscontinuityTime {readOnly} | | naturalCache/ | >>>>>>>>>> | | | permanentCache | >>>>>>>>>> | | +------------------+ >>>>>>>>>> | | >>>>>>>>>> | | 0..* +------------------+ >>>>>>>>>> | |--------->| ExportingProcess | >>>>>>>>>> +-----------------------------------+ +------------------+ >>>>>>>>>> >>>>>>>>>> Figure 12: Cache class >>>>>>>>>> >>>>>>>>>> What do you think? Do you see another way? >>>>>>>>>> >>>>>>>>>> Regards, Paul& Benoit. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>> _______________________________________________ >>>>> 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 Wed Sep 28 09:04:09 2011 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 08F7621F8C34 for ; Wed, 28 Sep 2011 09:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_75=0.6] 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 eDp9rEoYktjK for ; Wed, 28 Sep 2011 09:04: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 3F28121F8BFE for ; Wed, 28 Sep 2011 09:04:05 -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 p8SG6r0q017053; Wed, 28 Sep 2011 18:06:53 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8SG6mug003431; Wed, 28 Sep 2011 18:06:48 +0200 (CEST) Message-ID: <4E834617.3030805@cisco.com> Date: Wed, 28 Sep 2011 18:06:47 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Brian Trammell References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> <4E7AA240.4020506@plixer.com> <4E7AE9D1.9090002@cisco.com> <4E82081B.8040806@plixer.com> <4E823130.6000505@cisco.com> <4E82513F.9020604@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050505080507090604090807" Cc: ipfix@ietf.org Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped 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, 28 Sep 2011 16:04:09 -0000 This is a multi-part message in MIME format. --------------050505080507090604090807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Let me restate what I put in my initial email: Well. Two solutions: 1. we duplicate all the IEs to have the exact correct semantic. ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] ... and potentially some more such as pre|post This brings multiple new dimensions to IE and will lead to an explosion of IEs if we want to cover all the case 2. the collector tests the possible combination of IE in the Options Template Record. For example, if the collector sees such an Options Template Record, it knows that this a "The Metering Process Reliability Statistics Options Template" observationDomainId (scope) meteringProcessId (scope)_ _ ignoredPacketTotalCount ignoredOctetTotalCount observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds And I'm not sure what's the conclusion of this email thread is... Regards, Benoit. > On Sep 28, 2011, at 12:42 AM, Paul Aitken wrote: > >> Brian, >> >>> Hi, Paul, all, >>> >>> I suppose I should state for the sake of completeness that this is the first I've ever actually _thought_ about the MPRSO. I find the whole use case for it rather dubious -- it presumes an MP with somehow trustworthy knowledge about packet loss, which is never the case, and relying on such information at the collector side for anything other than entertainment purposes is fraught with peril -- so I saw the MAY on section 4 in 5101, was thankful it wasn't a MUST I had to fight against and/or simply ignore, and never looked back. >>> >>> That said, it does make sense to fix, since it's there. >>> >>> On Sep 27, 2011, at 10:25 PM, Paul Aitken wrote: >>> >>>> How do you know that the received template is a MPRSO? >>> Does it matter? Seriously, what is the difference between "an MPRSO" and "a template containing information about lost packets for a given time interval, along with maybe some other information"? Do we actually want to require an MP to keep time interval information for loss? Wouldn't those resources be better deployed not losing packets in the first place? So let's say I want to report missing packets, but don't have information about when I lost them. Do I have to throw a timestamp in there anyway in order for it to be "an MPRSO"? >>> >>> I think these are arguments against having the timestamps at all (or to include them, with a further instruction that they are optional). >> When a MP knows that it failed to meter some packets, it must have a way of reporting this which the CP can understand correctly. So it matters in that the CP has to understand the implicit "lost traffic" semantic and potentially take action, perhaps involving reports or alarm bells. > That's an argument for the following template: > > observationDomainId {scope} > meteringProcessId {scope} > ignoredPacketTotalCount > > Which, in my opinion, is a pretty good starting point. > > You can add ignoredOctetTotalCount if you actually know it. Calculating it at libpcap-based MPs like YAF, for example, would involve a little work and generate a bad number: you only get a guess from the kernel how many packets it dropped and no information about how big they are. You can infer octet loss by looking at TCP sequence numbers but now we're back to clear overengineering I think. Maybe on ASIC or FPGA based measurement systems you get good total counters and can measure loss subtractively... But I personally wouldn't waste the real estate on it unless it was a hard requirement. > > Again, if you know the timestamps, you can add them. But for the general case as I see it, your fidelity per IE for the template in 5101 is as follows: > > perfect: observationDomainId {scope} > (i hope you know this) meteringProcessId {scope} > > reasonably good guess: ignoredPacketTotalCount > > poor to fair guess: ignoredOctetTotalCount > (dep. on HW support) > > poor to good guess: a start timestamp of indeterminate IE > (dep. on HW support) an end timestamp of indeterminate IE > >>>> - must the fields be exactly in the specified order and no other combination in order to be a valid MPRSO? >>> This isn't a valid template recognition strategy in IPFIX. At least, it hasn't been to date, and it's a bad idea to make it so. IE-Doctors contains language meant to instruct IPFIX application authors to refrain from specifying such magic templates. >> Great; I'm pleased to hear it. Magic templates lead to inflexible collectors, which in turn lead to bug reports against the EP?! >> >> >>>> - how do you know which of the observationTime* elements (or missingObservationWindowEdge elements) is the first and which is the last? >>>> - only from their position in the template (so, field order and position are crucial) >>>> - by comparing them (so field order and position aren't important) >>> Time intervals can be treated as a special case, here, since time can generally be assumed to go in only one direction. "The time interval from A to B" is completely equivalent to "the time interval from B to A", so one could argue order doesn't matter. (We don't argue that anywhere in IPFIX, to be true. But what do I do when I get a flow with an endTime before the startTime?) >> When the timestamp wraps. The time between 11pm and 1am is 2 hours, while the time between 1am and 11pm is 22 hours. > We don't have any timestamps that only carry time information. They've all got implied dates (either based on the 1970 epoch for the UNIX-like timestamps, or on either the NTP or the UNIX epoch for the 1305 timestamps (we'll need to fix this in 5101bis), and there is no specified wrapping behavior as yet. You only hit this problem in 2038, then, and when you do, you've got bigger problems. > >>>> Suppose a mediator adds, removes, or re-orders the fields. >>>> - does this invalidate the MPRSO? >>>> - how does a mediator know not to do this? >>>> - how does the collector cope if a mediator does? >>> These questions seem to apply only to the case where MPRSO is magical. I'm trying to define it such that it isn't. >> I'm trying to get to the core of what constitues a valid, recognisable MPRSO. Put another way, what's the closest thing to an MPRSO that isn't an MPRSO? > I'm saying that it doesn't matter. Sure, 5101bis should give recommendations for the template an exporting process uses for this information, but any time a CP sees a template that's scoped to something that ID's an MP that contains loss counter IEs, it's an MPRSO. > >> If I use ignoredPacketTotalCount and ignoredOctetTotalCount in another template, does it become an MPRSO? > Depends. Are you binding them to a scope that identifies a metering process? You could also export them in a flow or "flexible flow"/flow aggregate, at which point you're giving very detailed error information. And the collector can infer whatever it wants about total reliability based on _that_... > >> If we ignore what is and what isn't an MPRSO for the moment, how exactly should a MP tell a CP about the traffic it knows it didn't meter? > Using something much like the MPRSO as defined by 5101... I'm just trying to lead us away from thinking of a "bright line" between MPRSO and not-MPRSO, because > >>>> The change to "missingObservationWindowEdge" is simply a rename of observationTime. I don't see that it adds anything. >>> observationTime already has a meaning. "This Information Element specifies the absolute time in seconds of an observation." In other words, "I saw the thing I'm talking about in this record at the specified time". It has never to date been specified in such a way that it means "I saw the thing I'm talking about in this record at the specified time, unless the record contains two observationTimes, in which case I saw the thing in the time interval between those two things". >> Then you're saying that it's invalid to have two different observationTime values in a flow record, because you can't observe an event at two different times. > Well.... yes, this is a bit ambiguous. > >> Thinking about it some more, I suppose this reports multiple instances of the observation with an AND semantic: I saw this at T1 AND at T2 (since other semantics don't make sense). >> Think if these were interfaces: the meaning would be "observed at int1 and int2", rather than "observed from int1 to int2". >> So I've convinced myself to agree that 2 x observationTime don't make sense. > (I'm trying to think of cases where it would be, but I don't think any are illustrative for this discussion...) > >>> missingObservationWindowEdge means "there is missing information within an interval described between this IE and the other identical IE in the record". If we keep the MPRSO defined as it is (and fix it only by dropping in , missingObservationWindowStartSeconds and missingObservationWindowEndSeconds, since it's more IPFIXish, but there was concern voiced in this thread about IE space explosion, so I figured we could exploit the nature of time and cut down on the IEs required by half. >>> >>> The advantage of a new IE is that it isn't overloaded, but more importantly that it does not lead to an ambiguous interpretation of the entire template at the collector. >> Unfortunately WindowEdge is ambiguous in the wrap case, whereas start and end aren't. > (see above on wrapping) > >>>> A long basicList isn't the right solution because >>>> - various list lengths mean there are multiple possible templates making the detection of the MPRSO a little more difficult >>>> ie, it's no longer a fixed template, nor a combination of a few possibilities, but a great many different possible templates. >>>> - there are two different semantics for the start and end of the window, so it's actually an ordered list of pairs ie a subTemplateList. >>>> Lists can have zero elements. However, if you want to report that nothing was lost, the ignored*Count = 0 report should indicate the start and end of the 100% period. A list length of zero doesn't tell when stuff was or was not lost - so it's of limited usefulness, unless perhaps as a total figure? Again, see questions above about what is / is not a valid MPRSO. >>> I withdraw my basicList comment; it was essentially just "thinking aloud", and I didn't actually intend to include a mention of it in the 5101bis MPRSO. 1. It doesn't really add anything to the original intent of the MPRSO, and 2. adding it in 5101bis would cause 5101bis to have a normative dependency on 6313, which is a terrible idea. >> +1. I already discussed with Benoit about using an ordered list or STL of observationTime, and discounted it for this reason. > Yay! At least we emphatically agree on _something_. ;) > > Cheers, > > Brian > >>>> On 27/09/11 18:30, Andrew Feren wrote: >>>>> Hi Brian, >>>>> >>>>> Well stated. >>>>> >>>>> Additional comments inline >>>>> >>>>> On 09/27/2011 12:15 PM, Brian Trammell wrote: >>>>>> Greetings, all, >>>>>> >>>>>> This is a little bit of an abuse of the ordering of IEs, in my opinion, and of the general rule that only IEs, and the scope in which they are defined, carry semantics. Even for templates which are defined within Standards Track RFCs, the records defined by the template should be decipherable without reference to the RFC. Put another way, we should not define magical templates, and this template as proposed looks pretty magical. >>>>> Yes, a black magic sort of magical. We have been discussing this proposed change in the office and coming to the same conclusion. >>>>>> Without reading the text of this thread, and following basically everything we've ever said about multiple IEs in a record, I would interpret a record matching this template as follows: >>>>>> >>>>>> For the metering process A and observation domain B: >>>>>> N packets were ignored; these contained a total of M octets. >>>>>> The first observation at this metering process was at time T0. >>>>>> The second observation at this metering process was at time T1. >>>>> This was exactly how I interpreted this template until I read the updated draft and saw the bit about "the Collecting Process MUST determine which is the oldest and the most recent timestamp in order the determine the right semantic ...." >>>>> >>>>>> This is quite far from the stated intention. I would strongly suggest that we not so lightly give up on "templates should be unambiguously understandable" requirement, even if the exception itself lives in the core protocol document. >>>>>> >>>>>> I would suggest, if you want to do a multiple IE solution here, you define something like missingObservationWindowEdge, and have two of them: >>>>>> >>>>>> observationDomainId {scope} >>>>>> meteringProcessId {scope} >>>>>> ignoredPacketTotalCount >>>>>> ignoredOctetTotalCount >>>>>> missingObservationWindowEdge >>>>>> missingObservationWindowEdge >>>>>> >>>>>> This has the advantage that you can have a long basicList of window edges in order to define multiple missing observation windows; each edge pair is a loss window. >>>>> I like this suggestion, and I have a few additional thoughts. >>>>> >>>>> Perhaps the basic list of edge times should either be limited to only one pair or the ignored*TotalCount IEs needs to be in a basiclist with N entries too. >>>>> >>>>> How about observationWindowEdge instead (no "missing") to be more generally useful. >>>>> >>>>> I think a list of time edges also works neatly when sending this template at regular intervals (which SHOULD be done). When the ignored*TotalCount IEs are zero, an empty list makes sense for edge times. >>>>> >>>>> >>>>>> Seconds suffice for these, I think. You might want to do one in milliseconds. But if you have the resources to calculate your packet loss window to nanosecond precision without having the resources to not lose packets, I humbly submit you've picked the wrong engineering tradeoffs. :) >>>>> Unless window edge isn't defined specifically for "missing" values. Then the higher precision timestamps might have some use. >>>>> >>>>> -Andrew >>>>>> Best regards, >>>>>> >>>>>> Brian >>>>>> >>>>>> On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote: >>>>>> >>>>>>> Yes, this makes sense. >>>>>>> >>>>>>> I gave this some thought and I don't have a better suggestion. I also agree that even though the flow[Start|End]* collection of IEs conveniently has one IE for both first and last, observationTime* is the more correct choice here. >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> On 09/22/2011 03:54 AM, Benoit Claise wrote: >>>>>>>> Hi Andrew, >>>>>>>>> Hi Benoit, >>>>>>>>> >>>>>>>>> I had the same thought about using >>>>>>>>> >>>>>>>>> 322 observationTimeSeconds >>>>>>>>> 323 observationTimeMilliseconds >>>>>>>>> 324 observationTimeMicroseconds >>>>>>>>> 325 observationTimeNanoseconds >>>>>>>>> >>>>>>>>> The problem is that you need two timestamps in the same record (first and last). How does that work with the above? >>>>>>>> Excellent question. We debated this question with Paul Aitken recently. >>>>>>>> Let me rephrase the question slightly differently: how does the collector determine that this is a "The Metering Process Reliability Statistics Options Template", and understands the semantic of the two counters? >>>>>>>> Well. Two solutions: >>>>>>>> 1. we duplicate all the IEs to have the exact correct semantic. >>>>>>>> ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] ... and potentially some more such as pre|post >>>>>>>> This brings multiple new dimensions to IE and will lead to an explosion of IEs if we want to cover all the case >>>>>>>> 2. the collector tests the possible combination of IE in the Options Template Record. >>>>>>>> For example, if the collector sees such an Options Template Record, it knows that this a "The Metering Process Reliability Statistics Options Template" >>>>>>>> observationDomainId (scope) >>>>>>>> meteringProcessId (scope) >>>>>>>> >>>>>>>> ignoredPacketTotalCount >>>>>>>> ignoredOctetTotalCount >>>>>>>> observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds >>>>>>>> observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds >>>>>>>> >>>>>>>> >>>>>>>> While the solution 2 is not perfect, this was the chosen track. >>>>>>>> >>>>>>>> Does it make sense? >>>>>>>> >>>>>>>> Regards, Benoit >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> On 09/21/2011 07:11 PM, Benoit Claise wrote: >>>>>>>>>> Hi Gerhard, >>>>>>>>>> >>>>>>>>>> Thanks for your reply. >>>>>>>>>> See in line. >>>>>>>>>>> Hi Benoit, >>>>>>>>>>> >>>>>>>>>>> See comments inline. >>>>>>>>>>> >>>>>>>>>>> On 20.09.2011 16:19, Benoit Claise wrote: >>>>>>>>>>>> Dear all, >>>>>>>>>>>> >>>>>>>>>>>> [this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt, TO DO -> "time first flow dropped" and "time last flow dropped" inconsistency. See the discussion on the list.] >>>>>>>>>>>> >>>>>>>>>>>> Paul Aitken discovered this issue., >>>>>>>>>>>> >>>>>>>>>>>> From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template >>>>>>>>>>>> >>>>>>>>>>>> time first flow dropped >>>>>>>>>>>> The timestamp of the first Flow was dropped by >>>>>>>>>>>> the Metering Process. For this timestamp, any >>>>>>>>>>>> of the "flowStart" timestamp Information >>>>>>>>>>>> Elements flowStartMilliseconds, >>>>>>>>>>>> flowStartMicroseconds, flowStartNanoseconds, and >>>>>>>>>>>> flowStartDeltaMicroseconds can be used. >>>>>>>>>>>> >>>>>>>>>>>> time last flow dropped >>>>>>>>>>>> The timestamp of the last IP packet that was >>>>>>>>>>>> ignored by the Metering Process. For this >>>>>>>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>>>>>>> Information Elements flowEndMilliseconds, >>>>>>>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o >>>>>>>>>>>> >>>>>>>>>>>> Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that". >>>>>>>>>>>> >>>>>>>>>>>> Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter? >>>>>>>>>>>> >>>>>>>>>>>> Here is a proposal for 4.2 and 4.3. The underlined parts are new >>>>>>>>>>>> >>>>>>>>>>>> 4.2. The Metering Process Reliability Statistics Option Template >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The Metering Process Reliability Option Template specifies the >>>>>>>>>>>> structure of a Data Record for reporting lack of reliability in the >>>>>>>>>>>> Metering Process. It SHOULD contain the following Information >>>>>>>>>>>> Elements that are defined in [ >>>>>>>>>>>> RFC5102 >>>>>>>>>>>> ]: >>>>>>>>>>>> >>>>>>>>>>>> observationDomainId >>>>>>>>>>>> An identifier of an Observation Domain that >>>>>>>>>>>> is locally unique to the Exporting Process. >>>>>>>>>>>> This Information Element MUST be defined as a >>>>>>>>>>>> Scope Field. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> meteringProcessId (*) >>>>>>>>>>>> The identifier of the Metering Process for >>>>>>>>>>>> which lack of reliability is reported. There >>>>>>>>>>>> This Information Element MUST be defined as a >>>>>>>>>>>> Scope Field. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ignoredPacketTotalCount >>>>>>>>>>>> The total number of IP packets that the >>>>>>>>>>>> Metering Process did not process. >>>>>>>>>>>> >>>>>>>>>>>> ignoredOctetTotalCount >>>>>>>>>>>> The total number of octets in observed IP >>>>>>>>>>>> packets that the Metering Process did not >>>>>>>>>>>> process. >>>>>>>>>>>> >>>>>>>>>>>> time first >>>>>>>>>>>> packet >>>>>>>>>>>> ignored >>>>>>>>>>>> The timestamp of the first IP packet that was >>>>>>>>>>>> ignored by the Metering Process. For this >>>>>>>>>>>> timestamp, any of the "flowStart" timestamp >>>>>>>>>>>> Information Elements flowStartMilliseconds, >>>>>>>>>>>> flowStartMicroseconds, flowStartNanoseconds, >>>>>>>>>>>> and flowStartDeltaMicroseconds can be used. >>>>>>>>>>>> >>>>>>>>>>>> time last >>>>>>>>>>>> packet >>>>>>>>>>>> ignored >>>>>>>>>>>> The timestamp of the last IP packet that was >>>>>>>>>>>> ignored by the Metering Process. For this >>>>>>>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>>>>>>> Information Elements flowEndMilliseconds, >>>>>>>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>>>>>> >>>>>>>>>>> I do not find these IEs in RFC5102. >>>>>>>>>> Which ones? flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds >>>>>>>>>> There are in http://www.iana.org/assignments/ipfix/ipfix.xml >>>>>>>>>> However, re-reading >>>>>>>>>> time first packet >>>>>>>>>> ignored >>>>>>>>>> The timestamp of the first IP packet that was >>>>>>>>>> ignored by the Metering Process. For this >>>>>>>>>> timestamp, any of the "flowStart" timestamp >>>>>>>>>> Information Elements flowStartMilliseconds, >>>>>>>>>> flowStartMicroseconds, flowStartNanoseconds, >>>>>>>>>> and flowStartDeltaMicroseconds can be used. >>>>>>>>>> >>>>>>>>>> time last >>>>>>>>>> packet >>>>>>>>>> ignored >>>>>>>>>> The timestamp of the last IP packet that was >>>>>>>>>> ignored by the Metering Process. For this >>>>>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>>>>> Information Elements flowEndMilliseconds, >>>>>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>>>> >>>>>>>>>> And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd" timestamp IE, >>>>>>>>>> I now believe that we should be using this series of IEs >>>>>>>>>> 322 observationTimeSeconds >>>>>>>>>> 323 observationTimeMilliseconds >>>>>>>>>> 324 observationTimeMicroseconds >>>>>>>>>> 325 observationTimeNanoseconds >>>>>>>>>> >>>>>>>>>>>> 4.3. The Exporting Process Reliability Statistics Option Template >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The Exporting Process Reliability Option Template specifies the >>>>>>>>>>>> structure of a Data Record for reporting lack of reliability in the >>>>>>>>>>>> Exporting process. It SHOULD contain the following Information >>>>>>>>>>>> Elements that are defined in [ >>>>>>>>>>>> RFC5102 >>>>>>>>>>>> ]: >>>>>>>>>>>> >>>>>>>>>>>> Exporting Process ID >>>>>>>>>>>> The identifier of the Exporting Process for >>>>>>>>>>>> which lack of reliability is reported. There >>>>>>>>>>>> are three Information Elements specified in >>>>>>>>>>>> [ >>>>>>>>>>>> RFC5102 >>>>>>>>>>>> ] that can be used for this purpose: >>>>>>>>>>>> exporterIPv4Address, exporterIPv6Address, or >>>>>>>>>>>> exportingProcessId. This Information Element >>>>>>>>>>>> MUST be defined as a Scope Field. >>>>>>>>>>>> >>>>>>>>>>>> notSentFlowTotalCount >>>>>>>>>>>> The total number of Flows that were generated by >>>>>>>>>>>> the Metering Process and dropped by the Metering >>>>>>>>>>>> Process or by the Exporting Process instead of >>>>>>>>>>>> being sent to the Collecting Process. >>>>>>>>>>>> >>>>>>>>>>>> notSentPacketTotalCount >>>>>>>>>>>> The total number of packets in Flow Records that >>>>>>>>>>>> were generated by the Metering Process and >>>>>>>>>>>> dropped by the Metering Process or by the >>>>>>>>>>>> Exporting Process instead of being sent to the >>>>>>>>>>>> Collecting Process. >>>>>>>>>>>> >>>>>>>>>>>> notSentOctetTotalCount >>>>>>>>>>>> The total number of octets in packets in Flow >>>>>>>>>>>> Records that were generated by the Metering >>>>>>>>>>>> Process and dropped by the Metering Process or >>>>>>>>>>>> by the Exporting Process instead of being sent >>>>>>>>>>>> to the Collecting Process. >>>>>>>>>>>> >>>>>>>>>>>> time first flow dropped >>>>>>>>>>>> >>>>>>>>>>>> The time at which the first Flow Record was dropped by >>>>>>>>>>>> the >>>>>>>>>>>> Exporting Process. >>>>>>>>>>>> For this timestamp, any >>>>>>>>>>>> of the "flowStart" timestamp Information >>>>>>>>>>>> Elements flowStartMilliseconds, >>>>>>>>>>>> flowStartMicroseconds, flowStartNanoseconds, and >>>>>>>>>>>> flowStartDeltaMicroseconds can be used. >>>>>>>>>>>> >>>>>>>>>>>> time last flow dropped >>>>>>>>>>>> >>>>>>>>>>>> The time at which the last Flow Record was >>>>>>>>>>>> dropped by the Exporting Process >>>>>>>>>>>> . For this >>>>>>>>>>>> timestamp, any of the "flowEnd" timestamp >>>>>>>>>>>> Information Elements flowEndMilliseconds, >>>>>>>>>>>> flowEndMicroseconds, flowEndNanoseconds, and >>>>>>>>>>>> flowEndDeltaMicroseconds can be used. >>>>>>>>>>>> >>>>>>>>>>> Again, I do not find these IEs in RFC5102. >>>>>>>>>> Same remark, I believe we should be using for the two previous IEs >>>>>>>>>> 322 observationTimeSeconds >>>>>>>>>> 323 observationTimeMilliseconds >>>>>>>>>> 324 observationTimeMicroseconds >>>>>>>>>> 325 observationTimeNanoseconds >>>>>>>>>> Regards, Benoit. >>>>>>>>>>>> The Exporting Process SHOULD export the Data Record specified by the >>>>>>>>>>>> Exporting Process Reliability Statistics Option Template on a regular >>>>>>>>>>>> basis or based on some export policy. This periodicity or export >>>>>>>>>>>> policy SHOULD be configurable. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> (*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id >>>>>>>>>>>> 1. there is a meteringProcessId in IPFIX IANA while there is no cache id >>>>>>>>>>> meteringProcessId should do the job. >>>>>>>>>>> >>>>>>>>>>>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId? >>>>>>>>>>>> [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name. >>>>>>>>>>>> From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process. >>>>>>>>>>>> If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below >>>>>>>>>>> See reply to Pauls mail. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Gerhard >>>>>>>>>>> >>>>>>>>>>>> 4.3. Cache Class >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> +-----------------------------------+ >>>>>>>>>>>> | Cache | >>>>>>>>>>>> +-----------------------------------+ 1 +------------------+ >>>>>>>>>>>> | name |<>--------| immediateCache/ | >>>>>>>>>>>> | dataRecords {readOnly} | | timeoutCache/ | >>>>>>>>>>>> | cacheDiscontinuityTime {readOnly} | | naturalCache/ | >>>>>>>>>>>> | | | permanentCache | >>>>>>>>>>>> | | +------------------+ >>>>>>>>>>>> | | >>>>>>>>>>>> | | 0..* +------------------+ >>>>>>>>>>>> | |--------->| ExportingProcess | >>>>>>>>>>>> +-----------------------------------+ +------------------+ >>>>>>>>>>>> >>>>>>>>>>>> Figure 12: Cache class >>>>>>>>>>>> >>>>>>>>>>>> What do you think? Do you see another way? >>>>>>>>>>>> >>>>>>>>>>>> Regards, Paul& Benoit. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>> _______________________________________________ >>>>>>> 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 --------------050505080507090604090807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Let me restate what I put in my initial email:
Well. Two solutions:
1. we duplicate all the IEs to have the exact correct semantic.
    ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] ... and potentially some more such as pre|post
    This brings multiple new dimensions to IE and will lead to an explosion of IEs if we want to cover all the case
2. the collector tests the possible combination of IE in the Options Template Record.
    For example, if the collector sees such an Options Template Record, it knows that this a "The Metering Process Reliability Statistics Options Template" 
  observationDomainId (scope)
  meteringProcessId (scope)
  ignoredPacketTotalCount
  ignoredOctetTotalCount
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
And I'm not sure what's the conclusion of this email thread is...

Regards, Benoit.
On Sep 28, 2011, at 12:42 AM, Paul Aitken wrote:


Brian,


Hi, Paul, all,

I suppose I should state for the sake of completeness that this is the first I've ever actually _thought_ about the MPRSO. I find the whole use case for it rather dubious -- it presumes an MP with somehow trustworthy knowledge about packet loss, which is never the case, and relying on such information at the collector side for anything other than entertainment purposes is fraught with peril -- so I saw the MAY on section 4 in 5101, was thankful it wasn't a MUST I had to fight against and/or simply ignore, and never looked back.

That said, it does make sense to fix, since it's there.

On Sep 27, 2011, at 10:25 PM, Paul Aitken wrote:


How do you know that the received template is a MPRSO?

Does it matter? Seriously, what is the difference between "an MPRSO" and "a template containing information about lost packets for a given time interval, along with maybe some other information"? Do we actually want to require an MP to keep time interval information for loss? Wouldn't those resources be better deployed not losing packets in the first place? So let's say I want to report missing packets, but don't have information about when I lost them. Do I have to throw a timestamp in there anyway in order for it to be "an MPRSO"?

I think these are arguments against having the timestamps at all (or to include them, with a further instruction that they are optional).

When a MP knows that it failed to meter some packets, it must have a way of reporting this which the CP can understand correctly. So it matters in that the CP has to understand the implicit "lost traffic" semantic and potentially take action, perhaps involving reports or alarm bells.

That's an argument for the following template:

  observationDomainId {scope}
  meteringProcessId {scope}
  ignoredPacketTotalCount

Which, in my opinion, is a pretty good starting point.

You can add ignoredOctetTotalCount if you actually know it. Calculating it at libpcap-based MPs like YAF, for example, would involve a little work and generate a bad number: you only get a guess from the kernel how many packets it dropped and no information about how big they are. You can infer octet loss by looking at TCP sequence numbers but now we're back to clear overengineering I think. Maybe on ASIC or FPGA based measurement systems you get good total counters and can measure loss subtractively... But I personally wouldn't waste the real estate on it unless it was a hard requirement.

Again, if you know the timestamps, you can add them. But for the general case as I see it, your fidelity per IE for the template in 5101 is as follows:

perfect:                observationDomainId {scope}
 (i hope you know this) meteringProcessId {scope}

reasonably good guess:  ignoredPacketTotalCount

poor to fair guess:     ignoredOctetTotalCount
 (dep. on HW support)

poor to good guess:     a start timestamp of indeterminate IE
 (dep. on HW support)   an end timestamp of indeterminate IE


   - must the fields be exactly in the specified order and no other combination in order to be a valid MPRSO?

This isn't a valid template recognition strategy in IPFIX. At least, it hasn't been to date, and it's a bad idea to make it so. IE-Doctors contains language meant to instruct IPFIX application authors to refrain from specifying such magic templates.

Great; I'm pleased to hear it. Magic templates lead to inflexible collectors, which in turn lead to bug reports against the EP?!



   - how do you know which of the observationTime* elements (or missingObservationWindowEdge elements) is the first and which is the last?
       - only from their position in the template (so, field order and position are crucial)
       - by comparing them (so field order and position aren't important)

Time intervals can be treated as a special case, here, since time can generally be assumed to go in only one direction. "The time interval from A to B" is completely equivalent to "the time interval from B to A", so one could argue order doesn't matter. (We don't argue that anywhere in IPFIX, to be true. But what do I do when I get a flow with an endTime before the startTime?)

When the timestamp wraps. The time between 11pm and 1am is 2 hours, while the time between 1am and 11pm is 22 hours.

We don't have any timestamps that only carry time information. They've all got implied dates (either based on the 1970 epoch for the UNIX-like timestamps, or on either the NTP or the UNIX epoch for the 1305 timestamps (we'll need to fix this in 5101bis), and there is no specified wrapping behavior as yet. You only hit this problem in 2038, then, and when you do, you've got bigger problems.


Suppose a mediator adds, removes, or re-orders the fields.
   - does this invalidate the MPRSO?
   - how does a mediator know not to do this?
   - how does the collector cope if a mediator does?

These questions seem to apply only to the case where MPRSO is magical. I'm trying to define it such that it isn't.

I'm trying to get to the core of what constitues a valid, recognisable MPRSO. Put another way, what's the closest thing to an MPRSO that isn't an MPRSO?

I'm saying that it doesn't matter. Sure, 5101bis should give recommendations for the template an exporting process uses for this information, but any time a CP sees a template that's scoped to something that ID's an MP that contains loss counter IEs, it's an MPRSO. 


If I use ignoredPacketTotalCount and ignoredOctetTotalCount in another template, does it become an MPRSO?

Depends. Are you binding them to a scope that identifies a metering process? You could also export them in a flow or "flexible flow"/flow aggregate, at which point you're giving very detailed error information. And the collector can infer whatever it wants about total reliability based on _that_...


If we ignore what is and what isn't an MPRSO for the moment, how exactly should a MP tell a CP about the traffic it knows it didn't meter?

Using something much like the MPRSO as defined by 5101... I'm just trying to lead us away from thinking of a "bright line" between MPRSO and not-MPRSO, because 


The change to "missingObservationWindowEdge" is simply a rename of observationTime. I don't see that it adds anything.

observationTime already has a meaning. "This Information Element specifies the absolute time in seconds of an observation." In other words, "I saw the thing I'm talking about in this record at the specified time". It has never to date been specified in such a way that it means "I saw the thing I'm talking about in this record at the specified time, unless the record contains two observationTimes, in which case I saw the thing in the time interval between those two things".

Then you're saying that it's invalid to have two different observationTime values in a flow record, because you can't observe an event at two different times.

Well.... yes, this is a bit ambiguous.


Thinking about it some more, I suppose this reports multiple instances of the observation with an AND semantic: I saw this at T1 AND at T2 (since other semantics don't make sense).
Think if these were interfaces: the meaning would be "observed at int1 and int2", rather than "observed from int1 to int2".
So I've convinced myself to agree that 2 x observationTime don't make sense.

(I'm trying to think of cases where it would be, but I don't think any are illustrative for this discussion...)


missingObservationWindowEdge means "there is missing information within an interval described between this IE and the other identical IE in the record". If we keep the MPRSO defined as it is (and fix it only by dropping in , missingObservationWindowStartSeconds and missingObservationWindowEndSeconds, since it's more IPFIXish, but there was concern voiced in this thread about IE space explosion, so I figured we could exploit the nature of time and cut down on the IEs required by half.

The advantage of a new IE is that it isn't overloaded, but more importantly that it does not lead to an ambiguous interpretation of the entire template at the collector.

Unfortunately WindowEdge is ambiguous in the wrap case, whereas start and end aren't.

(see above on wrapping)



        

          

            
A long basicList isn't the right solution because
   - various list lengths mean there are multiple possible templates making the detection of the MPRSO a little more difficult
      ie, it's no longer a fixed template, nor a combination of a few possibilities, but a great many different possible templates.
   - there are two different semantics for the start and end of the window, so it's actually an ordered list of pairs ie a subTemplateList.
Lists can have zero elements. However, if you want to report that nothing was lost, the ignored*Count = 0 report should indicate the start and end of the 100% period. A list length of zero doesn't tell when stuff was or was not lost - so it's of limited usefulness, unless perhaps as a total figure? Again, see questions above about what is / is not a valid MPRSO.


          

          
I withdraw my basicList comment; it was essentially just "thinking aloud", and I didn't actually intend to include a mention of it in the 5101bis MPRSO. 1. It doesn't really add anything to the original intent of the MPRSO, and 2. adding it in 5101bis would cause 5101bis to have a normative dependency on 6313, which is a terrible idea.


        

        
+1. I already discussed with Benoit about using an ordered list or STL of observationTime, and discounted it for this reason.


      

      
Yay! At least we emphatically agree on _something_. ;)

Cheers,

Brian



      

        

          

            
On 27/09/11 18:30, Andrew Feren wrote:


            

              
Hi Brian,

Well stated.

Additional comments inline

On 09/27/2011 12:15 PM, Brian Trammell wrote:


              

                
Greetings, all,

This is a little bit of an abuse of the ordering of IEs, in my opinion, and of the general rule that only IEs, and the scope in which they are defined, carry semantics. Even for templates which are defined within Standards Track RFCs, the records defined by the template should be decipherable without reference to the RFC. Put another way, we should not define magical templates, and this template as proposed looks pretty magical.


              

              
Yes, a black magic sort of magical.  We have been discussing this proposed change in the office and coming to the same conclusion.


              

                
Without reading the text of this thread, and following basically everything we've ever said about multiple IEs in a record, I would interpret a record matching this template as follows:

For the metering process A and observation domain B:
N packets were ignored; these contained a total of M octets.
The first observation at this metering process was at time T0.
The second observation at this metering process was at time T1.


              

              
This was exactly how I interpreted this template until I read the updated draft and saw the bit about "the Collecting Process MUST determine which is the oldest and the most recent timestamp in order the determine the right semantic ...."



              

                
This is quite far from the stated intention. I would strongly suggest that we not so lightly give up on "templates should be unambiguously understandable" requirement, even if the exception itself lives in the core protocol document.

I would suggest, if you want to do a multiple IE solution here, you define something like missingObservationWindowEdge, and have two of them:

  observationDomainId {scope}
  meteringProcessId {scope}
  ignoredPacketTotalCount
  ignoredOctetTotalCount
  missingObservationWindowEdge
  missingObservationWindowEdge

This has the advantage that you can have a long basicList of window edges in order to define multiple missing observation windows; each edge pair is a loss window.


              

              
I like this suggestion, and I have a few additional thoughts.

Perhaps the basic list of edge times should either be limited to only one pair or the ignored*TotalCount IEs needs to be in a basiclist with N entries too.

How about observationWindowEdge instead (no "missing") to be more generally useful.

I think a list of time edges also works neatly when sending this template at regular intervals (which SHOULD be done).  When the ignored*TotalCount IEs are zero, an empty list makes sense for edge times.




              

                
Seconds suffice for these, I think. You might want to do one in milliseconds. But if you have the resources to calculate your packet loss window to nanosecond precision without having the resources to not lose packets, I humbly submit you've picked the wrong engineering tradeoffs. :)


              

              
Unless window edge isn't defined specifically for "missing" values.  Then the higher precision timestamps might have some use.

-Andrew


              

                
Best regards,

Brian

On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote:



                

                  
Yes, this makes sense.

I gave this some thought and I don't have a better suggestion.  I also agree that even though the flow[Start|End]* collection of IEs conveniently has one IE for both first and last, observationTime* is the more correct choice here.

-Andrew

On 09/22/2011 03:54 AM, Benoit Claise wrote:


                  

                    
Hi Andrew,


                    

                      
Hi Benoit,

I had the same thought about using

322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds

The problem is that you need two timestamps in the same record (first and last).  How does that work with the above?


                    

                    
Excellent question. We debated this question with Paul Aitken recently.
Let me rephrase the question slightly differently: how does the collector determine that this is a "The Metering Process Reliability Statistics Options Template", and understands the semantic of the two counters?
Well. Two solutions:
1. we duplicate all the IEs to have the exact correct semantic.
    ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] ... and potentially some more such as pre|post
    This brings multiple new dimensions to IE and will lead to an explosion of IEs if we want to cover all the case
2. the collector tests the possible combination of IE in the Options Template Record.
    For example, if the collector sees such an Options Template Record, it knows that this a "The Metering Process Reliability Statistics Options Template"
  observationDomainId (scope)
  meteringProcessId (scope)

  ignoredPacketTotalCount
  ignoredOctetTotalCount
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds


While the solution 2 is not perfect, this was the chosen track.

Does it make sense?

Regards, Benoit


                    

                      
-Andrew

On 09/21/2011 07:11 PM, Benoit Claise wrote:


                      

                        
Hi Gerhard,

Thanks for your reply.
See in line.


                        

                          
Hi Benoit,

See comments inline.

On 20.09.2011 16:19, Benoit Claise wrote:


                          

                            
Dear all,

[this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO DO ->   "time first flow dropped" and "time last flow dropped" inconsistency.  See the discussion on the list.]

Paul Aitken discovered this issue.,

>From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template

time first flow dropped
                        The timestamp of the first Flow was dropped by
                        the Metering Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

time last flow dropped
                        The timestamp of the last IP packet that was
                        ignored by the Metering Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.


Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o

Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".

Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter?

Here is a proposal for 4.2 and 4.3. The underlined parts are new

4.2.  The Metering Process Reliability Statistics Option Template



   The Metering Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [
RFC5102
]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.



   meteringProcessId (*)
                           The identifier of the Metering Process for
                           which lack of reliability is reported.  There
                           This Information Element MUST be defined as a
                           Scope Field.


   ignoredPacketTotalCount
                           The total number of IP packets that the
                           Metering Process did not process.

   ignoredOctetTotalCount
                           The total number of octets in observed IP
                           packets that the Metering Process did not
                           process.

   time first
packet
ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last
packet
ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.



                          

                          
I do not find these IEs in RFC5102.


                        

                        
Which ones?  flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds
There are in http://www.iana.org/assignments/ipfix/ipfix.xml
However, re-reading
   time first packet
ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last
packet
ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.

And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd" timestamp IE,
I now believe that we should be using this series of IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds



                        

                          

                            
4.3.  The Exporting Process Reliability Statistics Option Template


   The Exporting Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Exporting process.  It SHOULD contain the following Information
   Elements that are defined in [
RFC5102
]:

   Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [
RFC5102
] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.

   notSentFlowTotalCount
                        The total number of Flows that were generated by
                        the Metering Process and dropped by the Metering
                        Process or by the Exporting Process instead of
                        being sent to the Collecting Process.

   notSentPacketTotalCount
                        The total number of packets in Flow Records that
                        were generated by the Metering Process and
                        dropped by the Metering Process or by the
                        Exporting Process instead of being sent to the
                        Collecting Process.

   notSentOctetTotalCount
                        The total number of octets in packets in Flow
                        Records that were generated by the Metering
                        Process and dropped by the Metering Process or
                        by the Exporting Process instead of being sent
                        to the Collecting Process.

   time first flow dropped

                      The time at which the first Flow Record was dropped by
                        the
Exporting Process.
  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

   time last flow dropped

The time at which the last Flow Record was
                        dropped by the Exporting Process
.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.



                          

                          
Again, I do not find these IEs in RFC5102.


                        

                        
Same remark, I believe we should be using for the two previous IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds
Regards, Benoit.


                        

                          

                            
   The Exporting Process SHOULD export the Data Record specified by the
   Exporting Process Reliability Statistics Option Template on a regular
   basis or based on some export policy.  This periodicity or export
   policy SHOULD be configurable.





(*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id
1. there is a meteringProcessId in IPFIX IANA while there is no cache id


                          

                          
meteringProcessId should do the job.



                          

                            
2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId?
    [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
    From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process.
    If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below


                          

                          
See reply to Pauls mail.

Regards,
Gerhard



                          

                            
4.3.  Cache Class


    +-----------------------------------+
    | Cache                             |
    +-----------------------------------+        1 +------------------+
    | name                              |<>--------| immediateCache/  |
    | dataRecords {readOnly}            |          | timeoutCache/    |
    | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
    |                                   |          | permanentCache   |
    |                                   |          +------------------+
    |                                   |
    |                                   |     0..* +------------------+
    |                                   |--------->| ExportingProcess |
    +-----------------------------------+          +------------------+

                          Figure 12: Cache class

What do you think? Do you see another way?

Regards, Paul&   Benoit.


_______________________________________________
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


                    

                  

                  
_______________________________________________
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


    

    

  


--------------050505080507090604090807--

From trammell@tik.ee.ethz.ch  Wed Sep 28 09:30:27 2011
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 A49A91F0C8C for ; Wed, 28 Sep 2011 09:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.003
X-Spam-Level: 
X-Spam-Status: No, score=-4.003 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_75=0.6, MIME_QP_LONG_LINE=1.396, 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 oFg5pLTKjtwU for ; Wed, 28 Sep 2011 09:30:25 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3EA1F0C69 for ; Wed, 28 Sep 2011 09:30:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3B4E0D930D; Wed, 28 Sep 2011 18:33:11 +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 vesaLUrmfLgp; Wed, 28 Sep 2011 18:33:10 +0200 (MEST)
Received: from [129.132.208.198] (vpn-global-dhcp1-198.ethz.ch [129.132.208.198]) (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 87974D930B; Wed, 28 Sep 2011 18:33:10 +0200 (MEST)
References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> <4E7AA240.4020506@plixer.com> <4E7AE9D1.9090002@cisco.com>  <4E82081B.8040806@plixer.com> <4E823130.6000505@cisco.com>  <4E83446A.4020003@cisco.com>
From: Brian Trammell 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <4E83446A.4020003@cisco.com>
Message-Id: <7CB4F714-9837-4556-A165-D6D32AC97F1F@tik.ee.ethz.ch>
Date: Wed, 28 Sep 2011 18:31:32 +0200
To: Benoit Claise 
Mime-Version: 1.0 (iPhone Mail 8L1)
X-Mailer: iPhone Mail (8L1)
Cc: "ipfix@ietf.org" 
Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped
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, 28 Sep 2011 16:30:27 -0000

hi, Benoit,

okay, cool... and this hardware never loses a packet for any other reason? (=
and it also keeps octet counts for the missing packets? and usable timestamp=
s? very neat. I'd buy one if I were in the market. :)

there are lots of ways to count single-point loss. I'm not convinced that an=
y of them count what they pretend to. this is my point here: yes, it is usef=
ul to detect whether the mp knows it's dropping or not. the order of magnitu=
de might be useful in some cases. but real lost packet counts should always b=
e taken with a half ton of salt at the CP.=20

all of this is kind of a sideline, though. the standing question is: given y=
ou want an MPRSO, how do you do it; on which, see next message...

cheers,=20

Brian

Sent from my iPhone

On 28.09.2011, at 17:59, Benoit Claise  wrote:

> Brian,
>> Hi, Paul, all,
>>=20
>> I suppose I should state for the sake of completeness that this is the fi=
rst I've ever actually _thought_ about the MPRSO. I find the whole use case f=
or it rather dubious -- it presumes an MP with somehow trustworthy knowledge=
 about packet loss, which is never the case,
> Well, I can give you an example of Cisco devices, with metering in hardwar=
e, that displays the number of packets that were not taken into account, due=
 to excessive cache collisions.
>=20
> Regards, Benoit.
>>  and relying on such information at the collector side for anything other=
 than entertainment purposes is fraught with peril -- so I saw the MAY on se=
ction 4 in 5101, was thankful it wasn't a MUST I had to fight against and/or=
 simply ignore, and never looked back.
>>=20
>> That said, it does make sense to fix, since it's there.
>>=20
>> On Sep 27, 2011, at 10:25 PM, Paul Aitken wrote:
>>=20
>>> How do you know that the received template is a MPRSO?
>> Does it matter? Seriously, what is the difference between "an MPRSO" and "=
a template containing information about lost packets for a given time interv=
al, along with maybe some other information"? Do we actually want to require=
 an MP to keep time interval information for loss? Wouldn't those resources b=
e better deployed not losing packets in the first place? So let's say I want=
 to report missing packets, but don't have information about when I lost the=
m. Do I have to throw a timestamp in there anyway in order for it to be "an M=
PRSO"?
>>=20
>> I think these are arguments against having the timestamps at all (or to i=
nclude them, with a further instruction that they are optional).
>>=20
>>>    - must the fields be exactly in the specified order and no other comb=
ination in order to be a valid MPRSO?
>> This isn't a valid template recognition strategy in IPFIX. At least, it h=
asn't been to date, and it's a bad idea to make it so. IE-Doctors contains l=
anguage meant to instruct IPFIX application authors to refrain from specifyi=
ng such magic templates.
>>=20
>>>    - how do you know which of the observationTime* elements (or missingO=
bservationWindowEdge elements) is the first and which is the last?
>>>        - only from their position in the template (so, field order and p=
osition are crucial)
>>>        - by comparing them (so field order and position aren't important=
)
>> Time intervals can be treated as a special case, here, since time can gen=
erally be assumed to go in only one direction. "The time interval from A to B=
" is completely equivalent to "the time interval from B to A", so one could a=
rgue order doesn't matter. (We don't argue that anywhere in IPFIX, to be tru=
e. But what do I do when I get a flow with an endTime before the startTime?)=

>>=20
>>> Suppose a mediator adds, removes, or re-orders the fields.
>>>    - does this invalidate the MPRSO?
>>>    - how does a mediator know not to do this?
>>>    - how does the collector cope if a mediator does?
>> These questions seem to apply only to the case where MPRSO is magical. I'=
m trying to define it such that it isn't.
>>=20
>>> The change to "missingObservationWindowEdge" is simply a rename of obser=
vationTime. I don't see that it adds anything.
>> observationTime already has a meaning. "This Information Element specifie=
s the absolute time in seconds of an observation." In other words, "I saw th=
e thing I'm talking about in this record at the specified time". It has neve=
r to date been specified in such a way that it means "I saw the thing I'm ta=
lking about in this record at the specified time, unless the record contains=
 two observationTimes, in which case I saw the thing in the time interval be=
tween those two things".
>>=20
>> missingObservationWindowEdge means "there is missing information within a=
n interval described between this IE and the other identical IE in the recor=
d". If we keep the MPRSO defined as it is (and fix it only by dropping in , m=
issingObservationWindowStartSeconds and missingObservationWindowEndSeconds, s=
ince it's more IPFIXish, but there was concern voiced in this thread about I=
E space explosion, so I figured we could exploit the nature of time and cut d=
own on the IEs required by half.
>>=20
>> The advantage of a new IE is that it isn't overloaded, but more important=
ly that it does not lead to an ambiguous interpretation of the entire templa=
te at the collector.
>>=20
>>> A long basicList isn't the right solution because
>>>    - various list lengths mean there are multiple possible templates mak=
ing the detection of the MPRSO a little more difficult
>>>       ie, it's no longer a fixed template, nor a combination of a few po=
ssibilities, but a great many different possible templates.
>>>    - there are two different semantics for the start and end of the wind=
ow, so it's actually an ordered list of pairs ie a subTemplateList.
>>> Lists can have zero elements. However, if you want to report that nothin=
g was lost, the ignored*Count =3D 0 report should indicate the start and end=
 of the 100% period. A list length of zero doesn't tell when stuff was or wa=
s not lost - so it's of limited usefulness, unless perhaps as a total figure=
? Again, see questions above about what is / is not a valid MPRSO.
>> I withdraw my basicList comment; it was essentially just "thinking aloud"=
, and I didn't actually intend to include a mention of it in the 5101bis MPR=
SO. 1. It doesn't really add anything to the original intent of the MPRSO, a=
nd 2. adding it in 5101bis would cause 5101bis to have a normative dependenc=
y on 6313, which is a terrible idea.
>>=20
>> Cheers,
>>=20
>> Brian
>>=20
>>> On 27/09/11 18:30, Andrew Feren wrote:
>>>> Hi Brian,
>>>>=20
>>>> Well stated.
>>>>=20
>>>> Additional comments inline
>>>>=20
>>>> On 09/27/2011 12:15 PM, Brian Trammell wrote:
>>>>> Greetings, all,
>>>>>=20
>>>>> This is a little bit of an abuse of the ordering of IEs, in my opinion=
, and of the general rule that only IEs, and the scope in which they are def=
ined, carry semantics. Even for templates which are defined within Standards=
 Track RFCs, the records defined by the template should be decipherable with=
out reference to the RFC. Put another way, we should not define magical temp=
lates, and this template as proposed looks pretty magical.
>>>> Yes, a black magic sort of magical.  We have been discussing this propo=
sed change in the office and coming to the same conclusion.
>>>>> Without reading the text of this thread, and following basically every=
thing we've ever said about multiple IEs in a record, I would interpret a re=
cord matching this template as follows:
>>>>>=20
>>>>> For the metering process A and observation domain B:
>>>>> N packets were ignored; these contained a total of M octets.
>>>>> The first observation at this metering process was at time T0.
>>>>> The second observation at this metering process was at time T1.
>>>> This was exactly how I interpreted this template until I read the updat=
ed draft and saw the bit about "the Collecting Process MUST determine which i=
s the oldest and the most recent timestamp in order the determine the right s=
emantic ...."
>>>>=20
>>>>> This is quite far from the stated intention. I would strongly suggest t=
hat we not so lightly give up on "templates should be unambiguously understa=
ndable" requirement, even if the exception itself lives in the core protocol=
 document.
>>>>>=20
>>>>> I would suggest, if you want to do a multiple IE solution here, you de=
fine something like missingObservationWindowEdge, and have two of them:
>>>>>=20
>>>>>   observationDomainId {scope}
>>>>>   meteringProcessId {scope}
>>>>>   ignoredPacketTotalCount
>>>>>   ignoredOctetTotalCount
>>>>>   missingObservationWindowEdge
>>>>>   missingObservationWindowEdge
>>>>>=20
>>>>> This has the advantage that you can have a long basicList of window ed=
ges in order to define multiple missing observation windows; each edge pair i=
s a loss window.
>>>> I like this suggestion, and I have a few additional thoughts.
>>>>=20
>>>> Perhaps the basic list of edge times should either be limited to only o=
ne pair or the ignored*TotalCount IEs needs to be in a basiclist with N entr=
ies too.
>>>>=20
>>>> How about observationWindowEdge instead (no "missing") to be more gener=
ally useful.
>>>>=20
>>>> I think a list of time edges also works neatly when sending this templa=
te at regular intervals (which SHOULD be done).  When the ignored*TotalCount=
 IEs are zero, an empty list makes sense for edge times.
>>>>=20
>>>>=20
>>>>> Seconds suffice for these, I think. You might want to do one in millis=
econds. But if you have the resources to calculate your packet loss window t=
o nanosecond precision without having the resources to not lose packets, I h=
umbly submit you've picked the wrong engineering tradeoffs. :)
>>>> Unless window edge isn't defined specifically for "missing" values.  Th=
en the higher precision timestamps might have some use.
>>>>=20
>>>> -Andrew
>>>>> Best regards,
>>>>>=20
>>>>> Brian
>>>>>=20
>>>>> On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote:
>>>>>=20
>>>>>> Yes, this makes sense.
>>>>>>=20
>>>>>> I gave this some thought and I don't have a better suggestion.  I als=
o agree that even though the flow[Start|End]* collection of IEs conveniently=
 has one IE for both first and last, observationTime* is the more correct ch=
oice here.
>>>>>>=20
>>>>>> -Andrew
>>>>>>=20
>>>>>> On 09/22/2011 03:54 AM, Benoit Claise wrote:
>>>>>>> Hi Andrew,
>>>>>>>> Hi Benoit,
>>>>>>>>=20
>>>>>>>> I had the same thought about using
>>>>>>>>=20
>>>>>>>> 322    observationTimeSeconds
>>>>>>>> 323    observationTimeMilliseconds
>>>>>>>> 324    observationTimeMicroseconds
>>>>>>>> 325    observationTimeNanoseconds
>>>>>>>>=20
>>>>>>>> The problem is that you need two timestamps in the same record (fir=
st and last).  How does that work with the above?
>>>>>>> Excellent question. We debated this question with Paul Aitken recent=
ly.
>>>>>>> Let me rephrase the question slightly differently: how does the coll=
ector determine that this is a "The Metering Process Reliability Statistics O=
ptions Template", and understands the semantic of the two counters?
>>>>>>> Well. Two solutions:
>>>>>>> 1. we duplicate all the IEs to have the exact correct semantic.
>>>>>>>     ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Mi=
croseconds|Nanoseconds] ... and potentially some more such as pre|post
>>>>>>>     This brings multiple new dimensions to IE and will lead to an ex=
plosion of IEs if we want to cover all the case
>>>>>>> 2. the collector tests the possible combination of IE in the Options=
 Template Record.
>>>>>>>     For example, if the collector sees such an Options Template Reco=
rd, it knows that this a "The Metering Process Reliability Statistics Option=
s Template"
>>>>>>>   observationDomainId (scope)
>>>>>>>   meteringProcessId (scope)
>>>>>>>=20
>>>>>>>   ignoredPacketTotalCount
>>>>>>>   ignoredOctetTotalCount
>>>>>>>   observationTimeSeconds | observationTimeMilliseconds | observation=
TimeMicroseconds | observationTimeNanoseconds
>>>>>>>   observationTimeSeconds | observationTimeMilliseconds | observation=
TimeMicroseconds | observationTimeNanoseconds
>>>>>>>=20
>>>>>>>=20
>>>>>>> While the solution 2 is not perfect, this was the chosen track.
>>>>>>>=20
>>>>>>> Does it make sense?
>>>>>>>=20
>>>>>>> Regards, Benoit
>>>>>>>> -Andrew
>>>>>>>>=20
>>>>>>>> On 09/21/2011 07:11 PM, Benoit Claise wrote:
>>>>>>>>> Hi Gerhard,
>>>>>>>>>=20
>>>>>>>>> Thanks for your reply.
>>>>>>>>> See in line.
>>>>>>>>>> Hi Benoit,
>>>>>>>>>>=20
>>>>>>>>>> See comments inline.
>>>>>>>>>>=20
>>>>>>>>>> On 20.09.2011 16:19, Benoit Claise wrote:
>>>>>>>>>>> Dear all,
>>>>>>>>>>>=20
>>>>>>>>>>> [this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.=
txt,  TO DO ->   "time first flow dropped" and "time last flow dropped" inco=
nsistency.  See the discussion on the list.]
>>>>>>>>>>>=20
>>>>>>>>>>> Paul Aitken discovered this issue.,
>>>>>>>>>>>=20
>>>>>>>>>>> =46rom [RFC5101], section 4.3. The Exporting Process Reliability=
 Statistics Option Template
>>>>>>>>>>>=20
>>>>>>>>>>> time first flow dropped
>>>>>>>>>>>                         The timestamp of the first Flow was drop=
ped by
>>>>>>>>>>>                         the Metering Process.  For this timestam=
p, any
>>>>>>>>>>>                         of the "flowStart" timestamp Information=

>>>>>>>>>>>                         Elements flowStartMilliseconds,
>>>>>>>>>>>                         flowStartMicroseconds, flowStartNanoseco=
nds, and
>>>>>>>>>>>                         flowStartDeltaMicroseconds can be used.
>>>>>>>>>>>=20
>>>>>>>>>>> time last flow dropped
>>>>>>>>>>>                         The timestamp of the last IP packet that=
 was
>>>>>>>>>>>                         ignored by the Metering Process.  For th=
is
>>>>>>>>>>>                         timestamp, any of the "flowEnd" timestam=
p
>>>>>>>>>>>                         Information Elements flowEndMilliseconds=
,
>>>>>>>>>>>                         flowEndMicroseconds, flowEndNanoseconds,=
 and
>>>>>>>>>>>                         flowEndDeltaMicroseconds can be used.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> Firstly, these definitions are inconsistent since the names and t=
he first definition say "flow" while the second definition says "IP packet".=
 Obviously "IP packet" !=3D "flow" :-o
>>>>>>>>>>>=20
>>>>>>>>>>> Secondly, "The timestamp of the first Flow was dropped by the Me=
tering Process." is bad English: at least it's missing "that".
>>>>>>>>>>>=20
>>>>>>>>>>> Thirdly, the section 4.2 doesn't take into account a metering pr=
ocess id. Indeed, what if we have multiple caches on the exporter?
>>>>>>>>>>>=20
>>>>>>>>>>> Here is a proposal for 4.2 and 4.3. The underlined parts are new=

>>>>>>>>>>>=20
>>>>>>>>>>> 4.2.  The Metering Process Reliability Statistics Option Templat=
e
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>    The Metering Process Reliability Option Template specifies th=
e
>>>>>>>>>>>    structure of a Data Record for reporting lack of reliability i=
n the
>>>>>>>>>>>    Metering Process.  It SHOULD contain the following Informatio=
n
>>>>>>>>>>>    Elements that are defined in [
>>>>>>>>>>> RFC5102
>>>>>>>>>>> ]:
>>>>>>>>>>>=20
>>>>>>>>>>>    observationDomainId
>>>>>>>>>>>                            An identifier of an Observation Domai=
n that
>>>>>>>>>>>                            is locally unique to the Exporting Pr=
ocess.
>>>>>>>>>>>                            This Information Element MUST be defi=
ned as a
>>>>>>>>>>>                            Scope Field.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>    meteringProcessId (*)
>>>>>>>>>>>                            The identifier of the Metering Proces=
s for
>>>>>>>>>>>                            which lack of reliability is reported=
.  There
>>>>>>>>>>>                            This Information Element MUST be defi=
ned as a
>>>>>>>>>>>                            Scope Field.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>    ignoredPacketTotalCount
>>>>>>>>>>>                            The total number of IP packets that t=
he
>>>>>>>>>>>                            Metering Process did not process.
>>>>>>>>>>>=20
>>>>>>>>>>>    ignoredOctetTotalCount
>>>>>>>>>>>                            The total number of octets in observe=
d IP
>>>>>>>>>>>                            packets that the Metering Process did=
 not
>>>>>>>>>>>                            process.
>>>>>>>>>>>=20
>>>>>>>>>>>    time first
>>>>>>>>>>> packet
>>>>>>>>>>> ignored
>>>>>>>>>>>                            The timestamp of the first IP packet t=
hat was
>>>>>>>>>>>                            ignored by the Metering Process.  For=
 this
>>>>>>>>>>>                            timestamp, any of the "flowStart" tim=
estamp
>>>>>>>>>>>                            Information Elements flowStartMillise=
conds,
>>>>>>>>>>>                            flowStartMicroseconds, flowStartNanos=
econds,
>>>>>>>>>>>                            and flowStartDeltaMicroseconds can be=
 used.
>>>>>>>>>>>=20
>>>>>>>>>>>    time last
>>>>>>>>>>> packet
>>>>>>>>>>> ignored
>>>>>>>>>>>                            The timestamp of the last IP packet t=
hat was
>>>>>>>>>>>                            ignored by the Metering Process.  For=
 this
>>>>>>>>>>>                            timestamp, any of the "flowEnd" times=
tamp
>>>>>>>>>>>                            Information Elements flowEndMilliseco=
nds,
>>>>>>>>>>>                            flowEndMicroseconds, flowEndNanosecon=
ds, and
>>>>>>>>>>>                            flowEndDeltaMicroseconds can be used.=

>>>>>>>>>>>=20
>>>>>>>>>> I do not find these IEs in RFC5102.
>>>>>>>>> Which ones?  flowEndMilliseconds, flowEndMicroseconds, flowEndNano=
seconds, and flowEndDeltaMicroseconds
>>>>>>>>> There are in http://www.iana.org/assignments/ipfix/ipfix.xml
>>>>>>>>> However, re-reading
>>>>>>>>>    time first packet
>>>>>>>>> ignored
>>>>>>>>>                            The timestamp of the first IP packet th=
at was
>>>>>>>>>                            ignored by the Metering Process.  For t=
his
>>>>>>>>>                            timestamp, any of the "flowStart" times=
tamp
>>>>>>>>>                            Information Elements flowStartMilliseco=
nds,
>>>>>>>>>                            flowStartMicroseconds, flowStartNanosec=
onds,
>>>>>>>>>                            and flowStartDeltaMicroseconds can be u=
sed.
>>>>>>>>>=20
>>>>>>>>>    time last
>>>>>>>>> packet
>>>>>>>>> ignored
>>>>>>>>>                            The timestamp of the last IP packet tha=
t was
>>>>>>>>>                            ignored by the Metering Process.  For t=
his
>>>>>>>>>                            timestamp, any of the "flowEnd" timesta=
mp
>>>>>>>>>                            Information Elements flowEndMillisecond=
s,
>>>>>>>>>                            flowEndMicroseconds, flowEndNanoseconds=
, and
>>>>>>>>>                            flowEndDeltaMicroseconds can be used.
>>>>>>>>>=20
>>>>>>>>> And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowE=
nd" timestamp IE,
>>>>>>>>> I now believe that we should be using this series of IEs
>>>>>>>>> 322    observationTimeSeconds
>>>>>>>>> 323    observationTimeMilliseconds
>>>>>>>>> 324    observationTimeMicroseconds
>>>>>>>>> 325    observationTimeNanoseconds
>>>>>>>>>=20
>>>>>>>>>>> 4.3.  The Exporting Process Reliability Statistics Option Templa=
te
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>    The Exporting Process Reliability Option Template specifies t=
he
>>>>>>>>>>>    structure of a Data Record for reporting lack of reliability i=
n the
>>>>>>>>>>>    Exporting process.  It SHOULD contain the following Informati=
on
>>>>>>>>>>>    Elements that are defined in [
>>>>>>>>>>> RFC5102
>>>>>>>>>>> ]:
>>>>>>>>>>>=20
>>>>>>>>>>>    Exporting Process ID
>>>>>>>>>>>                         The identifier of the Exporting Process f=
or
>>>>>>>>>>>                         which lack of reliability is reported.  T=
here
>>>>>>>>>>>                         are three Information Elements specified=
 in
>>>>>>>>>>>                         [
>>>>>>>>>>> RFC5102
>>>>>>>>>>> ] that can be used for this purpose:
>>>>>>>>>>>                         exporterIPv4Address, exporterIPv6Address=
, or
>>>>>>>>>>>                         exportingProcessId.  This Information El=
ement
>>>>>>>>>>>                         MUST be defined as a Scope Field.
>>>>>>>>>>>=20
>>>>>>>>>>>    notSentFlowTotalCount
>>>>>>>>>>>                         The total number of Flows that were gene=
rated by
>>>>>>>>>>>                         the Metering Process and dropped by the M=
etering
>>>>>>>>>>>                         Process or by the Exporting Process inst=
ead of
>>>>>>>>>>>                         being sent to the Collecting Process.
>>>>>>>>>>>=20
>>>>>>>>>>>    notSentPacketTotalCount
>>>>>>>>>>>                         The total number of packets in Flow Reco=
rds that
>>>>>>>>>>>                         were generated by the Metering Process a=
nd
>>>>>>>>>>>                         dropped by the Metering Process or by th=
e
>>>>>>>>>>>                         Exporting Process instead of being sent t=
o the
>>>>>>>>>>>                         Collecting Process.
>>>>>>>>>>>=20
>>>>>>>>>>>    notSentOctetTotalCount
>>>>>>>>>>>                         The total number of octets in packets in=
 Flow
>>>>>>>>>>>                         Records that were generated by the Meter=
ing
>>>>>>>>>>>                         Process and dropped by the Metering Proc=
ess or
>>>>>>>>>>>                         by the Exporting Process instead of bein=
g sent
>>>>>>>>>>>                         to the Collecting Process.
>>>>>>>>>>>=20
>>>>>>>>>>>    time first flow dropped
>>>>>>>>>>>=20
>>>>>>>>>>>                       The time at which the first Flow Record wa=
s dropped by
>>>>>>>>>>>                         the
>>>>>>>>>>> Exporting Process.
>>>>>>>>>>>   For this timestamp, any
>>>>>>>>>>>                         of the "flowStart" timestamp Information=

>>>>>>>>>>>                         Elements flowStartMilliseconds,
>>>>>>>>>>>                         flowStartMicroseconds, flowStartNanoseco=
nds, and
>>>>>>>>>>>                         flowStartDeltaMicroseconds can be used.
>>>>>>>>>>>=20
>>>>>>>>>>>    time last flow dropped
>>>>>>>>>>>=20
>>>>>>>>>>> The time at which the last Flow Record was
>>>>>>>>>>>                         dropped by the Exporting Process
>>>>>>>>>>> .  For this
>>>>>>>>>>>                         timestamp, any of the "flowEnd" timestam=
p
>>>>>>>>>>>                         Information Elements flowEndMilliseconds=
,
>>>>>>>>>>>                         flowEndMicroseconds, flowEndNanoseconds,=
 and
>>>>>>>>>>>                         flowEndDeltaMicroseconds can be used.
>>>>>>>>>>>=20
>>>>>>>>>> Again, I do not find these IEs in RFC5102.
>>>>>>>>> Same remark, I believe we should be using for the two previous IEs=

>>>>>>>>> 322    observationTimeSeconds
>>>>>>>>> 323    observationTimeMilliseconds
>>>>>>>>> 324    observationTimeMicroseconds
>>>>>>>>> 325    observationTimeNanoseconds
>>>>>>>>> Regards, Benoit.
>>>>>>>>>>>    The Exporting Process SHOULD export the Data Record specified=
 by the
>>>>>>>>>>>    Exporting Process Reliability Statistics Option Template on a=
 regular
>>>>>>>>>>>    basis or based on some export policy.  This periodicity or ex=
port
>>>>>>>>>>>    policy SHOULD be configurable.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> (*) regarding the meteringProcessId, we were hesitating between t=
he meteringProcessId and the cache id
>>>>>>>>>>> 1. there is a meteringProcessId in IPFIX IANA while there is no c=
ache id
>>>>>>>>>> meteringProcessId should do the job.
>>>>>>>>>>=20
>>>>>>>>>>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what s=
hould be the value in meteringProcessId?
>>>>>>>>>>>     [IPFIX-CONF] doesn't mention the meteringProcessId, but a ca=
che name.
>>>>>>>>>>>     =46rom figure 1 and 2, it seems that there is a one to one m=
atching between the cache and the metering process.
>>>>>>>>>>>     If this is the case, a solution could be to add a meteringPr=
ocess inside the cache in the figure 12 in [IPFIX-CONF] below
>>>>>>>>>> See reply to Pauls mail.
>>>>>>>>>>=20
>>>>>>>>>> Regards,
>>>>>>>>>> Gerhard
>>>>>>>>>>=20
>>>>>>>>>>> 4.3.  Cache Class
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>     +-----------------------------------+
>>>>>>>>>>>     | Cache                             |
>>>>>>>>>>>     +-----------------------------------+        1 +------------=
------+
>>>>>>>>>>>     | name                              |<>--------| immediateCa=
che/  |
>>>>>>>>>>>     | dataRecords {readOnly}            |          | timeoutCach=
e/    |
>>>>>>>>>>>     | cacheDiscontinuityTime {readOnly} |          | naturalCach=
e/    |
>>>>>>>>>>>     |                                   |          | permanentCa=
che   |
>>>>>>>>>>>     |                                   |          +------------=
------+
>>>>>>>>>>>     |                                   |
>>>>>>>>>>>     |                                   |     0..* +------------=
------+
>>>>>>>>>>>     |                                   |--------->| ExportingPr=
ocess |
>>>>>>>>>>>     +-----------------------------------+          +------------=
------+
>>>>>>>>>>>=20
>>>>>>>>>>>                           Figure 12: Cache class
>>>>>>>>>>>=20
>>>>>>>>>>> What do you think? Do you see another way?
>>>>>>>>>>>=20
>>>>>>>>>>> Regards, Paul&   Benoit.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> IPFIX mailing list
>>>>>>>>>>>=20
>>>>>>>>>>> IPFIX@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>> _______________________________________________
>>>>>>>>> IPFIX mailing list
>>>>>>>>>=20
>>>>>>>>> IPFIX@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> IPFIX mailing list
>>>>>>>>=20
>>>>>>>> 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
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix

From trammell@tik.ee.ethz.ch  Wed Sep 28 09:45:02 2011
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 A5D5711E80D9 for ; Wed, 28 Sep 2011 09:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.002
X-Spam-Level: 
X-Spam-Status: No, score=-4.002 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_75=0.6, MIME_QP_LONG_LINE=1.396, 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 OCB6KIlZy6o9 for ; Wed, 28 Sep 2011 09:44:59 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 96F0111E80D8 for ; Wed, 28 Sep 2011 09:44:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E6863D930E; Wed, 28 Sep 2011 18:47:46 +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 mrP10qwnq-72; Wed, 28 Sep 2011 18:47:46 +0200 (MEST)
Received: from [129.132.208.198] (vpn-global-dhcp1-198.ethz.ch [129.132.208.198]) (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 D89DAD930B; Wed, 28 Sep 2011 18:47:45 +0200 (MEST)
References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> <4E7AA240.4020506@plixer.com> <4E7AE9D1.9090002@cisco.com>  <4E82081B.8040806@plixer.com> <4E823130.6000505@cisco.com>  <4E82513F.9020604@cisco.com>  <4E834617.3030805@cisco.com>
In-Reply-To: <4E834617.3030805@cisco.com>
Mime-Version: 1.0 (iPhone Mail 8L1)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary=Apple-Mail-1--381155689
Message-Id: <10BEDBFE-B363-4B40-9202-B43F89F262D2@tik.ee.ethz.ch>
X-Mailer: iPhone Mail (8L1)
From: Brian Trammell 
Date: Wed, 28 Sep 2011 18:47:36 +0200
To: Benoit Claise 
Cc: "ipfix@ietf.org" 
Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped
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, 28 Sep 2011 16:45:02 -0000

--Apple-Mail-1--381155689
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi, Benoit, all,

Conclusion (from my side): neither.

2. relies on magical templates, which I regard as basically poisonous. Being=
 able to know what a template represents unambiguously is one of the key str=
engths of IPFIX.

1. is half-magical, so half poisonous. The timestamps carry no semantics ide=
ntifying that they have to do with a window during which loss occurred. We c=
ould I suppose change the definition of ignored*count to say "if present, ti=
mestamps in the same record identify the outer bounding window of the loss e=
vent(s)" or similar.

I suggest 3. drop the timestamps completely, or 4. define loss window timest=
amps.=20

Cheers,=20

Brian

Sent from my iPhone

On 28.09.2011, at 18:06, Benoit Claise  wrote:

> Dear all,
>=20
> Let me restate what I put in my initial email:
> Well. Two solutions:
> 1. we duplicate all the IEs to have the exact correct semantic.=20
>     ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microsec=
onds|Nanoseconds] ... and potentially some more such as pre|post
>     This brings multiple new dimensions to IE and will lead to an explosio=
n of IEs if we want to cover all the case
> 2. the collector tests the possible combination of IE in the Options Templ=
ate Record.
>     For example, if the collector sees such an Options Template Record, it=
 knows that this a "The Metering Process Reliability Statistics Options Temp=
late"
>   observationDomainId (scope)
>   meteringProcessId (scope)
>   ignoredPacketTotalCount
>   ignoredOctetTotalCount
>   observationTimeSeconds | observationTimeMilliseconds | observationTimeMi=
croseconds | observationTimeNanoseconds
>   observationTimeSeconds | observationTimeMilliseconds | observationTimeMi=
croseconds | observationTimeNanoseconds
>=20
>=20
> And I'm not sure what's the conclusion of this email thread is...
>=20
> Regards, Benoit.
>> On Sep 28, 2011, at 12:42 AM, Paul Aitken wrote:
>>=20
>>> Brian,
>>>=20
>>>> Hi, Paul, all,
>>>>=20
>>>> I suppose I should state for the sake of completeness that this is the f=
irst I've ever actually _thought_ about the MPRSO. I find the whole use case=
 for it rather dubious -- it presumes an MP with somehow trustworthy knowled=
ge about packet loss, which is never the case, and relying on such informati=
on at the collector side for anything other than entertainment purposes is f=
raught with peril -- so I saw the MAY on section 4 in 5101, was thankful it w=
asn't a MUST I had to fight against and/or simply ignore, and never looked b=
ack.
>>>>=20
>>>> That said, it does make sense to fix, since it's there.
>>>>=20
>>>> On Sep 27, 2011, at 10:25 PM, Paul Aitken wrote:
>>>>=20
>>>>> How do you know that the received template is a MPRSO?
>>>> Does it matter? Seriously, what is the difference between "an MPRSO" an=
d "a template containing information about lost packets for a given time int=
erval, along with maybe some other information"? Do we actually want to requ=
ire an MP to keep time interval information for loss? Wouldn't those resourc=
es be better deployed not losing packets in the first place? So let's say I w=
ant to report missing packets, but don't have information about when I lost t=
hem. Do I have to throw a timestamp in there anyway in order for it to be "a=
n MPRSO"?
>>>>=20
>>>> I think these are arguments against having the timestamps at all (or to=
 include them, with a further instruction that they are optional).
>>> When a MP knows that it failed to meter some packets, it must have a way=
 of reporting this which the CP can understand correctly. So it matters in t=
hat the CP has to understand the implicit "lost traffic" semantic and potent=
ially take action, perhaps involving reports or alarm bells.
>> That's an argument for the following template:
>>=20
>>   observationDomainId {scope}
>>   meteringProcessId {scope}
>>   ignoredPacketTotalCount
>>=20
>> Which, in my opinion, is a pretty good starting point.
>>=20
>> You can add ignoredOctetTotalCount if you actually know it. Calculating i=
t at libpcap-based MPs like YAF, for example, would involve a little work an=
d generate a bad number: you only get a guess from the kernel how many packe=
ts it dropped and no information about how big they are. You can infer octet=
 loss by looking at TCP sequence numbers but now we're back to clear overeng=
ineering I think. Maybe on ASIC or FPGA based measurement systems you get go=
od total counters and can measure loss subtractively... But I personally wou=
ldn't waste the real estate on it unless it was a hard requirement.
>>=20
>> Again, if you know the timestamps, you can add them. But for the general c=
ase as I see it, your fidelity per IE for the template in 5101 is as follows=
:
>>=20
>> perfect:                observationDomainId {scope}
>>  (i hope you know this) meteringProcessId {scope}
>>=20
>> reasonably good guess:  ignoredPacketTotalCount
>>=20
>> poor to fair guess:     ignoredOctetTotalCount
>>  (dep. on HW support)
>>=20
>> poor to good guess:     a start timestamp of indeterminate IE
>>  (dep. on HW support)   an end timestamp of indeterminate IE
>>=20
>>>=20
>>>>=20
>>>>>    - must the fields be exactly in the specified order and no other co=
mbination in order to be a valid MPRSO?
>>>> This isn't a valid template recognition strategy in IPFIX. At least, it=
 hasn't been to date, and it's a bad idea to make it so. IE-Doctors contains=
 language meant to instruct IPFIX application authors to refrain from specif=
ying such magic templates.
>>> Great; I'm pleased to hear it. Magic templates lead to inflexible collec=
tors, which in turn lead to bug reports against the EP?!
>>>=20
>>>=20
>>>>=20
>>>>>    - how do you know which of the observationTime* elements (or missin=
gObservationWindowEdge elements) is the first and which is the last?
>>>>>        - only from their position in the template (so, field order and=
 position are crucial)
>>>>>        - by comparing them (so field order and position aren't importa=
nt)
>>>> Time intervals can be treated as a special case, here, since time can g=
enerally be assumed to go in only one direction. "The time interval from A t=
o B" is completely equivalent to "the time interval from B to A", so one cou=
ld argue order doesn't matter. (We don't argue that anywhere in IPFIX, to be=
 true. But what do I do when I get a flow with an endTime before the startTi=
me?)
>>> When the timestamp wraps. The time between 11pm and 1am is 2 hours, whil=
e the time between 1am and 11pm is 22 hours.
>> We don't have any timestamps that only carry time information. They've al=
l got implied dates (either based on the 1970 epoch for the UNIX-like timest=
amps, or on either the NTP or the UNIX epoch for the 1305 timestamps (we'll n=
eed to fix this in 5101bis), and there is no specified wrapping behavior as y=
et. You only hit this problem in 2038, then, and when you do, you've got big=
ger problems.
>>=20
>>>=20
>>>>=20
>>>>> Suppose a mediator adds, removes, or re-orders the fields.
>>>>>    - does this invalidate the MPRSO?
>>>>>    - how does a mediator know not to do this?
>>>>>    - how does the collector cope if a mediator does?
>>>> These questions seem to apply only to the case where MPRSO is magical. I=
'm trying to define it such that it isn't.
>>> I'm trying to get to the core of what constitues a valid, recognisable M=
PRSO. Put another way, what's the closest thing to an MPRSO that isn't an MP=
RSO?
>> I'm saying that it doesn't matter. Sure, 5101bis should give recommendati=
ons for the template an exporting process uses for this information, but any=
 time a CP sees a template that's scoped to something that ID's an MP that c=
ontains loss counter IEs, it's an MPRSO.=20
>>=20
>>> If I use ignoredPacketTotalCount and ignoredOctetTotalCount in another t=
emplate, does it become an MPRSO?
>> Depends. Are you binding them to a scope that identifies a metering proce=
ss? You could also export them in a flow or "flexible flow"/flow aggregate, a=
t which point you're giving very detailed error information. And the collect=
or can infer whatever it wants about total reliability based on _that_...
>>=20
>>> If we ignore what is and what isn't an MPRSO for the moment, how exactly=
 should a MP tell a CP about the traffic it knows it didn't meter?
>> Using something much like the MPRSO as defined by 5101... I'm just trying=
 to lead us away from thinking of a "bright line" between MPRSO and not-MPRS=
O, because=20
>>=20
>>>=20
>>>>=20
>>>>> The change to "missingObservationWindowEdge" is simply a rename of obs=
ervationTime. I don't see that it adds anything.
>>>> observationTime already has a meaning. "This Information Element specif=
ies the absolute time in seconds of an observation." In other words, "I saw t=
he thing I'm talking about in this record at the specified time". It has nev=
er to date been specified in such a way that it means "I saw the thing I'm t=
alking about in this record at the specified time, unless the record contain=
s two observationTimes, in which case I saw the thing in the time interval b=
etween those two things".
>>> Then you're saying that it's invalid to have two different observationTi=
me values in a flow record, because you can't observe an event at two differ=
ent times.
>> Well.... yes, this is a bit ambiguous.
>>=20
>>> Thinking about it some more, I suppose this reports multiple instances o=
f the observation with an AND semantic: I saw this at T1 AND at T2 (since ot=
her semantics don't make sense).
>>> Think if these were interfaces: the meaning would be "observed at int1 a=
nd int2", rather than "observed from int1 to int2".
>>> So I've convinced myself to agree that 2 x observationTime don't make se=
nse.
>> (I'm trying to think of cases where it would be, but I don't think any ar=
e illustrative for this discussion...)
>>=20
>>>=20
>>>> missingObservationWindowEdge means "there is missing information within=
 an interval described between this IE and the other identical IE in the rec=
ord". If we keep the MPRSO defined as it is (and fix it only by dropping in ,=
 missingObservationWindowStartSeconds and missingObservationWindowEndSeconds=
, since it's more IPFIXish, but there was concern voiced in this thread abou=
t IE space explosion, so I figured we could exploit the nature of time and c=
ut down on the IEs required by half.
>>>>=20
>>>> The advantage of a new IE is that it isn't overloaded, but more importa=
ntly that it does not lead to an ambiguous interpretation of the entire temp=
late at the collector.
>>> Unfortunately WindowEdge is ambiguous in the wrap case, whereas start an=
d end aren't.
>> (see above on wrapping)
>>=20
>>>=20
>>>>=20
>>>>> A long basicList isn't the right solution because
>>>>>    - various list lengths mean there are multiple possible templates m=
aking the detection of the MPRSO a little more difficult
>>>>>       ie, it's no longer a fixed template, nor a combination of a few p=
ossibilities, but a great many different possible templates.
>>>>>    - there are two different semantics for the start and end of the wi=
ndow, so it's actually an ordered list of pairs ie a subTemplateList.
>>>>> Lists can have zero elements. However, if you want to report that noth=
ing was lost, the ignored*Count =3D 0 report should indicate the start and e=
nd of the 100% period. A list length of zero doesn't tell when stuff was or w=
as not lost - so it's of limited usefulness, unless perhaps as a total figur=
e? Again, see questions above about what is / is not a valid MPRSO.
>>>> I withdraw my basicList comment; it was essentially just "thinking alou=
d", and I didn't actually intend to include a mention of it in the 5101bis M=
PRSO. 1. It doesn't really add anything to the original intent of the MPRSO,=
 and 2. adding it in 5101bis would cause 5101bis to have a normative depende=
ncy on 6313, which is a terrible idea.
>>> +1. I already discussed with Benoit about using an ordered list or STL o=
f observationTime, and discounted it for this reason.
>> Yay! At least we emphatically agree on _something_. ;)
>>=20
>> Cheers,
>>=20
>> Brian
>>=20
>>>=20
>>>>=20
>>>>> On 27/09/11 18:30, Andrew Feren wrote:
>>>>>> Hi Brian,
>>>>>>=20
>>>>>> Well stated.
>>>>>>=20
>>>>>> Additional comments inline
>>>>>>=20
>>>>>> On 09/27/2011 12:15 PM, Brian Trammell wrote:
>>>>>>> Greetings, all,
>>>>>>>=20
>>>>>>> This is a little bit of an abuse of the ordering of IEs, in my opini=
on, and of the general rule that only IEs, and the scope in which they are d=
efined, carry semantics. Even for templates which are defined within Standar=
ds Track RFCs, the records defined by the template should be decipherable wi=
thout reference to the RFC. Put another way, we should not define magical te=
mplates, and this template as proposed looks pretty magical.
>>>>>> Yes, a black magic sort of magical.  We have been discussing this pro=
posed change in the office and coming to the same conclusion.
>>>>>>> Without reading the text of this thread, and following basically eve=
rything we've ever said about multiple IEs in a record, I would interpret a r=
ecord matching this template as follows:
>>>>>>>=20
>>>>>>> For the metering process A and observation domain B:
>>>>>>> N packets were ignored; these contained a total of M octets.
>>>>>>> The first observation at this metering process was at time T0.
>>>>>>> The second observation at this metering process was at time T1.
>>>>>> This was exactly how I interpreted this template until I read the upd=
ated draft and saw the bit about "the Collecting Process MUST determine whic=
h is the oldest and the most recent timestamp in order the determine the rig=
ht semantic ...."
>>>>>>=20
>>>>>>> This is quite far from the stated intention. I would strongly sugges=
t that we not so lightly give up on "templates should be unambiguously under=
standable" requirement, even if the exception itself lives in the core proto=
col document.
>>>>>>>=20
>>>>>>> I would suggest, if you want to do a multiple IE solution here, you d=
efine something like missingObservationWindowEdge, and have two of them:
>>>>>>>=20
>>>>>>>   observationDomainId {scope}
>>>>>>>   meteringProcessId {scope}
>>>>>>>   ignoredPacketTotalCount
>>>>>>>   ignoredOctetTotalCount
>>>>>>>   missingObservationWindowEdge
>>>>>>>   missingObservationWindowEdge
>>>>>>>=20
>>>>>>> This has the advantage that you can have a long basicList of window e=
dges in order to define multiple missing observation windows; each edge pair=
 is a loss window.
>>>>>> I like this suggestion, and I have a few additional thoughts.
>>>>>>=20
>>>>>> Perhaps the basic list of edge times should either be limited to only=
 one pair or the ignored*TotalCount IEs needs to be in a basiclist with N en=
tries too.
>>>>>>=20
>>>>>> How about observationWindowEdge instead (no "missing") to be more gen=
erally useful.
>>>>>>=20
>>>>>> I think a list of time edges also works neatly when sending this temp=
late at regular intervals (which SHOULD be done).  When the ignored*TotalCou=
nt IEs are zero, an empty list makes sense for edge times.
>>>>>>=20
>>>>>>=20
>>>>>>> Seconds suffice for these, I think. You might want to do one in mill=
iseconds. But if you have the resources to calculate your packet loss window=
 to nanosecond precision without having the resources to not lose packets, I=
 humbly submit you've picked the wrong engineering tradeoffs. :)
>>>>>> Unless window edge isn't defined specifically for "missing" values.  T=
hen the higher precision timestamps might have some use.
>>>>>>=20
>>>>>> -Andrew
>>>>>>> Best regards,
>>>>>>>=20
>>>>>>> Brian
>>>>>>>=20
>>>>>>> On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote:
>>>>>>>=20
>>>>>>>> Yes, this makes sense.
>>>>>>>>=20
>>>>>>>> I gave this some thought and I don't have a better suggestion.  I a=
lso agree that even though the flow[Start|End]* collection of IEs convenient=
ly has one IE for both first and last, observationTime* is the more correct c=
hoice here.
>>>>>>>>=20
>>>>>>>> -Andrew
>>>>>>>>=20
>>>>>>>> On 09/22/2011 03:54 AM, Benoit Claise wrote:
>>>>>>>>> Hi Andrew,
>>>>>>>>>> Hi Benoit,
>>>>>>>>>>=20
>>>>>>>>>> I had the same thought about using
>>>>>>>>>>=20
>>>>>>>>>> 322    observationTimeSeconds
>>>>>>>>>> 323    observationTimeMilliseconds
>>>>>>>>>> 324    observationTimeMicroseconds
>>>>>>>>>> 325    observationTimeNanoseconds
>>>>>>>>>>=20
>>>>>>>>>> The problem is that you need two timestamps in the same record (f=
irst and last).  How does that work with the above?
>>>>>>>>> Excellent question. We debated this question with Paul Aitken rece=
ntly.
>>>>>>>>> Let me rephrase the question slightly differently: how does the co=
llector determine that this is a "The Metering Process Reliability Statistic=
s Options Template", and understands the semantic of the two counters?
>>>>>>>>> Well. Two solutions:
>>>>>>>>> 1. we duplicate all the IEs to have the exact correct semantic.
>>>>>>>>>     ObservationTime[packet|flow][first|last][Seconds|Milliseconds|=
Microseconds|Nanoseconds] ... and potentially some more such as pre|post
>>>>>>>>>     This brings multiple new dimensions to IE and will lead to an e=
xplosion of IEs if we want to cover all the case
>>>>>>>>> 2. the collector tests the possible combination of IE in the Optio=
ns Template Record.
>>>>>>>>>     For example, if the collector sees such an Options Template Re=
cord, it knows that this a "The Metering Process Reliability Statistics Opti=
ons Template"
>>>>>>>>>   observationDomainId (scope)
>>>>>>>>>   meteringProcessId (scope)
>>>>>>>>>=20
>>>>>>>>>   ignoredPacketTotalCount
>>>>>>>>>   ignoredOctetTotalCount
>>>>>>>>>   observationTimeSeconds | observationTimeMilliseconds | observati=
onTimeMicroseconds | observationTimeNanoseconds
>>>>>>>>>   observationTimeSeconds | observationTimeMilliseconds | observati=
onTimeMicroseconds | observationTimeNanoseconds
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> While the solution 2 is not perfect, this was the chosen track.
>>>>>>>>>=20
>>>>>>>>> Does it make sense?
>>>>>>>>>=20
>>>>>>>>> Regards, Benoit
>>>>>>>>>> -Andrew
>>>>>>>>>>=20
>>>>>>>>>> On 09/21/2011 07:11 PM, Benoit Claise wrote:
>>>>>>>>>>> Hi Gerhard,
>>>>>>>>>>>=20
>>>>>>>>>>> Thanks for your reply.
>>>>>>>>>>> See in line.
>>>>>>>>>>>> Hi Benoit,
>>>>>>>>>>>>=20
>>>>>>>>>>>> See comments inline.
>>>>>>>>>>>>=20
>>>>>>>>>>>> On 20.09.2011 16:19, Benoit Claise wrote:
>>>>>>>>>>>>> Dear all,
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> [this email addresses draft-claise-ipfix-protocol-rfc5101bis-0=
0.txt,  TO DO ->   "time first flow dropped" and "time last flow dropped" in=
consistency.  See the discussion on the list.]
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Paul Aitken discovered this issue.,
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> >=46rom [RFC5101], section 4.3. The Exporting Process Reliabil=
ity Statistics Option Template
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> time first flow dropped
>>>>>>>>>>>>>                         The timestamp of the first Flow was dr=
opped by
>>>>>>>>>>>>>                         the Metering Process.  For this timest=
amp, any
>>>>>>>>>>>>>                         of the "flowStart" timestamp Informati=
on
>>>>>>>>>>>>>                         Elements flowStartMilliseconds,
>>>>>>>>>>>>>                         flowStartMicroseconds, flowStartNanose=
conds, and
>>>>>>>>>>>>>                         flowStartDeltaMicroseconds can be used=
.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> time last flow dropped
>>>>>>>>>>>>>                         The timestamp of the last IP packet th=
at was
>>>>>>>>>>>>>                         ignored by the Metering Process.  For t=
his
>>>>>>>>>>>>>                         timestamp, any of the "flowEnd" timest=
amp
>>>>>>>>>>>>>                         Information Elements flowEndMillisecon=
ds,
>>>>>>>>>>>>>                         flowEndMicroseconds, flowEndNanosecond=
s, and
>>>>>>>>>>>>>                         flowEndDeltaMicroseconds can be used.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Firstly, these definitions are inconsistent since the names an=
d the first definition say "flow" while the second definition says "IP packe=
t". Obviously "IP packet" !=3D "flow" :-o
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Secondly, "The timestamp of the first Flow was dropped by the M=
etering Process." is bad English: at least it's missing "that".
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Thirdly, the section 4.2 doesn't take into account a metering p=
rocess id. Indeed, what if we have multiple caches on the exporter?
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Here is a proposal for 4.2 and 4.3. The underlined parts are n=
ew
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> 4.2.  The Metering Process Reliability Statistics Option Templ=
ate
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>    The Metering Process Reliability Option Template specifies t=
he
>>>>>>>>>>>>>    structure of a Data Record for reporting lack of reliabilit=
y in the
>>>>>>>>>>>>>    Metering Process.  It SHOULD contain the following Informat=
ion
>>>>>>>>>>>>>    Elements that are defined in [
>>>>>>>>>>>>> RFC5102
>>>>>>>>>>>>> ]:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>    observationDomainId
>>>>>>>>>>>>>                            An identifier of an Observation Dom=
ain that
>>>>>>>>>>>>>                            is locally unique to the Exporting P=
rocess.
>>>>>>>>>>>>>                            This Information Element MUST be de=
fined as a
>>>>>>>>>>>>>                            Scope Field.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>    meteringProcessId (*)
>>>>>>>>>>>>>                            The identifier of the Metering Proc=
ess for
>>>>>>>>>>>>>                            which lack of reliability is report=
ed.  There
>>>>>>>>>>>>>                            This Information Element MUST be de=
fined as a
>>>>>>>>>>>>>                            Scope Field.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>    ignoredPacketTotalCount
>>>>>>>>>>>>>                            The total number of IP packets that=
 the
>>>>>>>>>>>>>                            Metering Process did not process.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>    ignoredOctetTotalCount
>>>>>>>>>>>>>                            The total number of octets in obser=
ved IP
>>>>>>>>>>>>>                            packets that the Metering Process d=
id not
>>>>>>>>>>>>>                            process.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>    time first
>>>>>>>>>>>>> packet
>>>>>>>>>>>>> ignored
>>>>>>>>>>>>>                            The timestamp of the first IP packe=
t that was
>>>>>>>>>>>>>                            ignored by the Metering Process.  Fo=
r this
>>>>>>>>>>>>>                            timestamp, any of the "flowStart" t=
imestamp
>>>>>>>>>>>>>                            Information Elements flowStartMilli=
seconds,
>>>>>>>>>>>>>                            flowStartMicroseconds, flowStartNan=
oseconds,
>>>>>>>>>>>>>                            and flowStartDeltaMicroseconds can b=
e used.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>    time last
>>>>>>>>>>>>> packet
>>>>>>>>>>>>> ignored
>>>>>>>>>>>>>                            The timestamp of the last IP packet=
 that was
>>>>>>>>>>>>>                            ignored by the Metering Process.  Fo=
r this
>>>>>>>>>>>>>                            timestamp, any of the "flowEnd" tim=
estamp
>>>>>>>>>>>>>                            Information Elements flowEndMillise=
conds,
>>>>>>>>>>>>>                            flowEndMicroseconds, flowEndNanosec=
onds, and
>>>>>>>>>>>>>                            flowEndDeltaMicroseconds can be use=
d.
>>>>>>>>>>>>>=20
>>>>>>>>>>>> I do not find these IEs in RFC5102.
>>>>>>>>>>> Which ones?  flowEndMilliseconds, flowEndMicroseconds, flowEndNa=
noseconds, and flowEndDeltaMicroseconds
>>>>>>>>>>> There are in http://www.iana.org/assignments/ipfix/ipfix.xml
>>>>>>>>>>> However, re-reading
>>>>>>>>>>>    time first packet
>>>>>>>>>>> ignored
>>>>>>>>>>>                            The timestamp of the first IP packet t=
hat was
>>>>>>>>>>>                            ignored by the Metering Process.  For=
 this
>>>>>>>>>>>                            timestamp, any of the "flowStart" tim=
estamp
>>>>>>>>>>>                            Information Elements flowStartMillise=
conds,
>>>>>>>>>>>                            flowStartMicroseconds, flowStartNanos=
econds,
>>>>>>>>>>>                            and flowStartDeltaMicroseconds can be=
 used.
>>>>>>>>>>>=20
>>>>>>>>>>>    time last
>>>>>>>>>>> packet
>>>>>>>>>>> ignored
>>>>>>>>>>>                            The timestamp of the last IP packet t=
hat was
>>>>>>>>>>>                            ignored by the Metering Process.  For=
 this
>>>>>>>>>>>                            timestamp, any of the "flowEnd" times=
tamp
>>>>>>>>>>>                            Information Elements flowEndMilliseco=
nds,
>>>>>>>>>>>                            flowEndMicroseconds, flowEndNanosecon=
ds, and
>>>>>>>>>>>                            flowEndDeltaMicroseconds can be used.=

>>>>>>>>>>>=20
>>>>>>>>>>> And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flo=
wEnd" timestamp IE,
>>>>>>>>>>> I now believe that we should be using this series of IEs
>>>>>>>>>>> 322    observationTimeSeconds
>>>>>>>>>>> 323    observationTimeMilliseconds
>>>>>>>>>>> 324    observationTimeMicroseconds
>>>>>>>>>>> 325    observationTimeNanoseconds
>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>> 4.3.  The Exporting Process Reliability Statistics Option Temp=
late
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>    The Exporting Process Reliability Option Template specifies=
 the
>>>>>>>>>>>>>    structure of a Data Record for reporting lack of reliabilit=
y in the
>>>>>>>>>>>>>    Exporting process.  It SHOULD contain the following Informa=
tion
>>>>>>>>>>>>>    Elements that are defined in [
>>>>>>>>>>>>> RFC5102
>>>>>>>>>>>>> ]:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>    Exporting Process ID
>>>>>>>>>>>>>                         The identifier of the Exporting Proces=
s for
>>>>>>>>>>>>>                         which lack of reliability is reported.=
  There
>>>>>>>>>>>>>                         are three Information Elements specifi=
ed in
>>>>>>>>>>>>>                         [
>>>>>>>>>>>>> RFC5102
>>>>>>>>>>>>> ] that can be used for this purpose:
>>>>>>>>>>>>>                         exporterIPv4Address, exporterIPv6Addre=
ss, or
>>>>>>>>>>>>>                         exportingProcessId.  This Information E=
lement
>>>>>>>>>>>>>                         MUST be defined as a Scope Field.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>    notSentFlowTotalCount
>>>>>>>>>>>>>                         The total number of Flows that were ge=
nerated by
>>>>>>>>>>>>>                         the Metering Process and dropped by th=
e Metering
>>>>>>>>>>>>>                         Process or by the Exporting Process in=
stead of
>>>>>>>>>>>>>                         being sent to the Collecting Process.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>    notSentPacketTotalCount
>>>>>>>>>>>>>                         The total number of packets in Flow Re=
cords that
>>>>>>>>>>>>>                         were generated by the Metering Process=
 and
>>>>>>>>>>>>>                         dropped by the Metering Process or by t=
he
>>>>>>>>>>>>>                         Exporting Process instead of being sen=
t to the
>>>>>>>>>>>>>                         Collecting Process.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>    notSentOctetTotalCount
>>>>>>>>>>>>>                         The total number of octets in packets i=
n Flow
>>>>>>>>>>>>>                         Records that were generated by the Met=
ering
>>>>>>>>>>>>>                         Process and dropped by the Metering Pr=
ocess or
>>>>>>>>>>>>>                         by the Exporting Process instead of be=
ing sent
>>>>>>>>>>>>>                         to the Collecting Process.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>    time first flow dropped
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>                       The time at which the first Flow Record w=
as dropped by
>>>>>>>>>>>>>                         the
>>>>>>>>>>>>> Exporting Process.
>>>>>>>>>>>>>   For this timestamp, any
>>>>>>>>>>>>>                         of the "flowStart" timestamp Informati=
on
>>>>>>>>>>>>>                         Elements flowStartMilliseconds,
>>>>>>>>>>>>>                         flowStartMicroseconds, flowStartNanose=
conds, and
>>>>>>>>>>>>>                         flowStartDeltaMicroseconds can be used=
.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>    time last flow dropped
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> The time at which the last Flow Record was
>>>>>>>>>>>>>                         dropped by the Exporting Process
>>>>>>>>>>>>> .  For this
>>>>>>>>>>>>>                         timestamp, any of the "flowEnd" timest=
amp
>>>>>>>>>>>>>                         Information Elements flowEndMillisecon=
ds,
>>>>>>>>>>>>>                         flowEndMicroseconds, flowEndNanosecond=
s, and
>>>>>>>>>>>>>                         flowEndDeltaMicroseconds can be used.
>>>>>>>>>>>>>=20
>>>>>>>>>>>> Again, I do not find these IEs in RFC5102.
>>>>>>>>>>> Same remark, I believe we should be using for the two previous I=
Es
>>>>>>>>>>> 322    observationTimeSeconds
>>>>>>>>>>> 323    observationTimeMilliseconds
>>>>>>>>>>> 324    observationTimeMicroseconds
>>>>>>>>>>> 325    observationTimeNanoseconds
>>>>>>>>>>> Regards, Benoit.
>>>>>>>>>>>>=20
>>>>>>>>>>>>>    The Exporting Process SHOULD export the Data Record specifi=
ed by the
>>>>>>>>>>>>>    Exporting Process Reliability Statistics Option Template on=
 a regular
>>>>>>>>>>>>>    basis or based on some export policy.  This periodicity or e=
xport
>>>>>>>>>>>>>    policy SHOULD be configurable.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> (*) regarding the meteringProcessId, we were hesitating betwee=
n the meteringProcessId and the cache id
>>>>>>>>>>>>> 1. there is a meteringProcessId in IPFIX IANA while there is n=
o cache id
>>>>>>>>>>>> meteringProcessId should do the job.
>>>>>>>>>>>>=20
>>>>>>>>>>>>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what=
 should be the value in meteringProcessId?
>>>>>>>>>>>>>     [IPFIX-CONF] doesn't mention the meteringProcessId, but a c=
ache name.
>>>>>>>>>>>>>     =46rom figure 1 and 2, it seems that there is a one to one=
 matching between the cache and the metering process.
>>>>>>>>>>>>>     If this is the case, a solution could be to add a metering=
Process inside the cache in the figure 12 in [IPFIX-CONF] below
>>>>>>>>>>>> See reply to Pauls mail.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Gerhard
>>>>>>>>>>>>=20
>>>>>>>>>>>>> 4.3.  Cache Class
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>     +-----------------------------------+
>>>>>>>>>>>>>     | Cache                             |
>>>>>>>>>>>>>     +-----------------------------------+        1 +----------=
--------+
>>>>>>>>>>>>>     | name                              |<>--------| immediate=
Cache/  |
>>>>>>>>>>>>>     | dataRecords {readOnly}            |          | timeoutCa=
che/    |
>>>>>>>>>>>>>     | cacheDiscontinuityTime {readOnly} |          | naturalCa=
che/    |
>>>>>>>>>>>>>     |                                   |          | permanent=
Cache   |
>>>>>>>>>>>>>     |                                   |          +----------=
--------+
>>>>>>>>>>>>>     |                                   |
>>>>>>>>>>>>>     |                                   |     0..* +----------=
--------+
>>>>>>>>>>>>>     |                                   |--------->| Exporting=
Process |
>>>>>>>>>>>>>     +-----------------------------------+          +----------=
--------+
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>                           Figure 12: Cache class
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> What do you think? Do you see another way?
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Regards, Paul&   Benoit.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> IPFIX mailing list
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> IPFIX@ietf.org
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>>>>>=20
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> IPFIX mailing list
>>>>>>>>>>>=20
>>>>>>>>>>> IPFIX@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>>> _______________________________________________
>>>>>>>>>> IPFIX mailing list
>>>>>>>>>>=20
>>>>>>>>>> IPFIX@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>=20
>>>>=20
>>>=20
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>=20

--Apple-Mail-1--381155689
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Hi, Benoit, all,

Conclusion (from my side): neither.

2. relies on=
 magical templates, which I regard as basically poisonous. Being able to kno=
w what a template represents unambiguously is one of the key strengths of IP=
FIX.

1. is half-magical, so half poisonous. The tim=
estamps carry no semantics identifying that they have to do with a window du=
ring which loss occurred. We could I suppose change the definition of ignore=
d*count to say "if present, timestamps in the same record identify the outer=
 bounding window of the loss event(s)" or similar.

=
I suggest 3. drop the timestamps completely, or 4. define loss window timest=
amps. 

Cheers, 

Brian

Sent from my iPhone

On 28.09.2011, at 18:06, Beno=
it Claise <bclaise@cisco.com>=
 wrote:

=

    Dear all,

    

    Let me restate what I put in my initial email:

    
Well. Two solutions:

      1. we duplicate all the IEs to have the exact correct semantic. 

         
      ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microsec=
onds|Nanoseconds]

      ... and potentially some more such as pre|post

          This brings multiple new dimensions to IE and will l=
ead to an
      explosion of IEs if we want to cover all the case

      2. the collector tests the possible combination of IE in the
      Options Template Record.

          For example, if the collector sees such an Options T=
emplate
      Record, it knows that this a "The Metering Process Reliability
      Statistics Options Template"
      
  observationDomainId (scope)
  meteringProcessId (scope)
  ignoredPacketTotalCount
  ignoredOctetTotalCount
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicr=
oseconds | observationTimeNanoseconds
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicr=
oseconds | observationTimeNanoseconds




    

    And I'm not sure what's the conclusion of this email thread is...

    

    Regards, Benoit.

    

      
On Sep 28, 2011, at 12:42 AM, Paul Aitken wrote:



      

        
Brian,



        

          
Hi, Paul, all,

I suppose I should state for the sake of completeness that this is the first=
 I've ever actually _thought_ about the MPRSO. I find the whole use case for=
 it rather dubious -- it presumes an MP with somehow trustworthy knowledge a=
bout packet loss, which is never the case, and relying on such information a=
t the collector side for anything other than entertainment purposes is fraug=
ht with peril -- so I saw the MAY on section 4 in 5101, was thankful it wasn=
't a MUST I had to fight against and/or simply ignore, and never looked back=
.

That said, it does make sense to fix, since it's there.

On Sep 27, 2011, at 10:25 PM, Paul Aitken wrote:



          

            
How do you know that the received template is a M=
PRSO?


          

          
Does it matter? Seriously, what is the difference b=
etween "an MPRSO" and "a template containing information about lost packets f=
or a given time interval, along with maybe some other information"? Do we ac=
tually want to require an MP to keep time interval information for loss? Wou=
ldn't those resources be better deployed not losing packets in the first pla=
ce? So let's say I want to report missing packets, but don't have informatio=
n about when I lost them. Do I have to throw a timestamp in there anyway in o=
rder for it to be "an MPRSO"?

I think these are arguments against having the timestamps at all (or to incl=
ude them, with a further instruction that they are optional).


        

        
When a MP knows that it failed to meter some packets,=
 it must have a way of reporting this which the CP can understand correctly.=
 So it matters in that the CP has to understand the implicit "lost traffic" s=
emantic and potentially take action, perhaps involving reports or alarm bell=
s.


      

      
That's an argument for the following template:

  observationDomainId {scope}
  meteringProcessId {scope}
  ignoredPacketTotalCount

Which, in my opinion, is a pretty good starting point.

You can add ignoredOctetTotalCount if you actually know it. Calculating it a=
t libpcap-based MPs like YAF, for example, would involve a little work and g=
enerate a bad number: you only get a guess from the kernel how many packets i=
t dropped and no information about how big they are. You can infer octet los=
s by looking at TCP sequence numbers but now we're back to clear overenginee=
ring I think. Maybe on ASIC or FPGA based measurement systems you get good t=
otal counters and can measure loss subtractively... But I personally wouldn'=
t waste the real estate on it unless it was a hard requirement.

Again, if you know the timestamps, you can add them. But for the general cas=
e as I see it, your fidelity per IE for the template in 5101 is as follows:

perfect:                observationDomainId {scope}
 (i hope you know this) meteringProcessId {scope}

reasonably good guess:  ignoredPacketTotalCount

poor to fair guess:     ignoredOctetTotalCount
 (dep. on HW support)

poor to good guess:     a start timestamp of indeterminate IE
 (dep. on HW support)   an end timestamp of indeterminate IE



      

        

          

            
   - must the fields be exactly in the specified o=
rder and no other combination in order to be a valid MPRSO?


          

          
This isn't a valid template recognition strategy in=
 IPFIX. At least, it hasn't been to date, and it's a bad idea to make it so.=
 IE-Doctors contains language meant to instruct IPFIX application authors to=
 refrain from specifying such magic templates.


        

        
Great; I'm pleased to hear it. Magic templates lead t=
o inflexible collectors, which in turn lead to bug reports against the EP?!




        

          

            
   - how do you know which of the observationTime=
* elements (or missingObservationWindowEdge elements) is the first and which=
 is the last?
       - only from their position in the template (so, field order and posit=
ion are crucial)
       - by comparing them (so field order and position aren't important)


          

          
Time intervals can be treated as a special case, he=
re, since time can generally be assumed to go in only one direction. "The ti=
me interval from A to B" is completely equivalent to "the time interval from=
 B to A", so one could argue order doesn't matter. (We don't argue that anyw=
here in IPFIX, to be true. But what do I do when I get a flow with an endTim=
e before the startTime?)


        

        
When the timestamp wraps. The time between 11pm and 1=
am is 2 hours, while the time between 1am and 11pm is 22 hours.


      

      
We don't have any timestamps that only carry time infor=
mation. They've all got implied dates (either based on the 1970 epoch for th=
e UNIX-like timestamps, or on either the NTP or the UNIX epoch for the 1305 t=
imestamps (we'll need to fix this in 5101bis), and there is no specified wra=
pping behavior as yet. You only hit this problem in 2038, then, and when you=
 do, you've got bigger problems.



      

        

          

            
Suppose a mediator adds, removes, or re-orders th=
e fields.
   - does this invalidate the MPRSO?
   - how does a mediator know not to do this?
   - how does the collector cope if a mediator does?


          

          
These questions seem to apply only to the case wher=
e MPRSO is magical. I'm trying to define it such that it isn't.


        

        
I'm trying to get to the core of what constitues a va=
lid, recognisable MPRSO. Put another way, what's the closest thing to an MPR=
SO that isn't an MPRSO?


      

      
I'm saying that it doesn't matter. Sure, 5101bis should=
 give recommendations for the template an exporting process uses for this in=
formation, but any time a CP sees a template that's scoped to something that=
 ID's an MP that contains loss counter IEs, it's an MPRSO.=20



      

        
If I use ignoredPacketTotalCount and ignoredOctetTota=
lCount in another template, does it become an MPRSO?


      

      
Depends. Are you binding them to a scope that identifie=
s a metering process? You could also export them in a flow or "flexible flow=
"/flow aggregate, at which point you're giving very detailed error informati=
on. And the collector can infer whatever it wants about total reliability ba=
sed on _that_...



      

        
If we ignore what is and what isn't an MPRSO for the m=
oment, how exactly should a MP tell a CP about the traffic it knows it didn'=
t meter?


      

      
Using something much like the MPRSO as defined by 5101.=
.. I'm just trying to lead us away from thinking of a "bright line" between M=
PRSO and not-MPRSO, because=20



      

        

          

            
The change to "missingObservationWindowEdge" is s=
imply a rename of observationTime. I don't see that it adds anything.


          

          
observationTime already has a meaning. "This Inform=
ation Element specifies the absolute time in seconds of an observation." In o=
ther words, "I saw the thing I'm talking about in this record at the specifi=
ed time". It has never to date been specified in such a way that it means "I=
 saw the thing I'm talking about in this record at the specified time, unles=
s the record contains two observationTimes, in which case I saw the thing in=
 the time interval between those two things".


        

        
Then you're saying that it's invalid to have two diff=
erent observationTime values in a flow record, because you can't observe an e=
vent at two different times.


      

      
Well.... yes, this is a bit ambiguous.



      

        
Thinking about it some more, I suppose this reports m=
ultiple instances of the observation with an AND semantic: I saw this at T1 A=
ND at T2 (since other semantics don't make sense).
Think if these were interfaces: the meaning would be "observed at int1 and i=
nt2", rather than "observed from int1 to int2".
So I've convinced myself to agree that 2 x observationTime don't make sense.=



      

      
(I'm trying to think of cases where it would be, but I d=
on't think any are illustrative for this discussion...)



      

        

          
missingObservationWindowEdge means "there is missin=
g information within an interval described between this IE and the other ide=
ntical IE in the record". If we keep the MPRSO defined as it is (and fix it o=
nly by dropping in , missingObservationWindowStartSeconds and missingObserva=
tionWindowEndSeconds, since it's more IPFIXish, but there was concern voiced=
 in this thread about IE space explosion, so I figured we could exploit the n=
ature of time and cut down on the IEs required by half.

The advantage of a new IE is that it isn't overloaded, but more importantly t=
hat it does not lead to an ambiguous interpretation of the entire template a=
t the collector.


        

        
Unfortunately WindowEdge is ambiguous in the wrap cas=
e, whereas start and end aren't.


      

      
(see above on wrapping)



      

        

        

          

            
A long basicList isn't the right solution because=

   - various list lengths mean there are multiple possible templates making t=
he detection of the MPRSO a little more difficult
      ie, it's no longer a fixed template, nor a combination of a few possib=
ilities, but a great many different possible templates.
   - there are two different semantics for the start and end of the window, s=
o it's actually an ordered list of pairs ie a subTemplateList.
Lists can have zero elements. However, if you want to report that nothing wa=
s lost, the ignored*Count =3D 0 report should indicate the start and end of t=
he 100% period. A list length of zero doesn't tell when stuff was or was not=
 lost - so it's of limited usefulness, unless perhaps as a total figure? Aga=
in, see questions above about what is / is not a valid MPRSO.


          

          
I withdraw my basicList comment; it was essentially=
 just "thinking aloud", and I didn't actually intend to include a mention of=
 it in the 5101bis MPRSO. 1. It doesn't really add anything to the original i=
ntent of the MPRSO, and 2. adding it in 5101bis would cause 5101bis to have a=
 normative dependency on 6313, which is a terrible idea.


        

        
+1. I already discussed with Benoit about using an or=
dered list or STL of observationTime, and discounted it for this reason.


      

      
Yay! At least we emphatically agree on _something_. ;)

Cheers,

Brian



      

        

          

            
On 27/09/11 18:30, Andrew Feren wrote:


            

              
Hi Brian,

Well stated.

Additional comments inline

On 09/27/2011 12:15 PM, Brian Trammell wrote:


              

                
Greetings, all,

This is a little bit of an abuse of the ordering of IEs, in my opinion, and o=
f the general rule that only IEs, and the scope in which they are defined, c=
arry semantics. Even for templates which are defined within Standards Track R=
FCs, the records defined by the template should be decipherable without refe=
rence to the RFC. Put another way, we should not define magical templates, a=
nd this template as proposed looks pretty magical.


              

              
Yes, a black magic sort of magical.  We have be=
en discussing this proposed change in the office and coming to the same conc=
lusion.


              

                
Without reading the text of this thread, and f=
ollowing basically everything we've ever said about multiple IEs in a record=
, I would interpret a record matching this template as follows:

For the metering process A and observation domain B:
N packets were ignored; these contained a total of M octets.
The first observation at this metering process was at time T0.
The second observation at this metering process was at time T1.


              

              
This was exactly how I interpreted this templat=
e until I read the updated draft and saw the bit about "the Collecting Proce=
ss MUST determine which is the oldest and the most recent timestamp in order=
 the determine the right semantic ...."



              

                
This is quite far from the stated intention. I=
 would strongly suggest that we not so lightly give up on "templates should b=
e unambiguously understandable" requirement, even if the exception itself li=
ves in the core protocol document.

I would suggest, if you want to do a multiple IE solution here, you define s=
omething like missingObservationWindowEdge, and have two of them:

  observationDomainId {scope}
  meteringProcessId {scope}
  ignoredPacketTotalCount
  ignoredOctetTotalCount
  missingObservationWindowEdge
  missingObservationWindowEdge

This has the advantage that you can have a long basicList of window edges in=
 order to define multiple missing observation windows; each edge pair is a l=
oss window.


              

              
I like this suggestion, and I have a few additi=
onal thoughts.

Perhaps the basic list of edge times should either be limited to only one pa=
ir or the ignored*TotalCount IEs needs to be in a basiclist with N entries t=
oo.

How about observationWindowEdge instead (no "missing") to be more generally u=
seful.

I think a list of time edges also works neatly when sending this template at=
 regular intervals (which SHOULD be done).  When the ignored*TotalCount IEs a=
re zero, an empty list makes sense for edge times.




              

                
Seconds suffice for these, I think. You might=
 want to do one in milliseconds. But if you have the resources to calculate y=
our packet loss window to nanosecond precision without having the resources t=
o not lose packets, I humbly submit you've picked the wrong engineering trad=
eoffs. :)


              

              
Unless window edge isn't defined specifically f=
or "missing" values.  Then the higher precision timestamps might have some u=
se.

-Andrew


              

                
Best regards,

Brian

On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote:



                

                  
Yes, this makes sense.

I gave this some thought and I don't have a better suggestion.  I also agree=
 that even though the flow[Start|End]* collection of IEs conveniently has on=
e IE for both first and last, observationTime* is the more correct choice he=
re.

-Andrew

On 09/22/2011 03:54 AM, Benoit Claise wrote:


                  

                    
Hi Andrew,


                    

                      
Hi Benoit,

I had the same thought about using

322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds

The problem is that you need two timestamps in the same record (first and la=
st).  How does that work with the above?


                    

                    
Excellent question. We debated this quest=
ion with Paul Aitken recently.
Let me rephrase the question slightly differently: how does the collector de=
termine that this is a "The Metering Process Reliability Statistics Options T=
emplate", and understands the semantic of the two counters?
Well. Two solutions:
1. we duplicate all the IEs to have the exact correct semantic.
    ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microsecon=
ds|Nanoseconds] ... and potentially some more such as pre|post
    This brings multiple new dimensions to IE and will lead to an explosion o=
f IEs if we want to cover all the case
2. the collector tests the possible combination of IE in the Options Templat=
e Record.
    For example, if the collector sees such an Options Template Record, it k=
nows that this a "The Metering Process Reliability Statistics Options Templa=
te"
  observationDomainId (scope)
  meteringProcessId (scope)

  ignoredPacketTotalCount
  ignoredOctetTotalCount
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicr=
oseconds | observationTimeNanoseconds
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicr=
oseconds | observationTimeNanoseconds


While the solution 2 is not perfect, this was the chosen track.

Does it make sense?

Regards, Benoit


                    

                      
-Andrew

On 09/21/2011 07:11 PM, Benoit Claise wrote:


                      

                        
Hi Gerhard,

Thanks for your reply.
See in line.


                        

                          
Hi Benoit,

See comments inline.

On 20.09.2011 16:19, Benoit Claise wrote:


                          

                            
Dear all,

[this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO DO -=
>   "time first flow dropped" and "time last flow dropped" inconsistency.=
  See the discussion on the list.]

Paul Aitken discovered this issue.,

>=46rom [RFC5101], section 4.3. The Exporting Process Reliability Statist=
ics Option Template

time first flow dropped
                        The timestamp of the first Flow was dropped by
                        the Metering Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

time last flow dropped
                        The timestamp of the last IP packet that was
                        ignored by the Metering Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.


Firstly, these definitions are inconsistent since the names and the first de=
finition say "flow" while the second definition says "IP packet". Obviously "=
IP packet" !=3D "flow" :-o

Secondly, "The timestamp of the first Flow was dropped by the Metering Proce=
ss." is bad English: at least it's missing "that".

Thirdly, the section 4.2 doesn't take into account a metering process id. In=
deed, what if we have multiple caches on the exporter?

Here is a proposal for 4.2 and 4.3. The underlined parts are new

4.2.  The Metering Process Reliability Statistics Option Template



   The Metering Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [
RFC5102
]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.



   meteringProcessId (*)
                           The identifier of the Metering Process for
                           which lack of reliability is reported.  There
                           This Information Element MUST be defined as a
                           Scope Field.


   ignoredPacketTotalCount
                           The total number of IP packets that the
                           Metering Process did not process.

   ignoredOctetTotalCount
                           The total number of octets in observed IP
                           packets that the Metering Process did not
                           process.

   time first
packet
ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last
packet
ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.



                          

                          
I do not find these IEs in RFC5102.=



                        

                        
Which ones?  flowEndMilliseconds, flo=
wEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds
There are in http://www.iana.org/assignments/ipfix/ipfix.xml
However, re-reading
   time first packet
ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last
packet
ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.

And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd=
" timestamp IE,
I now believe that we should be using this series of IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds



                        

                          

                            
4.3.  The Exporting Process Relia=
bility Statistics Option Template


   The Exporting Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Exporting process.  It SHOULD contain the following Information
   Elements that are defined in [
RFC5102
]:

   Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [
RFC5102
] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.

   notSentFlowTotalCount
                        The total number of Flows that were generated by
                        the Metering Process and dropped by the Metering
                        Process or by the Exporting Process instead of
                        being sent to the Collecting Process.

   notSentPacketTotalCount
                        The total number of packets in Flow Records that
                        were generated by the Metering Process and
                        dropped by the Metering Process or by the
                        Exporting Process instead of being sent to the
                        Collecting Process.

   notSentOctetTotalCount
                        The total number of octets in packets in Flow
                        Records that were generated by the Metering
                        Process and dropped by the Metering Process or
                        by the Exporting Process instead of being sent
                        to the Collecting Process.

   time first flow dropped

                      The time at which the first Flow Record was dropped by=

                        the
Exporting Process.
  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

   time last flow dropped

The time at which the last Flow Record was
                        dropped by the Exporting Process
.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.



                          

                          
Again, I do not find these IEs in R=
FC5102.


                        

                        
Same remark, I believe we should be u=
sing for the two previous IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds
Regards, Benoit.


                        

                          

                            
   The Exporting Process SHOULD e=
xport the Data Record specified by the
   Exporting Process Reliability Statistics Option Template on a regular
   basis or based on some export policy.  This periodicity or export
   policy SHOULD be configurable.





(*) regarding the meteringProcessId, we were hesitating between the metering=
ProcessId and the cache id
1. there is a meteringProcessId in IPFIX IANA while there is no cache id


                          

                          
meteringProcessId should do the job=
.



                          

                            
2. if the IPFIX exporter is confi=
gured from [IPFIX-CONF], what should be the value in meteringProcessId?
    [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
    =46rom figure 1 and 2, it seems that there is a one to one matching betw=
een the cache and the metering process.
    If this is the case, a solution could be to add a meteringProcess inside=
 the cache in the figure 12 in [IPFIX-CONF] below


                          

                          
See reply to Pauls mail.

Regards,
Gerhard



                          

                            
4.3.  Cache Class


    +-----------------------------------+
    | Cache                             |
    +-----------------------------------+        1 +------------------+
    | name                              |<>--------| immediateCache/  |=

    | dataRecords {readOnly}            |          | timeoutCache/    |
    | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
    |                                   |          | permanentCache   |
    |                                   |          +------------------+
    |                                   |
    |                                   |     0..* +------------------+
    |                                   |--------->| ExportingProcess |
    +-----------------------------------+          +------------------+

                          Figure 12: Cache class

What do you think? Do you see another way?

Regards, Paul&   Benoit.


_______________________________________________
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


                    

                  

                  
___________________________________________=
____
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


    

    

 =20


=

--Apple-Mail-1--381155689--

From bclaise@cisco.com  Thu Sep 29 03:18:24 2011
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 7F2E621F8CA7 for ; Thu, 29 Sep 2011 03:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.878
X-Spam-Level: 
X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_75=0.6]
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 o+d+6xTYBETB for ; Thu, 29 Sep 2011 03:18:20 -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 895AB21F8C82 for ; Thu, 29 Sep 2011 03:18:19 -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 p8T9xqV3012382; Thu, 29 Sep 2011 11:59:52 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8T9xpKR018932; Thu, 29 Sep 2011 11:59:51 +0200 (CEST)
Message-ID: <4E844197.6010103@cisco.com>
Date: Thu, 29 Sep 2011 11:59:51 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Brian Trammell 
References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> <4E7AA240.4020506@plixer.com> <4E7AE9D1.9090002@cisco.com>  <4E82081B.8040806@plixer.com> <4E823130.6000505@cisco.com>  <4E82513F.9020604@cisco.com>  <4E834617.3030805@cisco.com> <10BEDBFE-B363-4B40-9202-B43F89F262D2@tik.ee.ethz.ch>
In-Reply-To: <10BEDBFE-B363-4B40-9202-B43F89F262D2@tik.ee.ethz.ch>
Content-Type: multipart/alternative; boundary="------------060606000606050109020607"
Cc: "ipfix@ietf.org" 
Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped
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, 29 Sep 2011 10:18:24 -0000

This is a multi-part message in MIME format.
--------------060606000606050109020607
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 28/09/2011 18:47, Brian Trammell wrote:
> Hi, Benoit, all,
>
> Conclusion (from my side): neither.
>
> 2. relies on magical templates, which I regard as basically poisonous. 
> Being able to know what a template represents unambiguously is one of 
> the key strengths of IPFIX.
Agreed.
>
> 1. is half-magical, so half poisonous.
And again agreed.

Out of the bad solutions 1 and 2, we have to chose one.
> The timestamps carry no semantics identifying that they have to do 
> with a window during which loss occurred. We could I suppose change 
> the definition of ignored*count to say "if present, timestamps in the 
> same record identify the outer bounding window of the loss event(s)" 
> or similar.
>
> I suggest 3. drop the timestamps completely,
Sure, the IPFIX specifications will look fine, but we're postponing the 
problems.
> or 4. define loss window timestamps.
Proposal 5.  Keep for a single point in time observation

    322    observationTimeSeconds
    323    observationTimeMilliseconds
    324    observationTimeMicroseconds
    325    observationTimeNanoseconds

      Have to new series of observation times


    .           observationStartTimeSeconds
    .           observationStartTimeMilliseconds
    .           observationStartTimeMicroseconds
    .           observationStartTimeNanoseconds

    .           observationEndTimeSeconds
    .           observationEndTimeMilliseconds
    .           observationEndTimeMicroseconds
    .           observationEndTimeNanoseconds

Regards, Benoit.


>
> Cheers,
>
> Brian
>
> Sent from my iPhone
>
> On 28.09.2011, at 18:06, Benoit Claise  > wrote:
>
>> Dear all,
>>
>> Let me restate what I put in my initial email:
>>
>>     Well. Two solutions:
>>     1. we duplicate all the IEs to have the exact correct semantic.
>>        
>>     ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds]
>>     ... and potentially some more such as pre|post
>>         This brings multiple new dimensions to IE and will lead to an
>>     explosion of IEs if we want to cover all the case
>>     2. the collector tests the possible combination of IE in the
>>     Options Template Record.
>>         For example, if the collector sees such an Options Template
>>     Record, it knows that this a "The Metering Process Reliability
>>     Statistics Options Template"
>>
>>        observationDomainId (scope)
>>        meteringProcessId (scope)_
>>     _   ignoredPacketTotalCount
>>        ignoredOctetTotalCount
>>        observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
>>        observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
>>
>>
>>
>> And I'm not sure what's the conclusion of this email thread is...
>>
>> Regards, Benoit.
>>> On Sep 28, 2011, at 12:42 AM, Paul Aitken wrote:
>>>
>>>> Brian,
>>>>
>>>>> Hi, Paul, all,
>>>>>
>>>>> I suppose I should state for the sake of completeness that this is the first I've ever actually _thought_ about the MPRSO. I find the whole use case for it rather dubious -- it presumes an MP with somehow trustworthy knowledge about packet loss, which is never the case, and relying on such information at the collector side for anything other than entertainment purposes is fraught with peril -- so I saw the MAY on section 4 in 5101, was thankful it wasn't a MUST I had to fight against and/or simply ignore, and never looked back.
>>>>>
>>>>> That said, it does make sense to fix, since it's there.
>>>>>
>>>>> On Sep 27, 2011, at 10:25 PM, Paul Aitken wrote:
>>>>>
>>>>>> How do you know that the received template is a MPRSO?
>>>>> Does it matter? Seriously, what is the difference between "an MPRSO" and "a template containing information about lost packets for a given time interval, along with maybe some other information"? Do we actually want to require an MP to keep time interval information for loss? Wouldn't those resources be better deployed not losing packets in the first place? So let's say I want to report missing packets, but don't have information about when I lost them. Do I have to throw a timestamp in there anyway in order for it to be "an MPRSO"?
>>>>>
>>>>> I think these are arguments against having the timestamps at all (or to include them, with a further instruction that they are optional).
>>>> When a MP knows that it failed to meter some packets, it must have a way of reporting this which the CP can understand correctly. So it matters in that the CP has to understand the implicit "lost traffic" semantic and potentially take action, perhaps involving reports or alarm bells.
>>> That's an argument for the following template:
>>>
>>>    observationDomainId {scope}
>>>    meteringProcessId {scope}
>>>    ignoredPacketTotalCount
>>>
>>> Which, in my opinion, is a pretty good starting point.
>>>
>>> You can add ignoredOctetTotalCount if you actually know it. Calculating it at libpcap-based MPs like YAF, for example, would involve a little work and generate a bad number: you only get a guess from the kernel how many packets it dropped and no information about how big they are. You can infer octet loss by looking at TCP sequence numbers but now we're back to clear overengineering I think. Maybe on ASIC or FPGA based measurement systems you get good total counters and can measure loss subtractively... But I personally wouldn't waste the real estate on it unless it was a hard requirement.
>>>
>>> Again, if you know the timestamps, you can add them. But for the general case as I see it, your fidelity per IE for the template in 5101 is as follows:
>>>
>>> perfect:                observationDomainId {scope}
>>>   (i hope you know this) meteringProcessId {scope}
>>>
>>> reasonably good guess:  ignoredPacketTotalCount
>>>
>>> poor to fair guess:     ignoredOctetTotalCount
>>>   (dep. on HW support)
>>>
>>> poor to good guess:     a start timestamp of indeterminate IE
>>>   (dep. on HW support)   an end timestamp of indeterminate IE
>>>
>>>>>>     - must the fields be exactly in the specified order and no other combination in order to be a valid MPRSO?
>>>>> This isn't a valid template recognition strategy in IPFIX. At least, it hasn't been to date, and it's a bad idea to make it so. IE-Doctors contains language meant to instruct IPFIX application authors to refrain from specifying such magic templates.
>>>> Great; I'm pleased to hear it. Magic templates lead to inflexible collectors, which in turn lead to bug reports against the EP?!
>>>>
>>>>
>>>>>>     - how do you know which of the observationTime* elements (or missingObservationWindowEdge elements) is the first and which is the last?
>>>>>>         - only from their position in the template (so, field order and position are crucial)
>>>>>>         - by comparing them (so field order and position aren't important)
>>>>> Time intervals can be treated as a special case, here, since time can generally be assumed to go in only one direction. "The time interval from A to B" is completely equivalent to "the time interval from B to A", so one could argue order doesn't matter. (We don't argue that anywhere in IPFIX, to be true. But what do I do when I get a flow with an endTime before the startTime?)
>>>> When the timestamp wraps. The time between 11pm and 1am is 2 hours, while the time between 1am and 11pm is 22 hours.
>>> We don't have any timestamps that only carry time information. They've all got implied dates (either based on the 1970 epoch for the UNIX-like timestamps, or on either the NTP or the UNIX epoch for the 1305 timestamps (we'll need to fix this in 5101bis), and there is no specified wrapping behavior as yet. You only hit this problem in 2038, then, and when you do, you've got bigger problems.
>>>
>>>>>> Suppose a mediator adds, removes, or re-orders the fields.
>>>>>>     - does this invalidate the MPRSO?
>>>>>>     - how does a mediator know not to do this?
>>>>>>     - how does the collector cope if a mediator does?
>>>>> These questions seem to apply only to the case where MPRSO is magical. I'm trying to define it such that it isn't.
>>>> I'm trying to get to the core of what constitues a valid, recognisable MPRSO. Put another way, what's the closest thing to an MPRSO that isn't an MPRSO?
>>> I'm saying that it doesn't matter. Sure, 5101bis should give recommendations for the template an exporting process uses for this information, but any time a CP sees a template that's scoped to something that ID's an MP that contains loss counter IEs, it's an MPRSO.
>>>
>>>> If I use ignoredPacketTotalCount and ignoredOctetTotalCount in another template, does it become an MPRSO?
>>> Depends. Are you binding them to a scope that identifies a metering process? You could also export them in a flow or "flexible flow"/flow aggregate, at which point you're giving very detailed error information. And the collector can infer whatever it wants about total reliability based on _that_...
>>>
>>>> If we ignore what is and what isn't an MPRSO for the moment, how exactly should a MP tell a CP about the traffic it knows it didn't meter?
>>> Using something much like the MPRSO as defined by 5101... I'm just trying to lead us away from thinking of a "bright line" between MPRSO and not-MPRSO, because
>>>
>>>>>> The change to "missingObservationWindowEdge" is simply a rename of observationTime. I don't see that it adds anything.
>>>>> observationTime already has a meaning. "This Information Element specifies the absolute time in seconds of an observation." In other words, "I saw the thing I'm talking about in this record at the specified time". It has never to date been specified in such a way that it means "I saw the thing I'm talking about in this record at the specified time, unless the record contains two observationTimes, in which case I saw the thing in the time interval between those two things".
>>>> Then you're saying that it's invalid to have two different observationTime values in a flow record, because you can't observe an event at two different times.
>>> Well.... yes, this is a bit ambiguous.
>>>
>>>> Thinking about it some more, I suppose this reports multiple instances of the observation with an AND semantic: I saw this at T1 AND at T2 (since other semantics don't make sense).
>>>> Think if these were interfaces: the meaning would be "observed at int1 and int2", rather than "observed from int1 to int2".
>>>> So I've convinced myself to agree that 2 x observationTime don't make sense.
>>> (I'm trying to think of cases where it would be, but I don't think any are illustrative for this discussion...)
>>>
>>>>> missingObservationWindowEdge means "there is missing information within an interval described between this IE and the other identical IE in the record". If we keep the MPRSO defined as it is (and fix it only by dropping in , missingObservationWindowStartSeconds and missingObservationWindowEndSeconds, since it's more IPFIXish, but there was concern voiced in this thread about IE space explosion, so I figured we could exploit the nature of time and cut down on the IEs required by half.
>>>>>
>>>>> The advantage of a new IE is that it isn't overloaded, but more importantly that it does not lead to an ambiguous interpretation of the entire template at the collector.
>>>> Unfortunately WindowEdge is ambiguous in the wrap case, whereas start and end aren't.
>>> (see above on wrapping)
>>>
>>>>>> A long basicList isn't the right solution because
>>>>>>     - various list lengths mean there are multiple possible templates making the detection of the MPRSO a little more difficult
>>>>>>        ie, it's no longer a fixed template, nor a combination of a few possibilities, but a great many different possible templates.
>>>>>>     - there are two different semantics for the start and end of the window, so it's actually an ordered list of pairs ie a subTemplateList.
>>>>>> Lists can have zero elements. However, if you want to report that nothing was lost, the ignored*Count = 0 report should indicate the start and end of the 100% period. A list length of zero doesn't tell when stuff was or was not lost - so it's of limited usefulness, unless perhaps as a total figure? Again, see questions above about what is / is not a valid MPRSO.
>>>>> I withdraw my basicList comment; it was essentially just "thinking aloud", and I didn't actually intend to include a mention of it in the 5101bis MPRSO. 1. It doesn't really add anything to the original intent of the MPRSO, and 2. adding it in 5101bis would cause 5101bis to have a normative dependency on 6313, which is a terrible idea.
>>>> +1. I already discussed with Benoit about using an ordered list or STL of observationTime, and discounted it for this reason.
>>> Yay! At least we emphatically agree on _something_. ;)
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>>>>> On 27/09/11 18:30, Andrew Feren wrote:
>>>>>>> Hi Brian,
>>>>>>>
>>>>>>> Well stated.
>>>>>>>
>>>>>>> Additional comments inline
>>>>>>>
>>>>>>> On 09/27/2011 12:15 PM, Brian Trammell wrote:
>>>>>>>> Greetings, all,
>>>>>>>>
>>>>>>>> This is a little bit of an abuse of the ordering of IEs, in my opinion, and of the general rule that only IEs, and the scope in which they are defined, carry semantics. Even for templates which are defined within Standards Track RFCs, the records defined by the template should be decipherable without reference to the RFC. Put another way, we should not define magical templates, and this template as proposed looks pretty magical.
>>>>>>> Yes, a black magic sort of magical.  We have been discussing this proposed change in the office and coming to the same conclusion.
>>>>>>>> Without reading the text of this thread, and following basically everything we've ever said about multiple IEs in a record, I would interpret a record matching this template as follows:
>>>>>>>>
>>>>>>>> For the metering process A and observation domain B:
>>>>>>>> N packets were ignored; these contained a total of M octets.
>>>>>>>> The first observation at this metering process was at time T0.
>>>>>>>> The second observation at this metering process was at time T1.
>>>>>>> This was exactly how I interpreted this template until I read the updated draft and saw the bit about "the Collecting Process MUST determine which is the oldest and the most recent timestamp in order the determine the right semantic ...."
>>>>>>>
>>>>>>>> This is quite far from the stated intention. I would strongly suggest that we not so lightly give up on "templates should be unambiguously understandable" requirement, even if the exception itself lives in the core protocol document.
>>>>>>>>
>>>>>>>> I would suggest, if you want to do a multiple IE solution here, you define something like missingObservationWindowEdge, and have two of them:
>>>>>>>>
>>>>>>>>    observationDomainId {scope}
>>>>>>>>    meteringProcessId {scope}
>>>>>>>>    ignoredPacketTotalCount
>>>>>>>>    ignoredOctetTotalCount
>>>>>>>>    missingObservationWindowEdge
>>>>>>>>    missingObservationWindowEdge
>>>>>>>>
>>>>>>>> This has the advantage that you can have a long basicList of window edges in order to define multiple missing observation windows; each edge pair is a loss window.
>>>>>>> I like this suggestion, and I have a few additional thoughts.
>>>>>>>
>>>>>>> Perhaps the basic list of edge times should either be limited to only one pair or the ignored*TotalCount IEs needs to be in a basiclist with N entries too.
>>>>>>>
>>>>>>> How about observationWindowEdge instead (no "missing") to be more generally useful.
>>>>>>>
>>>>>>> I think a list of time edges also works neatly when sending this template at regular intervals (which SHOULD be done).  When the ignored*TotalCount IEs are zero, an empty list makes sense for edge times.
>>>>>>>
>>>>>>>
>>>>>>>> Seconds suffice for these, I think. You might want to do one in milliseconds. But if you have the resources to calculate your packet loss window to nanosecond precision without having the resources to not lose packets, I humbly submit you've picked the wrong engineering tradeoffs. :)
>>>>>>> Unless window edge isn't defined specifically for "missing" values.  Then the higher precision timestamps might have some use.
>>>>>>>
>>>>>>> -Andrew
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Brian
>>>>>>>>
>>>>>>>> On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote:
>>>>>>>>
>>>>>>>>> Yes, this makes sense.
>>>>>>>>>
>>>>>>>>> I gave this some thought and I don't have a better suggestion.  I also agree that even though the flow[Start|End]* collection of IEs conveniently has one IE for both first and last, observationTime* is the more correct choice here.
>>>>>>>>>
>>>>>>>>> -Andrew
>>>>>>>>>
>>>>>>>>> On 09/22/2011 03:54 AM, Benoit Claise wrote:
>>>>>>>>>> Hi Andrew,
>>>>>>>>>>> Hi Benoit,
>>>>>>>>>>>
>>>>>>>>>>> I had the same thought about using
>>>>>>>>>>>
>>>>>>>>>>> 322    observationTimeSeconds
>>>>>>>>>>> 323    observationTimeMilliseconds
>>>>>>>>>>> 324    observationTimeMicroseconds
>>>>>>>>>>> 325    observationTimeNanoseconds
>>>>>>>>>>>
>>>>>>>>>>> The problem is that you need two timestamps in the same record (first and last).  How does that work with the above?
>>>>>>>>>> Excellent question. We debated this question with Paul Aitken recently.
>>>>>>>>>> Let me rephrase the question slightly differently: how does the collector determine that this is a "The Metering Process Reliability Statistics Options Template", and understands the semantic of the two counters?
>>>>>>>>>> Well. Two solutions:
>>>>>>>>>> 1. we duplicate all the IEs to have the exact correct semantic.
>>>>>>>>>>      ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] ... and potentially some more such as pre|post
>>>>>>>>>>      This brings multiple new dimensions to IE and will lead to an explosion of IEs if we want to cover all the case
>>>>>>>>>> 2. the collector tests the possible combination of IE in the Options Template Record.
>>>>>>>>>>      For example, if the collector sees such an Options Template Record, it knows that this a "The Metering Process Reliability Statistics Options Template"
>>>>>>>>>>    observationDomainId (scope)
>>>>>>>>>>    meteringProcessId (scope)
>>>>>>>>>>
>>>>>>>>>>    ignoredPacketTotalCount
>>>>>>>>>>    ignoredOctetTotalCount
>>>>>>>>>>    observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
>>>>>>>>>>    observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> While the solution 2 is not perfect, this was the chosen track.
>>>>>>>>>>
>>>>>>>>>> Does it make sense?
>>>>>>>>>>
>>>>>>>>>> Regards, Benoit
>>>>>>>>>>> -Andrew
>>>>>>>>>>>
>>>>>>>>>>> On 09/21/2011 07:11 PM, Benoit Claise wrote:
>>>>>>>>>>>> Hi Gerhard,
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for your reply.
>>>>>>>>>>>> See in line.
>>>>>>>>>>>>> Hi Benoit,
>>>>>>>>>>>>>
>>>>>>>>>>>>> See comments inline.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 20.09.2011 16:19, Benoit Claise wrote:
>>>>>>>>>>>>>> Dear all,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO DO ->    "time first flow dropped" and "time last flow dropped" inconsistency.  See the discussion on the list.]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Paul Aitken discovered this issue.,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> > From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> time first flow dropped
>>>>>>>>>>>>>>                          The timestamp of the first Flow was dropped by
>>>>>>>>>>>>>>                          the Metering Process.  For this timestamp, any
>>>>>>>>>>>>>>                          of the "flowStart" timestamp Information
>>>>>>>>>>>>>>                          Elements flowStartMilliseconds,
>>>>>>>>>>>>>>                          flowStartMicroseconds, flowStartNanoseconds, and
>>>>>>>>>>>>>>                          flowStartDeltaMicroseconds can be used.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> time last flow dropped
>>>>>>>>>>>>>>                          The timestamp of the last IP packet that was
>>>>>>>>>>>>>>                          ignored by the Metering Process.  For this
>>>>>>>>>>>>>>                          timestamp, any of the "flowEnd" timestamp
>>>>>>>>>>>>>>                          Information Elements flowEndMilliseconds,
>>>>>>>>>>>>>>                          flowEndMicroseconds, flowEndNanoseconds, and
>>>>>>>>>>>>>>                          flowEndDeltaMicroseconds can be used.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here is a proposal for 4.2 and 4.3. The underlined parts are new
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 4.2.  The Metering Process Reliability Statistics Option Template
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     The Metering Process Reliability Option Template specifies the
>>>>>>>>>>>>>>     structure of a Data Record for reporting lack of reliability in the
>>>>>>>>>>>>>>     Metering Process.  It SHOULD contain the following Information
>>>>>>>>>>>>>>     Elements that are defined in [
>>>>>>>>>>>>>> RFC5102
>>>>>>>>>>>>>> ]:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     observationDomainId
>>>>>>>>>>>>>>                             An identifier of an Observation Domain that
>>>>>>>>>>>>>>                             is locally unique to the Exporting Process.
>>>>>>>>>>>>>>                             This Information Element MUST be defined as a
>>>>>>>>>>>>>>                             Scope Field.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     meteringProcessId (*)
>>>>>>>>>>>>>>                             The identifier of the Metering Process for
>>>>>>>>>>>>>>                             which lack of reliability is reported.  There
>>>>>>>>>>>>>>                             This Information Element MUST be defined as a
>>>>>>>>>>>>>>                             Scope Field.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     ignoredPacketTotalCount
>>>>>>>>>>>>>>                             The total number of IP packets that the
>>>>>>>>>>>>>>                             Metering Process did not process.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     ignoredOctetTotalCount
>>>>>>>>>>>>>>                             The total number of octets in observed IP
>>>>>>>>>>>>>>                             packets that the Metering Process did not
>>>>>>>>>>>>>>                             process.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     time first
>>>>>>>>>>>>>> packet
>>>>>>>>>>>>>> ignored
>>>>>>>>>>>>>>                             The timestamp of the first IP packet that was
>>>>>>>>>>>>>>                             ignored by the Metering Process.  For this
>>>>>>>>>>>>>>                             timestamp, any of the "flowStart" timestamp
>>>>>>>>>>>>>>                             Information Elements flowStartMilliseconds,
>>>>>>>>>>>>>>                             flowStartMicroseconds, flowStartNanoseconds,
>>>>>>>>>>>>>>                             and flowStartDeltaMicroseconds can be used.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     time last
>>>>>>>>>>>>>> packet
>>>>>>>>>>>>>> ignored
>>>>>>>>>>>>>>                             The timestamp of the last IP packet that was
>>>>>>>>>>>>>>                             ignored by the Metering Process.  For this
>>>>>>>>>>>>>>                             timestamp, any of the "flowEnd" timestamp
>>>>>>>>>>>>>>                             Information Elements flowEndMilliseconds,
>>>>>>>>>>>>>>                             flowEndMicroseconds, flowEndNanoseconds, and
>>>>>>>>>>>>>>                             flowEndDeltaMicroseconds can be used.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> I do not find these IEs in RFC5102.
>>>>>>>>>>>> Which ones?  flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds
>>>>>>>>>>>> There are inhttp://www.iana.org/assignments/ipfix/ipfix.xml
>>>>>>>>>>>> However, re-reading
>>>>>>>>>>>>     time first packet
>>>>>>>>>>>> ignored
>>>>>>>>>>>>                             The timestamp of the first IP packet that was
>>>>>>>>>>>>                             ignored by the Metering Process.  For this
>>>>>>>>>>>>                             timestamp, any of the "flowStart" timestamp
>>>>>>>>>>>>                             Information Elements flowStartMilliseconds,
>>>>>>>>>>>>                             flowStartMicroseconds, flowStartNanoseconds,
>>>>>>>>>>>>                             and flowStartDeltaMicroseconds can be used.
>>>>>>>>>>>>
>>>>>>>>>>>>     time last
>>>>>>>>>>>> packet
>>>>>>>>>>>> ignored
>>>>>>>>>>>>                             The timestamp of the last IP packet that was
>>>>>>>>>>>>                             ignored by the Metering Process.  For this
>>>>>>>>>>>>                             timestamp, any of the "flowEnd" timestamp
>>>>>>>>>>>>                             Information Elements flowEndMilliseconds,
>>>>>>>>>>>>                             flowEndMicroseconds, flowEndNanoseconds, and
>>>>>>>>>>>>                             flowEndDeltaMicroseconds can be used.
>>>>>>>>>>>>
>>>>>>>>>>>> Andhttp://www.iana.org/assignments/ipfix/ipfix.xml  for the "flowEnd" timestamp IE,
>>>>>>>>>>>> I now believe that we should be using this series of IEs
>>>>>>>>>>>> 322    observationTimeSeconds
>>>>>>>>>>>> 323    observationTimeMilliseconds
>>>>>>>>>>>> 324    observationTimeMicroseconds
>>>>>>>>>>>> 325    observationTimeNanoseconds
>>>>>>>>>>>>
>>>>>>>>>>>>>> 4.3.  The Exporting Process Reliability Statistics Option Template
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     The Exporting Process Reliability Option Template specifies the
>>>>>>>>>>>>>>     structure of a Data Record for reporting lack of reliability in the
>>>>>>>>>>>>>>     Exporting process.  It SHOULD contain the following Information
>>>>>>>>>>>>>>     Elements that are defined in [
>>>>>>>>>>>>>> RFC5102
>>>>>>>>>>>>>> ]:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     Exporting Process ID
>>>>>>>>>>>>>>                          The identifier of the Exporting Process for
>>>>>>>>>>>>>>                          which lack of reliability is reported.  There
>>>>>>>>>>>>>>                          are three Information Elements specified in
>>>>>>>>>>>>>>                          [
>>>>>>>>>>>>>> RFC5102
>>>>>>>>>>>>>> ] that can be used for this purpose:
>>>>>>>>>>>>>>                          exporterIPv4Address, exporterIPv6Address, or
>>>>>>>>>>>>>>                          exportingProcessId.  This Information Element
>>>>>>>>>>>>>>                          MUST be defined as a Scope Field.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     notSentFlowTotalCount
>>>>>>>>>>>>>>                          The total number of Flows that were generated by
>>>>>>>>>>>>>>                          the Metering Process and dropped by the Metering
>>>>>>>>>>>>>>                          Process or by the Exporting Process instead of
>>>>>>>>>>>>>>                          being sent to the Collecting Process.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     notSentPacketTotalCount
>>>>>>>>>>>>>>                          The total number of packets in Flow Records that
>>>>>>>>>>>>>>                          were generated by the Metering Process and
>>>>>>>>>>>>>>                          dropped by the Metering Process or by the
>>>>>>>>>>>>>>                          Exporting Process instead of being sent to the
>>>>>>>>>>>>>>                          Collecting Process.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     notSentOctetTotalCount
>>>>>>>>>>>>>>                          The total number of octets in packets in Flow
>>>>>>>>>>>>>>                          Records that were generated by the Metering
>>>>>>>>>>>>>>                          Process and dropped by the Metering Process or
>>>>>>>>>>>>>>                          by the Exporting Process instead of being sent
>>>>>>>>>>>>>>                          to the Collecting Process.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     time first flow dropped
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                        The time at which the first Flow Record was dropped by
>>>>>>>>>>>>>>                          the
>>>>>>>>>>>>>> Exporting Process.
>>>>>>>>>>>>>>    For this timestamp, any
>>>>>>>>>>>>>>                          of the "flowStart" timestamp Information
>>>>>>>>>>>>>>                          Elements flowStartMilliseconds,
>>>>>>>>>>>>>>                          flowStartMicroseconds, flowStartNanoseconds, and
>>>>>>>>>>>>>>                          flowStartDeltaMicroseconds can be used.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     time last flow dropped
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The time at which the last Flow Record was
>>>>>>>>>>>>>>                          dropped by the Exporting Process
>>>>>>>>>>>>>> .  For this
>>>>>>>>>>>>>>                          timestamp, any of the "flowEnd" timestamp
>>>>>>>>>>>>>>                          Information Elements flowEndMilliseconds,
>>>>>>>>>>>>>>                          flowEndMicroseconds, flowEndNanoseconds, and
>>>>>>>>>>>>>>                          flowEndDeltaMicroseconds can be used.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Again, I do not find these IEs in RFC5102.
>>>>>>>>>>>> Same remark, I believe we should be using for the two previous IEs
>>>>>>>>>>>> 322    observationTimeSeconds
>>>>>>>>>>>> 323    observationTimeMilliseconds
>>>>>>>>>>>> 324    observationTimeMicroseconds
>>>>>>>>>>>> 325    observationTimeNanoseconds
>>>>>>>>>>>> Regards, Benoit.
>>>>>>>>>>>>>>     The Exporting Process SHOULD export the Data Record specified by the
>>>>>>>>>>>>>>     Exporting Process Reliability Statistics Option Template on a regular
>>>>>>>>>>>>>>     basis or based on some export policy.  This periodicity or export
>>>>>>>>>>>>>>     policy SHOULD be configurable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id
>>>>>>>>>>>>>> 1. there is a meteringProcessId in IPFIX IANA while there is no cache id
>>>>>>>>>>>>> meteringProcessId should do the job.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId?
>>>>>>>>>>>>>>      [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
>>>>>>>>>>>>>>      From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process.
>>>>>>>>>>>>>>      If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below
>>>>>>>>>>>>> See reply to Pauls mail.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Gerhard
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 4.3.  Cache Class
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      +-----------------------------------+
>>>>>>>>>>>>>>      | Cache                             |
>>>>>>>>>>>>>>      +-----------------------------------+        1 +------------------+
>>>>>>>>>>>>>>      | name                              |<>--------| immediateCache/  |
>>>>>>>>>>>>>>      | dataRecords {readOnly}            |          | timeoutCache/    |
>>>>>>>>>>>>>>      | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
>>>>>>>>>>>>>>      |                                   |          | permanentCache   |
>>>>>>>>>>>>>>      |                                   |          +------------------+
>>>>>>>>>>>>>>      |                                   |
>>>>>>>>>>>>>>      |                                   |     0..* +------------------+
>>>>>>>>>>>>>>      |                                   |--------->| ExportingProcess |
>>>>>>>>>>>>>>      +-----------------------------------+          +------------------+
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                            Figure 12: Cache class
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What do you think? Do you see another way?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards, Paul&    Benoit.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> 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
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>


--------------060606000606050109020607
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 28/09/2011 18:47, Brian Trammell wrote:
    

      
Hi, Benoit, all,

      


      

      
Conclusion (from my side): neither.

      


      

      
2. relies on magical templates, which I regard as basically
        poisonous. Being able to know what a template represents
        unambiguously is one of the key strengths of IPFIX.

    

    Agreed.

    

      


      

      
1. is half-magical, so half poisonous. 

    

    And again agreed.

    

    Out of the bad solutions 1 and 2, we have to chose one.

    

      
The timestamps carry no semantics identifying that they have
        to do with a window during which loss occurred. We could I
        suppose change the definition of ignored*count to say "if
        present, timestamps in the same record identify the outer
        bounding window of the loss event(s)" or similar.

      


      

      
I suggest 3. drop the timestamps completely, 

    

    Sure, the IPFIX specifications will look fine, but we're postponing
    the problems.

    

      
or 4. define loss window timestamps. 

      

    

    Proposal 5.  Keep for a single point in time observation 

    
322    observationTimeSeconds

      323    observationTimeMilliseconds

      324    observationTimeMicroseconds

      325    observationTimeNanoseconds

      

    

         Have to new series of observation times

    


      .           observationStartTimeSeconds

      .           observationStartTimeMilliseconds

      .           observationStartTimeMicroseconds

      .           observationStartTimeNanoseconds

      

      .           observationEndTimeSeconds

      .           observationEndTimeMilliseconds

      .           observationEndTimeMicroseconds

      .           observationEndTimeNanoseconds

      

    

    Regards, Benoit.

    


    

    

      


      

      
Cheers, 

      


      

      
Brian

      


        Sent from my iPhone

      


        On 28.09.2011, at 18:06, Benoit Claise <bclaise@cisco.com>
        wrote:

        

      

      

      

        
 Dear all,

          

          Let me restate what I put in my initial email:

          
Well. Two solutions:

            1. we duplicate all the IEs to have the exact correct
            semantic. 

               
            ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds]


            ... and potentially some more such as pre|post

                This brings multiple new dimensions to IE and will lead
            to an explosion of IEs if we want to cover all the case

            2. the collector tests the possible combination of IE in the
            Options Template Record.

                For example, if the collector sees such an Options
            Template Record, it knows that this a "The Metering Process
            Reliability Statistics Options Template"
            
  observationDomainId (scope)
  meteringProcessId (scope)
  ignoredPacketTotalCount
  ignoredOctetTotalCount
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds




          

          And I'm not sure what's the conclusion of this email thread
          is...

          

          Regards, Benoit.

          

            
On Sep 28, 2011, at 12:42 AM, Paul Aitken wrote:



            

              
Brian,



              

                
Hi, Paul, all,

I suppose I should state for the sake of completeness that this is the first I've ever actually _thought_ about the MPRSO. I find the whole use case for it rather dubious -- it presumes an MP with somehow trustworthy knowledge about packet loss, which is never the case, and relying on such information at the collector side for anything other than entertainment purposes is fraught with peril -- so I saw the MAY on section 4 in 5101, was thankful it wasn't a MUST I had to fight against and/or simply ignore, and never looked back.

That said, it does make sense to fix, since it's there.

On Sep 27, 2011, at 10:25 PM, Paul Aitken wrote:



                

                  
How do you know that the received template is a MPRSO?


                

                
Does it matter? Seriously, what is the difference between "an MPRSO" and "a template containing information about lost packets for a given time interval, along with maybe some other information"? Do we actually want to require an MP to keep time interval information for loss? Wouldn't those resources be better deployed not losing packets in the first place? So let's say I want to report missing packets, but don't have information about when I lost them. Do I have to throw a timestamp in there anyway in order for it to be "an MPRSO"?

I think these are arguments against having the timestamps at all (or to include them, with a further instruction that they are optional).


              

              
When a MP knows that it failed to meter some packets, it must have a way of reporting this which the CP can understand correctly. So it matters in that the CP has to understand the implicit "lost traffic" semantic and potentially take action, perhaps involving reports or alarm bells.


            

            
That's an argument for the following template:

  observationDomainId {scope}
  meteringProcessId {scope}
  ignoredPacketTotalCount

Which, in my opinion, is a pretty good starting point.

You can add ignoredOctetTotalCount if you actually know it. Calculating it at libpcap-based MPs like YAF, for example, would involve a little work and generate a bad number: you only get a guess from the kernel how many packets it dropped and no information about how big they are. You can infer octet loss by looking at TCP sequence numbers but now we're back to clear overengineering I think. Maybe on ASIC or FPGA based measurement systems you get good total counters and can measure loss subtractively... But I personally wouldn't waste the real estate on it unless it was a hard requirement.

Again, if you know the timestamps, you can add them. But for the general case as I see it, your fidelity per IE for the template in 5101 is as follows:

perfect:                observationDomainId {scope}
 (i hope you know this) meteringProcessId {scope}

reasonably good guess:  ignoredPacketTotalCount

poor to fair guess:     ignoredOctetTotalCount
 (dep. on HW support)

poor to good guess:     a start timestamp of indeterminate IE
 (dep. on HW support)   an end timestamp of indeterminate IE



            

              

                

                  
   - must the fields be exactly in the specified order and no other combination in order to be a valid MPRSO?


                

                
This isn't a valid template recognition strategy in IPFIX. At least, it hasn't been to date, and it's a bad idea to make it so. IE-Doctors contains language meant to instruct IPFIX application authors to refrain from specifying such magic templates.


              

              
Great; I'm pleased to hear it. Magic templates lead to inflexible collectors, which in turn lead to bug reports against the EP?!




              

                

                  
   - how do you know which of the observationTime* elements (or missingObservationWindowEdge elements) is the first and which is the last?
       - only from their position in the template (so, field order and position are crucial)
       - by comparing them (so field order and position aren't important)


                

                
Time intervals can be treated as a special case, here, since time can generally be assumed to go in only one direction. "The time interval from A to B" is completely equivalent to "the time interval from B to A", so one could argue order doesn't matter. (We don't argue that anywhere in IPFIX, to be true. But what do I do when I get a flow with an endTime before the startTime?)


              

              
When the timestamp wraps. The time between 11pm and 1am is 2 hours, while the time between 1am and 11pm is 22 hours.


            

            
We don't have any timestamps that only carry time information. They've all got implied dates (either based on the 1970 epoch for the UNIX-like timestamps, or on either the NTP or the UNIX epoch for the 1305 timestamps (we'll need to fix this in 5101bis), and there is no specified wrapping behavior as yet. You only hit this problem in 2038, then, and when you do, you've got bigger problems.



            

              

                

                  
Suppose a mediator adds, removes, or re-orders the fields.
   - does this invalidate the MPRSO?
   - how does a mediator know not to do this?
   - how does the collector cope if a mediator does?


                

                
These questions seem to apply only to the case where MPRSO is magical. I'm trying to define it such that it isn't.


              

              
I'm trying to get to the core of what constitues a valid, recognisable MPRSO. Put another way, what's the closest thing to an MPRSO that isn't an MPRSO?


            

            
I'm saying that it doesn't matter. Sure, 5101bis should give recommendations for the template an exporting process uses for this information, but any time a CP sees a template that's scoped to something that ID's an MP that contains loss counter IEs, it's an MPRSO. 



            

              
If I use ignoredPacketTotalCount and ignoredOctetTotalCount in another template, does it become an MPRSO?


            

            
Depends. Are you binding them to a scope that identifies a metering process? You could also export them in a flow or "flexible flow"/flow aggregate, at which point you're giving very detailed error information. And the collector can infer whatever it wants about total reliability based on _that_...



            

              
If we ignore what is and what isn't an MPRSO for the moment, how exactly should a MP tell a CP about the traffic it knows it didn't meter?


            

            
Using something much like the MPRSO as defined by 5101... I'm just trying to lead us away from thinking of a "bright line" between MPRSO and not-MPRSO, because 



            

              

                

                  
The change to "missingObservationWindowEdge" is simply a rename of observationTime. I don't see that it adds anything.


                

                
observationTime already has a meaning. "This Information Element specifies the absolute time in seconds of an observation." In other words, "I saw the thing I'm talking about in this record at the specified time". It has never to date been specified in such a way that it means "I saw the thing I'm talking about in this record at the specified time, unless the record contains two observationTimes, in which case I saw the thing in the time interval between those two things".


              

              
Then you're saying that it's invalid to have two different observationTime values in a flow record, because you can't observe an event at two different times.


            

            
Well.... yes, this is a bit ambiguous.



            

              
Thinking about it some more, I suppose this reports multiple instances of the observation with an AND semantic: I saw this at T1 AND at T2 (since other semantics don't make sense).
Think if these were interfaces: the meaning would be "observed at int1 and int2", rather than "observed from int1 to int2".
So I've convinced myself to agree that 2 x observationTime don't make sense.


            

            
(I'm trying to think of cases where it would be, but I don't think any are illustrative for this discussion...)



            

              

                
missingObservationWindowEdge means "there is missing information within an interval described between this IE and the other identical IE in the record". If we keep the MPRSO defined as it is (and fix it only by dropping in , missingObservationWindowStartSeconds and missingObservationWindowEndSeconds, since it's more IPFIXish, but there was concern voiced in this thread about IE space explosion, so I figured we could exploit the nature of time and cut down on the IEs required by half.

The advantage of a new IE is that it isn't overloaded, but more importantly that it does not lead to an ambiguous interpretation of the entire template at the collector.


              

              
Unfortunately WindowEdge is ambiguous in the wrap case, whereas start and end aren't.


            

            
(see above on wrapping)



            

              

                

                  
A long basicList isn't the right solution because
   - various list lengths mean there are multiple possible templates making the detection of the MPRSO a little more difficult
      ie, it's no longer a fixed template, nor a combination of a few possibilities, but a great many different possible templates.
   - there are two different semantics for the start and end of the window, so it's actually an ordered list of pairs ie a subTemplateList.
Lists can have zero elements. However, if you want to report that nothing was lost, the ignored*Count = 0 report should indicate the start and end of the 100% period. A list length of zero doesn't tell when stuff was or was not lost - so it's of limited usefulness, unless perhaps as a total figure? Again, see questions above about what is / is not a valid MPRSO.


                

                
I withdraw my basicList comment; it was essentially just "thinking aloud", and I didn't actually intend to include a mention of it in the 5101bis MPRSO. 1. It doesn't really add anything to the original intent of the MPRSO, and 2. adding it in 5101bis would cause 5101bis to have a normative dependency on 6313, which is a terrible idea.


              

              
+1. I already discussed with Benoit about using an ordered list or STL of observationTime, and discounted it for this reason.


            

            
Yay! At least we emphatically agree on _something_. ;)

Cheers,

Brian



            

              

                

                  
On 27/09/11 18:30, Andrew Feren wrote:


                  

                    
Hi Brian,

Well stated.

Additional comments inline

On 09/27/2011 12:15 PM, Brian Trammell wrote:


                    

                      
Greetings, all,

This is a little bit of an abuse of the ordering of IEs, in my opinion, and of the general rule that only IEs, and the scope in which they are defined, carry semantics. Even for templates which are defined within Standards Track RFCs, the records defined by the template should be decipherable without reference to the RFC. Put another way, we should not define magical templates, and this template as proposed looks pretty magical.


                    

                    
Yes, a black magic sort of magical.  We have been discussing this proposed change in the office and coming to the same conclusion.


                    

                      
Without reading the text of this thread, and following basically everything we've ever said about multiple IEs in a record, I would interpret a record matching this template as follows:

For the metering process A and observation domain B:
N packets were ignored; these contained a total of M octets.
The first observation at this metering process was at time T0.
The second observation at this metering process was at time T1.


                    

                    
This was exactly how I interpreted this template until I read the updated draft and saw the bit about "the Collecting Process MUST determine which is the oldest and the most recent timestamp in order the determine the right semantic ...."



                    

                      
This is quite far from the stated intention. I would strongly suggest that we not so lightly give up on "templates should be unambiguously understandable" requirement, even if the exception itself lives in the core protocol document.

I would suggest, if you want to do a multiple IE solution here, you define something like missingObservationWindowEdge, and have two of them:

  observationDomainId {scope}
  meteringProcessId {scope}
  ignoredPacketTotalCount
  ignoredOctetTotalCount
  missingObservationWindowEdge
  missingObservationWindowEdge

This has the advantage that you can have a long basicList of window edges in order to define multiple missing observation windows; each edge pair is a loss window.


                    

                    
I like this suggestion, and I have a few additional thoughts.

Perhaps the basic list of edge times should either be limited to only one pair or the ignored*TotalCount IEs needs to be in a basiclist with N entries too.

How about observationWindowEdge instead (no "missing") to be more generally useful.

I think a list of time edges also works neatly when sending this template at regular intervals (which SHOULD be done).  When the ignored*TotalCount IEs are zero, an empty list makes sense for edge times.




                    

                      
Seconds suffice for these, I think. You might want to do one in milliseconds. But if you have the resources to calculate your packet loss window to nanosecond precision without having the resources to not lose packets, I humbly submit you've picked the wrong engineering tradeoffs. :)


                    

                    
Unless window edge isn't defined specifically for "missing" values.  Then the higher precision timestamps might have some use.

-Andrew


                    

                      
Best regards,

Brian

On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote:



                      

                        
Yes, this makes sense.

I gave this some thought and I don't have a better suggestion.  I also agree that even though the flow[Start|End]* collection of IEs conveniently has one IE for both first and last, observationTime* is the more correct choice here.

-Andrew

On 09/22/2011 03:54 AM, Benoit Claise wrote:


                        

                          
Hi Andrew,


                          

                            
Hi Benoit,

I had the same thought about using

322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds

The problem is that you need two timestamps in the same record (first and last).  How does that work with the above?


                          

                          
Excellent question. We debated this question with Paul Aitken recently.
Let me rephrase the question slightly differently: how does the collector determine that this is a "The Metering Process Reliability Statistics Options Template", and understands the semantic of the two counters?
Well. Two solutions:
1. we duplicate all the IEs to have the exact correct semantic.
    ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] ... and potentially some more such as pre|post
    This brings multiple new dimensions to IE and will lead to an explosion of IEs if we want to cover all the case
2. the collector tests the possible combination of IE in the Options Template Record.
    For example, if the collector sees such an Options Template Record, it knows that this a "The Metering Process Reliability Statistics Options Template"
  observationDomainId (scope)
  meteringProcessId (scope)

  ignoredPacketTotalCount
  ignoredOctetTotalCount
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds


While the solution 2 is not perfect, this was the chosen track.

Does it make sense?

Regards, Benoit


                          

                            
-Andrew

On 09/21/2011 07:11 PM, Benoit Claise wrote:


                            

                              
Hi Gerhard,

Thanks for your reply.
See in line.


                              

                                
Hi Benoit,

See comments inline.

On 20.09.2011 16:19, Benoit Claise wrote:


                                

                                  
Dear all,

[this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO DO ->   "time first flow dropped" and "time last flow dropped" inconsistency.  See the discussion on the list.]

Paul Aitken discovered this issue.,

>From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template

time first flow dropped
                        The timestamp of the first Flow was dropped by
                        the Metering Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

time last flow dropped
                        The timestamp of the last IP packet that was
                        ignored by the Metering Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.


Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o

Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".

Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter?

Here is a proposal for 4.2 and 4.3. The underlined parts are new

4.2.  The Metering Process Reliability Statistics Option Template



   The Metering Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [
RFC5102
]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.



   meteringProcessId (*)
                           The identifier of the Metering Process for
                           which lack of reliability is reported.  There
                           This Information Element MUST be defined as a
                           Scope Field.


   ignoredPacketTotalCount
                           The total number of IP packets that the
                           Metering Process did not process.

   ignoredOctetTotalCount
                           The total number of octets in observed IP
                           packets that the Metering Process did not
                           process.

   time first
packet
ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last
packet
ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.



                                

                                
I do not find these IEs in RFC5102.


                              

                              
Which ones?  flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds
There are in http://www.iana.org/assignments/ipfix/ipfix.xml
However, re-reading
   time first packet
ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last
packet
ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.

And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd" timestamp IE,
I now believe that we should be using this series of IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds



                              

                                

                                  
4.3.  The Exporting Process Reliability Statistics Option Template


   The Exporting Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Exporting process.  It SHOULD contain the following Information
   Elements that are defined in [
RFC5102
]:

   Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [
RFC5102
] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.

   notSentFlowTotalCount
                        The total number of Flows that were generated by
                        the Metering Process and dropped by the Metering
                        Process or by the Exporting Process instead of
                        being sent to the Collecting Process.

   notSentPacketTotalCount
                        The total number of packets in Flow Records that
                        were generated by the Metering Process and
                        dropped by the Metering Process or by the
                        Exporting Process instead of being sent to the
                        Collecting Process.

   notSentOctetTotalCount
                        The total number of octets in packets in Flow
                        Records that were generated by the Metering
                        Process and dropped by the Metering Process or
                        by the Exporting Process instead of being sent
                        to the Collecting Process.

   time first flow dropped

                      The time at which the first Flow Record was dropped by
                        the
Exporting Process.
  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

   time last flow dropped

The time at which the last Flow Record was
                        dropped by the Exporting Process
.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.



                                

                                
Again, I do not find these IEs in RFC5102.


                              

                              
Same remark, I believe we should be using for the two previous IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds
Regards, Benoit.


                              

                                

                                  
   The Exporting Process SHOULD export the Data Record specified by the
   Exporting Process Reliability Statistics Option Template on a regular
   basis or based on some export policy.  This periodicity or export
   policy SHOULD be configurable.





(*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id
1. there is a meteringProcessId in IPFIX IANA while there is no cache id


                                

                                
meteringProcessId should do the job.



                                

                                  
2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId?
    [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
    From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process.
    If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below


                                

                                
See reply to Pauls mail.

Regards,
Gerhard



                                

                                  
4.3.  Cache Class


    +-----------------------------------+
    | Cache                             |
    +-----------------------------------+        1 +------------------+
    | name                              |<>--------| immediateCache/  |
    | dataRecords {readOnly}            |          | timeoutCache/    |
    | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
    |                                   |          | permanentCache   |
    |                                   |          +------------------+
    |                                   |
    |                                   |     0..* +------------------+
    |                                   |--------->| ExportingProcess |
    +-----------------------------------+          +------------------+

                          Figure 12: Cache class

What do you think? Do you see another way?

Regards, Paul&   Benoit.


_______________________________________________
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


                          

                        

                        
_______________________________________________
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


          

          

        

      

    

    

  


--------------060606000606050109020607--

From andrewf@plixer.com  Thu Sep 29 06:11:10 2011
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 2044D21F8D28 for ; Thu, 29 Sep 2011 06:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.932
X-Spam-Level: 
X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_75=0.6]
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 xXUmMk78pBqB for ; Thu, 29 Sep 2011 06:11:05 -0700 (PDT)
Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id D80FD21F8D21 for ; Thu, 29 Sep 2011 06:11:04 -0700 (PDT)
Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 29 Sep 2011 09:13:54 -0400
Message-ID: <4E846F12.6000608@plixer.com>
Date: Thu, 29 Sep 2011 09:13:54 -0400
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110921 Thunderbird/9.0a1
MIME-Version: 1.0
To: ipfix@ietf.org
References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E7A397B.3080802@net.in.tum.de> <4E7A6F1B.5010600@cisco.com> <4E7AA240.4020506@plixer.com> <4E7AE9D1.9090002@cisco.com>  <4E82081B.8040806@plixer.com> <4E823130.6000505@cisco.com>  <4E82513F.9020604@cisco.com>  <4E834617.3030805@cisco.com> <10BEDBFE-B363-4B40-9202-B43F89F262D2@tik.ee.ethz.ch> <4E844197.6010103@cisco.com>
In-Reply-To: <4E844197.6010103@cisco.com>
Content-Type: multipart/alternative; boundary="------------090909080106020002050201"
X-OriginalArrivalTime: 29 Sep 2011 13:13:54.0993 (UTC) FILETIME=[A3D21A10:01CC7EA9]
Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped
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, 29 Sep 2011 13:11:10 -0000

This is a multi-part message in MIME format.
--------------090909080106020002050201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Benoit and list,

On 09/29/2011 05:59 AM, Benoit Claise wrote:
> On 28/09/2011 18:47, Brian Trammell wrote:
>> Hi, Benoit, all,
>>
>> Conclusion (from my side): neither.
>>
>> 2. relies on magical templates, which I regard as basically 
>> poisonous. Being able to know what a template represents 
>> unambiguously is one of the key strengths of IPFIX.
> Agreed.
>>
>> 1. is half-magical, so half poisonous.
> And again agreed.
>
> Out of the bad solutions 1 and 2, we have to chose one.
>> The timestamps carry no semantics identifying that they have to do 
>> with a window during which loss occurred. We could I suppose change 
>> the definition of ignored*count to say "if present, timestamps in the 
>> same record identify the outer bounding window of the loss event(s)" 
>> or similar.
>>
>> I suggest 3. drop the timestamps completely,
> Sure, the IPFIX specifications will look fine, but we're postponing 
> the problems.

Benoit could you elaborate on what problems we are postponing?  This is 
not clear to me.

>> or 4. define loss window timestamps.
> Proposal 5.  Keep for a single point in time observation
>
>     322    observationTimeSeconds
>     323    observationTimeMilliseconds
>     324    observationTimeMicroseconds
>     325    observationTimeNanoseconds
>
Seems reasonable.

The more I have looked at this template the less clear I have been on 
the reason for the two timestamps.  On my initial read I thought they 
bounded a window during which the most recent set of errors occurred.  
However, as I read more (and reread) it occurred to me that the counters 
are both total counters.  This seems to imply that the first timestamp 
is the first ignored[Packet|Octet] observed  since metering process 
start.  Resending first ignored over and over again seems to have little 
if any benefit.

There is, however, probably some detail(s) that I have not fully grokked.

Thanks for any clarification,
-Andrew


>      Have to new series of observation times
>
>
>     .           observationStartTimeSeconds
>     .           observationStartTimeMilliseconds
>     .           observationStartTimeMicroseconds
>     .           observationStartTimeNanoseconds
>
>     .           observationEndTimeSeconds
>     .           observationEndTimeMilliseconds
>     .           observationEndTimeMicroseconds
>     .           observationEndTimeNanoseconds
>
> Regards, Benoit.
>
>
>>
>> Cheers,
>>
>> Brian
>>
>> Sent from my iPhone
>>
>> On 28.09.2011, at 18:06, Benoit Claise > > wrote:
>>
>>> Dear all,
>>>
>>> Let me restate what I put in my initial email:
>>>
>>>     Well. Two solutions:
>>>     1. we duplicate all the IEs to have the exact correct semantic.
>>>        
>>>     ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds]
>>>     ... and potentially some more such as pre|post
>>>         This brings multiple new dimensions to IE and will lead to
>>>     an explosion of IEs if we want to cover all the case
>>>     2. the collector tests the possible combination of IE in the
>>>     Options Template Record.
>>>         For example, if the collector sees such an Options Template
>>>     Record, it knows that this a "The Metering Process Reliability
>>>     Statistics Options Template"
>>>
>>>        observationDomainId (scope)
>>>        meteringProcessId (scope)_
>>>     _   ignoredPacketTotalCount
>>>        ignoredOctetTotalCount
>>>        observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
>>>        observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
>>>
>>>
>>>
>>> And I'm not sure what's the conclusion of this email thread is...
>>>
>>> Regards, Benoit.
>>>> On Sep 28, 2011, at 12:42 AM, Paul Aitken wrote:
>>>>
>>>>> Brian,
>>>>>
>>>>>> Hi, Paul, all,
>>>>>>
>>>>>> I suppose I should state for the sake of completeness that this is the first I've ever actually _thought_ about the MPRSO. I find the whole use case for it rather dubious -- it presumes an MP with somehow trustworthy knowledge about packet loss, which is never the case, and relying on such information at the collector side for anything other than entertainment purposes is fraught with peril -- so I saw the MAY on section 4 in 5101, was thankful it wasn't a MUST I had to fight against and/or simply ignore, and never looked back.
>>>>>>
>>>>>> That said, it does make sense to fix, since it's there.
>>>>>>
>>>>>> On Sep 27, 2011, at 10:25 PM, Paul Aitken wrote:
>>>>>>
>>>>>>> How do you know that the received template is a MPRSO?
>>>>>> Does it matter? Seriously, what is the difference between "an MPRSO" and "a template containing information about lost packets for a given time interval, along with maybe some other information"? Do we actually want to require an MP to keep time interval information for loss? Wouldn't those resources be better deployed not losing packets in the first place? So let's say I want to report missing packets, but don't have information about when I lost them. Do I have to throw a timestamp in there anyway in order for it to be "an MPRSO"?
>>>>>>
>>>>>> I think these are arguments against having the timestamps at all (or to include them, with a further instruction that they are optional).
>>>>> When a MP knows that it failed to meter some packets, it must have a way of reporting this which the CP can understand correctly. So it matters in that the CP has to understand the implicit "lost traffic" semantic and potentially take action, perhaps involving reports or alarm bells.
>>>> That's an argument for the following template:
>>>>
>>>>    observationDomainId {scope}
>>>>    meteringProcessId {scope}
>>>>    ignoredPacketTotalCount
>>>>
>>>> Which, in my opinion, is a pretty good starting point.
>>>>
>>>> You can add ignoredOctetTotalCount if you actually know it. Calculating it at libpcap-based MPs like YAF, for example, would involve a little work and generate a bad number: you only get a guess from the kernel how many packets it dropped and no information about how big they are. You can infer octet loss by looking at TCP sequence numbers but now we're back to clear overengineering I think. Maybe on ASIC or FPGA based measurement systems you get good total counters and can measure loss subtractively... But I personally wouldn't waste the real estate on it unless it was a hard requirement.
>>>>
>>>> Again, if you know the timestamps, you can add them. But for the general case as I see it, your fidelity per IE for the template in 5101 is as follows:
>>>>
>>>> perfect:                observationDomainId {scope}
>>>>   (i hope you know this) meteringProcessId {scope}
>>>>
>>>> reasonably good guess:  ignoredPacketTotalCount
>>>>
>>>> poor to fair guess:     ignoredOctetTotalCount
>>>>   (dep. on HW support)
>>>>
>>>> poor to good guess:     a start timestamp of indeterminate IE
>>>>   (dep. on HW support)   an end timestamp of indeterminate IE
>>>>
>>>>>>>     - must the fields be exactly in the specified order and no other combination in order to be a valid MPRSO?
>>>>>> This isn't a valid template recognition strategy in IPFIX. At least, it hasn't been to date, and it's a bad idea to make it so. IE-Doctors contains language meant to instruct IPFIX application authors to refrain from specifying such magic templates.
>>>>> Great; I'm pleased to hear it. Magic templates lead to inflexible collectors, which in turn lead to bug reports against the EP?!
>>>>>
>>>>>
>>>>>>>     - how do you know which of the observationTime* elements (or missingObservationWindowEdge elements) is the first and which is the last?
>>>>>>>         - only from their position in the template (so, field order and position are crucial)
>>>>>>>         - by comparing them (so field order and position aren't important)
>>>>>> Time intervals can be treated as a special case, here, since time can generally be assumed to go in only one direction. "The time interval from A to B" is completely equivalent to "the time interval from B to A", so one could argue order doesn't matter. (We don't argue that anywhere in IPFIX, to be true. But what do I do when I get a flow with an endTime before the startTime?)
>>>>> When the timestamp wraps. The time between 11pm and 1am is 2 hours, while the time between 1am and 11pm is 22 hours.
>>>> We don't have any timestamps that only carry time information. They've all got implied dates (either based on the 1970 epoch for the UNIX-like timestamps, or on either the NTP or the UNIX epoch for the 1305 timestamps (we'll need to fix this in 5101bis), and there is no specified wrapping behavior as yet. You only hit this problem in 2038, then, and when you do, you've got bigger problems.
>>>>
>>>>>>> Suppose a mediator adds, removes, or re-orders the fields.
>>>>>>>     - does this invalidate the MPRSO?
>>>>>>>     - how does a mediator know not to do this?
>>>>>>>     - how does the collector cope if a mediator does?
>>>>>> These questions seem to apply only to the case where MPRSO is magical. I'm trying to define it such that it isn't.
>>>>> I'm trying to get to the core of what constitues a valid, recognisable MPRSO. Put another way, what's the closest thing to an MPRSO that isn't an MPRSO?
>>>> I'm saying that it doesn't matter. Sure, 5101bis should give recommendations for the template an exporting process uses for this information, but any time a CP sees a template that's scoped to something that ID's an MP that contains loss counter IEs, it's an MPRSO.
>>>>
>>>>> If I use ignoredPacketTotalCount and ignoredOctetTotalCount in another template, does it become an MPRSO?
>>>> Depends. Are you binding them to a scope that identifies a metering process? You could also export them in a flow or "flexible flow"/flow aggregate, at which point you're giving very detailed error information. And the collector can infer whatever it wants about total reliability based on _that_...
>>>>
>>>>> If we ignore what is and what isn't an MPRSO for the moment, how exactly should a MP tell a CP about the traffic it knows it didn't meter?
>>>> Using something much like the MPRSO as defined by 5101... I'm just trying to lead us away from thinking of a "bright line" between MPRSO and not-MPRSO, because
>>>>
>>>>>>> The change to "missingObservationWindowEdge" is simply a rename of observationTime. I don't see that it adds anything.
>>>>>> observationTime already has a meaning. "This Information Element specifies the absolute time in seconds of an observation." In other words, "I saw the thing I'm talking about in this record at the specified time". It has never to date been specified in such a way that it means "I saw the thing I'm talking about in this record at the specified time, unless the record contains two observationTimes, in which case I saw the thing in the time interval between those two things".
>>>>> Then you're saying that it's invalid to have two different observationTime values in a flow record, because you can't observe an event at two different times.
>>>> Well.... yes, this is a bit ambiguous.
>>>>
>>>>> Thinking about it some more, I suppose this reports multiple instances of the observation with an AND semantic: I saw this at T1 AND at T2 (since other semantics don't make sense).
>>>>> Think if these were interfaces: the meaning would be "observed at int1 and int2", rather than "observed from int1 to int2".
>>>>> So I've convinced myself to agree that 2 x observationTime don't make sense.
>>>> (I'm trying to think of cases where it would be, but I don't think any are illustrative for this discussion...)
>>>>
>>>>>> missingObservationWindowEdge means "there is missing information within an interval described between this IE and the other identical IE in the record". If we keep the MPRSO defined as it is (and fix it only by dropping in , missingObservationWindowStartSeconds and missingObservationWindowEndSeconds, since it's more IPFIXish, but there was concern voiced in this thread about IE space explosion, so I figured we could exploit the nature of time and cut down on the IEs required by half.
>>>>>>
>>>>>> The advantage of a new IE is that it isn't overloaded, but more importantly that it does not lead to an ambiguous interpretation of the entire template at the collector.
>>>>> Unfortunately WindowEdge is ambiguous in the wrap case, whereas start and end aren't.
>>>> (see above on wrapping)
>>>>
>>>>>>> A long basicList isn't the right solution because
>>>>>>>     - various list lengths mean there are multiple possible templates making the detection of the MPRSO a little more difficult
>>>>>>>        ie, it's no longer a fixed template, nor a combination of a few possibilities, but a great many different possible templates.
>>>>>>>     - there are two different semantics for the start and end of the window, so it's actually an ordered list of pairs ie a subTemplateList.
>>>>>>> Lists can have zero elements. However, if you want to report that nothing was lost, the ignored*Count = 0 report should indicate the start and end of the 100% period. A list length of zero doesn't tell when stuff was or was not lost - so it's of limited usefulness, unless perhaps as a total figure? Again, see questions above about what is / is not a valid MPRSO.
>>>>>> I withdraw my basicList comment; it was essentially just "thinking aloud", and I didn't actually intend to include a mention of it in the 5101bis MPRSO. 1. It doesn't really add anything to the original intent of the MPRSO, and 2. adding it in 5101bis would cause 5101bis to have a normative dependency on 6313, which is a terrible idea.
>>>>> +1. I already discussed with Benoit about using an ordered list or STL of observationTime, and discounted it for this reason.
>>>> Yay! At least we emphatically agree on _something_. ;)
>>>>
>>>> Cheers,
>>>>
>>>> Brian
>>>>
>>>>>>> On 27/09/11 18:30, Andrew Feren wrote:
>>>>>>>> Hi Brian,
>>>>>>>>
>>>>>>>> Well stated.
>>>>>>>>
>>>>>>>> Additional comments inline
>>>>>>>>
>>>>>>>> On 09/27/2011 12:15 PM, Brian Trammell wrote:
>>>>>>>>> Greetings, all,
>>>>>>>>>
>>>>>>>>> This is a little bit of an abuse of the ordering of IEs, in my opinion, and of the general rule that only IEs, and the scope in which they are defined, carry semantics. Even for templates which are defined within Standards Track RFCs, the records defined by the template should be decipherable without reference to the RFC. Put another way, we should not define magical templates, and this template as proposed looks pretty magical.
>>>>>>>> Yes, a black magic sort of magical.  We have been discussing this proposed change in the office and coming to the same conclusion.
>>>>>>>>> Without reading the text of this thread, and following basically everything we've ever said about multiple IEs in a record, I would interpret a record matching this template as follows:
>>>>>>>>>
>>>>>>>>> For the metering process A and observation domain B:
>>>>>>>>> N packets were ignored; these contained a total of M octets.
>>>>>>>>> The first observation at this metering process was at time T0.
>>>>>>>>> The second observation at this metering process was at time T1.
>>>>>>>> This was exactly how I interpreted this template until I read the updated draft and saw the bit about "the Collecting Process MUST determine which is the oldest and the most recent timestamp in order the determine the right semantic ...."
>>>>>>>>
>>>>>>>>> This is quite far from the stated intention. I would strongly suggest that we not so lightly give up on "templates should be unambiguously understandable" requirement, even if the exception itself lives in the core protocol document.
>>>>>>>>>
>>>>>>>>> I would suggest, if you want to do a multiple IE solution here, you define something like missingObservationWindowEdge, and have two of them:
>>>>>>>>>
>>>>>>>>>    observationDomainId {scope}
>>>>>>>>>    meteringProcessId {scope}
>>>>>>>>>    ignoredPacketTotalCount
>>>>>>>>>    ignoredOctetTotalCount
>>>>>>>>>    missingObservationWindowEdge
>>>>>>>>>    missingObservationWindowEdge
>>>>>>>>>
>>>>>>>>> This has the advantage that you can have a long basicList of window edges in order to define multiple missing observation windows; each edge pair is a loss window.
>>>>>>>> I like this suggestion, and I have a few additional thoughts.
>>>>>>>>
>>>>>>>> Perhaps the basic list of edge times should either be limited to only one pair or the ignored*TotalCount IEs needs to be in a basiclist with N entries too.
>>>>>>>>
>>>>>>>> How about observationWindowEdge instead (no "missing") to be more generally useful.
>>>>>>>>
>>>>>>>> I think a list of time edges also works neatly when sending this template at regular intervals (which SHOULD be done).  When the ignored*TotalCount IEs are zero, an empty list makes sense for edge times.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Seconds suffice for these, I think. You might want to do one in milliseconds. But if you have the resources to calculate your packet loss window to nanosecond precision without having the resources to not lose packets, I humbly submit you've picked the wrong engineering tradeoffs. :)
>>>>>>>> Unless window edge isn't defined specifically for "missing" values.  Then the higher precision timestamps might have some use.
>>>>>>>>
>>>>>>>> -Andrew
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Brian
>>>>>>>>>
>>>>>>>>> On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote:
>>>>>>>>>
>>>>>>>>>> Yes, this makes sense.
>>>>>>>>>>
>>>>>>>>>> I gave this some thought and I don't have a better suggestion.  I also agree that even though the flow[Start|End]* collection of IEs conveniently has one IE for both first and last, observationTime* is the more correct choice here.
>>>>>>>>>>
>>>>>>>>>> -Andrew
>>>>>>>>>>
>>>>>>>>>> On 09/22/2011 03:54 AM, Benoit Claise wrote:
>>>>>>>>>>> Hi Andrew,
>>>>>>>>>>>> Hi Benoit,
>>>>>>>>>>>>
>>>>>>>>>>>> I had the same thought about using
>>>>>>>>>>>>
>>>>>>>>>>>> 322    observationTimeSeconds
>>>>>>>>>>>> 323    observationTimeMilliseconds
>>>>>>>>>>>> 324    observationTimeMicroseconds
>>>>>>>>>>>> 325    observationTimeNanoseconds
>>>>>>>>>>>>
>>>>>>>>>>>> The problem is that you need two timestamps in the same record (first and last).  How does that work with the above?
>>>>>>>>>>> Excellent question. We debated this question with Paul Aitken recently.
>>>>>>>>>>> Let me rephrase the question slightly differently: how does the collector determine that this is a "The Metering Process Reliability Statistics Options Template", and understands the semantic of the two counters?
>>>>>>>>>>> Well. Two solutions:
>>>>>>>>>>> 1. we duplicate all the IEs to have the exact correct semantic.
>>>>>>>>>>>      ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] ... and potentially some more such as pre|post
>>>>>>>>>>>      This brings multiple new dimensions to IE and will lead to an explosion of IEs if we want to cover all the case
>>>>>>>>>>> 2. the collector tests the possible combination of IE in the Options Template Record.
>>>>>>>>>>>      For example, if the collector sees such an Options Template Record, it knows that this a "The Metering Process Reliability Statistics Options Template"
>>>>>>>>>>>    observationDomainId (scope)
>>>>>>>>>>>    meteringProcessId (scope)
>>>>>>>>>>>
>>>>>>>>>>>    ignoredPacketTotalCount
>>>>>>>>>>>    ignoredOctetTotalCount
>>>>>>>>>>>    observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
>>>>>>>>>>>    observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> While the solution 2 is not perfect, this was the chosen track.
>>>>>>>>>>>
>>>>>>>>>>> Does it make sense?
>>>>>>>>>>>
>>>>>>>>>>> Regards, Benoit
>>>>>>>>>>>> -Andrew
>>>>>>>>>>>>
>>>>>>>>>>>> On 09/21/2011 07:11 PM, Benoit Claise wrote:
>>>>>>>>>>>>> Hi Gerhard,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for your reply.
>>>>>>>>>>>>> See in line.
>>>>>>>>>>>>>> Hi Benoit,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See comments inline.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 20.09.2011 16:19, Benoit Claise wrote:
>>>>>>>>>>>>>>> Dear all,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO DO ->    "time first flow dropped" and "time last flow dropped" inconsistency.  See the discussion on the list.]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Paul Aitken discovered this issue.,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> > From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> time first flow dropped
>>>>>>>>>>>>>>>                          The timestamp of the first Flow was dropped by
>>>>>>>>>>>>>>>                          the Metering Process.  For this timestamp, any
>>>>>>>>>>>>>>>                          of the "flowStart" timestamp Information
>>>>>>>>>>>>>>>                          Elements flowStartMilliseconds,
>>>>>>>>>>>>>>>                          flowStartMicroseconds, flowStartNanoseconds, and
>>>>>>>>>>>>>>>                          flowStartDeltaMicroseconds can be used.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> time last flow dropped
>>>>>>>>>>>>>>>                          The timestamp of the last IP packet that was
>>>>>>>>>>>>>>>                          ignored by the Metering Process.  For this
>>>>>>>>>>>>>>>                          timestamp, any of the "flowEnd" timestamp
>>>>>>>>>>>>>>>                          Information Elements flowEndMilliseconds,
>>>>>>>>>>>>>>>                          flowEndMicroseconds, flowEndNanoseconds, and
>>>>>>>>>>>>>>>                          flowEndDeltaMicroseconds can be used.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here is a proposal for 4.2 and 4.3. The underlined parts are new
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 4.2.  The Metering Process Reliability Statistics Option Template
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     The Metering Process Reliability Option Template specifies the
>>>>>>>>>>>>>>>     structure of a Data Record for reporting lack of reliability in the
>>>>>>>>>>>>>>>     Metering Process.  It SHOULD contain the following Information
>>>>>>>>>>>>>>>     Elements that are defined in [
>>>>>>>>>>>>>>> RFC5102
>>>>>>>>>>>>>>> ]:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     observationDomainId
>>>>>>>>>>>>>>>                             An identifier of an Observation Domain that
>>>>>>>>>>>>>>>                             is locally unique to the Exporting Process.
>>>>>>>>>>>>>>>                             This Information Element MUST be defined as a
>>>>>>>>>>>>>>>                             Scope Field.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     meteringProcessId (*)
>>>>>>>>>>>>>>>                             The identifier of the Metering Process for
>>>>>>>>>>>>>>>                             which lack of reliability is reported.  There
>>>>>>>>>>>>>>>                             This Information Element MUST be defined as a
>>>>>>>>>>>>>>>                             Scope Field.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     ignoredPacketTotalCount
>>>>>>>>>>>>>>>                             The total number of IP packets that the
>>>>>>>>>>>>>>>                             Metering Process did not process.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     ignoredOctetTotalCount
>>>>>>>>>>>>>>>                             The total number of octets in observed IP
>>>>>>>>>>>>>>>                             packets that the Metering Process did not
>>>>>>>>>>>>>>>                             process.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     time first
>>>>>>>>>>>>>>> packet
>>>>>>>>>>>>>>> ignored
>>>>>>>>>>>>>>>                             The timestamp of the first IP packet that was
>>>>>>>>>>>>>>>                             ignored by the Metering Process.  For this
>>>>>>>>>>>>>>>                             timestamp, any of the "flowStart" timestamp
>>>>>>>>>>>>>>>                             Information Elements flowStartMilliseconds,
>>>>>>>>>>>>>>>                             flowStartMicroseconds, flowStartNanoseconds,
>>>>>>>>>>>>>>>                             and flowStartDeltaMicroseconds can be used.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     time last
>>>>>>>>>>>>>>> packet
>>>>>>>>>>>>>>> ignored
>>>>>>>>>>>>>>>                             The timestamp of the last IP packet that was
>>>>>>>>>>>>>>>                             ignored by the Metering Process.  For this
>>>>>>>>>>>>>>>                             timestamp, any of the "flowEnd" timestamp
>>>>>>>>>>>>>>>                             Information Elements flowEndMilliseconds,
>>>>>>>>>>>>>>>                             flowEndMicroseconds, flowEndNanoseconds, and
>>>>>>>>>>>>>>>                             flowEndDeltaMicroseconds can be used.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I do not find these IEs in RFC5102.
>>>>>>>>>>>>> Which ones?  flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds
>>>>>>>>>>>>> There are inhttp://www.iana.org/assignments/ipfix/ipfix.xml
>>>>>>>>>>>>> However, re-reading
>>>>>>>>>>>>>     time first packet
>>>>>>>>>>>>> ignored
>>>>>>>>>>>>>                             The timestamp of the first IP packet that was
>>>>>>>>>>>>>                             ignored by the Metering Process.  For this
>>>>>>>>>>>>>                             timestamp, any of the "flowStart" timestamp
>>>>>>>>>>>>>                             Information Elements flowStartMilliseconds,
>>>>>>>>>>>>>                             flowStartMicroseconds, flowStartNanoseconds,
>>>>>>>>>>>>>                             and flowStartDeltaMicroseconds can be used.
>>>>>>>>>>>>>
>>>>>>>>>>>>>     time last
>>>>>>>>>>>>> packet
>>>>>>>>>>>>> ignored
>>>>>>>>>>>>>                             The timestamp of the last IP packet that was
>>>>>>>>>>>>>                             ignored by the Metering Process.  For this
>>>>>>>>>>>>>                             timestamp, any of the "flowEnd" timestamp
>>>>>>>>>>>>>                             Information Elements flowEndMilliseconds,
>>>>>>>>>>>>>                             flowEndMicroseconds, flowEndNanoseconds, and
>>>>>>>>>>>>>                             flowEndDeltaMicroseconds can be used.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andhttp://www.iana.org/assignments/ipfix/ipfix.xml  for the "flowEnd" timestamp IE,
>>>>>>>>>>>>> I now believe that we should be using this series of IEs
>>>>>>>>>>>>> 322    observationTimeSeconds
>>>>>>>>>>>>> 323    observationTimeMilliseconds
>>>>>>>>>>>>> 324    observationTimeMicroseconds
>>>>>>>>>>>>> 325    observationTimeNanoseconds
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 4.3.  The Exporting Process Reliability Statistics Option Template
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     The Exporting Process Reliability Option Template specifies the
>>>>>>>>>>>>>>>     structure of a Data Record for reporting lack of reliability in the
>>>>>>>>>>>>>>>     Exporting process.  It SHOULD contain the following Information
>>>>>>>>>>>>>>>     Elements that are defined in [
>>>>>>>>>>>>>>> RFC5102
>>>>>>>>>>>>>>> ]:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     Exporting Process ID
>>>>>>>>>>>>>>>                          The identifier of the Exporting Process for
>>>>>>>>>>>>>>>                          which lack of reliability is reported.  There
>>>>>>>>>>>>>>>                          are three Information Elements specified in
>>>>>>>>>>>>>>>                          [
>>>>>>>>>>>>>>> RFC5102
>>>>>>>>>>>>>>> ] that can be used for this purpose:
>>>>>>>>>>>>>>>                          exporterIPv4Address, exporterIPv6Address, or
>>>>>>>>>>>>>>>                          exportingProcessId.  This Information Element
>>>>>>>>>>>>>>>                          MUST be defined as a Scope Field.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     notSentFlowTotalCount
>>>>>>>>>>>>>>>                          The total number of Flows that were generated by
>>>>>>>>>>>>>>>                          the Metering Process and dropped by the Metering
>>>>>>>>>>>>>>>                          Process or by the Exporting Process instead of
>>>>>>>>>>>>>>>                          being sent to the Collecting Process.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     notSentPacketTotalCount
>>>>>>>>>>>>>>>                          The total number of packets in Flow Records that
>>>>>>>>>>>>>>>                          were generated by the Metering Process and
>>>>>>>>>>>>>>>                          dropped by the Metering Process or by the
>>>>>>>>>>>>>>>                          Exporting Process instead of being sent to the
>>>>>>>>>>>>>>>                          Collecting Process.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     notSentOctetTotalCount
>>>>>>>>>>>>>>>                          The total number of octets in packets in Flow
>>>>>>>>>>>>>>>                          Records that were generated by the Metering
>>>>>>>>>>>>>>>                          Process and dropped by the Metering Process or
>>>>>>>>>>>>>>>                          by the Exporting Process instead of being sent
>>>>>>>>>>>>>>>                          to the Collecting Process.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     time first flow dropped
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                        The time at which the first Flow Record was dropped by
>>>>>>>>>>>>>>>                          the
>>>>>>>>>>>>>>> Exporting Process.
>>>>>>>>>>>>>>>    For this timestamp, any
>>>>>>>>>>>>>>>                          of the "flowStart" timestamp Information
>>>>>>>>>>>>>>>                          Elements flowStartMilliseconds,
>>>>>>>>>>>>>>>                          flowStartMicroseconds, flowStartNanoseconds, and
>>>>>>>>>>>>>>>                          flowStartDeltaMicroseconds can be used.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     time last flow dropped
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The time at which the last Flow Record was
>>>>>>>>>>>>>>>                          dropped by the Exporting Process
>>>>>>>>>>>>>>> .  For this
>>>>>>>>>>>>>>>                          timestamp, any of the "flowEnd" timestamp
>>>>>>>>>>>>>>>                          Information Elements flowEndMilliseconds,
>>>>>>>>>>>>>>>                          flowEndMicroseconds, flowEndNanoseconds, and
>>>>>>>>>>>>>>>                          flowEndDeltaMicroseconds can be used.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Again, I do not find these IEs in RFC5102.
>>>>>>>>>>>>> Same remark, I believe we should be using for the two previous IEs
>>>>>>>>>>>>> 322    observationTimeSeconds
>>>>>>>>>>>>> 323    observationTimeMilliseconds
>>>>>>>>>>>>> 324    observationTimeMicroseconds
>>>>>>>>>>>>> 325    observationTimeNanoseconds
>>>>>>>>>>>>> Regards, Benoit.
>>>>>>>>>>>>>>>     The Exporting Process SHOULD export the Data Record specified by the
>>>>>>>>>>>>>>>     Exporting Process Reliability Statistics Option Template on a regular
>>>>>>>>>>>>>>>     basis or based on some export policy.  This periodicity or export
>>>>>>>>>>>>>>>     policy SHOULD be configurable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id
>>>>>>>>>>>>>>> 1. there is a meteringProcessId in IPFIX IANA while there is no cache id
>>>>>>>>>>>>>> meteringProcessId should do the job.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId?
>>>>>>>>>>>>>>>      [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
>>>>>>>>>>>>>>>      From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process.
>>>>>>>>>>>>>>>      If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below
>>>>>>>>>>>>>> See reply to Pauls mail.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Gerhard
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 4.3.  Cache Class
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>      +-----------------------------------+
>>>>>>>>>>>>>>>      | Cache                             |
>>>>>>>>>>>>>>>      +-----------------------------------+        1 +------------------+
>>>>>>>>>>>>>>>      | name                              |<>--------| immediateCache/  |
>>>>>>>>>>>>>>>      | dataRecords {readOnly}            |          | timeoutCache/    |
>>>>>>>>>>>>>>>      | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
>>>>>>>>>>>>>>>      |                                   |          | permanentCache   |
>>>>>>>>>>>>>>>      |                                   |          +------------------+
>>>>>>>>>>>>>>>      |                                   |
>>>>>>>>>>>>>>>      |                                   |     0..* +------------------+
>>>>>>>>>>>>>>>      |                                   |--------->| ExportingProcess |
>>>>>>>>>>>>>>>      +-----------------------------------+          +------------------+
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                            Figure 12: Cache class
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What do you think? Do you see another way?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards, Paul&    Benoit.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> 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
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--------------090909080106020002050201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi, Benoit and list,

    

    On 09/29/2011 05:59 AM, Benoit Claise wrote:
    

      
      On 28/09/2011 18:47, Brian Trammell wrote:
      

        
Hi, Benoit, all,

        


        

        
Conclusion (from my side): neither.

        


        

        
2. relies on magical templates, which I regard as basically
          poisonous. Being able to know what a template represents
          unambiguously is one of the key strengths of IPFIX.

      

      Agreed.

      

        


        

        
1. is half-magical, so half poisonous. 

      

      And again agreed.

      

      Out of the bad solutions 1 and 2, we have to chose one.

      

        
The timestamps carry no semantics identifying that they
          have to do with a window during which loss occurred. We could
          I suppose change the definition of ignored*count to say "if
          present, timestamps in the same record identify the outer
          bounding window of the loss event(s)" or similar.

        


        

        
I suggest 3. drop the timestamps completely, 

      

      Sure, the IPFIX specifications will look fine, but we're
      postponing the problems.

    

    

    Benoit could you elaborate on what problems we are postponing?  This
    is not clear to me.

    

    

      

        
or 4. define loss window timestamps. 

        

      

      Proposal 5.  Keep for a single point in time observation 

      
322    observationTimeSeconds

        323    observationTimeMilliseconds

        324    observationTimeMicroseconds

        325    observationTimeNanoseconds

      

    

    Seems reasonable.

    

    The more I have looked at this template the less clear I have been
    on the reason for the two timestamps.  On my initial read I thought
    they bounded a window during which the most recent set of errors
    occurred.  However, as I read more (and reread) it occurred to me
    that the counters are both total counters.  This seems to imply that
    the first timestamp is the first ignored[Packet|Octet] observed 
    since metering process start.  Resending first ignored over and over
    again seems to have little if any benefit.

    

    There is, however, probably some detail(s) that I have not fully
    grokked.

    

    Thanks for any clarification,

    -Andrew

    

    

    
     
      Have to new series of observation times

      


        .           observationStartTimeSeconds

        .           observationStartTimeMilliseconds

        .           observationStartTimeMicroseconds

        .           observationStartTimeNanoseconds

        

        .           observationEndTimeSeconds

        .           observationEndTimeMilliseconds

        .           observationEndTimeMicroseconds

        .           observationEndTimeNanoseconds

        

      

      Regards, Benoit.

      


      

      

        


        

        
Cheers, 

        


        

        
Brian

        


          Sent from my iPhone

        


          On 28.09.2011, at 18:06, Benoit Claise <bclaise@cisco.com>

          wrote:

          

        

        

        

          
 Dear all,

            

            Let me restate what I put in my initial email:

            
Well. Two solutions:

              1. we duplicate all the IEs to have the exact correct
              semantic. 

                 
              ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds]



              ... and potentially some more such as pre|post

                  This brings multiple new dimensions to IE and will
              lead to an explosion of IEs if we want to cover all the
              case

              2. the collector tests the possible combination of IE in
              the Options Template Record.

                  For example, if the collector sees such an Options
              Template Record, it knows that this a "The Metering
              Process Reliability Statistics Options Template"
              
  observationDomainId (scope)
  meteringProcessId (scope)
  ignoredPacketTotalCount
  ignoredOctetTotalCount
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds




            

            And I'm not sure what's the conclusion of this email thread
            is...

            

            Regards, Benoit.

            

              
On Sep 28, 2011, at 12:42 AM, Paul Aitken wrote:



              

                
Brian,



                

                  
Hi, Paul, all,

I suppose I should state for the sake of completeness that this is the first I've ever actually _thought_ about the MPRSO. I find the whole use case for it rather dubious -- it presumes an MP with somehow trustworthy knowledge about packet loss, which is never the case, and relying on such information at the collector side for anything other than entertainment purposes is fraught with peril -- so I saw the MAY on section 4 in 5101, was thankful it wasn't a MUST I had to fight against and/or simply ignore, and never looked back.

That said, it does make sense to fix, since it's there.

On Sep 27, 2011, at 10:25 PM, Paul Aitken wrote:



                  

                    
How do you know that the received template is a MPRSO?


                  

                  
Does it matter? Seriously, what is the difference between "an MPRSO" and "a template containing information about lost packets for a given time interval, along with maybe some other information"? Do we actually want to require an MP to keep time interval information for loss? Wouldn't those resources be better deployed not losing packets in the first place? So let's say I want to report missing packets, but don't have information about when I lost them. Do I have to throw a timestamp in there anyway in order for it to be "an MPRSO"?

I think these are arguments against having the timestamps at all (or to include them, with a further instruction that they are optional).


                

                
When a MP knows that it failed to meter some packets, it must have a way of reporting this which the CP can understand correctly. So it matters in that the CP has to understand the implicit "lost traffic" semantic and potentially take action, perhaps involving reports or alarm bells.


              

              
That's an argument for the following template:

  observationDomainId {scope}
  meteringProcessId {scope}
  ignoredPacketTotalCount

Which, in my opinion, is a pretty good starting point.

You can add ignoredOctetTotalCount if you actually know it. Calculating it at libpcap-based MPs like YAF, for example, would involve a little work and generate a bad number: you only get a guess from the kernel how many packets it dropped and no information about how big they are. You can infer octet loss by looking at TCP sequence numbers but now we're back to clear overengineering I think. Maybe on ASIC or FPGA based measurement systems you get good total counters and can measure loss subtractively... But I personally wouldn't waste the real estate on it unless it was a hard requirement.

Again, if you know the timestamps, you can add them. But for the general case as I see it, your fidelity per IE for the template in 5101 is as follows:

perfect:                observationDomainId {scope}
 (i hope you know this) meteringProcessId {scope}

reasonably good guess:  ignoredPacketTotalCount

poor to fair guess:     ignoredOctetTotalCount
 (dep. on HW support)

poor to good guess:     a start timestamp of indeterminate IE
 (dep. on HW support)   an end timestamp of indeterminate IE



              

                

                  

                    
   - must the fields be exactly in the specified order and no other combination in order to be a valid MPRSO?


                  

                  
This isn't a valid template recognition strategy in IPFIX. At least, it hasn't been to date, and it's a bad idea to make it so. IE-Doctors contains language meant to instruct IPFIX application authors to refrain from specifying such magic templates.


                

                
Great; I'm pleased to hear it. Magic templates lead to inflexible collectors, which in turn lead to bug reports against the EP?!




                

                  

                    
   - how do you know which of the observationTime* elements (or missingObservationWindowEdge elements) is the first and which is the last?
       - only from their position in the template (so, field order and position are crucial)
       - by comparing them (so field order and position aren't important)


                  

                  
Time intervals can be treated as a special case, here, since time can generally be assumed to go in only one direction. "The time interval from A to B" is completely equivalent to "the time interval from B to A", so one could argue order doesn't matter. (We don't argue that anywhere in IPFIX, to be true. But what do I do when I get a flow with an endTime before the startTime?)


                

                
When the timestamp wraps. The time between 11pm and 1am is 2 hours, while the time between 1am and 11pm is 22 hours.


              

              
We don't have any timestamps that only carry time information. They've all got implied dates (either based on the 1970 epoch for the UNIX-like timestamps, or on either the NTP or the UNIX epoch for the 1305 timestamps (we'll need to fix this in 5101bis), and there is no specified wrapping behavior as yet. You only hit this problem in 2038, then, and when you do, you've got bigger problems.



              

                

                  

                    
Suppose a mediator adds, removes, or re-orders the fields.
   - does this invalidate the MPRSO?
   - how does a mediator know not to do this?
   - how does the collector cope if a mediator does?


                  

                  
These questions seem to apply only to the case where MPRSO is magical. I'm trying to define it such that it isn't.


                

                
I'm trying to get to the core of what constitues a valid, recognisable MPRSO. Put another way, what's the closest thing to an MPRSO that isn't an MPRSO?


              

              
I'm saying that it doesn't matter. Sure, 5101bis should give recommendations for the template an exporting process uses for this information, but any time a CP sees a template that's scoped to something that ID's an MP that contains loss counter IEs, it's an MPRSO. 



              

                
If I use ignoredPacketTotalCount and ignoredOctetTotalCount in another template, does it become an MPRSO?


              

              
Depends. Are you binding them to a scope that identifies a metering process? You could also export them in a flow or "flexible flow"/flow aggregate, at which point you're giving very detailed error information. And the collector can infer whatever it wants about total reliability based on _that_...



              

                
If we ignore what is and what isn't an MPRSO for the moment, how exactly should a MP tell a CP about the traffic it knows it didn't meter?


              

              
Using something much like the MPRSO as defined by 5101... I'm just trying to lead us away from thinking of a "bright line" between MPRSO and not-MPRSO, because 



              

                

                  

                    
The change to "missingObservationWindowEdge" is simply a rename of observationTime. I don't see that it adds anything.


                  

                  
observationTime already has a meaning. "This Information Element specifies the absolute time in seconds of an observation." In other words, "I saw the thing I'm talking about in this record at the specified time". It has never to date been specified in such a way that it means "I saw the thing I'm talking about in this record at the specified time, unless the record contains two observationTimes, in which case I saw the thing in the time interval between those two things".


                

                
Then you're saying that it's invalid to have two different observationTime values in a flow record, because you can't observe an event at two different times.


              

              
Well.... yes, this is a bit ambiguous.



              

                
Thinking about it some more, I suppose this reports multiple instances of the observation with an AND semantic: I saw this at T1 AND at T2 (since other semantics don't make sense).
Think if these were interfaces: the meaning would be "observed at int1 and int2", rather than "observed from int1 to int2".
So I've convinced myself to agree that 2 x observationTime don't make sense.


              

              
(I'm trying to think of cases where it would be, but I don't think any are illustrative for this discussion...)



              

                

                  
missingObservationWindowEdge means "there is missing information within an interval described between this IE and the other identical IE in the record". If we keep the MPRSO defined as it is (and fix it only by dropping in , missingObservationWindowStartSeconds and missingObservationWindowEndSeconds, since it's more IPFIXish, but there was concern voiced in this thread about IE space explosion, so I figured we could exploit the nature of time and cut down on the IEs required by half.

The advantage of a new IE is that it isn't overloaded, but more importantly that it does not lead to an ambiguous interpretation of the entire template at the collector.


                

                
Unfortunately WindowEdge is ambiguous in the wrap case, whereas start and end aren't.


              

              
(see above on wrapping)



              

                

                  

                    
A long basicList isn't the right solution because
   - various list lengths mean there are multiple possible templates making the detection of the MPRSO a little more difficult
      ie, it's no longer a fixed template, nor a combination of a few possibilities, but a great many different possible templates.
   - there are two different semantics for the start and end of the window, so it's actually an ordered list of pairs ie a subTemplateList.
Lists can have zero elements. However, if you want to report that nothing was lost, the ignored*Count = 0 report should indicate the start and end of the 100% period. A list length of zero doesn't tell when stuff was or was not lost - so it's of limited usefulness, unless perhaps as a total figure? Again, see questions above about what is / is not a valid MPRSO.


                  

                  
I withdraw my basicList comment; it was essentially just "thinking aloud", and I didn't actually intend to include a mention of it in the 5101bis MPRSO. 1. It doesn't really add anything to the original intent of the MPRSO, and 2. adding it in 5101bis would cause 5101bis to have a normative dependency on 6313, which is a terrible idea.


                

                
+1. I already discussed with Benoit about using an ordered list or STL of observationTime, and discounted it for this reason.


              

              
Yay! At least we emphatically agree on _something_. ;)

Cheers,

Brian



              

                

                  

                    
On 27/09/11 18:30, Andrew Feren wrote:


                    

                      
Hi Brian,

Well stated.

Additional comments inline

On 09/27/2011 12:15 PM, Brian Trammell wrote:


                      

                        
Greetings, all,

This is a little bit of an abuse of the ordering of IEs, in my opinion, and of the general rule that only IEs, and the scope in which they are defined, carry semantics. Even for templates which are defined within Standards Track RFCs, the records defined by the template should be decipherable without reference to the RFC. Put another way, we should not define magical templates, and this template as proposed looks pretty magical.


                      

                      
Yes, a black magic sort of magical.  We have been discussing this proposed change in the office and coming to the same conclusion.


                      

                        
Without reading the text of this thread, and following basically everything we've ever said about multiple IEs in a record, I would interpret a record matching this template as follows:

For the metering process A and observation domain B:
N packets were ignored; these contained a total of M octets.
The first observation at this metering process was at time T0.
The second observation at this metering process was at time T1.


                      

                      
This was exactly how I interpreted this template until I read the updated draft and saw the bit about "the Collecting Process MUST determine which is the oldest and the most recent timestamp in order the determine the right semantic ...."



                      

                        
This is quite far from the stated intention. I would strongly suggest that we not so lightly give up on "templates should be unambiguously understandable" requirement, even if the exception itself lives in the core protocol document.

I would suggest, if you want to do a multiple IE solution here, you define something like missingObservationWindowEdge, and have two of them:

  observationDomainId {scope}
  meteringProcessId {scope}
  ignoredPacketTotalCount
  ignoredOctetTotalCount
  missingObservationWindowEdge
  missingObservationWindowEdge

This has the advantage that you can have a long basicList of window edges in order to define multiple missing observation windows; each edge pair is a loss window.


                      

                      
I like this suggestion, and I have a few additional thoughts.

Perhaps the basic list of edge times should either be limited to only one pair or the ignored*TotalCount IEs needs to be in a basiclist with N entries too.

How about observationWindowEdge instead (no "missing") to be more generally useful.

I think a list of time edges also works neatly when sending this template at regular intervals (which SHOULD be done).  When the ignored*TotalCount IEs are zero, an empty list makes sense for edge times.




                      

                        
Seconds suffice for these, I think. You might want to do one in milliseconds. But if you have the resources to calculate your packet loss window to nanosecond precision without having the resources to not lose packets, I humbly submit you've picked the wrong engineering tradeoffs. :)


                      

                      
Unless window edge isn't defined specifically for "missing" values.  Then the higher precision timestamps might have some use.

-Andrew


                      

                        
Best regards,

Brian

On Sep 23, 2011, at 11:07 PM, Andrew Feren wrote:



                        

                          
Yes, this makes sense.

I gave this some thought and I don't have a better suggestion.  I also agree that even though the flow[Start|End]* collection of IEs conveniently has one IE for both first and last, observationTime* is the more correct choice here.

-Andrew

On 09/22/2011 03:54 AM, Benoit Claise wrote:


                          

                            
Hi Andrew,


                            

                              
Hi Benoit,

I had the same thought about using

322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds

The problem is that you need two timestamps in the same record (first and last).  How does that work with the above?


                            

                            
Excellent question. We debated this question with Paul Aitken recently.
Let me rephrase the question slightly differently: how does the collector determine that this is a "The Metering Process Reliability Statistics Options Template", and understands the semantic of the two counters?
Well. Two solutions:
1. we duplicate all the IEs to have the exact correct semantic.
    ObservationTime[packet|flow][first|last][Seconds|Milliseconds|Microseconds|Nanoseconds] ... and potentially some more such as pre|post
    This brings multiple new dimensions to IE and will lead to an explosion of IEs if we want to cover all the case
2. the collector tests the possible combination of IE in the Options Template Record.
    For example, if the collector sees such an Options Template Record, it knows that this a "The Metering Process Reliability Statistics Options Template"
  observationDomainId (scope)
  meteringProcessId (scope)

  ignoredPacketTotalCount
  ignoredOctetTotalCount
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds
  observationTimeSeconds | observationTimeMilliseconds | observationTimeMicroseconds | observationTimeNanoseconds


While the solution 2 is not perfect, this was the chosen track.

Does it make sense?

Regards, Benoit


                            

                              
-Andrew

On 09/21/2011 07:11 PM, Benoit Claise wrote:


                              

                                
Hi Gerhard,

Thanks for your reply.
See in line.


                                

                                  
Hi Benoit,

See comments inline.

On 20.09.2011 16:19, Benoit Claise wrote:


                                  

                                    
Dear all,

[this email addresses draft-claise-ipfix-protocol-rfc5101bis-00.txt,  TO DO ->   "time first flow dropped" and "time last flow dropped" inconsistency.  See the discussion on the list.]

Paul Aitken discovered this issue.,

>From [RFC5101], section 4.3. The Exporting Process Reliability Statistics Option Template

time first flow dropped
                        The timestamp of the first Flow was dropped by
                        the Metering Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

time last flow dropped
                        The timestamp of the last IP packet that was
                        ignored by the Metering Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.


Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o

Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".

Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter?

Here is a proposal for 4.2 and 4.3. The underlined parts are new

4.2.  The Metering Process Reliability Statistics Option Template



   The Metering Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [
RFC5102
]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.



   meteringProcessId (*)
                           The identifier of the Metering Process for
                           which lack of reliability is reported.  There
                           This Information Element MUST be defined as a
                           Scope Field.


   ignoredPacketTotalCount
                           The total number of IP packets that the
                           Metering Process did not process.

   ignoredOctetTotalCount
                           The total number of octets in observed IP
                           packets that the Metering Process did not
                           process.

   time first
packet
ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last
packet
ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.



                                  

                                  
I do not find these IEs in RFC5102.


                                

                                
Which ones?  flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds
There are in http://www.iana.org/assignments/ipfix/ipfix.xml
However, re-reading
   time first packet
ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last
packet
ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.

And http://www.iana.org/assignments/ipfix/ipfix.xml for the "flowEnd" timestamp IE,
I now believe that we should be using this series of IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds



                                

                                  

                                    
4.3.  The Exporting Process Reliability Statistics Option Template


   The Exporting Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Exporting process.  It SHOULD contain the following Information
   Elements that are defined in [
RFC5102
]:

   Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [
RFC5102
] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.

   notSentFlowTotalCount
                        The total number of Flows that were generated by
                        the Metering Process and dropped by the Metering
                        Process or by the Exporting Process instead of
                        being sent to the Collecting Process.

   notSentPacketTotalCount
                        The total number of packets in Flow Records that
                        were generated by the Metering Process and
                        dropped by the Metering Process or by the
                        Exporting Process instead of being sent to the
                        Collecting Process.

   notSentOctetTotalCount
                        The total number of octets in packets in Flow
                        Records that were generated by the Metering
                        Process and dropped by the Metering Process or
                        by the Exporting Process instead of being sent
                        to the Collecting Process.

   time first flow dropped

                      The time at which the first Flow Record was dropped by
                        the
Exporting Process.
  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

   time last flow dropped

The time at which the last Flow Record was
                        dropped by the Exporting Process
.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.



                                  

                                  
Again, I do not find these IEs in RFC5102.


                                

                                
Same remark, I believe we should be using for the two previous IEs
322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds
Regards, Benoit.


                                

                                  

                                    
   The Exporting Process SHOULD export the Data Record specified by the
   Exporting Process Reliability Statistics Option Template on a regular
   basis or based on some export policy.  This periodicity or export
   policy SHOULD be configurable.





(*) regarding the meteringProcessId, we were hesitating between the meteringProcessId and the cache id
1. there is a meteringProcessId in IPFIX IANA while there is no cache id


                                  

                                  
meteringProcessId should do the job.



                                  

                                    
2. if the IPFIX exporter is configured from [IPFIX-CONF], what should be the value in meteringProcessId?
    [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache name.
    From figure 1 and 2, it seems that there is a one to one matching between the cache and the metering process.
    If this is the case, a solution could be to add a meteringProcess inside the cache in the figure 12 in [IPFIX-CONF] below


                                  

                                  
See reply to Pauls mail.

Regards,
Gerhard



                                  

                                    
4.3.  Cache Class


    +-----------------------------------+
    | Cache                             |
    +-----------------------------------+        1 +------------------+
    | name                              |<>--------| immediateCache/  |
    | dataRecords {readOnly}            |          | timeoutCache/    |
    | cacheDiscontinuityTime {readOnly} |          | naturalCache/    |
    |                                   |          | permanentCache   |
    |                                   |          +------------------+
    |                                   |
    |                                   |     0..* +------------------+
    |                                   |--------->| ExportingProcess |
    +-----------------------------------+          +------------------+

                          Figure 12: Cache class

What do you think? Do you see another way?

Regards, Paul&   Benoit.


_______________________________________________
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


                            

                          

                          
_______________________________________________
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


            

            

          

        

      

      

      

      

      

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


    

    

  


--------------090909080106020002050201--

From n.brownlee@auckland.ac.nz  Thu Sep 29 15:08:12 2011
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 665AE21F8C47 for ; Thu, 29 Sep 2011 15:08:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.93
X-Spam-Level: 
X-Spam-Status: No, score=-102.93 tagged_above=-999 required=5 tests=[AWL=-0.331, 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 j6YX+fs5UFse for ; Thu, 29 Sep 2011 15:08:11 -0700 (PDT)
Received: from mx1-int.auckland.ac.nz (mx1-int.auckland.ac.nz [130.216.12.40]) by ietfa.amsl.com (Postfix) with ESMTP id F0BEC21F8C06 for ; Thu, 29 Sep 2011 15:08:10 -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=1317334264; x=1348870264; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4E84ECEF.6010605@auckland.ac.nz>|Date:=20 Fri,=2030=20Sep=202011=2011:10:55=20+1300|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20Benoit=20Claise=20|CC:=20 IETF=20IPFIX=20Working=20Group=20 |Subject:=20Re:=20[IPFIX]=20proposal=20for=20IPFIX=20char ter=20update|References:=20=20<4E6D1E73.9@net.in.tum.de>=20<4E8323E6.8080305@cis co.com>|In-Reply-To:=20<4E8323E6.8080305@cisco.com> |Content-Transfer-Encoding:=207bit; bh=2HK/Mkme5AXBKolyLjinrPXgrsWmyDWVOMgParYVyWA=; b=MGzktxxgKc33Kob20q6Hw+33puPb6DLQ9zIdjekKJ3auLyqRuYTXK/fk RjyuFLDfXlmG57CI0uxSfD2n0cHCG2xxkggUte66Xa12QJOW/1N7UXjEa daRC6QDBNwEqyz7ORNphQSW4wKtTRXDk3Ndweh9PJrM9lKm2jPAI5TSly 4=;
X-IronPort-AV: E=Sophos;i="4.68,463,1312113600"; d="scan'208";a="101191109"
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 mx1-int.auckland.ac.nz with ESMTP; 30 Sep 2011 11:10:56 +1300
Message-ID: <4E84ECEF.6010605@auckland.ac.nz>
Date: Fri, 30 Sep 2011 11:10:55 +1300
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: Benoit Claise 
References:  <4E6D1E73.9@net.in.tum.de> <4E8323E6.8080305@cisco.com>
In-Reply-To: <4E8323E6.8080305@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] proposal for IPFIX charter update
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, 29 Sep 2011 22:08:12 -0000

Hi all:

Juergen posted the proposed new IPFIX charter at the end of August.
I've only seen one comment on it, which was "what happened to the
Link Layer IEs draft?"

Looking at the minutes from our meeting in Quebec, we said
"We discussed whether this could be a 'trial run for the
IE Doctors,' or a WG item.  We reached consensus for it as a WG item,
with the proviso that it will need views from Layer 2 domain experts,
e.g. IEEE 802.1."

So Juergen, please add this as one more charter item.

With that, I think we're ready to ask Dan to take it to IESG for
approval.

Cheers, Nevil

PS: it's really good to see lots of discussion on the IPFIX list
     about improvements to 5101 et al :-)


On 29/09/11 2:40 AM, Benoit Claise wrote:
> IPFIX chairs,
>>
>> Hi Juergen,
>>
>> The IPFIX configuration data model is pending because of the IPFIX and
>> PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of highest
>> priority, and a solution be published before any other new draft.
> I agree.
>
> Btw, where is the new charter? ;-) There is always a tendency to delay
> work for which there is no deadlines...
>
> Regards, Benoit.
>> (I already see IPFIX config being outdated by RFC5101/5102bis before
>> it ever becomes RFC...)
>>
>> Regards,
>> Gerhard
>>
>>
>> On 29.08.2011 06:57, Juergen Quittek wrote:
>>> Dear all,
>>>
>>> At our session in Quebec we discussed candidates
>>> for new IPFIX work items. Based on this discussion,
>>> Nevil and I drafted an update of our charter that
>>> you can find below.
>>>
>>> Please have a look at it and send us your comments.
>>>
>>> Thanks,
>>>
>>> Juergen
>>>
>>>
>>> IP Flow Information Export (ipfix)
>>>
>>>
>>> Description of Working Group
>>>
>>>
>>> The IPFIX working group has specified the information model (to describe
>>> IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX
>>> exporters to collectors). Several implementers have already built
>>> applications using the IPFIX protocol. As a result of a series of IPFIX
>>> interoperability testing events the WG has produced guidelines for IPFIX
>>> implementation and testing as well as recommendations for handling
>>> special cases such as bidirectional flow reporting and reducing
>>> redundancy in flow records.
>>>
>>> The IPFIX WG has developed a mediation framework, that defines IPFIX
>>> mediators for processing flow records for various purposes including
>>> aggregation, anonymization, etc. For configuring IPFIX devices, a YANG
>>> module has been developed.
>>>
>>> 1. Having a solid standardized base for IPFIX deployment and operation
>>> and several exiting implementations, the IPFIX WG will revisit the IPFIX
>>> protocol specifications (RFC 5101) and the IPFIX information element
>>> specification (RFC 5102) in order to advance them to draft standard.
>>>
>>> 2. For giving guidelines to developers of new IPFIX information
>>> elements and for better defining the process of registering new
>>> information elements at IANA the IPFIX WG will create an information
>>> element developers guideline document.
>>>
>>> 3. The export of IPFIX flow records from IPFIX mediators introduces a
>>> set of potential issues at the protocol level, such as the loss of
>>> information on the original exporter, loss of base time information,
>>> loss of original options template information, etc. The IPFIX WG will
>>> define common ways to deal with these issues, by specifying guidelines
>>> for the use of the IPFIX protocol on IPFIX mediators.
>>>
>>> 4. For supporting the aggregation of flow records at IPFIX mediators
>>> the IPFIX WG will define how to export aggregated flow information using
>>> IPFIX. An aggregated flow is essentially an IPFIX flow representing
>>> packets from multiple original Flows sharing some set of common
>>> properties.
>>>
>>> 5. The IPFIX WG will investigate the use of the IPFIX protocol for
>>> exporting
>>> MIB objects, avoiding the need to define new IPFIX information elements
>>> for existing management information base objects that are already fully
>>> specified. This method requires the specification of new template set
>>> and options template sets to allow the export of MIB objects along
>>> with IPFIX information elements.
>>>
>>> 6. The IPFIX MIB module (RFC 5815) defined a way to register packet
>>> selector functions at IANA. The WG agreed that another method would
>>> be preferable that requires a minor change of RFC 5815. The IPFIX WG
>>> will produce a new version of RFC 5815 with small modifications of
>>> the IANA actions and DESCRIPTION clauses in the the MIB modules.
>>>
>>> Oct 2011 Publish draft on guidelines for IE doctors
>>> Oct 2011 Publish draft on IPFIX use at mediators
>>> Oct 2011 Publish draft on intermediate aggregation
>>> Oct 2011 Publish draft on exporting MIB objects
>>> Oct 2011 Publish draft on data link IEs
>>> Dec 2011 Publish draft revising RFC 5101
>>> Dec 2011 Publish draft revising RFC 5102
>>>
>>> Apr 2012 Submit guidelines for IE doctors for publication as
>>> Informational BCP RFC
>>> Apr 2012 Submit draft on IPFIX use at mediators for publication as
>>> Standards track RFC
>>> Apr 2012 Submit draft on intermediate aggregation for publication as
>>> Standards track RFC
>>> Apr 2012 Submit draft on data link IEs for publication as Standards
>>> track RFC
>>> Apr 2012 Submit draft revising RFC 5101 for publication as Standards
>>> track RFC
>>> Apr 2012 Submit draft revising RFC 5102 for publication as Standards
>>> track RFC
>>> Sep 2012 Submit draft on exporting MIB objects for publication as
>>> Standards track RFC
>>>
>>>
>>> _______________________________________________
>>> 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


-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

From Quittek@neclab.eu  Fri Sep 30 00:16:04 2011
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 7FF3E21F8C21 for ; Fri, 30 Sep 2011 00:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.378
X-Spam-Level: 
X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 D9JZvpcMuJ+a for ; Fri, 30 Sep 2011 00:16:03 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 40E1821F8C2B for ; Fri, 30 Sep 2011 00:15:37 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A4B63280001D9; Fri, 30 Sep 2011 09:18:29 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWcOTmpSAuIR; Fri, 30 Sep 2011 09:18:29 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 86F94280001D6; Fri, 30 Sep 2011 09:18:14 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.240]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 30 Sep 2011 09:18:14 +0200
From: Juergen Quittek 
To: Nevil Brownlee , Benoit Claise 
Thread-Topic: [IPFIX] proposal for IPFIX charter update
Thread-Index: AQHMf0EdRtxQtjbCZEKS2DVE78xKwg==
Date: Fri, 30 Sep 2011 07:18:13 +0000
Message-ID: 
In-Reply-To: <4E84ECEF.6010605@auckland.ac.nz>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.1.2.219]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] proposal for IPFIX charter update
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: Fri, 30 Sep 2011 07:16:04 -0000

Nevil,

Thanks for the summary.
I will post a new version of the charter at the weekend.

    Juergen

On 30.09.11 00:10, "Nevil Brownlee"  wrote:

>
>Hi all:
>
>Juergen posted the proposed new IPFIX charter at the end of August.
>I've only seen one comment on it, which was "what happened to the
>Link Layer IEs draft?"
>
>Looking at the minutes from our meeting in Quebec, we said
>"We discussed whether this could be a 'trial run for the
>IE Doctors,' or a WG item.  We reached consensus for it as a WG item,
>with the proviso that it will need views from Layer 2 domain experts,
>e.g. IEEE 802.1."
>
>So Juergen, please add this as one more charter item.
>
>With that, I think we're ready to ask Dan to take it to IESG for
>approval.
>
>Cheers, Nevil
>
>PS: it's really good to see lots of discussion on the IPFIX list
>     about improvements to 5101 et al :-)
>
>
>On 29/09/11 2:40 AM, Benoit Claise wrote:
>> IPFIX chairs,
>>>
>>> Hi Juergen,
>>>
>>> The IPFIX configuration data model is pending because of the IPFIX and
>>> PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of highest
>>> priority, and a solution be published before any other new draft.
>> I agree.
>>
>> Btw, where is the new charter? ;-) There is always a tendency to delay
>> work for which there is no deadlines...
>>
>> Regards, Benoit.
>>> (I already see IPFIX config being outdated by RFC5101/5102bis before
>>> it ever becomes RFC...)
>>>
>>> Regards,
>>> Gerhard
>>>
>>>
>>> On 29.08.2011 06:57, Juergen Quittek wrote:
>>>> Dear all,
>>>>
>>>> At our session in Quebec we discussed candidates
>>>> for new IPFIX work items. Based on this discussion,
>>>> Nevil and I drafted an update of our charter that
>>>> you can find below.
>>>>
>>>> Please have a look at it and send us your comments.
>>>>
>>>> Thanks,
>>>>
>>>> Juergen
>>>>
>>>>
>>>> IP Flow Information Export (ipfix)
>>>>
>>>>
>>>> Description of Working Group
>>>>
>>>>
>>>> The IPFIX working group has specified the information model (to
>>>>describe
>>>> IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX
>>>> exporters to collectors). Several implementers have already built
>>>> applications using the IPFIX protocol. As a result of a series of
>>>>IPFIX
>>>> interoperability testing events the WG has produced guidelines for
>>>>IPFIX
>>>> implementation and testing as well as recommendations for handling
>>>> special cases such as bidirectional flow reporting and reducing
>>>> redundancy in flow records.
>>>>
>>>> The IPFIX WG has developed a mediation framework, that defines IPFIX
>>>> mediators for processing flow records for various purposes including
>>>> aggregation, anonymization, etc. For configuring IPFIX devices, a YANG
>>>> module has been developed.
>>>>
>>>> 1. Having a solid standardized base for IPFIX deployment and operation
>>>> and several exiting implementations, the IPFIX WG will revisit the
>>>>IPFIX
>>>> protocol specifications (RFC 5101) and the IPFIX information element
>>>> specification (RFC 5102) in order to advance them to draft standard.
>>>>
>>>> 2. For giving guidelines to developers of new IPFIX information
>>>> elements and for better defining the process of registering new
>>>> information elements at IANA the IPFIX WG will create an information
>>>> element developers guideline document.
>>>>
>>>> 3. The export of IPFIX flow records from IPFIX mediators introduces a
>>>> set of potential issues at the protocol level, such as the loss of
>>>> information on the original exporter, loss of base time information,
>>>> loss of original options template information, etc. The IPFIX WG will
>>>> define common ways to deal with these issues, by specifying guidelines
>>>> for the use of the IPFIX protocol on IPFIX mediators.
>>>>
>>>> 4. For supporting the aggregation of flow records at IPFIX mediators
>>>> the IPFIX WG will define how to export aggregated flow information
>>>>using
>>>> IPFIX. An aggregated flow is essentially an IPFIX flow representing
>>>> packets from multiple original Flows sharing some set of common
>>>> properties.
>>>>
>>>> 5. The IPFIX WG will investigate the use of the IPFIX protocol for
>>>> exporting
>>>> MIB objects, avoiding the need to define new IPFIX information
>>>>elements
>>>> for existing management information base objects that are already
>>>>fully
>>>> specified. This method requires the specification of new template set
>>>> and options template sets to allow the export of MIB objects along
>>>> with IPFIX information elements.
>>>>
>>>> 6. The IPFIX MIB module (RFC 5815) defined a way to register packet
>>>> selector functions at IANA. The WG agreed that another method would
>>>> be preferable that requires a minor change of RFC 5815. The IPFIX WG
>>>> will produce a new version of RFC 5815 with small modifications of
>>>> the IANA actions and DESCRIPTION clauses in the the MIB modules.
>>>>
>>>> Oct 2011 Publish draft on guidelines for IE doctors
>>>> Oct 2011 Publish draft on IPFIX use at mediators
>>>> Oct 2011 Publish draft on intermediate aggregation
>>>> Oct 2011 Publish draft on exporting MIB objects
>>>> Oct 2011 Publish draft on data link IEs
>>>> Dec 2011 Publish draft revising RFC 5101
>>>> Dec 2011 Publish draft revising RFC 5102
>>>>
>>>> Apr 2012 Submit guidelines for IE doctors for publication as
>>>> Informational BCP RFC
>>>> Apr 2012 Submit draft on IPFIX use at mediators for publication as
>>>> Standards track RFC
>>>> Apr 2012 Submit draft on intermediate aggregation for publication as
>>>> Standards track RFC
>>>> Apr 2012 Submit draft on data link IEs for publication as Standards
>>>> track RFC
>>>> Apr 2012 Submit draft revising RFC 5101 for publication as Standards
>>>> track RFC
>>>> Apr 2012 Submit draft revising RFC 5102 for publication as Standards
>>>> track RFC
>>>> Sep 2012 Submit draft on exporting MIB objects for publication as
>>>> Standards track RFC
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
>
>--=20
>---------------------------------------------------------------------
>  Nevil Brownlee                    Computer Science Department | ITS
>  Phone: +64 9 373 7599 x88941             The University of Auckland
>  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
>_______________________________________________
>IPFIX mailing list
>IPFIX@ietf.org
>https://www.ietf.org/mailman/listinfo/ipfix