From nobody Mon Feb 1 00:23:33 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A26D1A8A3E for ; Mon, 1 Feb 2016 00:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTOOpBwExWrV for ; Mon, 1 Feb 2016 00:23:29 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2BD1A8A23 for ; Mon, 1 Feb 2016 00:23:29 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2EB1D74B; Mon, 1 Feb 2016 09:23:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lHqSLEz_Thuv; Mon, 1 Feb 2016 09:23:25 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 1 Feb 2016 09:23:25 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 678482002C; Mon, 1 Feb 2016 09:23:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ucF_wNL_3B1G; Mon, 1 Feb 2016 09:23:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA1F820013; Mon, 1 Feb 2016 09:23:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D5DD839D1519; Mon, 1 Feb 2016 09:23:22 +0100 (CET) Date: Mon, 1 Feb 2016 09:23:22 +0100 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160201082322.GA10733@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9@AMEXMB01.ds.jdsu.net> <20160127140429.GB56525@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B1903@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160128082904.GA1957@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B2139@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A5B2139@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Result Correlation X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 08:23:32 -0000 Tim, I am not sure I understand your suggestion. What is 'task-action'? What are 'SPs'? Are you suggesting a) to turn ma-task-cycle-id and ma-report-task-cycle-id into a tag list instead of a string (like in the YANG data model) and/or b) to add ma-action-cycle-id (or an equivalent list) to ma-action-obj? I think both make sense. The ma-report-task-cycle-id would then report the set union of ma-task-cycle-id and ma-action-cycle-id. /js On Thu, Jan 28, 2016 at 05:10:59PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > You are correct; I missed the point. Sorry > > I would simply add the correlation tag to the task-action as an option. These get reported in the report so you can use that. I wouldn't think we would need to specify this as it is probably something SPs would control. > > BR, > Tim > > -----Original Message----- > From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, January 28, 2016 2:29 AM > To: Carey, Timothy (Nokia - US) > Cc: Ron Stana; alissa@cooperw.in; lmap@ietf.org > Subject: Re: [lmap] LMAP Result Correlation > > Tim, > > how does this observation related to the discussion? The YANG model includes the task name and the metric URIs in the report. This is inline with ma-report-task-obj in the information model. > > The place where the report YANG data model differs from the information model is the ma-report-task-cycle-id: the YANG data model allows for a set of tags instead of a single cycle-id. > > /js > > On Wed, Jan 27, 2016 at 10:50:12PM +0000, Carey, Timothy (Nokia - US) wrote: > > Juergen, > > > > In the TR-069 data model we report the name of the task (not registry entry) that was used in the report information. This is part of the ma-report-task-obj.... > > > > BR, > > Tim > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, January 27, 2016 8:04 AM > > To: Ron Stana > > Cc: alissa@cooperw.in; lmap@ietf.org > > Subject: Re: [lmap] LMAP Result Correlation > > > > On Tue, Jan 12, 2016 at 05:02:36PM +0000, Ron Stana wrote: > > > Alissa, LMAP Team, > > > Regarding the September 2015 version of A Framework for Large-Scale Measurement of Broadband Performance [LMAP], I am trying to determine how multiple result sets for a given schedule instance/execution can be correlated. > > > I think my questions are best illustrated using a couple scenarios: > > > Scenario #1: > > > > > > 1. Schedule A is configured to execute Monday@ 9:00am for 1 hour > > > > > > 2. Schedule B is configured to execute Tuesday @ 9:00am for 1 hour > > > > > > 3. Both schedules reference the same task and use the same task configurations thus they are measuring the same network measurement but at different times. > > > > > > 4. Intermediate results are sent to the collector periodically while the schedule executes and then final results are sent once it completes. > > > > > > 5. What in the results can be used to know which sets of results belong to a single execution of the same schedule instance (example: Schedule A)? This is my interpretation of LMAP; item #3 seems to address the need. > > > Item 1: The ietf-lmap-report path report/input/date is the time each result set was sent to the collector so that will be unique for each set of results and so cannot be used. > > > Item 2: The report/input/task/name will be the same across the results from the different schedules since they are both executing the same task so that cannot be used. > > > > > > Item 3: The report/input/task/row/start value would be the same across results from a given schedule instance (ie. the Monday run) and yet unique across schedule instances (ie Mon vs Tues run) so it could be used. > > > > > > > > > 6. What in the results can be used to know which sets of results belong to all executions of the same schedule instance (example: Schedule A)? > > > > I think you can configure two different tasks with different tags and since the tags are reported and the task name, you can distinguish things. Whether this is practical or whether it should also be possible to set tags on an action is perhaps something to discuss. > > > > > Scenario #2: > > > While Item #3 above can address part of Scenario #1, it does not address this additional scenario: > > > > > > 1. Schedule A is performing a Performance Monitoring task (ex. TWAMP) and so is configured for immediate and startup execution/events so it should always be running. > > > > > > 2. The task is sending results to the collector periodically during execution. > > > > > > 3. The device hosting the MA is rebooted so the MA restarts the schedule/task execution. Thus the report/input/task/row/start value would be different in the results sent after the restart. > > > > > > 4. Since the same schedule/task definition is producing the results before and after the MA restart, they logically belong to the same schedule execution. > > > > > > 5. What can be used to group the results from before and after the restart together? > > > > I think the mechanism to group measurements belonging logically together tags. Looking at time stamps to group things is likely brittle. > > > > > Adding the schedule name to report/input/task would help but since the schedule name can be reused, it does not infer a specific schedule instance. > > > > While having the schedule name may help in some situations, it won't in others. I think we should rather use tags that have no other meaning. This allows for example to rename schedules etc. In fact, I would prefer not to expose the details how something got scheduled to the collector. It should not matter much to the collector whether I use multiple schedules bound to the same event with one action each or a single schedule bound to the event with multiple concurrent actions. > > > > > Adding something like an 'initial schedule start' to report/input/task, where it is the date/time the schedule started the very first time (thus not changing across MA restarts), seems to provide the needed association between the result sets. This could be abstracted to a 'schedule id' since it could alternatively be a unique id assigned to each schedule by the Controller. > > > > I would rather not put a requirement into the data model that an lmap implementation has to manage persistent state. > > > > > While a custom value like this could be placed in report/input/task/tag or report/input/task/option I wanted to know if a common approach existed or was planned. > > > > I think the tag was designed for this purpose, namely to be able to correlate results that logically belong together. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 1 00:27:54 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2341A8A68 for ; Mon, 1 Feb 2016 00:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51CauvH6Yg9j for ; Mon, 1 Feb 2016 00:27:50 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4251A8A63 for ; Mon, 1 Feb 2016 00:27:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 10BD3F91; Mon, 1 Feb 2016 09:27:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4gcWrCwT2uVP; Mon, 1 Feb 2016 09:27:48 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 1 Feb 2016 09:27:48 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17F292002C; Mon, 1 Feb 2016 09:27:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cYYDiyA1tt4c; Mon, 1 Feb 2016 09:27:47 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8855620013; Mon, 1 Feb 2016 09:27:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 68AA539D1559; Mon, 1 Feb 2016 09:27:46 +0100 (CET) Date: Mon, 1 Feb 2016 09:27:46 +0100 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20160201082746.GB10733@elstar.local> Mail-Followup-To: Ron Stana , "Carey, Timothy (Nokia - US)" , "alissa@cooperw.in" , "lmap@ietf.org" References: <9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9@AMEXMB01.ds.jdsu.net> <20160127140429.GB56525@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B1903@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160128082904.GA1957@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B2139@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "Carey, Timothy \(Nokia - US\)" , "alissa@cooperw.in" , "lmap@ietf.org" Subject: Re: [lmap] LMAP Result Correlation X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 08:27:53 -0000 On Sun, Jan 31, 2016 at 03:36:15PM -0500, Ron Stana wrote: > Juergen, Tim, > > The intention is to be able to identify a set of results in the collector > for each schedule. My understanding is the correlation tag would therefore > need to be provided with the schedule rather than the task. > > This is my interpretation of LMAP, please correct me if it is incorrect: > 1) tasks are predefined by the MA (example, ping, TWAMP,Y.1564, etc) > 2) therefore, if a configuration cannot be sent to the MA containing a task > with a task name that is unknown to the MA > 3) the 'options' object sent within a task should be treated as a way to > change the default parameters for the task from that point forward > 4) a schedule is required to start an instance of a task > 5) the 'options' object sent within the schedule is a way to override the > task parameters for just that schedule > > Thus, if we have a ping test that as 2 parameters (target IP and number of > pings), and a user wants to ping two destinations daily with the same > number of pings, LMAP supports this scenario with the following > configuration: > 1) the 'options' for the Ping task could be used to set the number of pings. > 2) the 'options' for Schedule A could set the target IP to y. This > schedule will run daily. > 3) the 'options' for Schedule B could set the target IP to z. This > schedule will run daily at a time that does not conflict with Schedule A. > > Alternatively the Ping task would not have to be reconfigured at all if > Schedules A and B additionally specified the number of pings in their > 'options'. This is correct. > If this understanding is correct, then to retrieve the results from the > collector for either Schedule A or Schedule B seems to require unique tag > to be specified with the schedule instead of the task. The 'options' > object for the schedule could be used, however it would be more symmetrical > to allow a tag for the schedule since the value would be sent to the > collector in the 'tag' object of the report. I agree that we should allow the definition of additional tags in the action configuration. Tim might have suggested this as well but I was not sure, see my other email. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 1 03:45:51 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D5A1B3120 for ; Mon, 1 Feb 2016 03:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew2er05dqdMX for ; Mon, 1 Feb 2016 03:45:48 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6721B311E for ; Mon, 1 Feb 2016 03:45:48 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DyAQD+RK9W/xUHmMZdGQEBAQEPAQEBAYI+IStSc4hSr0eCEwENgWOGDwKBMzgUAQEBAQEBAX8LhEMBAQMSG14BDAkVViYBBBsah3kBnjuFEpkKAQoBAQEchhGFa4JLMYMrgQ8Flm8BjyWEQoMZhTqKbINSHgEBQoNsiGsBewEBAQ X-IPAS-Result: A2DyAQD+RK9W/xUHmMZdGQEBAQEPAQEBAYI+IStSc4hSr0eCEwENgWOGDwKBMzgUAQEBAQEBAX8LhEMBAQMSG14BDAkVViYBBBsah3kBnjuFEpkKAQoBAQEchhGFa4JLMYMrgQ8Flm8BjyWEQoMZhTqKbINSHgEBQoNsiGsBewEBAQ X-IronPort-AV: E=Sophos;i="5.22,379,1449550800"; d="scan'208,217";a="158714098" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Feb 2016 06:45:46 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 01 Feb 2016 06:45:46 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Mon, 1 Feb 2016 12:45:45 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP virtual interim - February 22, 2016 Thread-Index: AdFc5hWl2Q3q5UYGQJ+qZYlE6/f3uw== Date: Mon, 1 Feb 2016 11:45:45 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BEFFD1A@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BEFFD1AAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP virtual interim - February 22, 2016 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 11:45:50 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEFFD1AAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The Doodle poll for a virtual interim meeting of the LMAP WG in February is= now closed. The result was almost a draw between three options, Jason and = me decided on Monday February 22nd, between noon and 2PM EST, which seems t= o work well for the majority of participants and critical contributors. Ple= ase mark this time slot on your schedules. Webex information will follow. A= s discussed at the interim, the will make a final decision about the meetin= g in the week before the call, function of agenda items and submissions tha= t show progress on the work items. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEFFD1AAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The Doodle poll for a virtual interim meeting of the= LMAP WG in February is now closed. The result was almost a draw between th= ree options, Jason and me decided on Monday February 22nd, betwe= en noon and 2PM EST, which seems to work well for the majority of participants and critical contributors. Plea= se mark this time slot on your schedules. Webex information will follow. As= discussed at the interim, the will make a final decision about the meeting= in the week before the call, function of agenda items and submissions that show progress on the work items.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BEFFD1AAZFFEXMB04globa_-- From nobody Mon Feb 1 10:48:00 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1281B343A for ; Mon, 1 Feb 2016 10:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsXsttXYOJIu for ; Mon, 1 Feb 2016 10:47:53 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EBA1B3439 for ; Mon, 1 Feb 2016 10:47:53 -0800 (PST) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id C785B8702FB4; Mon, 1 Feb 2016 18:47:48 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u11Ilpgq026843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Feb 2016 18:47:52 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u11IloRB029869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Feb 2016 18:47:51 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.82]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 1 Feb 2016 13:47:50 -0500 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder , Ron Stana Thread-Topic: [lmap] LMAP Result Correlation Thread-Index: AQHRWT1zdQZ+9uOJak2nQiJ7JPqUTZ8P9GBggAD43ICAACJXcIAFX9OAgADGywCAAFZ3kA== Date: Mon, 1 Feb 2016 18:47:49 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A5B5748@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9@AMEXMB01.ds.jdsu.net> <20160127140429.GB56525@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B1903@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160128082904.GA1957@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B2139@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160201082746.GB10733@elstar.local> In-Reply-To: <20160201082746.GB10733@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "alissa@cooperw.in" , "lmap@ietf.org" Subject: Re: [lmap] LMAP Result Correlation X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 18:47:57 -0000 Juergen and Ron, My comments in line -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Monday, February 01, 2016 2:28 AM To: Ron Stana Cc: Carey, Timothy (Nokia - US); alissa@cooperw.in; lmap@ietf.org Subject: Re: [lmap] LMAP Result Correlation On Sun, Jan 31, 2016 at 03:36:15PM -0500, Ron Stana wrote: > Juergen, Tim, >=20 > The intention is to be able to identify a set of results in the=20 > collector for each schedule. My understanding is the correlation tag=20 > would therefore need to be provided with the schedule rather than the tas= k. >=20 > This is my interpretation of LMAP, please correct me if it is incorrect: > 1) tasks are predefined by the MA (example, ping, TWAMP,Y.1564, etc) > 2) therefore, if a configuration cannot be sent to the MA containing a=20 > task with a task name that is unknown to the MA > 3) the 'options' object sent within a task should be treated as a way=20 > to change the default parameters for the task from that point forward > 4) a schedule is required to start an instance of a task > 5) the 'options' object sent within the schedule is a way to override=20 > the task parameters for just that schedule >=20 > Thus, if we have a ping test that as 2 parameters (target IP and=20 > number of pings), and a user wants to ping two destinations daily with=20 > the same number of pings, LMAP supports this scenario with the=20 > following > configuration: > 1) the 'options' for the Ping task could be used to set the number of pin= gs. > 2) the 'options' for Schedule A could set the target IP to y. This=20 > schedule will run daily. > 3) the 'options' for Schedule B could set the target IP to z. This=20 > schedule will run daily at a time that does not conflict with Schedule A. >=20 > Alternatively the Ping task would not have to be reconfigured at all=20 > if Schedules A and B additionally specified the number of pings in=20 > their 'options'. This is correct. This is correct if you use the schedule's action (ma-action-obj). A s= chedule by itself doesn't have options - just the scheduled action.=20 > If this understanding is correct, then to retrieve the results from=20 > the collector for either Schedule A or Schedule B seems to require=20 > unique tag to be specified with the schedule instead of the task. The 'o= ptions' > object for the schedule could be used, however it would be more=20 > symmetrical to allow a tag for the schedule since the value would be=20 > sent to the collector in the 'tag' object of the report. I agree that we should allow the definition of additional tags in the actio= n configuration. Tim might have suggested this as well but I was not sure, = see my other email. Again it is the schedule action that would have the option - I am loo= king at draft-07 of the information framework section 3.7.2. The report has the scheduled action options in the ma-report-task-object se= ction 3.6.2 so I don't understand the comment for the need in the schedule.= .. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 1 11:37:18 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4221B3518 for ; Mon, 1 Feb 2016 11:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyMGv_mH9Bc1 for ; Mon, 1 Feb 2016 11:37:16 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FA071B3535 for ; Mon, 1 Feb 2016 11:36:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4D9ADFC6; Mon, 1 Feb 2016 20:36:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id WD6FqYHLOECY; Mon, 1 Feb 2016 20:36:38 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 1 Feb 2016 20:36:38 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E84820013; Mon, 1 Feb 2016 20:36:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id oJTEb8V1jYjM; Mon, 1 Feb 2016 20:36:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 343EA2002B; Mon, 1 Feb 2016 20:36:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3CD8D39D207B; Mon, 1 Feb 2016 20:36:36 +0100 (CET) Date: Mon, 1 Feb 2016 20:36:36 +0100 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160201193636.GA12248@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , Ron Stana , "alissa@cooperw.in" , "lmap@ietf.org" References: <9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9@AMEXMB01.ds.jdsu.net> <20160127140429.GB56525@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B1903@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160128082904.GA1957@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B2139@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160201082746.GB10733@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B5748@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A5B5748@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "alissa@cooperw.in" , Ron Stana , "lmap@ietf.org" Subject: Re: [lmap] LMAP Result Correlation X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 19:37:17 -0000 On Mon, Feb 01, 2016 at 06:47:49PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen and Ron, > > My comments in line > > > > If this understanding is correct, then to retrieve the results from > > the collector for either Schedule A or Schedule B seems to require > > unique tag to be specified with the schedule instead of the task. The 'options' > > object for the schedule could be used, however it would be more > > symmetrical to allow a tag for the schedule since the value would be > > sent to the collector in the 'tag' object of the report. > > I agree that we should allow the definition of additional tags in the action configuration. Tim might have suggested this as well but I was not sure, see my other email. > > > Again it is the schedule action that would have the option - I am looking at draft-07 of the information framework section 3.7.2. > The report has the scheduled action options in the ma-report-task-object section 3.6.2 so I don't understand the comment for the need in the schedule... > Tim, we are talking about tags, not options. A tag is the YANG representation of what is called the cycle-id in the information model. In contrast to the information model, the YANG model allows a set of tags and not just a single one. The ma-task-obj has a ma-task-cycle-id of type string in the information model. In the YANG data model, we have instead a list of tags (and one of the tags can carry a cycle identifier. This allows us to have multiple tags for a given task. The ma-report-task-obj has a matching ma-report-task-cycle-id in the information model. In the YANG data model, we have again a list of tags. In order to distinguish reports from a given task kicked by different actions, the proposal was made to have the ability to define a tag or cycle-id in addition as part of the ma-action-obj. I suggest to align the information model here with the YANG data model. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Feb 2 04:36:28 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE371A8AB3 for ; Tue, 2 Feb 2016 04:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.901 X-Spam-Level: X-Spam-Status: No, score=-8.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV7vbLOgtYoC for ; Tue, 2 Feb 2016 04:36:25 -0800 (PST) Received: from sjmda15.webex.com (sjmda15.webex.com [64.68.124.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56FA1A8ABF for ; Tue, 2 Feb 2016 04:36:23 -0800 (PST) Received: from jva2tc209.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-1.webex.com [64.68.121.245]) by sjmda15.webex.com (Postfix) with ESMTP id 6588343A5C for ; Tue, 2 Feb 2016 12:36:23 +0000 (GMT) Received: from jva2tc209.webex.com (localhost [127.0.0.1]) by jva2tc209.webex.com (Postfix) with ESMTP id D773840141 for ; Tue, 2 Feb 2016 12:36:23 +0000 (GMT) Date: Tue, 2 Feb 2016 12:36:23 +0000 (GMT) From: LMAP Working Group To: lmap@ietf.org Message-ID: <793790983.77990.1454416583880.JavaMail.nobody@jva2tc209.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_77988_136397735.1454416583879" X-Priority: 3 Importance: normal Archived-At: Subject: [lmap] WebEx meeting invitation: Fevruary 2016 LMAP Virtual Interim X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: lmap-chairs@ietf.org List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 12:36:27 -0000 ------=_Part_77988_136397735.1454416583879 Content-Type: multipart/Alternative; boundary="----=_Part_77989_1071680796.1454416583879" ------=_Part_77989_1071680796.1454416583879 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTE1BUCBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJF eCBtZWV0aW5nLgoKCkZldnJ1YXJ5IDIwMTYgTE1BUCBWaXJ0dWFsIEludGVyaW0KTW9uZGF5LCBG ZWJydWFyeSAyMiwgMjAxNgoxMjowMCBwbSAgfCAgRWFzdGVybiBTdGFuZGFyZCBUaW1lIChOZXcg WW9yaywgR01ULTA1OjAwKSAgfCAgMiBocnMKCgpKT0lOIFdFQkVYIE1FRVRJTkcKaHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTI5ZmYxM2ExZTNkOTBiYjM3YmQyODdjMzQ2 NTg0NmZhCk1lZXRpbmcgbnVtYmVyOiA2NDQgMDE5IDQ0MwpNZWV0aW5nIHBhc3N3b3JkOiBsYXJn ZXNjYWxlCgoNCkpPSU4gQlkgUEhPTkUNCjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVl IG51bWJlciAoVVMvQ2FuYWRhKSAKMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAo VVMvQ2FuYWRhKQpBY2Nlc3MgY29kZTogNjQ0IDAxOSA0NDMKClRvbGwtZnJlZSBkaWFsaW5nIHJl c3RyaWN0aW9uczogCmh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlv bnMucGRmDQoNCgpBZGQgdGhpcyBtZWV0aW5nIHRvIHlvdXIgY2FsZW5kYXIgKENhbm5vdCBhZGQg ZnJvbSBtb2JpbGUgZGV2aWNlcyk6Cmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9N VElEPW1mNTBiNzliMTBhMWVkMTdmNGI1YWNmMGY3NWE5NGI4Nw0KDQoKQ2FuJ3Qgam9pbiB0aGUg bWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6Cmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9tYwoKCklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2 aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNl c3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdh bCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25z ZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJl Y29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9p biB0aGUgc2Vzc2lvbi4K ------=_Part_77989_1071680796.1454416583879 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBMTUFQ IFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYkV4IG1lZXRpbmcuCiAg ICAgICAgICAgICAgICAJICAgICAgICAgICA8L3RkPgogICAgICA8L3RyPgo8L3RhYmxlPgoKCgoK PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoy MHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlICB3aWR0aD0iMTAwJSI+ CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJmb250LXNpemU6MTZweDsgY29sb3I6IzRE NEQ0RCI+CgkJCQkJCQkJCTxiPkZldnJ1YXJ5IDIwMTYgTE1BUCBWaXJ0dWFsIEludGVyaW08L2I+ CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgi PgoJCQkJCQkJCTx0ZD5Nb25kYXksIEZlYnJ1YXJ5IDIyLCAyMDE2CgkJCQkJCQkJPC90ZD4KCQkJ CQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD4xMjow MCBwbSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDtFYXN0ZXJuIFN0YW5kYXJkIFRpbWUgKE5ldyBZ b3JrLCBHTVQtMDU6MDApJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzIgaHJzCgkJCQkJCQkJPC90 ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFibGU+Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3Rh YmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50 Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImNvbG9yOiMwMEFGRjk7Zm9udC1zaXpl OjE2cHgiPgoJCQkJCQkJCQk8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5w aHA/TVRJRD1tMjlmZjEzYTFlM2Q5MGJiMzdiZDI4N2MzNDY1ODQ2ZmEiCgkJCQkJCQkJCQlzdHls ZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjE2cHg7Y29sb3I6IzAwQUZGOSI+CgkJ CQkJCQkJCQk8Yj5Kb2luIFdlYkV4IG1lZXRpbmc8L2I+CgkJCQkJCQkJCTwvYT4KCQkJCQkJCQk8 L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3aWR0 aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjow cHgiPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFkZGluZy1yaWdodDogNXB4OyI+CgkJCQkJCQkJCU1l ZXRpbmcgbnVtYmVyOgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQkJPHRkPjY0NCAwMTkgNDQzCgkJCQkJ CQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJwYWRk aW5nLXJpZ2h0OiA1cHg7Ij5NZWV0aW5nIHBhc3N3b3JkOjwvdGQ+CgkJCQkJCQkJPHRkPmxhcmdl c2NhbGU8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCgoKCQoKCTx0YWJsZT48dHIg c3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwv dGQ+PC90cj48L3RhYmxlPjx0YWJsZT48dHI+PHRkIHN0eWxlPSJmb250LXNpemU6MTZweCI+PGI+ Sm9pbiBieSBwaG9uZTwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGI+ MS04NzctNjY4LTQ0OTM8L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5h ZGEpPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPjxiPjEtNjUwLTQ3OS0zMjA4 PC9iPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0 eWxlPSJtYXJnaW46MHB4Ij48dGQ+QWNjZXNzIGNvZGU6Jm5ic3A7NjQ0IDAxOSA0NDM8L3RkPjwv dHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5j b20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246 bm9uZTtmb250LXNpemU6MTNweDtjb2xvcjojMDBBRkY5OyI+VG9sbC1mcmVlIGNhbGxpbmcgcmVz dHJpY3Rpb25zPC9hPjwvdGQ+PC90cj48L3RhYmxlPgoKCQkJCQk8dGFibGU+PHRyIHN0eWxlPSJs aW5lLWhlaWdodDoyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+ PC90YWJsZT48dGFibGU+PHRyPjx0ZCBzdHlsZT0iZm9udC1zaXplOjEzcHgiPjxhIGhyZWY9Imh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1mNTBiNzliMTBhMWVkMTdmNGI1 YWNmMGY3NWE5NGI4NyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjk7 IGZvbnQtc2l6ZToxM3B4Ij5BZGQgdGhpcyBtZWV0aW5nPC9hPiB0byB5b3VyIGNhbGVuZGFyLiAo Q2Fubm90IGFkZCBmcm9tIG1vYmlsZSBkZXZpY2VzLik8L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxl Pjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4m bmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPgogICAgPHRyPgogICAgICAgPHRkIHN0eWxl PSJmb250LXNpemU6IDEzcHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiAjNjY2NjY2OyI+CiAg ICAgICAgQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8KICAgICAJPGEgaHJlZj0iaHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL21jIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXpl OjEzcHg7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzAwQUZGOTtmb250LWNvbG9yOiMwMEFGRjk7 Ij4KICAgICAgICAJQ29udGFjdCBzdXBwb3J0LjwvYT4KCQk8L3RkPgogICAgPC90cj4KPC90YWJs ZT4KPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDEwcHg7Ij48dGQgc3R5bGU9ImhlaWdo dDoxMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlPgoJCQkJCQkJPHRy PgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjEycHg7Y29sb3I6ICNBMEEwQTA7Ij4KCQkJ CQkJCQkJSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZp Y2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vz c2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2Fs IG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNl bnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVj b3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2lu IHRoZSBzZXNzaW9uLjwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJPC90ZD4K CQkJPC90cj4KCQk8L3RhYmxlPgoJPC90ZD4KICAgPC90cj4KPC90YWJsZT4KCjwvYm9keT4= ------=_Part_77989_1071680796.1454416583879-- ------=_Part_77988_136397735.1454416583879 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE0MTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE0MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86bG1hcEBpZXRmLm9yZwpPUkdBTklaRVI7Q049IkxN QVAgV29ya2luZyBHcm91cCI6TUFJTFRPOmxtYXAtY2hhaXJzQGlldGYub3JnCkRUU1RBUlQ7VFpJ RD0iRWFzdGVybiBUaW1lIjoyMDE2MDIyMlQxMjAwMDAKRFRFTkQ7VFpJRD0iRWFzdGVybiBUaW1l IjoyMDE2MDIyMlQxNDAwMDAKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmClRS QU5TUDpPUEFRVUUKU0VRVUVOQ0U6MTQ1NDQxNjU4MwpVSUQ6YmQ3ZDZkMjEtNzJiNy00OTczLThi M2YtMGMzYWZhOTIzYzkwCkRUU1RBTVA6MjAxNjAyMjJUMTcwMDAwWgpERVNDUklQVElPTjpcblxu XG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9N VElEPW1iZjhhODI5ZDY3M2NhMGFiZWVlYjJjMmVkMGM3YjZiN1xuTWVldGluZyBudW1iZXI6IDY0 NCAwMTkgNDQzXG5NZWV0aW5nIHBhc3N3b3JkOiBsYXJnZXNjYWxlXG5cblxuSk9JTiBCWSBQSE9O RVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIFxu MS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuQWNjZXNzIGNv ZGU6IDY0NCAwMTkgNDQzXG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9uczogXG5odHRw Oi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxuXG5cblxuQ2Fu J3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYu d2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0 IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNl bnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292 ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1 dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29u c2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhv c3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRUWVBFPXRleHQv aHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZPTlQgU0laRT0i NCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9qLnBocD9NVElEPW1iZjhhODI5ZDY3M2NhMGFiZWVlYjJjMmVkMGM3YjZiNyI+PEZPTlQgU0la RT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1lZXRpbmc8L0ZP TlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05UPgkJCQkJPC90 ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPjY0NCAwMTkgNDQzPC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCTx0 YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+ TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+bGFyZ2VzY2FsZTwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT4J CTwvRk9OVD48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48 L0ZPTlQ+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsgPEJSPjxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTg3Ny02Njgt NDQ5Mzwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwv Rk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlh bCI+PHN0cm9uZz4xLTY1MC00NzktMzIwODwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2 NjY2NiIgRkFDRT0iYXJpYWwiPkFjY2VzcyBjb2RlOiA2NDQgMDE5IDQ0MzwvRk9OVD4mbmJzcDsg PEJSPjxhIGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlv bnMucGRmIj48Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPlRvbGwt ZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvRk9OVD48L2E+ICZuYnNwOyA8QlI+PC9GT05UPjxC Uj48QlI+CSZuYnNwOzxCUj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj4JCQkJQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz88L0ZPTlQ+CTxhIGhyZWY9Imh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9tYyI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBG QUNFPSJBcmlhbCI+Q29udGFjdCBzdXBwb3J0LjwvRk9OVD48L2E+CSZuYnNwOzxCUj4mbmJzcDs8 QlI+PEZPTlQgQ09MT1I9IiNBMEEwQTAiIHNpemU9IjEiIEZBQ0U9ImFyaWFsIj5JTVBPUlRBTlQg Tk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8g YW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29y ZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2lu aW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29y ZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5 b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uPC9G T05UPjwvRk9OVD4KU1VNTUFSWTpGZXZydWFyeSAyMDE2IExNQVAgVmlydHVhbCBJbnRlcmltClBS SU9SSVRZOjUKQ0xBU1M6UFVCTElDCkJFR0lOOlZBTEFSTQpUUklHR0VSOi1QVDVNCkFDVElPTjpE SVNQTEFZCkRFU0NSSVBUSU9OOlJlbWluZGVyCkVORDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNB TEVOREFSCg== ------=_Part_77988_136397735.1454416583879-- From nobody Tue Feb 2 04:59:16 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857891B2A89 for ; Tue, 2 Feb 2016 04:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_Dpl2xaLxmc for ; Tue, 2 Feb 2016 04:59:12 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70761B2A88 for ; Tue, 2 Feb 2016 04:59:11 -0800 (PST) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 4A81296EC643C; Tue, 2 Feb 2016 12:59:09 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u12CxA9J021819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Feb 2016 12:59:10 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u12Cx9Em023019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Feb 2016 12:59:09 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.82]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 2 Feb 2016 07:59:09 -0500 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] LMAP Result Correlation Thread-Index: AQHRWT1zdQZ+9uOJak2nQiJ7JPqUTZ8P9GBggAD43ICAACJXcIAFX9OAgADGywCAAFZ3kIAAZGgAgADN0BA= Date: Tue, 2 Feb 2016 12:59:08 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A5B609F@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9@AMEXMB01.ds.jdsu.net> <20160127140429.GB56525@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B1903@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160128082904.GA1957@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B2139@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160201082746.GB10733@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B5748@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160201193636.GA12248@elstar.local> In-Reply-To: <20160201193636.GA12248@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "alissa@cooperw.in" , Ron Stana , "lmap@ietf.org" Subject: Re: [lmap] LMAP Result Correlation X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 12:59:15 -0000 Juergen, Oh - I am sorry then - I missed that this point.=20 I wouldn't have an issue with a correlation point on the scheduled action -= that is where the options are. BR, Tim -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Monday, February 01, 2016 1:37 PM To: Carey, Timothy (Nokia - US) Cc: Ron Stana; alissa@cooperw.in; lmap@ietf.org Subject: Re: [lmap] LMAP Result Correlation On Mon, Feb 01, 2016 at 06:47:49PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen and Ron, >=20 > My comments in line >=20 >=20 > > If this understanding is correct, then to retrieve the results from=20 > > the collector for either Schedule A or Schedule B seems to require=20 > > unique tag to be specified with the schedule instead of the task. The = 'options' > > object for the schedule could be used, however it would be more=20 > > symmetrical to allow a tag for the schedule since the value would be=20 > > sent to the collector in the 'tag' object of the report. >=20 > I agree that we should allow the definition of additional tags in the act= ion configuration. Tim might have suggested this as well but I was not sure= , see my other email. >=20 >=20 > Again it is the schedule action that would have the option - I am l= ooking at draft-07 of the information framework section 3.7.2. > The report has the scheduled action options in the ma-report-task-object = section 3.6.2 so I don't understand the comment for the need in the schedul= e... > Tim, we are talking about tags, not options. A tag is the YANG representation of= what is called the cycle-id in the information model. In contrast to the i= nformation model, the YANG model allows a set of tags and not just a single= one. The ma-task-obj has a ma-task-cycle-id of type string in the information model. In the YANG data model, we have instead a list of tags (and one of the tags can carry a cycle identifier. This allows us to have multiple tags for a given task. The ma-report-task-obj has a matching ma-report-task-cycle-id in the information model. In the YANG data model, we have again a list of tags. In order to distinguish reports from a given task kicked by different actions, the proposal was made to have the ability to define a tag or cycle-id in addition as part of the ma-action-obj. I suggest to align the information model here with the YANG data model. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Feb 2 08:20:16 2016 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5BB1B2D01; Tue, 2 Feb 2016 08:20:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160202162015.26938.73098.idtracker@ietfa.amsl.com> Date: Tue, 02 Feb 2016 08:20:15 -0800 Archived-At: Cc: lmap@ietf.org Subject: [lmap] LMAP WG Virtual Interim Meeting: February 22, 2016 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Reply-To: lmap@ietf.org List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 16:20:15 -0000 The Large-Scale Measurement of Broadband Performance (lmap) Working Group will hold a virtual interim meeting on Monday, February 22, 2016 between noon and 2:00pm EST (UTC-5). The agenda information will follow on the LMAP mailing list: https://mailarchive.ietf.org/arch/browse/lmap/ JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=mbf8a829d673ca0abeeeb2c2ed0c7b6b7 Meeting number: 644 019 443 Meeting password: largescale JOIN BY PHONE 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 644 019 443 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Can't join the meeting? Contact support here: https://ietf.webex.com/ietf/mc IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. From nobody Wed Feb 3 04:09:00 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492F01B34BD for ; Wed, 3 Feb 2016 04:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W29k5KuN4XE for ; Wed, 3 Feb 2016 04:08:58 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD421B34BC for ; Wed, 3 Feb 2016 04:08:57 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AC481A99 for ; Wed, 3 Feb 2016 13:08:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id krbJfhUqKzmp for ; Wed, 3 Feb 2016 13:08:56 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 3 Feb 2016 13:08:56 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BB8E2002B for ; Wed, 3 Feb 2016 13:08:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id A_LdEPZwBwdP; Wed, 3 Feb 2016 13:08:55 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B76020013; Wed, 3 Feb 2016 13:08:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BCCBD39DE2E0; Wed, 3 Feb 2016 13:08:54 +0100 (CET) Date: Wed, 3 Feb 2016 13:08:54 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20160203120854.GA19493@elstar.local> Mail-Followup-To: lmap@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [lmap] default value for the controller-timeout X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 12:08:59 -0000 Hi, should the ma-config-controller-timeout (information model) have a default value? The YANG model has this as an optional object. What does it mean if lmap/agent/controller-timeout is not present? I think I would prefer to have a default so that there is always a timeout. What about a week (= 604800 seconds) as a default? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 3 05:58:00 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42E1AC435 for ; Wed, 3 Feb 2016 05:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLJ0UBjKeXAj for ; Wed, 3 Feb 2016 05:57:57 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id AB9931AC445 for ; Wed, 3 Feb 2016 05:57:57 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id 08B8F121D03; Wed, 3 Feb 2016 09:00:41 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 2DB0DE051B; Wed, 3 Feb 2016 08:54:52 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Wed, 3 Feb 2016 08:57:57 -0500 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , "lmap@ietf.org" Date: Wed, 3 Feb 2016 08:57:56 -0500 Thread-Topic: [lmap] default value for the controller-timeout Thread-Index: AdFee7Rj/lFfZGbPR02ScEAYan900AADlY4w Message-ID: <4AF73AA205019A4C8A1DDD32C034631D2E26DF2772@NJFPSRVEXG0.research.att.com> References: <20160203120854.GA19493@elstar.local> In-Reply-To: <20160203120854.GA19493@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] default value for the controller-timeout X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:57:58 -0000 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, February 03, 2016 7:09 AM > To: lmap@ietf.org > Subject: [lmap] default value for the controller-timeout >=20 > Hi, >=20 > should the ma-config-controller-timeout (information model) have a > default value? The YANG model has this as an optional object. What > does it mean if lmap/agent/controller-timeout is not present? I think > I would prefer to have a default so that there is always a timeout. >=20 > What about a week (=3D 604800 seconds) as a default? >=20 [ACM] Good to supply a default, 1 week ok, not sure if timeout should be=20 optional in the YANG model (even if the timeout object is omitted, a timeout is enforced at the MA?=20 How to instruct the MA not to use a timeout?) Al From nobody Wed Feb 3 08:58:47 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EEF1B2A2B for ; Wed, 3 Feb 2016 08:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c40LAEDOhw5B for ; Wed, 3 Feb 2016 08:58:43 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51361B2A30 for ; Wed, 3 Feb 2016 08:58:43 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 069D710F4; Wed, 3 Feb 2016 17:58:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1k9pJC_JtlEi; Wed, 3 Feb 2016 17:58:40 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Feb 2016 17:58:41 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36FDA2002B; Wed, 3 Feb 2016 17:58:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id J4ohh3b7y6FJ; Wed, 3 Feb 2016 17:58:40 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE41920013; Wed, 3 Feb 2016 17:58:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E472A39DE596; Wed, 3 Feb 2016 17:58:39 +0100 (CET) Date: Wed, 3 Feb 2016 17:58:39 +0100 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20160203165839.GA19908@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <20160203120854.GA19493@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2772@NJFPSRVEXG0.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D2E26DF2772@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] default value for the controller-timeout X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 16:58:45 -0000 On Wed, Feb 03, 2016 at 08:57:56AM -0500, MORTON, ALFRED C (AL) wrote: > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Wednesday, February 03, 2016 7:09 AM > > To: lmap@ietf.org > > Subject: [lmap] default value for the controller-timeout > > > > Hi, > > > > should the ma-config-controller-timeout (information model) have a > > default value? The YANG model has this as an optional object. What > > does it mean if lmap/agent/controller-timeout is not present? I think > > I would prefer to have a default so that there is always a timeout. > > > > What about a week (= 604800 seconds) as a default? > > > > [ACM] Good to supply a default, 1 week ok, not sure if timeout should be > optional in the YANG model (even if the timeout object is omitted, a > timeout is enforced at the MA? > How to instruct the MA not to use a timeout?) > While coding this up I stumbled over this. Right now, the text is not very precise. I could go with setting the timeout to zero means no timeout and the default is one week. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 4 05:53:26 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035D41B2F93 for ; Thu, 4 Feb 2016 05:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwGgdMbuetr5 for ; Thu, 4 Feb 2016 05:53:23 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4131B2F92 for ; Thu, 4 Feb 2016 05:53:23 -0800 (PST) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 7BE2012221F; Thu, 4 Feb 2016 08:56:09 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-azure.research.att.com (Postfix) with ESMTP id DF5E7E0523; Thu, 4 Feb 2016 08:53:19 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Thu, 4 Feb 2016 08:53:19 -0500 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder Date: Thu, 4 Feb 2016 08:53:18 -0500 Thread-Topic: [lmap] default value for the controller-timeout Thread-Index: AdFepCx+71MSYMn1SDaBGY9V3fEQHQArqwdQ Message-ID: <4AF73AA205019A4C8A1DDD32C034631D2E26DF2907@NJFPSRVEXG0.research.att.com> References: <20160203120854.GA19493@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2772@NJFPSRVEXG0.research.att.com> <20160203165839.GA19908@elstar.local> In-Reply-To: <20160203165839.GA19908@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] default value for the controller-timeout X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 13:53:25 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Wednesday, February 03, 2016 11:59 AM > To: MORTON, ALFRED C (AL) > Cc: lmap@ietf.org > Subject: Re: [lmap] default value for the controller-timeout >=20 > On Wed, Feb 03, 2016 at 08:57:56AM -0500, MORTON, ALFRED C (AL) wrote: > > > -----Original Message----- > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: Wednesday, February 03, 2016 7:09 AM > > > To: lmap@ietf.org > > > Subject: [lmap] default value for the controller-timeout > > > > > > Hi, > > > > > > should the ma-config-controller-timeout (information model) have a > > > default value? The YANG model has this as an optional object. What > > > does it mean if lmap/agent/controller-timeout is not present? I > think > > > I would prefer to have a default so that there is always a timeout. > > > > > > What about a week (=3D 604800 seconds) as a default? > > > > > > > [ACM] Good to supply a default, 1 week ok, not sure if timeout should > be > > optional in the YANG model (even if the timeout object is omitted, a > > timeout is enforced at the MA? > > How to instruct the MA not to use a timeout?) > > >=20 > While coding this up I stumbled over this. Right now, the text is not > very precise. I could go with setting the timeout to zero means no > timeout and the default is one week. >=20 > /js >=20 [ACM]=20 As an alternate, we could view the default simply as guidance. If you include the ma-config-controller-timeout object, then you must supply a value, and if you need guidance about this you=20 specify the default value. OTOH, if you don't want a timeout, you don't include the ma-config-controller-timeout object at all. AND, I don't feel strongly about this... Al From nobody Thu Feb 4 06:15:26 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892491B2FF9 for ; Thu, 4 Feb 2016 06:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhHacRtV5LKG for ; Thu, 4 Feb 2016 06:15:24 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF761AC3DE for ; Thu, 4 Feb 2016 06:15:23 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A82691A3B; Thu, 4 Feb 2016 15:15:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dnpdpiy5w_EF; Thu, 4 Feb 2016 15:15:21 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 4 Feb 2016 15:15:21 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C19852002B; Thu, 4 Feb 2016 15:15:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PsFHdOczVMWC; Thu, 4 Feb 2016 15:15:20 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8020720013; Thu, 4 Feb 2016 15:15:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C4A6E39DEFEA; Thu, 4 Feb 2016 15:15:20 +0100 (CET) Date: Thu, 4 Feb 2016 15:15:20 +0100 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20160204141520.GB21868@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <20160203120854.GA19493@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2772@NJFPSRVEXG0.research.att.com> <20160203165839.GA19908@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2907@NJFPSRVEXG0.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D2E26DF2907@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] default value for the controller-timeout X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 14:15:25 -0000 On Thu, Feb 04, 2016 at 08:53:18AM -0500, MORTON, ALFRED C (AL) wrote: > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Wednesday, February 03, 2016 11:59 AM > > To: MORTON, ALFRED C (AL) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] default value for the controller-timeout > > > > On Wed, Feb 03, 2016 at 08:57:56AM -0500, MORTON, ALFRED C (AL) wrote: > > > > -----Original Message----- > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > > > Schoenwaelder > > > > Sent: Wednesday, February 03, 2016 7:09 AM > > > > To: lmap@ietf.org > > > > Subject: [lmap] default value for the controller-timeout > > > > > > > > Hi, > > > > > > > > should the ma-config-controller-timeout (information model) have a > > > > default value? The YANG model has this as an optional object. What > > > > does it mean if lmap/agent/controller-timeout is not present? I > > think > > > > I would prefer to have a default so that there is always a timeout. > > > > > > > > What about a week (= 604800 seconds) as a default? > > > > > > > > > > [ACM] Good to supply a default, 1 week ok, not sure if timeout should > > be > > > optional in the YANG model (even if the timeout object is omitted, a > > > timeout is enforced at the MA? > > > How to instruct the MA not to use a timeout?) > > > > > > > While coding this up I stumbled over this. Right now, the text is not > > very precise. I could go with setting the timeout to zero means no > > timeout and the default is one week. > > > > /js > > > > [ACM] > As an alternate, we could view the default simply as guidance. > If you include the ma-config-controller-timeout object, then > you must supply a value, and if you need guidance about this you > specify the default value. > > OTOH, if you don't want a timeout, you don't include the > ma-config-controller-timeout object at all. > > AND, I don't feel strongly about this... Yes, but this means the default is actually to have no timeout since the ma-config-controller-timeout is optional to have. It's a policy question whether we want to have a timeout configured by default and it takes effort to run without one or whether we are fine with no timeout by default and we require effort to create one. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 4 06:42:35 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BF31B3081 for ; Thu, 4 Feb 2016 06:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWKaJNMf23WU for ; Thu, 4 Feb 2016 06:42:32 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 221821B2CDC for ; Thu, 4 Feb 2016 06:42:32 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 7B549122287; Thu, 4 Feb 2016 09:45:18 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id C5995F0467; Thu, 4 Feb 2016 09:42:28 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Thu, 4 Feb 2016 09:42:28 -0500 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder Date: Thu, 4 Feb 2016 09:42:27 -0500 Thread-Topic: [lmap] default value for the controller-timeout Thread-Index: AdFfVoP3cNa2SJ91Ra+/AVPaey3tYgAAtT6g Message-ID: <4AF73AA205019A4C8A1DDD32C034631D2E26DF2918@NJFPSRVEXG0.research.att.com> References: <20160203120854.GA19493@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2772@NJFPSRVEXG0.research.att.com> <20160203165839.GA19908@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2907@NJFPSRVEXG0.research.att.com> <20160204141520.GB21868@elstar.local> In-Reply-To: <20160204141520.GB21868@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] default value for the controller-timeout X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 14:42:34 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, February 04, 2016 9:15 AM > To: MORTON, ALFRED C (AL) > Cc: lmap@ietf.org > Subject: Re: [lmap] default value for the controller-timeout >=20 > On Thu, Feb 04, 2016 at 08:53:18AM -0500, MORTON, ALFRED C (AL) wrote: > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > university.de] > > > Sent: Wednesday, February 03, 2016 11:59 AM > > > To: MORTON, ALFRED C (AL) > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] default value for the controller-timeout > > > > > > On Wed, Feb 03, 2016 at 08:57:56AM -0500, MORTON, ALFRED C (AL) > wrote: > > > > > -----Original Message----- > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > > > > Schoenwaelder > > > > > Sent: Wednesday, February 03, 2016 7:09 AM > > > > > To: lmap@ietf.org > > > > > Subject: [lmap] default value for the controller-timeout > > > > > > > > > > Hi, > > > > > > > > > > should the ma-config-controller-timeout (information model) have > a > > > > > default value? The YANG model has this as an optional object. > What > > > > > does it mean if lmap/agent/controller-timeout is not present? I > > > think > > > > > I would prefer to have a default so that there is always a > timeout. > > > > > > > > > > What about a week (=3D 604800 seconds) as a default? > > > > > > > > > > > > > [ACM] Good to supply a default, 1 week ok, not sure if timeout > should > > > be > > > > optional in the YANG model (even if the timeout object is omitted, > a > > > > timeout is enforced at the MA? > > > > How to instruct the MA not to use a timeout?) > > > > > > > > > > While coding this up I stumbled over this. Right now, the text is > not > > > very precise. I could go with setting the timeout to zero means no > > > timeout and the default is one week. > > > > > > /js > > > > > > > [ACM] > > As an alternate, we could view the default simply as guidance. > > If you include the ma-config-controller-timeout object, then > > you must supply a value, and if you need guidance about this you > > specify the default value. > > > > OTOH, if you don't want a timeout, you don't include the > > ma-config-controller-timeout object at all. > > > > AND, I don't feel strongly about this... >=20 >=20 > Yes, but this means the default is actually to have no timeout since > the ma-config-controller-timeout is optional to have. It's a policy > question whether we want to have a timeout configured by default and > it takes effort to run without one or whether we are fine with no > timeout by default and we require effort to create one. >=20 [ACM] Right. The default condition of the MA is having no instructions and having nothing scheduled, etc. When we ask the MA to perform measurements that send traffic, reports, etc., then we may need a timeout, and all these functions require effort to create them. Al From nobody Thu Feb 4 07:40:58 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89371B318E for ; Thu, 4 Feb 2016 07:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3gOfcj6u8fh for ; Thu, 4 Feb 2016 07:40:56 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBA41B3081 for ; Thu, 4 Feb 2016 07:40:55 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D9703120F; Thu, 4 Feb 2016 16:40:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id D0QAqitp8Cew; Thu, 4 Feb 2016 16:40:52 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 4 Feb 2016 16:40:52 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCB4F20013; Thu, 4 Feb 2016 16:40:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yyPqvziWSc_H; Thu, 4 Feb 2016 16:40:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F2D72002C; Thu, 4 Feb 2016 16:40:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D97C439DF0C7; Thu, 4 Feb 2016 16:40:50 +0100 (CET) Date: Thu, 4 Feb 2016 16:40:50 +0100 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20160204154050.GA22049@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <20160203120854.GA19493@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2772@NJFPSRVEXG0.research.att.com> <20160203165839.GA19908@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2907@NJFPSRVEXG0.research.att.com> <20160204141520.GB21868@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2918@NJFPSRVEXG0.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D2E26DF2918@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] default value for the controller-timeout X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 15:40:58 -0000 On Thu, Feb 04, 2016 at 09:42:27AM -0500, MORTON, ALFRED C (AL) wrote: > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Thursday, February 04, 2016 9:15 AM > > To: MORTON, ALFRED C (AL) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] default value for the controller-timeout > > > > On Thu, Feb 04, 2016 at 08:53:18AM -0500, MORTON, ALFRED C (AL) wrote: > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > > university.de] > > > > Sent: Wednesday, February 03, 2016 11:59 AM > > > > To: MORTON, ALFRED C (AL) > > > > Cc: lmap@ietf.org > > > > Subject: Re: [lmap] default value for the controller-timeout > > > > > > > > On Wed, Feb 03, 2016 at 08:57:56AM -0500, MORTON, ALFRED C (AL) > > wrote: > > > > > > -----Original Message----- > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > > > > > Schoenwaelder > > > > > > Sent: Wednesday, February 03, 2016 7:09 AM > > > > > > To: lmap@ietf.org > > > > > > Subject: [lmap] default value for the controller-timeout > > > > > > > > > > > > Hi, > > > > > > > > > > > > should the ma-config-controller-timeout (information model) have > > a > > > > > > default value? The YANG model has this as an optional object. > > What > > > > > > does it mean if lmap/agent/controller-timeout is not present? I > > > > think > > > > > > I would prefer to have a default so that there is always a > > timeout. > > > > > > > > > > > > What about a week (= 604800 seconds) as a default? > > > > > > > > > > > > > > > > [ACM] Good to supply a default, 1 week ok, not sure if timeout > > should > > > > be > > > > > optional in the YANG model (even if the timeout object is omitted, > > a > > > > > timeout is enforced at the MA? > > > > > How to instruct the MA not to use a timeout?) > > > > > > > > > > > > > While coding this up I stumbled over this. Right now, the text is > > not > > > > very precise. I could go with setting the timeout to zero means no > > > > timeout and the default is one week. > > > > > > > > /js > > > > > > > > > > [ACM] > > > As an alternate, we could view the default simply as guidance. > > > If you include the ma-config-controller-timeout object, then > > > you must supply a value, and if you need guidance about this you > > > specify the default value. > > > > > > OTOH, if you don't want a timeout, you don't include the > > > ma-config-controller-timeout object at all. > > > > > > AND, I don't feel strongly about this... > > > > > > Yes, but this means the default is actually to have no timeout since > > the ma-config-controller-timeout is optional to have. It's a policy > > question whether we want to have a timeout configured by default and > > it takes effort to run without one or whether we are fine with no > > timeout by default and we require effort to create one. > > > > [ACM] Right. The default condition of the MA is having no instructions > and having nothing scheduled, etc. When we ask the MA to perform > measurements that send traffic, reports, etc., then we may need a timeout, > and all these functions require effort to create them. > We are talking about loosing contact to the controller, which should trigger an appropriate event. Relying on someone to configure this in a meaningful way (= having no default) means we will see boxes that simply will never react to lost contact to a controller. Yes, it is a policy issue but I am somewhat concerned about boxes going crazy and never detecting this and properly shutting down. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 4 08:22:32 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E24F1B31ED for ; Thu, 4 Feb 2016 08:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaF_0Bp8Ca6Z for ; Thu, 4 Feb 2016 08:22:27 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0491AD2EE for ; Thu, 4 Feb 2016 08:22:27 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id DFD43122359; Thu, 4 Feb 2016 11:25:13 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 124DEE01A6; Thu, 4 Feb 2016 11:19:21 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Thu, 4 Feb 2016 11:22:26 -0500 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder Date: Thu, 4 Feb 2016 11:22:25 -0500 Thread-Topic: [lmap] default value for the controller-timeout Thread-Index: AdFfYnSk8SAdnlfcSEyI7tS0pkHAYwAAZJFQ Message-ID: <4AF73AA205019A4C8A1DDD32C034631D2E26DF295B@NJFPSRVEXG0.research.att.com> References: <20160203120854.GA19493@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2772@NJFPSRVEXG0.research.att.com> <20160203165839.GA19908@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2907@NJFPSRVEXG0.research.att.com> <20160204141520.GB21868@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2918@NJFPSRVEXG0.research.att.com> <20160204154050.GA22049@elstar.local> In-Reply-To: <20160204154050.GA22049@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] default value for the controller-timeout X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 16:22:31 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, February 04, 2016 10:41 AM > To: MORTON, ALFRED C (AL) > Cc: lmap@ietf.org > Subject: Re: [lmap] default value for the controller-timeout >=20 > On Thu, Feb 04, 2016 at 09:42:27AM -0500, MORTON, ALFRED C (AL) wrote: > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > university.de] > > > Sent: Thursday, February 04, 2016 9:15 AM > > > To: MORTON, ALFRED C (AL) > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] default value for the controller-timeout > > > > > > On Thu, Feb 04, 2016 at 08:53:18AM -0500, MORTON, ALFRED C (AL) > wrote: > > > > > -----Original Message----- > > > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > > > university.de] > > > > > Sent: Wednesday, February 03, 2016 11:59 AM > > > > > To: MORTON, ALFRED C (AL) > > > > > Cc: lmap@ietf.org > > > > > Subject: Re: [lmap] default value for the controller-timeout > > > > > > > > > > On Wed, Feb 03, 2016 at 08:57:56AM -0500, MORTON, ALFRED C (AL) > > > wrote: > > > > > > > -----Original Message----- > > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of > Juergen > > > > > > > Schoenwaelder > > > > > > > Sent: Wednesday, February 03, 2016 7:09 AM > > > > > > > To: lmap@ietf.org > > > > > > > Subject: [lmap] default value for the controller-timeout > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > should the ma-config-controller-timeout (information model) > have > > > a > > > > > > > default value? The YANG model has this as an optional > object. > > > What > > > > > > > does it mean if lmap/agent/controller-timeout is not > present? I > > > > > think > > > > > > > I would prefer to have a default so that there is always a > > > timeout. > > > > > > > > > > > > > > What about a week (=3D 604800 seconds) as a default? > > > > > > > > > > > > > > > > > > > [ACM] Good to supply a default, 1 week ok, not sure if timeout > > > should > > > > > be > > > > > > optional in the YANG model (even if the timeout object is > omitted, > > > a > > > > > > timeout is enforced at the MA? > > > > > > How to instruct the MA not to use a timeout?) > > > > > > > > > > > > > > > > While coding this up I stumbled over this. Right now, the text > is > > > not > > > > > very precise. I could go with setting the timeout to zero means > no > > > > > timeout and the default is one week. > > > > > > > > > > /js > > > > > > > > > > > > > [ACM] > > > > As an alternate, we could view the default simply as guidance. > > > > If you include the ma-config-controller-timeout object, then > > > > you must supply a value, and if you need guidance about this you > > > > specify the default value. > > > > > > > > OTOH, if you don't want a timeout, you don't include the > > > > ma-config-controller-timeout object at all. > > > > > > > > AND, I don't feel strongly about this... > > > > > > > > > Yes, but this means the default is actually to have no timeout since > > > the ma-config-controller-timeout is optional to have. It's a policy > > > question whether we want to have a timeout configured by default and > > > it takes effort to run without one or whether we are fine with no > > > timeout by default and we require effort to create one. > > > > > > > [ACM] Right. The default condition of the MA is having no instructions > > and having nothing scheduled, etc. When we ask the MA to perform > > measurements that send traffic, reports, etc., then we may need a > timeout, > > and all these functions require effort to create them. > > >=20 > We are talking about loosing contact to the controller, which should > trigger an appropriate event. Relying on someone to configure this in > a meaningful way (=3D having no default) means we will see boxes that > simply will never react to lost contact to a controller. Yes, it is a > policy issue but I am somewhat concerned about boxes going crazy and > never detecting this and properly shutting down. >=20 [ACM] My concern as we started this discussion is about having=20 an "embedded behavior" =3D default timeout in the MA. =20 I'm using this term "embedded behavior" for lack of a better one, since the MA would apparently need to be instantiated with this timeout. The framework mentions the timeout configuration (end of 5.3.1): http://tools.ietf.org/html/rfc7594#section-5.3.1 The Controller may want an MA to run the same Measurement Task indefinitely (for example, "run the 'upload speed' Measurement Task once an hour until further notice"). To prevent the MA continuously generating traffic after a Controller has permanently failed (or communications with the Controller have failed), the MA can be configured with a time limit; if the MA doesn't hear from the Controller for this length of time, then it stops operating Measurement Tasks. but doesn't mention an embedded default for this time limit. After having read=20 https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04 yesterday (which I know you've read, too) the "embedded behavior" =3D default timeout in the MA isn't part of "Applied Configuration" or "Derived State", so it may not be possible to retrieve the timeout setting. What is the down-side to making the=20 ma-config-controller-timeout object Mandatory?=20 Having to repeat the object with every Instruction? But this would make the timeout part of the retrievable configuration, and that's what I would like to see, if it's not a burden elsewhere. Al From nobody Mon Feb 8 08:14:49 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9586A1B2E6B for ; Mon, 8 Feb 2016 08:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NAXO1keBZ-T for ; Mon, 8 Feb 2016 08:14:46 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE521B2E77 for ; Mon, 8 Feb 2016 08:14:43 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AbAgCeiLhW/xUHmMZdGQEBAQEPAQEBAYI+IStSc4hVsQgBDYFmhg0CgSo4FAEBAQEBAQF/C4RDAQEDEhteAQwJFVYmAQQbGod5AZ4nhRKZAAwBHYYUiEgBAR2DK4EPBZZ1AY8qh12FO4VuiFAeAQFCggMZgUiIDTQBewEBAQ X-IPAS-Result: A2AbAgCeiLhW/xUHmMZdGQEBAQEPAQEBAYI+IStSc4hVsQgBDYFmhg0CgSo4FAEBAQEBAQF/C4RDAQEDEhteAQwJFVYmAQQbGod5AZ4nhRKZAAwBHYYUiEgBAR2DK4EPBZZ1AY8qh12FO4VuiFAeAQFCggMZgUiIDTQBewEBAQ X-IronPort-AV: E=Sophos;i="5.22,415,1449550800"; d="scan'208,217";a="141780699" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Feb 2016 11:14:40 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 08 Feb 2016 11:14:39 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 8 Feb 2016 17:14:38 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: second virtual interim - yes or not? Thread-Index: AdFii85ZMMqLtNIeQnuZOP1bZwVmyw== Date: Mon, 8 Feb 2016 16:14:37 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF0DE9F@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BF0DE9FAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] second virtual interim - yes or not? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 16:14:48 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF0DE9FAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The second virtual interim meeting between IETF 94 and IETF 95 is scheduled= tentatively two weeks from now, for 2/22. At the previous interim (on 1/12) we said that a final decision will be tak= en based on work progress. Right now the situation seems to be that we had = a couple of important threads related to the Information Model on the mail = list, but the I-D was not updated. First question is for the document edito= r (Juergen) whether an update is expected to be submitted in the coming day= s. Second question is for all WG participants - will holding the 2/22 meeti= ng be useful? If yes, what should be on the agenda. We need to reach a decision by the end of the week. The agenda needs to be = submitted until 2/15 the latest. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF0DE9FAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The second virtual interim meeting between IETF 94 a= nd IETF 95 is scheduled tentatively two weeks from now, for 2/22.

 

At the previous interim (on 1/12) we said that a fin= al decision will be taken based on work progress. Right now the situation s= eems to be that we had a couple of important threads related to the Informa= tion Model on the mail list, but the I-D was not updated. First question is for the document editor (Juergen) w= hether an update is expected to be submitted in the coming days. Second que= stion is for all WG participants – will holding the 2/22 meeting be u= seful? If yes, what should be on the agenda.

 

We need to reach a decision by the end of the week. = The agenda needs to be submitted until 2/15 the latest.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BF0DE9FAZFFEXMB04globa_-- From nobody Tue Feb 9 08:36:37 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21A91ACCEE for ; Tue, 9 Feb 2016 08:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EueA_ltPeBSQ for ; Tue, 9 Feb 2016 08:36:31 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539201ACC91 for ; Tue, 9 Feb 2016 08:36:31 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2394C132F; Tue, 9 Feb 2016 17:36:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id KwsyKrXz1huq; Tue, 9 Feb 2016 17:36:28 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 9 Feb 2016 17:36:28 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B0272002C; Tue, 9 Feb 2016 17:36:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id h2vjcOUTEe6G; Tue, 9 Feb 2016 17:36:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 393ED2002B; Tue, 9 Feb 2016 17:36:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F025439E188A; Tue, 9 Feb 2016 17:36:26 +0100 (CET) Date: Tue, 9 Feb 2016 17:36:26 +0100 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20160209163626.GA31941@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <20160203120854.GA19493@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2772@NJFPSRVEXG0.research.att.com> <20160203165839.GA19908@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2907@NJFPSRVEXG0.research.att.com> <20160204141520.GB21868@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2918@NJFPSRVEXG0.research.att.com> <20160204154050.GA22049@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D2E26DF295B@NJFPSRVEXG0.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D2E26DF295B@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] default value for the controller-timeout X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 16:36:35 -0000 On Thu, Feb 04, 2016 at 11:22:25AM -0500, MORTON, ALFRED C (AL) wrote: > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Thursday, February 04, 2016 10:41 AM > > To: MORTON, ALFRED C (AL) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] default value for the controller-timeout > > > > On Thu, Feb 04, 2016 at 09:42:27AM -0500, MORTON, ALFRED C (AL) wrote: > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > > university.de] > > > > Sent: Thursday, February 04, 2016 9:15 AM > > > > To: MORTON, ALFRED C (AL) > > > > Cc: lmap@ietf.org > > > > Subject: Re: [lmap] default value for the controller-timeout > > > > > > > > On Thu, Feb 04, 2016 at 08:53:18AM -0500, MORTON, ALFRED C (AL) > > wrote: > > > > > > -----Original Message----- > > > > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > > > > university.de] > > > > > > Sent: Wednesday, February 03, 2016 11:59 AM > > > > > > To: MORTON, ALFRED C (AL) > > > > > > Cc: lmap@ietf.org > > > > > > Subject: Re: [lmap] default value for the controller-timeout > > > > > > > > > > > > On Wed, Feb 03, 2016 at 08:57:56AM -0500, MORTON, ALFRED C (AL) > > > > wrote: > > > > > > > > -----Original Message----- > > > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of > > Juergen > > > > > > > > Schoenwaelder > > > > > > > > Sent: Wednesday, February 03, 2016 7:09 AM > > > > > > > > To: lmap@ietf.org > > > > > > > > Subject: [lmap] default value for the controller-timeout > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > should the ma-config-controller-timeout (information model) > > have > > > > a > > > > > > > > default value? The YANG model has this as an optional > > object. > > > > What > > > > > > > > does it mean if lmap/agent/controller-timeout is not > > present? I > > > > > > think > > > > > > > > I would prefer to have a default so that there is always a > > > > timeout. > > > > > > > > > > > > > > > > What about a week (= 604800 seconds) as a default? > > > > > > > > > > > > > > > > > > > > > > [ACM] Good to supply a default, 1 week ok, not sure if timeout > > > > should > > > > > > be > > > > > > > optional in the YANG model (even if the timeout object is > > omitted, > > > > a > > > > > > > timeout is enforced at the MA? > > > > > > > How to instruct the MA not to use a timeout?) > > > > > > > > > > > > > > > > > > > While coding this up I stumbled over this. Right now, the text > > is > > > > not > > > > > > very precise. I could go with setting the timeout to zero means > > no > > > > > > timeout and the default is one week. > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > [ACM] > > > > > As an alternate, we could view the default simply as guidance. > > > > > If you include the ma-config-controller-timeout object, then > > > > > you must supply a value, and if you need guidance about this you > > > > > specify the default value. > > > > > > > > > > OTOH, if you don't want a timeout, you don't include the > > > > > ma-config-controller-timeout object at all. > > > > > > > > > > AND, I don't feel strongly about this... > > > > > > > > > > > > Yes, but this means the default is actually to have no timeout since > > > > the ma-config-controller-timeout is optional to have. It's a policy > > > > question whether we want to have a timeout configured by default and > > > > it takes effort to run without one or whether we are fine with no > > > > timeout by default and we require effort to create one. > > > > > > > > > > [ACM] Right. The default condition of the MA is having no instructions > > > and having nothing scheduled, etc. When we ask the MA to perform > > > measurements that send traffic, reports, etc., then we may need a > > timeout, > > > and all these functions require effort to create them. > > > > > > > We are talking about loosing contact to the controller, which should > > trigger an appropriate event. Relying on someone to configure this in > > a meaningful way (= having no default) means we will see boxes that > > simply will never react to lost contact to a controller. Yes, it is a > > policy issue but I am somewhat concerned about boxes going crazy and > > never detecting this and properly shutting down. > > > > [ACM] My concern as we started this discussion is about having > an "embedded behavior" = default timeout in the MA. > I'm using this term "embedded behavior" for lack of a better one, > since the MA would apparently need to be instantiated with this timeout. > The framework mentions the timeout configuration (end of 5.3.1): > http://tools.ietf.org/html/rfc7594#section-5.3.1 > > The Controller may want an MA to run the same Measurement Task > indefinitely (for example, "run the 'upload speed' Measurement Task > once an hour until further notice"). To prevent the MA continuously > generating traffic after a Controller has permanently failed (or > communications with the Controller have failed), the MA can be > configured with a time limit; if the MA doesn't hear from the > Controller for this length of time, then it stops operating > Measurement Tasks. > > but doesn't mention an embedded default for this time limit. > > After having read > https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04 > yesterday (which I know you've read, too) > the "embedded behavior" = default timeout in the MA > isn't part of "Applied Configuration" or "Derived State", > so it may not be possible to retrieve the timeout setting. > > What is the down-side to making the > ma-config-controller-timeout object Mandatory? > Having to repeat the object with every Instruction? > But this would make the timeout part of the retrievable configuration, > and that's what I would like to see, if it's not a burden elsewhere. > Defaults have nothing to do with the opstate discussions. YANG has a way to define defaults and NETCONF has mechanisms to requests whether default values are reported or not. The basic question remains but you are right that we could mandate that a default is explicitly configured. The question is whether this simplifies things or leads to better settings than a reasonable default value. There are many timers around us that we never bother about because they do have workable defaults. Anyway, the options are: (a) We define a default (strawman 1 week) and unless someone specifies something different explicitly, this is what an implementation will use. (b) We make the configuration of a timeout optional, which means the default is no timeout. (c) We make the configuration of a timeout value mandatory and we do not provide a default. My preference is (a), I am concerned about (b) causing noise, and I feel (c) just adds more configuration hassle and people may end up picking (or more likely copying) their own arbitrary defaults. So my preference is (a) then (c) and finally (b). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Feb 9 08:45:35 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBB71ACCF9 for ; Tue, 9 Feb 2016 08:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFeonGQopz0c for ; Tue, 9 Feb 2016 08:45:31 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA671A90C2 for ; Tue, 9 Feb 2016 08:45:30 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 862C61382 for ; Tue, 9 Feb 2016 17:45:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3uWoSWMIxEuD for ; Tue, 9 Feb 2016 17:45:28 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 9 Feb 2016 17:45:28 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F4742002C for ; Tue, 9 Feb 2016 17:45:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3MQcBQw_QB4n; Tue, 9 Feb 2016 17:45:27 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7339D2002B; Tue, 9 Feb 2016 17:45:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 76A8A39E191B; Tue, 9 Feb 2016 17:45:27 +0100 (CET) Date: Tue, 9 Feb 2016 17:45:27 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20160209164527.GC31941@elstar.local> Mail-Followup-To: lmap@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [lmap] streamlining the usage of tags X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 16:45:33 -0000 Here is a proposal to streamline the usage of tags so that tags can be efficiently used both for suppression (identifying the set of schedules or actions to suppress) and for reporting what the framework calls measurement cycle identifiers (see also the email thread 'LMAP Result Correlation'). 1) change ma-suppression-tags -> ma-suppression-match Explain that matching is using glob-style pattern (* matches any sequence of characters, ? matches a single arbitrary character, [] matches a set or sequence of characters, \ followed by a character matches the following character). (This definition is consistent with Posix fnmatch()). The ma-suppression-match values are going to match ma-schedule-tags or ma-action-tags (plus any tags inherited from the referenced task). Multiple ma-suppression-match result in the union of the individual matches. Rationale: Glob style matching allows to use tags that have a certain structure. For example, all schedules belonging a regulator X's campaign in year YYYY could be tagged with X-YYYY and then I can easily suppress lets say all fcc measurements (fcc-*) or all measurements in 2016 (*-2016) etc. Right now, we only have all and an explicit list of tags. Q: Does it make sense to suppress actions contained in a schedule? Or is it sufficient to suppress whole schedules? If we allow to suppress individual actions, what does this mean in pipelined execution mode? I would say it breaks the pipeline, that is, all subsequent actions will as a consequence of breaking the pipeline be suppressed as well. 2) change ma-suppression-tags -> ma-schedule-tags The schedule tags may be used for matching suppressions but they will also be echoed with result reports. Rationale: Instead of tags for suppression matching and measurement cycle id reporting, we use a single list of tags. 3) change ma-action-suppression-tags -> ma-action-tags The action tags will be echoed with result reports. The tags will not be suppression specific. Rationale: Instead of tags for suppression matching and measurement cycle id reporting, we use a single list of tags. 4) change ma-task-cycle-id -> ma-task-tags Change this into a list of tag values. Explain somewhere that a measurement cycle identifier can be encoded in the task tags or schedule tags or action tags. Rationale: Alignment with the YANG data model. The tags of schedules and actions (and those inherited from the tasks) will also be reported in the results. How this is done will be the subject of a separate proposal. (Note that ma-report-task-obj is kind of a misnomer since what is being executed are actions triggered by schedules.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Feb 9 08:56:51 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AF91ACD33 for ; Tue, 9 Feb 2016 08:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p42lQxrrBWdo for ; Tue, 9 Feb 2016 08:56:48 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6561C1ACD30 for ; Tue, 9 Feb 2016 08:56:48 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 33DC71056; Tue, 9 Feb 2016 17:56:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rdku3tqRdznK; Tue, 9 Feb 2016 17:56:46 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 9 Feb 2016 17:56:46 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BA1E2002C; Tue, 9 Feb 2016 17:56:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UyJdM7DHAEnp; Tue, 9 Feb 2016 17:56:45 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCA2B2002B; Tue, 9 Feb 2016 17:56:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A778C39E195B; Tue, 9 Feb 2016 17:56:45 +0100 (CET) Date: Tue, 9 Feb 2016 17:56:45 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20160209165645.GD31941@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA6BF0DE9F@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BF0DE9F@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] second virtual interim - yes or not? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 16:56:50 -0000 Dan, I have been spending a couple of days updating our implementation in order to align it with the current definitions. I have just posted a proposal to simplify and streamline how we use tags. The main question really is whether you want me to have a separate email thread for every issue that comes up or whether you want me to produce a proposal in the form of a revised IDs that we then discuss. The thing is that I now have three documents to keep consistent, the information model, the YANG data model, and our C code. The more drain there is between the three, the more complicated my editing job gets. /js PS: I just sent a question to the yang-doctors concerning the usage of boolean vs. empty leafs, which is triggered by lmap but a more general 'how to do things in YANG question' I think. The question is whether to use true or and it was not clear to me whether there are any hidden gotchas. On Mon, Feb 08, 2016 at 04:14:37PM +0000, Romascanu, Dan (Dan) wrote: > Hi, > > The second virtual interim meeting between IETF 94 and IETF 95 is scheduled tentatively two weeks from now, for 2/22. > > At the previous interim (on 1/12) we said that a final decision will be taken based on work progress. Right now the situation seems to be that we had a couple of important threads related to the Information Model on the mail list, but the I-D was not updated. First question is for the document editor (Juergen) whether an update is expected to be submitted in the coming days. Second question is for all WG participants - will holding the 2/22 meeting be useful? If yes, what should be on the agenda. > > We need to reach a decision by the end of the week. The agenda needs to be submitted until 2/15 the latest. > > Thanks and Regards, > > Dan > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Feb 9 09:40:10 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD601ACD58 for ; Tue, 9 Feb 2016 09:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_CPj3aokObh for ; Tue, 9 Feb 2016 09:40:06 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF2E1A8994 for ; Tue, 9 Feb 2016 09:40:05 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BLBQAzJLpW/xUHmMZbAxkBAQEBDwEBAQGCXytSbQaIVrEqgWYhhWwCgTY5EwEBAQEBAQGBCoRBAQEBAQMSKDQLDAICAgEIDQECAQQBAQEKFAkHGxcUCQgCBA4FCBqHeQENpVOZMQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEBIYQhDWEAhACAR0hJoJkgQ8FlngBhUuCbIZzh12FO4VviFAiAT+CAxmBSGoBh1YBewEBAQ X-IPAS-Result: A2BLBQAzJLpW/xUHmMZbAxkBAQEBDwEBAQGCXytSbQaIVrEqgWYhhWwCgTY5EwEBAQEBAQGBCoRBAQEBAQMSKDQLDAICAgEIDQECAQQBAQEKFAkHGxcUCQgCBA4FCBqHeQENpVOZMQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEBIYQhDWEAhACAR0hJoJkgQ8FlngBhUuCbIZzh12FO4VviFAiAT+CAxmBSGoBh1YBewEBAQ X-IronPort-AV: E=Sophos;i="5.22,421,1449550800"; d="scan'208";a="141960120" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Feb 2016 12:39:51 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 09 Feb 2016 12:39:51 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Tue, 9 Feb 2016 12:39:47 -0500 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [lmap] second virtual interim - yes or not? Thread-Index: AQHRY1rltagUzcEpqESNMmy0sr/dKZ8j8IlA Date: Tue, 9 Feb 2016 17:39:46 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF107D6@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BF0DE9F@AZ-FFEXMB04.global.avaya.com> <20160209165645.GD31941@elstar.local> In-Reply-To: <20160209165645.GD31941@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] second virtual interim - yes or not? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 17:40:08 -0000 Hi Juergen, My take is that the information model drives the other items and this is wh= ere we should focus.=20 Thus my personal preference is for submitting a revised ID, and discussing = it on the mail list, and then at the virtual interim. That's only a contrib= utor opinion, however, and I invite other WG participants to express their = preferences.=20 Thanks for all the great work.=20 Regards, Dan > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Tuesday, February 09, 2016 6:57 PM > To: Romascanu, Dan (Dan) > Cc: lmap@ietf.org > Subject: Re: [lmap] second virtual interim - yes or not? >=20 > Dan, >=20 > I have been spending a couple of days updating our implementation in orde= r > to align it with the current definitions. I have just posted a proposal t= o > simplify and streamline how we use tags. >=20 > The main question really is whether you want me to have a separate email > thread for every issue that comes up or whether you want me to produce a > proposal in the form of a revised IDs that we then discuss. > The thing is that I now have three documents to keep consistent, the > information model, the YANG data model, and our C code. The more drain > there is between the three, the more complicated my editing job gets. >=20 > /js >=20 > PS: I just sent a question to the yang-doctors concerning the usage of > boolean vs. empty leafs, which is triggered by lmap but a more > general 'how to do things in YANG question' I think. The question > is whether to use >=20 > true >=20 > or >=20 > >=20 > and it was not clear to me whether there are any hidden gotchas. >=20 > On Mon, Feb 08, 2016 at 04:14:37PM +0000, Romascanu, Dan (Dan) wrote: > > Hi, > > > > The second virtual interim meeting between IETF 94 and IETF 95 is > scheduled tentatively two weeks from now, for 2/22. > > > > At the previous interim (on 1/12) we said that a final decision will be= taken > based on work progress. Right now the situation seems to be that we had a > couple of important threads related to the Information Model on the mail > list, but the I-D was not updated. First question is for the document edi= tor > (Juergen) whether an update is expected to be submitted in the coming > days. Second question is for all WG participants - will holding the 2/22 > meeting be useful? If yes, what should be on the agenda. > > > > We need to reach a decision by the end of the week. The agenda needs to > be submitted until 2/15 the latest. > > > > Thanks and Regards, > > > > Dan > > >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mail > > > man_listinfo_lmap&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31 > OcNXCJf > > QzvlsiLQfucBXRucPvdrphpBsFA&m=3D4Z7KQTkSKOI832ZN4b6bO6G-nufG- > MIMprSYF9Y- > > dGA&s=3DAxutEEpLbkYM3N6zi_WxFvEBE1k6QU16ZzYIPnzTBXA&e=3D >=20 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > 2Duniversity.de_&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3D4Z7KQTkSKOI832ZN4b6bO6G- > nufG-MIMprSYF9Y-dGA&s=3DanMVV2gbSQNljlkBIMIH5IqeJ- > UA6sPOp2Yj1LSgy_Q&e=3D > >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_lmap&d=3DBQICAg&c=3DBFpWQw8bsuKpl1 > SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3D4Z7KQTk > SKOI832ZN4b6bO6G-nufG-MIMprSYF9Y- > dGA&s=3DAxutEEpLbkYM3N6zi_WxFvEBE1k6QU16ZzYIPnzTBXA&e=3D From nobody Tue Feb 9 11:51:43 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D785D1ACEF4 for ; Tue, 9 Feb 2016 11:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZz1Chynl1vZ for ; Tue, 9 Feb 2016 11:51:40 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4181ACEF7 for ; Tue, 9 Feb 2016 11:51:39 -0800 (PST) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 104967FA811F7; Tue, 9 Feb 2016 19:51:35 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u19JpcwL000526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Feb 2016 19:51:38 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u19JpblW019780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Feb 2016 19:51:38 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.137]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 9 Feb 2016 14:51:37 -0500 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder , "lmap@ietf.org" Thread-Topic: [lmap] streamlining the usage of tags Thread-Index: AQHRY2DxbzGLMDoGe0em7unjNVDMyZ8kGr8Q Date: Tue, 9 Feb 2016 19:51:38 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A5BCBA5@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20160209164527.GC31941@elstar.local> In-Reply-To: <20160209164527.GC31941@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] streamlining the usage of tags X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 19:51:42 -0000 Juergen, I know in section 5.2 of BBF TR-304 (https://www.broadband-forum.org/techni= cal/download/TR-304.pdf) there are specific requirements outlined for suppr= ession. These requirements were reflected in the information model - So the concept= s of suppressing a schedule or individual action is necessary if I read the= requirements correctly. I am alittle concerned about merging the option tags with the suppression t= ags simply because we do not have a way of identifying one type of tag by a= nother. One is used for correlation of suppression messages; the other for actions/= tasks... BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, February 09, 2016 10:45 AM To: lmap@ietf.org Subject: [lmap] streamlining the usage of tags Here is a proposal to streamline the usage of tags so that tags can be effi= ciently used both for suppression (identifying the set of schedules or acti= ons to suppress) and for reporting what the framework calls measurement cyc= le identifiers (see also the email thread 'LMAP Result Correlation'). 1) change ma-suppression-tags -> ma-suppression-match Explain that matching is using glob-style pattern (* matches any sequence of characters, ? matches a single arbitrary character, [] matches a set or sequence of characters, \ followed by a character matches the following character). (This definition is consistent with Posix fnmatch()). The ma-suppression-match values are going to match ma-schedule-tags or ma-action-tags (plus any tags inherited from the referenced task). Multiple ma-suppression-match result in the union of the individual matches. Rationale: Glob style matching allows to use tags that have a certain structure. For example, all schedules belonging a regulator X's campaign in year YYYY could be tagged with X-YYYY and then I can easily suppress lets say all fcc measurements (fcc-*) or all measurements in 2016 (*-2016) etc. Right now, we only have all and an explicit list of tags. Q: Does it make sense to suppress actions contained in a schedule? Or is it sufficient to suppress whole schedules? If we allow to suppress individual actions, what does this mean in pipelined execution mode? I would say it breaks the pipeline, that is, all subsequent actions will as a consequence of breaking the pipeline be suppressed as well. 2) change ma-suppression-tags -> ma-schedule-tags The schedule tags may be used for matching suppressions but they will also be echoed with result reports. Rationale: Instead of tags for suppression matching and measurement cycle id reporting, we use a single list of tags. 3) change ma-action-suppression-tags -> ma-action-tags The action tags will be echoed with result reports. The tags will not be suppression specific. Rationale: Instead of tags for suppression matching and measurement cycle id reporting, we use a single list of tags. 4) change ma-task-cycle-id -> ma-task-tags Change this into a list of tag values. Explain somewhere that a measurement cycle identifier can be encoded in the task tags or schedule tags or action tags. Rationale: Alignment with the YANG data model. The tags of schedules and actions (and those inherited from the tasks) will= also be reported in the results. How this is done will be the subject of a= separate proposal. (Note that ma-report-task-obj is kind of a misnomer sin= ce what is being executed are actions triggered by schedules.) /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 11 07:56:05 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E3B1B2C27 for ; Thu, 11 Feb 2016 07:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS8bkuYUybp2 for ; Thu, 11 Feb 2016 07:56:02 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296FA1B2B7B for ; Thu, 11 Feb 2016 07:56:02 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 53D02120E for ; Thu, 11 Feb 2016 16:56:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id h7uaVdrgBBmF for ; Thu, 11 Feb 2016 16:55:54 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 11 Feb 2016 16:55:59 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A5CB22002C for ; Thu, 11 Feb 2016 16:55:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Z2NoZdOjeC8q; Thu, 11 Feb 2016 16:55:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EB2B2002B; Thu, 11 Feb 2016 16:55:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 916D239E3C23; Thu, 11 Feb 2016 16:55:59 +0100 (CET) Date: Thu, 11 Feb 2016 16:55:59 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20160211155559.GA55278@elstar.local> Mail-Followup-To: lmap@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [lmap] milliseconds in ma-periodic-interval and ma-event-random-spread X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 15:56:03 -0000 Hi, the timing objects use milliseconds for (a) the periodic timer interval and (b) for the random spread. Since timing objects are used to start the execution of schedules (which then trigger tasks) and they are not used for packet timings (as this happens inside of measurement tasks), I find the millisecond resolution (i) awkward to read and configure, (ii) somewhat painful to implement (can't simply use a time_t internally), and (iii) pretty useless (since there will be some additional unpredictable delay until a task has been started and a first packet his a wire). Note also that timing events have a maximum resolution of seconds. Hence, my proposal is to change ma-periodic-interval and ma-event-random-spread from milliseconds to seconds. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 11 08:41:43 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928EE1B2C2B for ; Thu, 11 Feb 2016 08:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZzFPJ6rHkqD for ; Thu, 11 Feb 2016 08:41:39 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id A930C1B2C3F for ; Thu, 11 Feb 2016 08:41:39 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 01C0A1224AF; Thu, 11 Feb 2016 11:44:47 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id 2BA2EF04E0; Thu, 11 Feb 2016 11:41:36 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Thu, 11 Feb 2016 11:41:36 -0500 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , "lmap@ietf.org" Date: Thu, 11 Feb 2016 11:41:35 -0500 Thread-Topic: [lmap] milliseconds in ma-periodic-interval and ma-event-random-spread Thread-Index: AdFk5MC7XNi1CDJ1RWOYlQv2nlUDowAA5jsA Message-ID: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30488@NJFPSRVEXG0.research.att.com> References: <20160211155559.GA55278@elstar.local> In-Reply-To: <20160211155559.GA55278@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] milliseconds in ma-periodic-interval and ma-event-random-spread X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 16:41:41 -0000 Hi Juergen, Brief reply with reservations on your proposal, apologies in advance. Many active measurements are conducted using periodic packet streams at integer second intervals, and many use 1 second inter-packet intervals. Or, when emulating VoIP, 20ms inter-packet intervals. Integer random spreads don't help these cases. The intent of the random spread is to assist multiple streams from aligning= . We aren't just talking about 1 sender here. Large Scale. Even if some implementations have an unpredictable delay after the task is initiated, others could anticipate the schedule and=20 prepare a measurement process so it actually begins sending=20 when scheduled. Perhaps we can work out another solution, but I feel that=20 changing to integer random spreads would be a mistake. http://tools.ietf.org/html/rfc3432#section-3 Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Thursday, February 11, 2016 10:56 AM > To: lmap@ietf.org > Subject: [lmap] milliseconds in ma-periodic-interval and ma-event- > random-spread >=20 > Hi, >=20 > the timing objects use milliseconds for (a) the periodic timer > interval and (b) for the random spread. Since timing objects are used > to start the execution of schedules (which then trigger tasks) and > they are not used for packet timings (as this happens inside of > measurement tasks), I find the millisecond resolution (i) awkward to > read and configure, (ii) somewhat painful to implement (can't simply > use a time_t internally), and (iii) pretty useless (since there will > be some additional unpredictable delay until a task has been started > and a first packet his a wire). >=20 > Note also that timing events have a maximum resolution of > seconds. Hence, my proposal is to change ma-periodic-interval and > ma-event-random-spread from milliseconds to seconds. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Feb 12 14:31:08 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCDD1A914A for ; Fri, 12 Feb 2016 14:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-DqCkMEV888 for ; Fri, 12 Feb 2016 14:31:04 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F021A9149 for ; Fri, 12 Feb 2016 14:31:04 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id p63so39951520wmp.1 for ; Fri, 12 Feb 2016 14:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viavisolutions-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=5P2MHy0W8ybf158YHKSRcoLWUHoNt6iJ2+H0nLhj3U8=; b=Qn2T+0AZWbiDzvVQppcOW+NFkQctTakFBB52dIfeBfKzWGXj+w8UDEgxcHTnzaFGCo qe7I+AaFEcck+E1dLmmlARs+LQbTClXKYpib7NLLWxekk465iabexDwYCGmy5HsZsl4e uyc0VuPihhZtnp+DGzSixMe2ULHFpdcpHHiSO07mgZJJnvFCCn2NF25sfhKY8Q73+V1m icf1r9tz4cIjqgbFAi5+bVaO+eOfbqemdUvCGVvxpVTJ3IWj+Q/0XASdXLZHCrB2JQfb +3dKGZo1wVYIZ5bcyKt1rQoiw3vRIoNyNLWaaLw+O2Kb4vCaSC5OjI0XtXuzQvCMvAlE 9+RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=5P2MHy0W8ybf158YHKSRcoLWUHoNt6iJ2+H0nLhj3U8=; b=A+4ezqxAM+aS3xlyCCXyInHVnDzwIBghCoBESDnZz5bLh2Mnc+kJxK5TMTjykTxxKe UJjSyEmrRler+X1nJVlUFTx4fwiMrTxQ6lN0Q9D4JgLYp2X0nMjArDMH+7mufbiK79J0 f64eAKNTGDB2wdxxJo46vFWbek+m0MLSD/SrAJ9p7ANkD+ifooLEzOX/P9LrSiJqAGot kp5sUi5FP/9FQgbB1AmiPLkfwTqWIvrSOaVa+pWO8jS05DOu4HBxE6CnWCcThb26h2lp TKTZWBbSps8McHLmVH82gaiWCn7R0c+U9IXSjBrnG7fYUoLlBGC3Y3I1ayKTJ7bQ/kz/ mSJw== X-Gm-Message-State: AG10YOQKkF472lteLOMXC2KtQvjXy8Jyj15kY4b15WRiSOua44py/VPjkDljFHsEVURSBtAy4QYBEH0BSK0yKVIE MIME-Version: 1.0 X-Received: by 10.28.88.81 with SMTP id m78mr212888wmb.58.1455316262756; Fri, 12 Feb 2016 14:31:02 -0800 (PST) Received: by 10.28.165.147 with HTTP; Fri, 12 Feb 2016 14:31:02 -0800 (PST) Date: Fri, 12 Feb 2016 17:31:02 -0500 Message-ID: From: Ron Stana To: lmap@ietf.org Content-Type: multipart/alternative; boundary=001a11443124e0c992052b9a38dc Archived-At: Cc: alissa@cooperw.in Subject: [lmap] Support for multiple report table formats from one task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 22:31:07 -0000 --001a11443124e0c992052b9a38dc Content-Type: text/plain; charset=UTF-8 LMAP Team, My understanding of the LMAP proposal is ietf-lmap-report:report/task/name is supposed to contain one of the values defined in ietf-lmap-control:lmap/tasks/task/name. If this is correct, and since each task instance within a report can only contain one table definition (one header + its row data) then how does a task send multiple tables of results that contain different table formats? Use Cases: 1) Y.1564 task has results for the Service Configuration and the Service Performance data, and each table has a different set of columns. 2) An RFC-2544 task would need a different table for the Throughput, Latency, Frame Loss and Back to Back result sets. 3) Any task may want to send a minimal result set while it is executing that is very different from the final result set when it has completed. The ietf-lmap-report:report/task/tag could be used to differentiate the result sets sent by the same task. However this is not very efficient since this approach requires the MA to send each report to the collector separately because each report can only contain one set of results per task name. Any guidance or clarification on the LMAP proposal would be appreciated, Ron --001a11443124e0c992052b9a38dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
LMAP Team,

My understanding of the LMAP= proposal is ietf-lmap-report:report/task/name is supposed to contain one o= f the values defined in ietf-lmap-control:lmap/tasks/task/name.
<= br>
If this is correct, and since each task instance within a rep= ort can only contain one table definition (one header + its row data) then = how does a task send multiple tables of results that contain different tabl= e formats?

Use Cases:
1) Y.1564 task has= results for the Service Configuration and the Service Performance data, an= d each table has a different set of columns.
2) An RFC-2544 task = would need a different table for the Throughput, Latency, Frame Loss and Ba= ck to Back result sets.
3) Any task may want to send a minimal re= sult set while it is executing that is very different from the final result= set when it has completed.

The ietf-lmap-report:r= eport/task/tag could be used to differentiate the result sets sent by the s= ame task. However this is not very efficient since this approach requires t= he MA to send each report to the collector separately because each report c= an only contain one set of results per task name.

= Any guidance or clarification on the LMAP proposal would be appreciated,

Ron





--001a11443124e0c992052b9a38dc-- From nobody Sun Feb 14 08:11:58 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDF01AD0D1 for ; Sun, 14 Feb 2016 08:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldlM6JN16Dxk for ; Sun, 14 Feb 2016 08:11:54 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A1E1AD0D0 for ; Sun, 14 Feb 2016 08:11:54 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 358B2DF09B776; Sun, 14 Feb 2016 16:11:51 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u1EGBqT0010940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 14 Feb 2016 16:11:52 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u1EGBp7T013024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Feb 2016 16:11:51 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.121]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Sun, 14 Feb 2016 11:11:51 -0500 From: "Carey, Timothy (Nokia - US)" To: Ron Stana , "lmap@ietf.org" Thread-Topic: [lmap] Support for multiple report table formats from one task Thread-Index: AQHRZpkvpmDKnEpIoUqJmeiE7E+MV58rttDw Date: Sun, 14 Feb 2016 16:11:51 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A5CE3C2@US70UWXCHMBA05.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A5CE3C2US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Cc: "alissa@cooperw.in" Subject: Re: [lmap] Support for multiple report table formats from one task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 16:11:56 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A5CE3C2US70UWXCHMBA0_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9uLA0KDQpUaGUgdGFzayBoYXMgbXVsdGlwbGUgcmVnaXN0cnkgZW50cmllcyDigJMgSSB3b3Vs ZCBhc3N1bWUgeW91ciBleGFtcGxlIGlzIHRoYXQgdGhpcyB0YXNrDQp3b3VsZCBoYXZlIDMgcmVn aXN0cnkgZW50cmllcy4NCg0KVGhlIGNvbHVtbnMgYXJlIGZvciB0aGUgdGFzayBhbmQgd291bGQg aGF2ZSB0byBoYXZlIGEgdW5pb24gb2YgYWxsIHRoZSBtZXRyaWNzIGZvciByZWdpc3RyeSBlbnRy aWVzLiDigJMgSXMgdGhpcyB3aGF0IHlvdSB3ZXJlIGFza2luZz8NCg0KSXQgc2VlbXMgdGhhdCB3 ZSBsb3NlIHRoZSBjb250ZXh0IG9mIHRoZSByZWdpc3RyeSBlbnRyeSB0byBjb2x1bW4gdGhvdWdo 4oCmDQoNCkJSLA0KVGltDQoNCkZyb206IFJvbiBTdGFuYSBbbWFpbHRvOnJvbi5zdGFuYUB2aWF2 aXNvbHV0aW9ucy5jb21dDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDEyLCAyMDE2IDQ6MzEgUE0N ClRvOiBsbWFwQGlldGYub3JnDQpDYzogYWxpc3NhQGNvb3BlcncuaW4NClN1YmplY3Q6IFtsbWFw XSBTdXBwb3J0IGZvciBtdWx0aXBsZSByZXBvcnQgdGFibGUgZm9ybWF0cyBmcm9tIG9uZSB0YXNr DQoNCkxNQVAgVGVhbSwNCg0KTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgTE1BUCBwcm9wb3NhbCBp cyBpZXRmLWxtYXAtcmVwb3J0OnJlcG9ydC90YXNrL25hbWUgaXMgc3VwcG9zZWQgdG8gY29udGFp biBvbmUgb2YgdGhlIHZhbHVlcyBkZWZpbmVkIGluIGlldGYtbG1hcC1jb250cm9sOmxtYXAvdGFz a3MvdGFzay9uYW1lLg0KDQpJZiB0aGlzIGlzIGNvcnJlY3QsIGFuZCBzaW5jZSBlYWNoIHRhc2sg aW5zdGFuY2Ugd2l0aGluIGEgcmVwb3J0IGNhbiBvbmx5IGNvbnRhaW4gb25lIHRhYmxlIGRlZmlu aXRpb24gKG9uZSBoZWFkZXIgKyBpdHMgcm93IGRhdGEpIHRoZW4gaG93IGRvZXMgYSB0YXNrIHNl bmQgbXVsdGlwbGUgdGFibGVzIG9mIHJlc3VsdHMgdGhhdCBjb250YWluIGRpZmZlcmVudCB0YWJs ZSBmb3JtYXRzPw0KDQpVc2UgQ2FzZXM6DQoxKSBZLjE1NjQgdGFzayBoYXMgcmVzdWx0cyBmb3Ig dGhlIFNlcnZpY2UgQ29uZmlndXJhdGlvbiBhbmQgdGhlIFNlcnZpY2UgUGVyZm9ybWFuY2UgZGF0 YSwgYW5kIGVhY2ggdGFibGUgaGFzIGEgZGlmZmVyZW50IHNldCBvZiBjb2x1bW5zLg0KMikgQW4g UkZDLTI1NDQgdGFzayB3b3VsZCBuZWVkIGEgZGlmZmVyZW50IHRhYmxlIGZvciB0aGUgVGhyb3Vn aHB1dCwgTGF0ZW5jeSwgRnJhbWUgTG9zcyBhbmQgQmFjayB0byBCYWNrIHJlc3VsdCBzZXRzLg0K MykgQW55IHRhc2sgbWF5IHdhbnQgdG8gc2VuZCBhIG1pbmltYWwgcmVzdWx0IHNldCB3aGlsZSBp dCBpcyBleGVjdXRpbmcgdGhhdCBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIHRoZSBmaW5hbCByZXN1 bHQgc2V0IHdoZW4gaXQgaGFzIGNvbXBsZXRlZC4NCg0KVGhlIGlldGYtbG1hcC1yZXBvcnQ6cmVw b3J0L3Rhc2svdGFnIGNvdWxkIGJlIHVzZWQgdG8gZGlmZmVyZW50aWF0ZSB0aGUgcmVzdWx0IHNl dHMgc2VudCBieSB0aGUgc2FtZSB0YXNrLiBIb3dldmVyIHRoaXMgaXMgbm90IHZlcnkgZWZmaWNp ZW50IHNpbmNlIHRoaXMgYXBwcm9hY2ggcmVxdWlyZXMgdGhlIE1BIHRvIHNlbmQgZWFjaCByZXBv cnQgdG8gdGhlIGNvbGxlY3RvciBzZXBhcmF0ZWx5IGJlY2F1c2UgZWFjaCByZXBvcnQgY2FuIG9u bHkgY29udGFpbiBvbmUgc2V0IG9mIHJlc3VsdHMgcGVyIHRhc2sgbmFtZS4NCg0KQW55IGd1aWRh bmNlIG9yIGNsYXJpZmljYXRpb24gb24gdGhlIExNQVAgcHJvcG9zYWwgd291bGQgYmUgYXBwcmVj aWF0ZWQsDQoNClJvbg0KDQoNCg0KDQoNCg== --_000_9966516C6EB5FC4381E05BF80AA55F77012A5CE3C2US70UWXCHMBA0_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1T IjsNCglwYW5vc2UtMToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IlRyZWJ1Y2hldCBNUyIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVi dWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb24s PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHRhc2sgaGFzIG11bHRpcGxlIHJlZ2lzdHJ5IGVudHJp ZXMg4oCTIEkgd291bGQgYXNzdW1lIHlvdXIgZXhhbXBsZSBpcyB0aGF0IHRoaXMgdGFzazxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPndvdWxkIGhhdmUgMyByZWdpc3RyeSBlbnRy aWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBjb2x1bW5zIGFyZSBmb3IgdGhlIHRhc2sgYW5k IHdvdWxkIGhhdmUgdG8gaGF2ZSBhIHVuaW9uIG9mIGFsbCB0aGUgbWV0cmljcyBmb3IgcmVnaXN0 cnkgZW50cmllcy4g4oCTIElzIHRoaXMgd2hhdCB5b3Ugd2VyZSBhc2tpbmc/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SXQgc2VlbXMgdGhhdCB3ZSBsb3NlIHRoZSBjb250ZXh0IG9mIHRoZSByZWdpc3Ry eSBlbnRyeSB0byBjb2x1bW4gdGhvdWdo4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0 IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QlIsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGltPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJvbiBT dGFuYSBbbWFpbHRvOnJvbi5zdGFuYUB2aWF2aXNvbHV0aW9ucy5jb21dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAxMiwgMjAxNiA0OjMxIFBNPGJyPg0KPGI+VG86PC9iPiBs bWFwQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBhbGlzc2FAY29vcGVydy5pbjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBbbG1hcF0gU3VwcG9ydCBmb3IgbXVsdGlwbGUgcmVwb3J0IHRhYmxlIGZvcm1h dHMgZnJvbSBvbmUgdGFzazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TE1BUCBUZWFtLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgTE1BUCBwcm9wb3NhbCBpcyBpZXRmLWxtYXAt cmVwb3J0OnJlcG9ydC90YXNrL25hbWUgaXMgc3VwcG9zZWQgdG8gY29udGFpbiBvbmUgb2YgdGhl IHZhbHVlcyBkZWZpbmVkIGluIGlldGYtbG1hcC1jb250cm9sOmxtYXAvdGFza3MvdGFzay9uYW1l LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J ZiB0aGlzIGlzIGNvcnJlY3QsIGFuZCBzaW5jZSBlYWNoIHRhc2sgaW5zdGFuY2Ugd2l0aGluIGEg cmVwb3J0IGNhbiBvbmx5IGNvbnRhaW4gb25lIHRhYmxlIGRlZmluaXRpb24gKG9uZSBoZWFkZXIg JiM0MzsgaXRzIHJvdyBkYXRhKSB0aGVuIGhvdyBkb2VzIGEgdGFzayBzZW5kIG11bHRpcGxlIHRh YmxlcyBvZiByZXN1bHRzIHRoYXQgY29udGFpbiBkaWZmZXJlbnQgdGFibGUgZm9ybWF0cz88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VXNlIENh c2VzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ MSkgWS4xNTY0IHRhc2sgaGFzIHJlc3VsdHMgZm9yIHRoZSBTZXJ2aWNlIENvbmZpZ3VyYXRpb24g YW5kIHRoZSBTZXJ2aWNlIFBlcmZvcm1hbmNlIGRhdGEsIGFuZCBlYWNoIHRhYmxlIGhhcyBhIGRp ZmZlcmVudCBzZXQgb2YgY29sdW1ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjIpIEFuIFJGQy0yNTQ0IHRhc2sgd291bGQgbmVlZCBhIGRpZmZl cmVudCB0YWJsZSBmb3IgdGhlIFRocm91Z2hwdXQsIExhdGVuY3ksIEZyYW1lIExvc3MgYW5kIEJh Y2sgdG8gQmFjayByZXN1bHQgc2V0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjMpIEFueSB0YXNrIG1heSB3YW50IHRvIHNlbmQgYSBtaW5pbWFs IHJlc3VsdCBzZXQgd2hpbGUgaXQgaXMgZXhlY3V0aW5nIHRoYXQgaXMgdmVyeSBkaWZmZXJlbnQg ZnJvbSB0aGUgZmluYWwgcmVzdWx0IHNldCB3aGVuIGl0IGhhcyBjb21wbGV0ZWQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpZXRmLWxt YXAtcmVwb3J0OnJlcG9ydC90YXNrL3RhZyBjb3VsZCBiZSB1c2VkIHRvIGRpZmZlcmVudGlhdGUg dGhlIHJlc3VsdCBzZXRzIHNlbnQgYnkgdGhlIHNhbWUgdGFzay4gSG93ZXZlciB0aGlzIGlzIG5v dCB2ZXJ5IGVmZmljaWVudCBzaW5jZSB0aGlzIGFwcHJvYWNoIHJlcXVpcmVzIHRoZSBNQSB0byBz ZW5kIGVhY2ggcmVwb3J0IHRvIHRoZSBjb2xsZWN0b3Igc2VwYXJhdGVseSBiZWNhdXNlIGVhY2gN CiByZXBvcnQgY2FuIG9ubHkgY29udGFpbiBvbmUgc2V0IG9mIHJlc3VsdHMgcGVyIHRhc2sgbmFt ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QW55IGd1aWRhbmNlIG9yIGNsYXJpZmljYXRpb24gb24gdGhlIExNQVAgcHJvcG9zYWwgd291bGQg YmUgYXBwcmVjaWF0ZWQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlJvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9966516C6EB5FC4381E05BF80AA55F77012A5CE3C2US70UWXCHMBA0_-- From nobody Mon Feb 15 03:16:28 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8DA1A0078 for ; Mon, 15 Feb 2016 03:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oCmZe6EN6qX for ; Mon, 15 Feb 2016 03:16:24 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286981A90AD for ; Mon, 15 Feb 2016 03:16:24 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0F5F19D5; Mon, 15 Feb 2016 12:16:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4Fu_2FRYRb8F; Mon, 15 Feb 2016 12:16:18 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 15 Feb 2016 12:16:21 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 163C620031; Mon, 15 Feb 2016 12:16:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id F3qKYL3T1dT6; Mon, 15 Feb 2016 12:16:20 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F5ED2002C; Mon, 15 Feb 2016 12:16:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id ED7B339F21BE; Mon, 15 Feb 2016 12:16:20 +0100 (CET) Date: Mon, 15 Feb 2016 12:16:20 +0100 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20160215111620.GB71796@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <20160211155559.GA55278@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D3FF3A30488@NJFPSRVEXG0.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30488@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] milliseconds in ma-periodic-interval and ma-event-random-spread X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 11:16:26 -0000 Al, this is the scheduler starting measurement tasks, it is _not_ the task internal scheduler that sends packet streams. Some large existing measurement systems use cron for this purpose and cron does at most second granularity (at least those that I have seen in my life so far). This is _not_ about inter-packet intervals etc. /js On Thu, Feb 11, 2016 at 11:41:35AM -0500, MORTON, ALFRED C (AL) wrote: > Hi Juergen, > > Brief reply with reservations on your proposal, apologies in advance. > > Many active measurements are conducted using periodic packet streams > at integer second intervals, and many use 1 second inter-packet intervals. > Or, when emulating VoIP, 20ms inter-packet intervals. > Integer random spreads don't help these cases. > > The intent of the random spread is to assist multiple streams from aligning. > We aren't just talking about 1 sender here. Large Scale. > > Even if some implementations have an unpredictable delay after the > task is initiated, others could anticipate the schedule and > prepare a measurement process so it actually begins sending > when scheduled. > > Perhaps we can work out another solution, but I feel that > changing to integer random spreads would be a mistake. > http://tools.ietf.org/html/rfc3432#section-3 > > Al > > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Thursday, February 11, 2016 10:56 AM > > To: lmap@ietf.org > > Subject: [lmap] milliseconds in ma-periodic-interval and ma-event- > > random-spread > > > > Hi, > > > > the timing objects use milliseconds for (a) the periodic timer > > interval and (b) for the random spread. Since timing objects are used > > to start the execution of schedules (which then trigger tasks) and > > they are not used for packet timings (as this happens inside of > > measurement tasks), I find the millisecond resolution (i) awkward to > > read and configure, (ii) somewhat painful to implement (can't simply > > use a time_t internally), and (iii) pretty useless (since there will > > be some additional unpredictable delay until a task has been started > > and a first packet his a wire). > > > > Note also that timing events have a maximum resolution of > > seconds. Hence, my proposal is to change ma-periodic-interval and > > ma-event-random-spread from milliseconds to seconds. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 15 03:53:24 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DD11B3139 for ; Mon, 15 Feb 2016 03:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.205 X-Spam-Level: X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuM6ibkLgopZ for ; Mon, 15 Feb 2016 03:53:22 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80271B31EB for ; Mon, 15 Feb 2016 03:53:22 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D1AQDUu8FW/yYyC4deGQEBAQEPAQECgj4hK1JzuhMBDYFnhg0CgS04FAEBAQEBAQF/C4RDAQEDEhteAQwJFVYmAQQbGod4AZ4lhRKYfwwBHYYSiGaDK4EPBZZ5AY8whEODGoU7jj4eAQFCg2OIZgF7AQEB X-IPAS-Result: A2D1AQDUu8FW/yYyC4deGQEBAQEPAQECgj4hK1JzuhMBDYFnhg0CgS04FAEBAQEBAQF/C4RDAQEDEhteAQwJFVYmAQQbGod4AZ4lhRKYfwwBHYYSiGaDK4EPBZZ5AY8whEODGoU7jj4eAQFCg2OIZgF7AQEB X-IronPort-AV: E=Sophos;i="5.22,450,1449550800"; d="scan'208,217";a="160903551" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Feb 2016 06:53:09 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 15 Feb 2016 06:53:09 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Mon, 15 Feb 2016 06:53:06 -0500 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: virtual interim - time for decision Thread-Index: AdFn52y66oGTZUowSo+BYltGTOzwEQ== Date: Mon, 15 Feb 2016 11:53:05 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF18FF5@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BF18FF5AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] virtual interim - time for decision X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 11:53:24 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF18FF5AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It's time to decide whether to hold the 2/22 LMAP virtual interim meeting. = Please state you opinions one way or the other. If you support holding the = meeting please state what should be on the agenda, as a draft of the agenda= must be uploaded today 2/15. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF18FF5AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

It’s time to decide whether to hold the 2/22 L= MAP virtual interim meeting. Please state you opinions one way or the other= . If you support holding the meeting please state what should be on the age= nda, as a draft of the agenda must be uploaded today 2/15.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BF18FF5AZFFEXMB04globa_-- From nobody Mon Feb 15 04:33:38 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D061B32B0 for ; Mon, 15 Feb 2016 04:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPJl8-hPMQE1 for ; Mon, 15 Feb 2016 04:33:35 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7525D1B32AE for ; Mon, 15 Feb 2016 04:33:35 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id F31C61210F8; Mon, 15 Feb 2016 07:34:29 -0500 (EST) Received: from exchange.research.att.com (sentinel.research.att.com [135.207.255.38]) by mail-green.research.att.com (Postfix) with ESMTP id D15EAE00C7; Mon, 15 Feb 2016 07:27:54 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by sentinel.research.att.com ([fe80::7914:9c7e:6a73:a8d6%10]) with mapi; Mon, 15 Feb 2016 07:31:07 -0500 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder Date: Mon, 15 Feb 2016 07:31:07 -0500 Thread-Topic: [lmap] milliseconds in ma-periodic-interval and ma-event-random-spread Thread-Index: AdFn4lT2XbZP3jHqRbeH824w5bP3UgACBuRE Message-ID: <4AF73AA205019A4C8A1DDD32C034631D3FF3B4288C@NJFPSRVEXG0.research.att.com> References: <20160211155559.GA55278@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D3FF3A30488@NJFPSRVEXG0.research.att.com>, <20160215111620.GB71796@elstar.local> In-Reply-To: <20160215111620.GB71796@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] milliseconds in ma-periodic-interval and ma-event-random-spread X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 12:33:37 -0000 Hi Juergen, I understand the difference between these schedulers quite well. If we both send one packet per second, and we both use random Integer second offsets for our start times, say 12:00:01 and 12:00:07, then we both send packets at the same time on the integer second chime (after 6 seconds). As I said below, we cannot count on random time to start a test after the schedule says 'go'.=20 The random offset is to deliberately avoid synchronization in cases like th= is. I get it, this is harder to do. Al ________________________________________ From: Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de] Sent: Monday, February 15, 2016 6:16 AM To: MORTON, ALFRED C (AL) Cc: lmap@ietf.org Subject: Re: [lmap] milliseconds in ma-periodic-interval and ma-event-rando= m-spread Al, this is the scheduler starting measurement tasks, it is _not_ the task internal scheduler that sends packet streams. Some large existing measurement systems use cron for this purpose and cron does at most second granularity (at least those that I have seen in my life so far). This is _not_ about inter-packet intervals etc. /js On Thu, Feb 11, 2016 at 11:41:35AM -0500, MORTON, ALFRED C (AL) wrote: > Hi Juergen, > > Brief reply with reservations on your proposal, apologies in advance. > > Many active measurements are conducted using periodic packet streams > at integer second intervals, and many use 1 second inter-packet intervals= . > Or, when emulating VoIP, 20ms inter-packet intervals. > Integer random spreads don't help these cases. > > The intent of the random spread is to assist multiple streams from aligni= ng. > We aren't just talking about 1 sender here. Large Scale. > > Even if some implementations have an unpredictable delay after the > task is initiated, others could anticipate the schedule and > prepare a measurement process so it actually begins sending > when scheduled. > > Perhaps we can work out another solution, but I feel that > changing to integer random spreads would be a mistake. > http://tools.ietf.org/html/rfc3432#section-3 > > Al > > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Thursday, February 11, 2016 10:56 AM > > To: lmap@ietf.org > > Subject: [lmap] milliseconds in ma-periodic-interval and ma-event- > > random-spread > > > > Hi, > > > > the timing objects use milliseconds for (a) the periodic timer > > interval and (b) for the random spread. Since timing objects are used > > to start the execution of schedules (which then trigger tasks) and > > they are not used for packet timings (as this happens inside of > > measurement tasks), I find the millisecond resolution (i) awkward to > > read and configure, (ii) somewhat painful to implement (can't simply > > use a time_t internally), and (iii) pretty useless (since there will > > be some additional unpredictable delay until a task has been started > > and a first packet his a wire). > > > > Note also that timing events have a maximum resolution of > > seconds. Hence, my proposal is to change ma-periodic-interval and > > ma-event-random-spread from milliseconds to seconds. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 15 05:42:57 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC131B3270 for ; Mon, 15 Feb 2016 05:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcxnOjTZ6Wgm for ; Mon, 15 Feb 2016 05:42:54 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35AF91B311C for ; Mon, 15 Feb 2016 05:42:54 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DD46510C8; Mon, 15 Feb 2016 14:42:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dj8JNqf57IOy; Mon, 15 Feb 2016 14:42:48 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 15 Feb 2016 14:42:51 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8841120031; Mon, 15 Feb 2016 14:42:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tEIXarK7JVqV; Mon, 15 Feb 2016 14:42:49 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5923E2002C; Mon, 15 Feb 2016 14:42:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CAA9839F224E; Mon, 15 Feb 2016 14:42:50 +0100 (CET) Date: Mon, 15 Feb 2016 14:42:50 +0100 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20160215134250.GA72079@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <20160211155559.GA55278@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D3FF3B4288C@NJFPSRVEXG0.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D3FF3B4288C@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] milliseconds in ma-periodic-interval and ma-event-random-spread X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 13:42:56 -0000 On Mon, Feb 15, 2016 at 07:31:07AM -0500, MORTON, ALFRED C (AL) wrote: > Hi Juergen, > I understand the difference between these schedulers quite well. > > If we both send one packet per second, and we both use random > Integer second offsets for our start times, say 12:00:01 and 12:00:07, > then we both send packets at the same time on the integer second > chime (after 6 seconds). As I said below, we cannot count on random > time to start a test after the schedule says 'go'. I do not understand your example. What are 12:00:01 and 12:00:07? One-off absolute times without ma-event-random-spread? Or your concern is that both packets will be aligned to the systems' notion of a 'complete' second? Well, not really true, since the event is going to start a task and the likelihood that the tasks start at exactly the same time and get their first packet on the way is small. Again, I question that it is realistic to schedule tasks to start once per second in order to send one packet. > The random offset is to deliberately avoid synchronization in cases > like this. The question is whether the granularity needs to be milliseconds. I did not question to have ma-event-random-spread. Note that regular crons do not even go to second resolution, they stop a minutes. OK, this is not a strong argument but perhaps the disconnect here is what kind of tasks we ultimately assume to be scheduled. Anyway, my original proposal was primarily about ma-periodic-interval. If people feel strongly that the ma-event-random-spread should remain with milliseconds resolution, I can probably live with that. Having ma-periodic-interval at milliseconds resolution is however more of a pain to implement. /js > I get it, this is harder to do. > Al > ________________________________________ > From: Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de] > Sent: Monday, February 15, 2016 6:16 AM > To: MORTON, ALFRED C (AL) > Cc: lmap@ietf.org > Subject: Re: [lmap] milliseconds in ma-periodic-interval and ma-event-random-spread > > Al, > > this is the scheduler starting measurement tasks, it is _not_ the task > internal scheduler that sends packet streams. Some large existing > measurement systems use cron for this purpose and cron does at most > second granularity (at least those that I have seen in my life so > far). This is _not_ about inter-packet intervals etc. > > /js > > On Thu, Feb 11, 2016 at 11:41:35AM -0500, MORTON, ALFRED C (AL) wrote: > > Hi Juergen, > > > > Brief reply with reservations on your proposal, apologies in advance. > > > > Many active measurements are conducted using periodic packet streams > > at integer second intervals, and many use 1 second inter-packet intervals. > > Or, when emulating VoIP, 20ms inter-packet intervals. > > Integer random spreads don't help these cases. > > > > The intent of the random spread is to assist multiple streams from aligning. > > We aren't just talking about 1 sender here. Large Scale. > > > > Even if some implementations have an unpredictable delay after the > > task is initiated, others could anticipate the schedule and > > prepare a measurement process so it actually begins sending > > when scheduled. > > > > Perhaps we can work out another solution, but I feel that > > changing to integer random spreads would be a mistake. > > http://tools.ietf.org/html/rfc3432#section-3 > > > > Al > > > > > > > -----Original Message----- > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: Thursday, February 11, 2016 10:56 AM > > > To: lmap@ietf.org > > > Subject: [lmap] milliseconds in ma-periodic-interval and ma-event- > > > random-spread > > > > > > Hi, > > > > > > the timing objects use milliseconds for (a) the periodic timer > > > interval and (b) for the random spread. Since timing objects are used > > > to start the execution of schedules (which then trigger tasks) and > > > they are not used for packet timings (as this happens inside of > > > measurement tasks), I find the millisecond resolution (i) awkward to > > > read and configure, (ii) somewhat painful to implement (can't simply > > > use a time_t internally), and (iii) pretty useless (since there will > > > be some additional unpredictable delay until a task has been started > > > and a first packet his a wire). > > > > > > Note also that timing events have a maximum resolution of > > > seconds. Hence, my proposal is to change ma-periodic-interval and > > > ma-event-random-spread from milliseconds to seconds. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 15 05:50:28 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AA51B3404 for ; Mon, 15 Feb 2016 05:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdS3x4ZWhnrC for ; Mon, 15 Feb 2016 05:50:25 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7D11B3402 for ; Mon, 15 Feb 2016 05:50:24 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6E8B08FC; Mon, 15 Feb 2016 14:50:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id E-lLTDalchQO; Mon, 15 Feb 2016 14:50:19 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 15 Feb 2016 14:50:22 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 437FE20031; Mon, 15 Feb 2016 14:50:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id S4hhpwUfvqKh; Mon, 15 Feb 2016 14:50:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B1FA2002C; Mon, 15 Feb 2016 14:50:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1233439F22E3; Mon, 15 Feb 2016 14:50:22 +0100 (CET) Date: Mon, 15 Feb 2016 14:50:22 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20160215135021.GA72134@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA6BF0DE9F@AZ-FFEXMB04.global.avaya.com> <20160209165645.GD31941@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA6BF107D6@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BF107D6@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] second virtual interim - yes or not? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 13:50:27 -0000 Dan, I am working on our implementation based on the YANG data model and things in reality go backwards (from implementation experience to data model changes to information model changes). Top down works on paper but the truth is you only know you got an information model right once there are corresponding data models and implementations of those data models. /js On Tue, Feb 09, 2016 at 05:39:46PM +0000, Romascanu, Dan (Dan) wrote: > Hi Juergen, > > My take is that the information model drives the other items and this is where we should focus. > > Thus my personal preference is for submitting a revised ID, and discussing it on the mail list, and then at the virtual interim. That's only a contributor opinion, however, and I invite other WG participants to express their preferences. > > Thanks for all the great work. > > Regards, > > Dan > > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Tuesday, February 09, 2016 6:57 PM > > To: Romascanu, Dan (Dan) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] second virtual interim - yes or not? > > > > Dan, > > > > I have been spending a couple of days updating our implementation in order > > to align it with the current definitions. I have just posted a proposal to > > simplify and streamline how we use tags. > > > > The main question really is whether you want me to have a separate email > > thread for every issue that comes up or whether you want me to produce a > > proposal in the form of a revised IDs that we then discuss. > > The thing is that I now have three documents to keep consistent, the > > information model, the YANG data model, and our C code. The more drain > > there is between the three, the more complicated my editing job gets. > > > > /js > > > > PS: I just sent a question to the yang-doctors concerning the usage of > > boolean vs. empty leafs, which is triggered by lmap but a more > > general 'how to do things in YANG question' I think. The question > > is whether to use > > > > true > > > > or > > > > > > > > and it was not clear to me whether there are any hidden gotchas. > > > > On Mon, Feb 08, 2016 at 04:14:37PM +0000, Romascanu, Dan (Dan) wrote: > > > Hi, > > > > > > The second virtual interim meeting between IETF 94 and IETF 95 is > > scheduled tentatively two weeks from now, for 2/22. > > > > > > At the previous interim (on 1/12) we said that a final decision will be taken > > based on work progress. Right now the situation seems to be that we had a > > couple of important threads related to the Information Model on the mail > > list, but the I-D was not updated. First question is for the document editor > > (Juergen) whether an update is expected to be submitted in the coming > > days. Second question is for all WG participants - will holding the 2/22 > > meeting be useful? If yes, what should be on the agenda. > > > > > > We need to reach a decision by the end of the week. The agenda needs to > > be submitted until 2/15 the latest. > > > > > > Thanks and Regards, > > > > > > Dan > > > > > > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_mail > > > > > man_listinfo_lmap&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31 > > OcNXCJf > > > QzvlsiLQfucBXRucPvdrphpBsFA&m=4Z7KQTkSKOI832ZN4b6bO6G-nufG- > > MIMprSYF9Y- > > > dGA&s=AxutEEpLbkYM3N6zi_WxFvEBE1k6QU16ZzYIPnzTBXA&e= > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > 2Duniversity.de_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O > > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=4Z7KQTkSKOI832ZN4b6bO6G- > > nufG-MIMprSYF9Y-dGA&s=anMVV2gbSQNljlkBIMIH5IqeJ- > > UA6sPOp2Yj1LSgy_Q&e= > > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_mailman_listinfo_lmap&d=BQICAg&c=BFpWQw8bsuKpl1 > > SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=4Z7KQTk > > SKOI832ZN4b6bO6G-nufG-MIMprSYF9Y- > > dGA&s=AxutEEpLbkYM3N6zi_WxFvEBE1k6QU16ZzYIPnzTBXA&e= > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 15 09:40:36 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F4E1A9084 for ; Mon, 15 Feb 2016 09:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fz_JQaiBZo0h for ; Mon, 15 Feb 2016 09:40:22 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C8D1A9089 for ; Mon, 15 Feb 2016 09:40:21 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id b205so77121358wmb.1 for ; Mon, 15 Feb 2016 09:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viavisolutions-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fwng6wPR1ErCrxssuNjabPl9e8JeGjIwX10LHAE3vJw=; b=C+9h7OQ5ODMxCNmfZ/HGgsBgAuhb81m9pQ9PP5Ko6VAyuFb5XqOsYvmwm5lKSgyYRe QkO8fEo6UBygK+W5C95Gcq0PimAFppJrJEQFCK/V6+S2+yFXLZRWEMc86w43S6oAemi+ fU3YrUsCc4IviV0r3EUwB7rwQpROvIqhgzXso0BQ9pqWjDsIvgGYpuqv2REgwzZnavMQ yxSnW6fCMGAzyjJtyj5VWLGePVSBI4pLCGqNmiJY22fevZwSkJPdEcJZyN/Z43ASCsyc 7oPYiGDHiSTbN0pbaFi+KLOYiagqh1oYQvRZ9AemAXaQWWsOyX+NVQAEs8H9GrVELYPx 7LfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Fwng6wPR1ErCrxssuNjabPl9e8JeGjIwX10LHAE3vJw=; b=MngfultsickLxg0NaXRyii4a5DgxJUmwPSKf56EhaCi5QqHDmmyFww2ry066TKLwfN yKrAqSuhNZ9ZNDwh+uiEbEvQK+hvvkf6qiNZj/CJxSxmVVbuMaxkd/+6VK3lYFMG3WhU ggRsWh1Cg1ufoKhuTw5FT2TLl3be+d0YEfNyhJTaTxyPDWnGgyQUe8GUUbjpehS0/r1C mpKFFQPFKrVh0sv9UwBKBxxIsvgWF0ZeglId/RCAv5RY9uuWfmxhS0i9mp4jQur1/RvH 7+Y4BE4CmQX6pwiOHIZcdIyexNl0NiQlp//UyMsqjSN0QgG9zj5QwKp0PrnDmkMNk7mm 3r3A== X-Gm-Message-State: AG10YOSx/ZG8klJfnLbvXok5GmNJ/hnIUf/LnHLQcgf2Ndz9GxXkb5NF1MdPMszrGbHIAiReACEA3ndeo95WNvTe MIME-Version: 1.0 X-Received: by 10.194.250.103 with SMTP id zb7mr19077107wjc.65.1455558020159; Mon, 15 Feb 2016 09:40:20 -0800 (PST) Received: by 10.28.165.147 with HTTP; Mon, 15 Feb 2016 09:40:20 -0800 (PST) In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A5CE3C2@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A5CE3C2@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Mon, 15 Feb 2016 12:40:20 -0500 Message-ID: From: Ron Stana To: "Carey, Timothy (Nokia - US)" Content-Type: multipart/alternative; boundary=001a11c26ccabe06f6052bd28208 Archived-At: Cc: "alissa@cooperw.in" , "lmap@ietf.org" Subject: Re: [lmap] Support for multiple report table formats from one task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 17:40:24 -0000 --001a11c26ccabe06f6052bd28208 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tim, While multiple registry entries could be used to define each of the report types (table formats), this would require those registry entries to replicate the inputs ('fixed parameters' in registry terms) and any outputs that are common across the different types. It would be better to have one registry entry that defined the inputs to the task once, all possible outputs once and then allowed the outputs to be grouped into different report types. The report type is just some string value. When the tables were sent from the MA to the Collector they would then just need to include the report type. Example: 1) Task measures bandwidth for one or more streams 2) One registry entry is defined for the task. It includes: a) the numerous inputs that define the stream's packet format b) an output definition for the 'last one second bandwidth' c) an output definition for the 'average bandwidth since task start' 3) The 'last one second bandwidth' is only useful while the task is running so it is assigned to the report type 'running'. The description of the output 4) The 'average bandwidth since task start' is useful while the task is running and as a final value when the task completes so it is assigned to the report types 'running' and 'final'. 5) When the reports are sent from the MA, they indicate the report type. This is where I suggested the 'tag' object in the report could be used. In the end I am asking about these three issues: 1) How does a task properly define multiple report types (tables)? 2) How does the MA identify the report type being sent? Even if #1 is addressed using multiple registry entries, and #2 is addressed by including a reference to the registry entry in the 'metric/uri' object of the task within the report, there is still this issue: 3) How does the MA send multiple report types at the same time? My understanding of the current report definition is that it limits each task to having one table definition per POST. The MA could send each table definition to the collector separately but allowing each task to send an array of table definitions would be more efficient. You brought up a fourth issue which is how the data in each table is mapped to the registry. I have been making the assumption this was going to be accomplished by setting the column header value in the report to one of the summary/name values defined in the registry for the metric. Ron On Sun, Feb 14, 2016 at 11:11 AM, Carey, Timothy (Nokia - US) < timothy.carey@nokia.com> wrote: > Ron, > > > > The task has multiple registry entries =E2=80=93 I would assume your exam= ple is > that this task > > would have 3 registry entries. > > > > The columns are for the task and would have to have a union of all the > metrics for registry entries. =E2=80=93 Is this what you were asking? > > > > It seems that we lose the context of the registry entry to column though= =E2=80=A6 > > > > BR, > > Tim > > > > *From:* Ron Stana [mailto:ron.stana@viavisolutions.com] > *Sent:* Friday, February 12, 2016 4:31 PM > *To:* lmap@ietf.org > *Cc:* alissa@cooperw.in > *Subject:* [lmap] Support for multiple report table formats from one task > > > > LMAP Team, > > > > My understanding of the LMAP proposal is ietf-lmap-report:report/task/nam= e > is supposed to contain one of the values defined in > ietf-lmap-control:lmap/tasks/task/name. > > > > If this is correct, and since each task instance within a report can only > contain one table definition (one header + its row data) then how does a > task send multiple tables of results that contain different table formats= ? > > > > Use Cases: > > 1) Y.1564 task has results for the Service Configuration and the Service > Performance data, and each table has a different set of columns. > > 2) An RFC-2544 task would need a different table for the Throughput, > Latency, Frame Loss and Back to Back result sets. > > 3) Any task may want to send a minimal result set while it is executing > that is very different from the final result set when it has completed. > > > > The ietf-lmap-report:report/task/tag could be used to differentiate the > result sets sent by the same task. However this is not very efficient sin= ce > this approach requires the MA to send each report to the collector > separately because each report can only contain one set of results per ta= sk > name. > > > > Any guidance or clarification on the LMAP proposal would be appreciated, > > > > Ron > > > > > > > > > > > --001a11c26ccabe06f6052bd28208 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tim,

While multiple registry entries co= uld be used to define each of the report types (table formats), this would = require those registry entries to replicate the inputs ('fixed paramete= rs' in registry terms) and any outputs that are common across the diffe= rent types.=C2=A0 It would be better to have one registry entry that define= d the inputs to the task once, all possible outputs once and then allowed t= he outputs to be grouped into different report types. The report type is ju= st some string value. When the tables were sent from the MA to the Collecto= r they would then just need to include the report type. =C2=A0
Example:
1) Task measures bandwidth for one or more = streams
2) One registry entry is defined for the task. It include= s:
=C2=A0 =C2=A0 a) the numerous inputs that define the strea= m's packet format
=C2=A0 =C2=A0 b) an output definition for t= he 'last one second bandwidth'
=C2=A0 =C2=A0 c) an output= definition for the 'average bandwidth since task start'
= 3) The 'last one second bandwidth' is only useful while the task is= running so it is assigned to the report type 'running'.=C2=A0 The = description of the output=C2=A0
4) The 'average bandwidth sin= ce task start' is useful while the task is running and as a final value= when the task completes so it is assigned to the report types 'running= ' and 'final'.
5) When the reports are sent from the = MA, they indicate the report type. This is where I suggested the 'tag&#= 39; object in the report could be used.

In the end= I am asking about these three issues:
1) How does a task properl= y define multiple report types (tables)?
2) How does the MA ident= ify the report type being sent?
Even if #1 is addressed using mul= tiple registry entries, and #2 is addressed by including a reference to the= registry entry in the 'metric/uri' object of the task within the r= eport, there is still this issue:
3) How does the MA send multipl= e report types at the same time? My understanding of the current report def= inition is that it limits each task to having one table definition per POST= .=C2=A0 The MA could send each table definition to the collector separately= but allowing each task to send an array of table definitions would be more= efficient.

You brought up a fourth issue which is= how the data in each table is mapped to the registry.=C2=A0 I have been ma= king the assumption this was going to be accomplished by setting the column= header value in the report to one of the summary/name values defined in th= e registry for the metric.

Ron

On Sun, Feb 14, 2016 at 1= 1:11 AM, Carey, Timothy (Nokia - US) <timothy.carey@nokia.com>= ; wrote:

Ron,

=C2=A0=

The task has multipl= e registry entries =E2=80=93 I would assume your example is that this task<= u>

would have 3 registr= y entries.

=C2=A0=

The columns are for = the task and would have to have a union of all the metrics for registry ent= ries. =E2=80=93 Is this what you were asking?

=C2=A0=

It seems that we los= e the context of the registry entry to column though=E2=80=A6=

=C2=A0=

BR,

Tim

=C2=A0=

From: Ron Stan= a [mailto:ron.stana@viavisolutions.com]
Sent: Friday, February 12, 2016 4:31 PM
To: lmap@ietf.org=
Cc: alissa@co= operw.in
Subject: [lmap] Support for multiple report table formats from one t= ask

=C2=A0

LMAP Team,

=C2=A0

My understanding of the LMAP proposal is ietf-lmap-r= eport:report/task/name is supposed to contain one of the values defined in = ietf-lmap-control:lmap/tasks/task/name.

=C2=A0

If this is correct, and since each task instance wit= hin a report can only contain one table definition (one header + its row da= ta) then how does a task send multiple tables of results that contain diffe= rent table formats?

=C2=A0

Use Cases:

1) Y.1564 task has results for the Service Configura= tion and the Service Performance data, and each table has a different set o= f columns.

2) An RFC-2544 task would need a different table for= the Throughput, Latency, Frame Loss and Back to Back result sets.

3) Any task may want to send a minimal result set wh= ile it is executing that is very different from the final result set when i= t has completed.

=C2=A0

The ietf-lmap-report:report/task/tag could be used t= o differentiate the result sets sent by the same task. However this is not = very efficient since this approach requires the MA to send each report to t= he collector separately because each report can only contain one set of results per task name.

=C2=A0

Any guidance or clarification on the LMAP proposal w= ould be appreciated,

=C2=A0

Ron

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--001a11c26ccabe06f6052bd28208-- From nobody Mon Feb 15 14:31:18 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACE81A00ED for ; Mon, 15 Feb 2016 14:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAo5IgDnufKL for ; Mon, 15 Feb 2016 14:31:11 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F5B1A00DB for ; Mon, 15 Feb 2016 14:31:11 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id EED434DD1BF1; Mon, 15 Feb 2016 22:31:07 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u1FMV94u022882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Feb 2016 22:31:10 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u1FMV8Ab001925 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Feb 2016 22:31:09 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.121]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Mon, 15 Feb 2016 17:31:08 -0500 From: "Carey, Timothy (Nokia - US)" To: Ron Stana Thread-Topic: [lmap] Support for multiple report table formats from one task Thread-Index: AQHRZpkvpmDKnEpIoUqJmeiE7E+MV58rttDwgAH/sACAAFE+8A== Date: Mon, 15 Feb 2016 22:31:08 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A5D0D00@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A5CE3C2@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A5D0D00US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Cc: "alissa@cooperw.in" , "lmap@ietf.org" Subject: Re: [lmap] Support for multiple report table formats from one task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 22:31:17 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A5D0D00US70UWXCHMBA0_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9uLA0KDQpJIHdvdWxkIHRhbGsgdG8gdGhlIElQUE0gdGVhbSB0aGVuIOKAkyBpdHMgcmVhbGx5 IGhvdyB0aGV5IGRlZmluZSB0aGUgbWV0cmljcyB0aGF0IG1ha2UgdXAgdGhlIHJlZ2lzdHJ5Lg0K DQpBcyBmb3IgYSByZXBvcnQgcGVyIHRhc2sgY29uc3RyYWludCDigJMgSSBkb27igJl0IGtub3cg aWYgc2F2aW5nIGlucHV0cyBhbmQgb3V0cHV0cyBhcyB5b3Ugc3VnZ2VzdCB3YXJyYW50IGJyZWFr aW5nIHRoYXQgY29uc3RyYWludCDigJMgd2h5IG5vdCBqdXN0IGhhdmUgMiB0YXNrcyBhbmQgZHVw bGljYXRlIHRoZSByZWdpc3RyeSBlbnRyeS4NCg0KSSBsaWtlIHRoZSB3aGVuIHRoZSB0YXNrIGlz IGNvbXBsZXRlIOKAkyBnZW5lcmF0ZSB0aGUgcmVzdWx0cyBmb3IgcmVwb3J0aW5nIGFuZCB0aGVu IHJlcG9ydCByZXN1bHRzIGJhc2VkIG9uIHRoZSBzY2hlZHVsZSB0byB0aGUgY29sbGVjdG9yLiBJ IGtub3cgaW4gb3VyIEJCRiBpbXBsZW1lbnRhdGlvbiB0aGlzIHdvcmtzIHF1aXRlIHdlbGwuDQoN Ck90aGVyd2lzZSB5b3UgZ2V0IGludG8gdGhlIG5hc3R5IHByb2JsZW0gb2YgYSBzdGF0ZSBtYWNo aW5lIHRoYXQgY29ycmVsYXRlcyBydW5uaW5nIHRoZSB0ZXN0cyB3aXRoIHJlcG9ydGluZyByZXN1 bHRzIGluIHRoZSBjb250ZXh0IG9mIHRoZSBvdmVyYXJjaGluZyBzY2hlZHVsZWQgdGFzayAoWW91 IGNhbGwgaXQgcnVubmluZyBhbmQgZmluYWwgYnV0IHRoZXJlIGlzIGEgY29udGV4dCB0byB0aG9z ZSBzdGF0ZXMgZm9yIHRoYXQgcGFydGljdWxhciB0YXNrKS4NCg0KQlIsDQpUaW0NCg0KDQpGcm9t OiBSb24gU3RhbmEgW21haWx0bzpyb24uc3RhbmFAdmlhdmlzb2x1dGlvbnMuY29tXQ0KU2VudDog TW9uZGF5LCBGZWJydWFyeSAxNSwgMjAxNiA1OjQwIFBNDQpUbzogQ2FyZXksIFRpbW90aHkgKE5v a2lhIC0gVVMpDQpDYzogYWxpc3NhQGNvb3BlcncuaW47IGxtYXBAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbbG1hcF0gU3VwcG9ydCBmb3IgbXVsdGlwbGUgcmVwb3J0IHRhYmxlIGZvcm1hdHMgZnJv bSBvbmUgdGFzaw0KDQpUaW0sDQoNCldoaWxlIG11bHRpcGxlIHJlZ2lzdHJ5IGVudHJpZXMgY291 bGQgYmUgdXNlZCB0byBkZWZpbmUgZWFjaCBvZiB0aGUgcmVwb3J0IHR5cGVzICh0YWJsZSBmb3Jt YXRzKSwgdGhpcyB3b3VsZCByZXF1aXJlIHRob3NlIHJlZ2lzdHJ5IGVudHJpZXMgdG8gcmVwbGlj YXRlIHRoZSBpbnB1dHMgKCdmaXhlZCBwYXJhbWV0ZXJzJyBpbiByZWdpc3RyeSB0ZXJtcykgYW5k IGFueSBvdXRwdXRzIHRoYXQgYXJlIGNvbW1vbiBhY3Jvc3MgdGhlIGRpZmZlcmVudCB0eXBlcy4g IEl0IHdvdWxkIGJlIGJldHRlciB0byBoYXZlIG9uZSByZWdpc3RyeSBlbnRyeSB0aGF0IGRlZmlu ZWQgdGhlIGlucHV0cyB0byB0aGUgdGFzayBvbmNlLCBhbGwgcG9zc2libGUgb3V0cHV0cyBvbmNl IGFuZCB0aGVuIGFsbG93ZWQgdGhlIG91dHB1dHMgdG8gYmUgZ3JvdXBlZCBpbnRvIGRpZmZlcmVu dCByZXBvcnQgdHlwZXMuIFRoZSByZXBvcnQgdHlwZSBpcyBqdXN0IHNvbWUgc3RyaW5nIHZhbHVl LiBXaGVuIHRoZSB0YWJsZXMgd2VyZSBzZW50IGZyb20gdGhlIE1BIHRvIHRoZSBDb2xsZWN0b3Ig dGhleSB3b3VsZCB0aGVuIGp1c3QgbmVlZCB0byBpbmNsdWRlIHRoZSByZXBvcnQgdHlwZS4NCg0K RXhhbXBsZToNCjEpIFRhc2sgbWVhc3VyZXMgYmFuZHdpZHRoIGZvciBvbmUgb3IgbW9yZSBzdHJl YW1zDQoyKSBPbmUgcmVnaXN0cnkgZW50cnkgaXMgZGVmaW5lZCBmb3IgdGhlIHRhc2suIEl0IGlu Y2x1ZGVzOg0KICAgIGEpIHRoZSBudW1lcm91cyBpbnB1dHMgdGhhdCBkZWZpbmUgdGhlIHN0cmVh bSdzIHBhY2tldCBmb3JtYXQNCiAgICBiKSBhbiBvdXRwdXQgZGVmaW5pdGlvbiBmb3IgdGhlICds YXN0IG9uZSBzZWNvbmQgYmFuZHdpZHRoJw0KICAgIGMpIGFuIG91dHB1dCBkZWZpbml0aW9uIGZv ciB0aGUgJ2F2ZXJhZ2UgYmFuZHdpZHRoIHNpbmNlIHRhc2sgc3RhcnQnDQozKSBUaGUgJ2xhc3Qg b25lIHNlY29uZCBiYW5kd2lkdGgnIGlzIG9ubHkgdXNlZnVsIHdoaWxlIHRoZSB0YXNrIGlzIHJ1 bm5pbmcgc28gaXQgaXMgYXNzaWduZWQgdG8gdGhlIHJlcG9ydCB0eXBlICdydW5uaW5nJy4gIFRo ZSBkZXNjcmlwdGlvbiBvZiB0aGUgb3V0cHV0DQo0KSBUaGUgJ2F2ZXJhZ2UgYmFuZHdpZHRoIHNp bmNlIHRhc2sgc3RhcnQnIGlzIHVzZWZ1bCB3aGlsZSB0aGUgdGFzayBpcyBydW5uaW5nIGFuZCBh cyBhIGZpbmFsIHZhbHVlIHdoZW4gdGhlIHRhc2sgY29tcGxldGVzIHNvIGl0IGlzIGFzc2lnbmVk IHRvIHRoZSByZXBvcnQgdHlwZXMgJ3J1bm5pbmcnIGFuZCAnZmluYWwnLg0KNSkgV2hlbiB0aGUg cmVwb3J0cyBhcmUgc2VudCBmcm9tIHRoZSBNQSwgdGhleSBpbmRpY2F0ZSB0aGUgcmVwb3J0IHR5 cGUuIFRoaXMgaXMgd2hlcmUgSSBzdWdnZXN0ZWQgdGhlICd0YWcnIG9iamVjdCBpbiB0aGUgcmVw b3J0IGNvdWxkIGJlIHVzZWQuDQoNCkluIHRoZSBlbmQgSSBhbSBhc2tpbmcgYWJvdXQgdGhlc2Ug dGhyZWUgaXNzdWVzOg0KMSkgSG93IGRvZXMgYSB0YXNrIHByb3Blcmx5IGRlZmluZSBtdWx0aXBs ZSByZXBvcnQgdHlwZXMgKHRhYmxlcyk/DQoyKSBIb3cgZG9lcyB0aGUgTUEgaWRlbnRpZnkgdGhl IHJlcG9ydCB0eXBlIGJlaW5nIHNlbnQ/DQpFdmVuIGlmICMxIGlzIGFkZHJlc3NlZCB1c2luZyBt dWx0aXBsZSByZWdpc3RyeSBlbnRyaWVzLCBhbmQgIzIgaXMgYWRkcmVzc2VkIGJ5IGluY2x1ZGlu ZyBhIHJlZmVyZW5jZSB0byB0aGUgcmVnaXN0cnkgZW50cnkgaW4gdGhlICdtZXRyaWMvdXJpJyBv YmplY3Qgb2YgdGhlIHRhc2sgd2l0aGluIHRoZSByZXBvcnQsIHRoZXJlIGlzIHN0aWxsIHRoaXMg aXNzdWU6DQozKSBIb3cgZG9lcyB0aGUgTUEgc2VuZCBtdWx0aXBsZSByZXBvcnQgdHlwZXMgYXQg dGhlIHNhbWUgdGltZT8gTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgY3VycmVudCByZXBvcnQgZGVm aW5pdGlvbiBpcyB0aGF0IGl0IGxpbWl0cyBlYWNoIHRhc2sgdG8gaGF2aW5nIG9uZSB0YWJsZSBk ZWZpbml0aW9uIHBlciBQT1NULiAgVGhlIE1BIGNvdWxkIHNlbmQgZWFjaCB0YWJsZSBkZWZpbml0 aW9uIHRvIHRoZSBjb2xsZWN0b3Igc2VwYXJhdGVseSBidXQgYWxsb3dpbmcgZWFjaCB0YXNrIHRv IHNlbmQgYW4gYXJyYXkgb2YgdGFibGUgZGVmaW5pdGlvbnMgd291bGQgYmUgbW9yZSBlZmZpY2ll bnQuDQoNCllvdSBicm91Z2h0IHVwIGEgZm91cnRoIGlzc3VlIHdoaWNoIGlzIGhvdyB0aGUgZGF0 YSBpbiBlYWNoIHRhYmxlIGlzIG1hcHBlZCB0byB0aGUgcmVnaXN0cnkuICBJIGhhdmUgYmVlbiBt YWtpbmcgdGhlIGFzc3VtcHRpb24gdGhpcyB3YXMgZ29pbmcgdG8gYmUgYWNjb21wbGlzaGVkIGJ5 IHNldHRpbmcgdGhlIGNvbHVtbiBoZWFkZXIgdmFsdWUgaW4gdGhlIHJlcG9ydCB0byBvbmUgb2Yg dGhlIHN1bW1hcnkvbmFtZSB2YWx1ZXMgZGVmaW5lZCBpbiB0aGUgcmVnaXN0cnkgZm9yIHRoZSBt ZXRyaWMuDQoNClJvbg0KDQpPbiBTdW4sIEZlYiAxNCwgMjAxNiBhdCAxMToxMSBBTSwgQ2FyZXks IFRpbW90aHkgKE5va2lhIC0gVVMpIDx0aW1vdGh5LmNhcmV5QG5va2lhLmNvbTxtYWlsdG86dGlt b3RoeS5jYXJleUBub2tpYS5jb20+PiB3cm90ZToNClJvbiwNCg0KVGhlIHRhc2sgaGFzIG11bHRp cGxlIHJlZ2lzdHJ5IGVudHJpZXMg4oCTIEkgd291bGQgYXNzdW1lIHlvdXIgZXhhbXBsZSBpcyB0 aGF0IHRoaXMgdGFzaw0Kd291bGQgaGF2ZSAzIHJlZ2lzdHJ5IGVudHJpZXMuDQoNClRoZSBjb2x1 bW5zIGFyZSBmb3IgdGhlIHRhc2sgYW5kIHdvdWxkIGhhdmUgdG8gaGF2ZSBhIHVuaW9uIG9mIGFs bCB0aGUgbWV0cmljcyBmb3IgcmVnaXN0cnkgZW50cmllcy4g4oCTIElzIHRoaXMgd2hhdCB5b3Ug d2VyZSBhc2tpbmc/DQoNCkl0IHNlZW1zIHRoYXQgd2UgbG9zZSB0aGUgY29udGV4dCBvZiB0aGUg cmVnaXN0cnkgZW50cnkgdG8gY29sdW1uIHRob3VnaOKApg0KDQpCUiwNClRpbQ0KDQpGcm9tOiBS b24gU3RhbmEgW21haWx0bzpyb24uc3RhbmFAdmlhdmlzb2x1dGlvbnMuY29tPG1haWx0bzpyb24u c3RhbmFAdmlhdmlzb2x1dGlvbnMuY29tPl0NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTIsIDIw MTYgNDozMSBQTQ0KVG86IGxtYXBAaWV0Zi5vcmc8bWFpbHRvOmxtYXBAaWV0Zi5vcmc+DQpDYzog YWxpc3NhQGNvb3BlcncuaW48bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluPg0KU3ViamVjdDogW2xt YXBdIFN1cHBvcnQgZm9yIG11bHRpcGxlIHJlcG9ydCB0YWJsZSBmb3JtYXRzIGZyb20gb25lIHRh c2sNCg0KTE1BUCBUZWFtLA0KDQpNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBMTUFQIHByb3Bvc2Fs IGlzIGlldGYtbG1hcC1yZXBvcnQ6cmVwb3J0L3Rhc2svbmFtZSBpcyBzdXBwb3NlZCB0byBjb250 YWluIG9uZSBvZiB0aGUgdmFsdWVzIGRlZmluZWQgaW4gaWV0Zi1sbWFwLWNvbnRyb2w6bG1hcC90 YXNrcy90YXNrL25hbWUuDQoNCklmIHRoaXMgaXMgY29ycmVjdCwgYW5kIHNpbmNlIGVhY2ggdGFz ayBpbnN0YW5jZSB3aXRoaW4gYSByZXBvcnQgY2FuIG9ubHkgY29udGFpbiBvbmUgdGFibGUgZGVm aW5pdGlvbiAob25lIGhlYWRlciArIGl0cyByb3cgZGF0YSkgdGhlbiBob3cgZG9lcyBhIHRhc2sg c2VuZCBtdWx0aXBsZSB0YWJsZXMgb2YgcmVzdWx0cyB0aGF0IGNvbnRhaW4gZGlmZmVyZW50IHRh YmxlIGZvcm1hdHM/DQoNClVzZSBDYXNlczoNCjEpIFkuMTU2NCB0YXNrIGhhcyByZXN1bHRzIGZv ciB0aGUgU2VydmljZSBDb25maWd1cmF0aW9uIGFuZCB0aGUgU2VydmljZSBQZXJmb3JtYW5jZSBk YXRhLCBhbmQgZWFjaCB0YWJsZSBoYXMgYSBkaWZmZXJlbnQgc2V0IG9mIGNvbHVtbnMuDQoyKSBB biBSRkMtMjU0NCB0YXNrIHdvdWxkIG5lZWQgYSBkaWZmZXJlbnQgdGFibGUgZm9yIHRoZSBUaHJv dWdocHV0LCBMYXRlbmN5LCBGcmFtZSBMb3NzIGFuZCBCYWNrIHRvIEJhY2sgcmVzdWx0IHNldHMu DQozKSBBbnkgdGFzayBtYXkgd2FudCB0byBzZW5kIGEgbWluaW1hbCByZXN1bHQgc2V0IHdoaWxl IGl0IGlzIGV4ZWN1dGluZyB0aGF0IGlzIHZlcnkgZGlmZmVyZW50IGZyb20gdGhlIGZpbmFsIHJl c3VsdCBzZXQgd2hlbiBpdCBoYXMgY29tcGxldGVkLg0KDQpUaGUgaWV0Zi1sbWFwLXJlcG9ydDpy ZXBvcnQvdGFzay90YWcgY291bGQgYmUgdXNlZCB0byBkaWZmZXJlbnRpYXRlIHRoZSByZXN1bHQg c2V0cyBzZW50IGJ5IHRoZSBzYW1lIHRhc2suIEhvd2V2ZXIgdGhpcyBpcyBub3QgdmVyeSBlZmZp Y2llbnQgc2luY2UgdGhpcyBhcHByb2FjaCByZXF1aXJlcyB0aGUgTUEgdG8gc2VuZCBlYWNoIHJl cG9ydCB0byB0aGUgY29sbGVjdG9yIHNlcGFyYXRlbHkgYmVjYXVzZSBlYWNoIHJlcG9ydCBjYW4g b25seSBjb250YWluIG9uZSBzZXQgb2YgcmVzdWx0cyBwZXIgdGFzayBuYW1lLg0KDQpBbnkgZ3Vp ZGFuY2Ugb3IgY2xhcmlmaWNhdGlvbiBvbiB0aGUgTE1BUCBwcm9wb3NhbCB3b3VsZCBiZSBhcHBy ZWNpYXRlZCwNCg0KUm9uDQoNCg0KDQoNCg0KDQo= --_000_9966516C6EB5FC4381E05BF80AA55F77012A5D0D00US70UWXCHMBA0_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1T IjsNCglwYW5vc2UtMToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiVHJlYnVjaGV0IE1T Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlJvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtU cmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxkIHRhbGsgdG8g dGhlIElQUE0gdGVhbSB0aGVuIOKAkyBpdHMgcmVhbGx5IGhvdyB0aGV5IGRlZmluZSB0aGUgbWV0 cmljcyB0aGF0IG1ha2UgdXAgdGhlIHJlZ2lzdHJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1 Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIGZv ciBhIHJlcG9ydCBwZXIgdGFzayBjb25zdHJhaW50IOKAkyBJIGRvbuKAmXQga25vdyBpZiBzYXZp bmcgaW5wdXRzIGFuZCBvdXRwdXRzIGFzIHlvdSBzdWdnZXN0IHdhcnJhbnQgYnJlYWtpbmcgdGhh dCBjb25zdHJhaW50IOKAkyB3aHkgbm90IGp1c3QgaGF2ZSAyIHRhc2tzDQogYW5kIGR1cGxpY2F0 ZSB0aGUgcmVnaXN0cnkgZW50cnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBsaWtlIHRoZSB3aGVu IHRoZSB0YXNrIGlzIGNvbXBsZXRlIOKAkyBnZW5lcmF0ZSB0aGUgcmVzdWx0cyBmb3IgcmVwb3J0 aW5nIGFuZCB0aGVuIHJlcG9ydCByZXN1bHRzIGJhc2VkIG9uIHRoZSBzY2hlZHVsZSB0byB0aGUg Y29sbGVjdG9yLiBJIGtub3cgaW4gb3VyDQogQkJGIGltcGxlbWVudGF0aW9uIHRoaXMgd29ya3Mg cXVpdGUgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQg TVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PdGhlcndpc2UgeW91IGdldCBpbnRvIHRo ZSBuYXN0eSBwcm9ibGVtIG9mIGEgc3RhdGUgbWFjaGluZSB0aGF0IGNvcnJlbGF0ZXMgcnVubmlu ZyB0aGUgdGVzdHMgd2l0aCByZXBvcnRpbmcgcmVzdWx0cyBpbiB0aGUgY29udGV4dCBvZiB0aGUg b3ZlcmFyY2hpbmcNCiBzY2hlZHVsZWQgdGFzayAoWW91IGNhbGwgaXQgcnVubmluZyBhbmQgZmlu YWwgYnV0IHRoZXJlIGlzIGEgY29udGV4dCB0byB0aG9zZSBzdGF0ZXMgZm9yIHRoYXQgcGFydGlj dWxhciB0YXNrKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQg TVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVi dWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUm9uIFN0YW5hIFttYWlsdG86cm9uLnN0YW5hQHZpYXZpc29s dXRpb25zLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDE1LCAyMDE2 IDU6NDAgUE08YnI+DQo8Yj5Ubzo8L2I+IENhcmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKTxicj4N CjxiPkNjOjwvYj4gYWxpc3NhQGNvb3BlcncuaW47IGxtYXBAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtsbWFwXSBTdXBwb3J0IGZvciBtdWx0aXBsZSByZXBvcnQgdGFibGUgZm9y bWF0cyBmcm9tIG9uZSB0YXNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaW0sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XaGlsZSBtdWx0aXBsZSByZWdpc3RyeSBlbnRyaWVzIGNvdWxkIGJlIHVzZWQgdG8gZGVmaW5l IGVhY2ggb2YgdGhlIHJlcG9ydCB0eXBlcyAodGFibGUgZm9ybWF0cyksIHRoaXMgd291bGQgcmVx dWlyZSB0aG9zZSByZWdpc3RyeSBlbnRyaWVzIHRvIHJlcGxpY2F0ZSB0aGUgaW5wdXRzICgnZml4 ZWQgcGFyYW1ldGVycycgaW4gcmVnaXN0cnkgdGVybXMpIGFuZCBhbnkgb3V0cHV0cyB0aGF0IGFy ZSBjb21tb24gYWNyb3NzDQogdGhlIGRpZmZlcmVudCB0eXBlcy4mbmJzcDsgSXQgd291bGQgYmUg YmV0dGVyIHRvIGhhdmUgb25lIHJlZ2lzdHJ5IGVudHJ5IHRoYXQgZGVmaW5lZCB0aGUgaW5wdXRz IHRvIHRoZSB0YXNrIG9uY2UsIGFsbCBwb3NzaWJsZSBvdXRwdXRzIG9uY2UgYW5kIHRoZW4gYWxs b3dlZCB0aGUgb3V0cHV0cyB0byBiZSBncm91cGVkIGludG8gZGlmZmVyZW50IHJlcG9ydCB0eXBl cy4gVGhlIHJlcG9ydCB0eXBlIGlzIGp1c3Qgc29tZSBzdHJpbmcgdmFsdWUuIFdoZW4NCiB0aGUg dGFibGVzIHdlcmUgc2VudCBmcm9tIHRoZSBNQSB0byB0aGUgQ29sbGVjdG9yIHRoZXkgd291bGQg dGhlbiBqdXN0IG5lZWQgdG8gaW5jbHVkZSB0aGUgcmVwb3J0IHR5cGUuICZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FeGFtcGxlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgVGFz ayBtZWFzdXJlcyBiYW5kd2lkdGggZm9yIG9uZSBvciBtb3JlIHN0cmVhbXM8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIpIE9uZSByZWdpc3RyeSBl bnRyeSBpcyBkZWZpbmVkIGZvciB0aGUgdGFzay4gSXQgaW5jbHVkZXM6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IGEpIHRo ZSBudW1lcm91cyBpbnB1dHMgdGhhdCBkZWZpbmUgdGhlIHN0cmVhbSdzIHBhY2tldCBmb3JtYXQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDsgYikgYW4gb3V0cHV0IGRlZmluaXRpb24gZm9yIHRoZSAnbGFzdCBvbmUgc2Vjb25k IGJhbmR3aWR0aCc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgYykgYW4gb3V0cHV0IGRlZmluaXRpb24gZm9yIHRoZSAnYXZl cmFnZSBiYW5kd2lkdGggc2luY2UgdGFzayBzdGFydCc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMpIFRoZSAnbGFzdCBvbmUgc2Vjb25kIGJhbmR3 aWR0aCcgaXMgb25seSB1c2VmdWwgd2hpbGUgdGhlIHRhc2sgaXMgcnVubmluZyBzbyBpdCBpcyBh c3NpZ25lZCB0byB0aGUgcmVwb3J0IHR5cGUgJ3J1bm5pbmcnLiZuYnNwOyBUaGUgZGVzY3JpcHRp b24gb2YgdGhlIG91dHB1dCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+NCkgVGhlICdhdmVyYWdlIGJhbmR3aWR0aCBzaW5jZSB0YXNrIHN0 YXJ0JyBpcyB1c2VmdWwgd2hpbGUgdGhlIHRhc2sgaXMgcnVubmluZyBhbmQgYXMgYSBmaW5hbCB2 YWx1ZSB3aGVuIHRoZSB0YXNrIGNvbXBsZXRlcyBzbyBpdCBpcyBhc3NpZ25lZCB0byB0aGUgcmVw b3J0IHR5cGVzICdydW5uaW5nJyBhbmQgJ2ZpbmFsJy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUpIFdoZW4gdGhlIHJlcG9ydHMgYXJlIHNlbnQg ZnJvbSB0aGUgTUEsIHRoZXkgaW5kaWNhdGUgdGhlIHJlcG9ydCB0eXBlLiBUaGlzIGlzIHdoZXJl IEkgc3VnZ2VzdGVkIHRoZSAndGFnJyBvYmplY3QgaW4gdGhlIHJlcG9ydCBjb3VsZCBiZSB1c2Vk LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J biB0aGUgZW5kIEkgYW0gYXNraW5nIGFib3V0IHRoZXNlIHRocmVlIGlzc3Vlczo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIEhvdyBkb2VzIGEg dGFzayBwcm9wZXJseSBkZWZpbmUgbXVsdGlwbGUgcmVwb3J0IHR5cGVzICh0YWJsZXMpPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgSG93IGRv ZXMgdGhlIE1BIGlkZW50aWZ5IHRoZSByZXBvcnQgdHlwZSBiZWluZyBzZW50PzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXZlbiBpZiAjMSBpcyBh ZGRyZXNzZWQgdXNpbmcgbXVsdGlwbGUgcmVnaXN0cnkgZW50cmllcywgYW5kICMyIGlzIGFkZHJl c3NlZCBieSBpbmNsdWRpbmcgYSByZWZlcmVuY2UgdG8gdGhlIHJlZ2lzdHJ5IGVudHJ5IGluIHRo ZSAnbWV0cmljL3VyaScgb2JqZWN0IG9mIHRoZSB0YXNrIHdpdGhpbiB0aGUgcmVwb3J0LCB0aGVy ZSBpcyBzdGlsbCB0aGlzIGlzc3VlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+MykgSG93IGRvZXMgdGhlIE1BIHNlbmQgbXVsdGlwbGUgcmVwb3J0 IHR5cGVzIGF0IHRoZSBzYW1lIHRpbWU/IE15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGN1cnJlbnQg cmVwb3J0IGRlZmluaXRpb24gaXMgdGhhdCBpdCBsaW1pdHMgZWFjaCB0YXNrIHRvIGhhdmluZyBv bmUgdGFibGUgZGVmaW5pdGlvbiBwZXIgUE9TVC4mbmJzcDsgVGhlIE1BIGNvdWxkIHNlbmQgZWFj aCB0YWJsZSBkZWZpbml0aW9uIHRvIHRoZSBjb2xsZWN0b3INCiBzZXBhcmF0ZWx5IGJ1dCBhbGxv d2luZyBlYWNoIHRhc2sgdG8gc2VuZCBhbiBhcnJheSBvZiB0YWJsZSBkZWZpbml0aW9ucyB3b3Vs ZCBiZSBtb3JlIGVmZmljaWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+WW91IGJyb3VnaHQgdXAgYSBmb3VydGggaXNzdWUgd2hpY2ggaXMg aG93IHRoZSBkYXRhIGluIGVhY2ggdGFibGUgaXMgbWFwcGVkIHRvIHRoZSByZWdpc3RyeS4mbmJz cDsgSSBoYXZlIGJlZW4gbWFraW5nIHRoZSBhc3N1bXB0aW9uIHRoaXMgd2FzIGdvaW5nIHRvIGJl IGFjY29tcGxpc2hlZCBieSBzZXR0aW5nIHRoZSBjb2x1bW4gaGVhZGVyIHZhbHVlIGluIHRoZSBy ZXBvcnQgdG8gb25lIG9mIHRoZSBzdW1tYXJ5L25hbWUNCiB2YWx1ZXMgZGVmaW5lZCBpbiB0aGUg cmVnaXN0cnkgZm9yIHRoZSBtZXRyaWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIEZlYiAxNCwgMjAxNiBhdCAxMToxMSBBTSwg Q2FyZXksIFRpbW90aHkgKE5va2lhIC0gVVMpICZsdDs8YSBocmVmPSJtYWlsdG86dGltb3RoeS5j YXJleUBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj50aW1vdGh5LmNhcmV5QG5va2lhLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlJvbiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHRhc2sgaGFzIG11bHRpcGxlIHJlZ2lz dHJ5IGVudHJpZXMg4oCTIEkgd291bGQgYXNzdW1lIHlvdXIgZXhhbXBsZSBpcyB0aGF0IHRoaXMg dGFzazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+d291bGQgaGF2ZSAzIHJl Z2lzdHJ5IGVudHJpZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVi dWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBjb2x1bW5zIGFyZSBm b3IgdGhlIHRhc2sgYW5kIHdvdWxkIGhhdmUgdG8gaGF2ZSBhIHVuaW9uIG9mIGFsbCB0aGUgbWV0 cmljcyBmb3IgcmVnaXN0cnkNCiBlbnRyaWVzLiDigJMgSXMgdGhpcyB3aGF0IHlvdSB3ZXJlIGFz a2luZz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgc2VlbXMgdGhhdCB3ZSBsb3NlIHRoZSBj b250ZXh0IG9mIHRoZSByZWdpc3RyeSBlbnRyeSB0byBjb2x1bW4gdGhvdWdo4oCmPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkJSLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGltPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSb24gU3RhbmEgW21haWx0bzo8YSBocmVmPSJtYWls dG86cm9uLnN0YW5hQHZpYXZpc29sdXRpb25zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbi5zdGFu YUB2aWF2aXNvbHV0aW9ucy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVi cnVhcnkgMTIsIDIwMTYgNDozMSBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmxt YXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sbWFwQGlldGYub3JnPC9hPjxicj4NCjxiPkNj OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluIiB0YXJnZXQ9Il9ibGFuayI+ YWxpc3NhQGNvb3BlcncuaW48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtsbWFwXSBTdXBwb3J0 IGZvciBtdWx0aXBsZSByZXBvcnQgdGFibGUgZm9ybWF0cyBmcm9tIG9uZSB0YXNrPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TE1BUCBUZWFtLDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk15IHVuZGVyc3Rh bmRpbmcgb2YgdGhlIExNQVAgcHJvcG9zYWwgaXMgaWV0Zi1sbWFwLXJlcG9ydDpyZXBvcnQvdGFz ay9uYW1lIGlzIHN1cHBvc2VkIHRvIGNvbnRhaW4gb25lIG9mIHRoZSB2YWx1ZXMgZGVmaW5lZCBp biBpZXRmLWxtYXAtY29udHJvbDpsbWFwL3Rhc2tzL3Rhc2svbmFtZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHRoaXMgaXMgY29y cmVjdCwgYW5kIHNpbmNlIGVhY2ggdGFzayBpbnN0YW5jZSB3aXRoaW4gYSByZXBvcnQgY2FuIG9u bHkgY29udGFpbiBvbmUgdGFibGUgZGVmaW5pdGlvbiAob25lIGhlYWRlciAmIzQzOyBpdHMgcm93 IGRhdGEpIHRoZW4gaG93IGRvZXMgYSB0YXNrIHNlbmQgbXVsdGlwbGUgdGFibGVzIG9mIHJlc3Vs dHMNCiB0aGF0IGNvbnRhaW4gZGlmZmVyZW50IHRhYmxlIGZvcm1hdHM/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Vc2UgQ2FzZXM6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEpIFku MTU2NCB0YXNrIGhhcyByZXN1bHRzIGZvciB0aGUgU2VydmljZSBDb25maWd1cmF0aW9uIGFuZCB0 aGUgU2VydmljZSBQZXJmb3JtYW5jZSBkYXRhLCBhbmQgZWFjaCB0YWJsZSBoYXMgYSBkaWZmZXJl bnQgc2V0IG9mIGNvbHVtbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjIpIEFuIFJGQy0yNTQ0IHRhc2sgd291bGQgbmVlZCBhIGRpZmZlcmVu dCB0YWJsZSBmb3IgdGhlIFRocm91Z2hwdXQsIExhdGVuY3ksIEZyYW1lIExvc3MgYW5kIEJhY2sg dG8gQmFjayByZXN1bHQgc2V0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+MykgQW55IHRhc2sgbWF5IHdhbnQgdG8gc2VuZCBhIG1pbmltYWwg cmVzdWx0IHNldCB3aGlsZSBpdCBpcyBleGVjdXRpbmcgdGhhdCBpcyB2ZXJ5IGRpZmZlcmVudCBm cm9tIHRoZSBmaW5hbCByZXN1bHQgc2V0IHdoZW4gaXQgaGFzIGNvbXBsZXRlZC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBpZXRm LWxtYXAtcmVwb3J0OnJlcG9ydC90YXNrL3RhZyBjb3VsZCBiZSB1c2VkIHRvIGRpZmZlcmVudGlh dGUgdGhlIHJlc3VsdCBzZXRzIHNlbnQgYnkgdGhlIHNhbWUgdGFzay4gSG93ZXZlciB0aGlzIGlz IG5vdCB2ZXJ5IGVmZmljaWVudCBzaW5jZSB0aGlzIGFwcHJvYWNoIHJlcXVpcmVzIHRoZSBNQQ0K IHRvIHNlbmQgZWFjaCByZXBvcnQgdG8gdGhlIGNvbGxlY3RvciBzZXBhcmF0ZWx5IGJlY2F1c2Ug ZWFjaCByZXBvcnQgY2FuIG9ubHkgY29udGFpbiBvbmUgc2V0IG9mIHJlc3VsdHMgcGVyIHRhc2sg bmFtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkFueSBndWlkYW5jZSBvciBjbGFyaWZpY2F0aW9uIG9uIHRoZSBMTUFQIHByb3Bvc2Fs IHdvdWxkIGJlIGFwcHJlY2lhdGVkLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Um9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_9966516C6EB5FC4381E05BF80AA55F77012A5D0D00US70UWXCHMBA0_-- From nobody Mon Feb 15 14:52:51 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A081A1BE4 for ; Mon, 15 Feb 2016 14:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIkUJFluNn14 for ; Mon, 15 Feb 2016 14:52:48 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id E1C6E1A1BE3 for ; Mon, 15 Feb 2016 14:52:47 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id F3DEBD8128; Mon, 15 Feb 2016 17:56:07 -0500 (EST) Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.99]) by mail-green.research.att.com (Postfix) with ESMTP id 34A91E0FBF; Mon, 15 Feb 2016 17:49:31 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by njmtcas1.research.att.com ([fe80::f1f7:6c06:d0d0:d48c%10]) with mapi; Mon, 15 Feb 2016 17:52:44 -0500 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Date: Mon, 15 Feb 2016 17:52:42 -0500 Thread-Topic: virtual interim - time for decision Thread-Index: AdFn52y66oGTZUowSo+BYltGTOzwEQAWljUA Message-ID: <4AF73AA205019A4C8A1DDD32C034631D3FF3A3086D@NJFPSRVEXG0.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BF18FF5@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BF18FF5@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D3FF3A3086DNJFPSRVEXG0re_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] virtual interim - time for decision X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 22:52:50 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D3FF3A3086DNJFPSRVEXG0re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, regarding agenda topics: I hope to update the draft in Initial Registry contents http://tools.ietf.org/html/draft-morton-ippm-initial-registry-03.txt replacing the last of the Section 4 binary formats with decimal64 https://tools.ietf.org/html/rfc6020#section-9.3 I hope to update this draft on the flight home this Saturday, so don't look for the 04 version before then. Also, some of our list recent exchanges indicate that it might be useful to discuss an example of Periodic Stream measurement with randomized start time (although the data formats will not be updated yet in this section, the plan is to sort-out section 4 first). Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Monday, February 15, 2016 6:53 AM To: lmap@ietf.org Subject: [lmap] virtual interim - time for decision Hi, It's time to decide whether to hold the 2/22 LMAP virtual interim meeting. = Please state you opinions one way or the other. If you support holding the = meeting please state what should be on the agenda, as a draft of the agenda= must be uploaded today 2/15. Thanks and Regards, Dan --_000_4AF73AA205019A4C8A1DDD32C034631D3FF3A3086DNJFPSRVEXG0re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dan, regarding agenda topics:=

 

I hope to update the draft in = Initial Registry contents

http://tools.ietf.org/= html/draft-morton-ippm-initial-registry-03.txt

rep= lacing the last of the Section 4 binary formats with decimal64

https:= //tools.ietf.org/html/rfc6020#section-9.3

I hope t= o update this draft on the flight home this Saturday,

=

= so don’t look for the 04 version before then.

<= p class=3DMsoNormal><= o:p> 

Also, some of our list recent exchanges indicate= that it might be useful

to discuss an example of Peri= odic Stream measurement with randomized

start time (al= though the data formats will not be updated yet in

thi= s section, the plan is to sort-out section 4 first).

<= p class=3DMsoNormal><= o:p> 

Al

 =

From: lmap [mailto:lmap-bounces= @ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday,= February 15, 2016 6:53 AM
To: lmap@ietf.org
Subject: [= lmap] virtual interim - time for decision

=

 

Hi,

 

ItR= 17;s time to decide whether to hold the 2/22 LMAP virtual interim meeting. = Please state you opinions one way or the other. If you support holding the = meeting please state what should be on the agenda, as a draft of the agenda= must be uploaded today 2/15.

&nbs= p;

Thanks and Regards,

 

Dan

 

= --_000_4AF73AA205019A4C8A1DDD32C034631D3FF3A3086DNJFPSRVEXG0re_-- From nobody Mon Feb 15 15:39:54 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38701AC3BA for ; Mon, 15 Feb 2016 15:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXvz-wa_DJ_9 for ; Mon, 15 Feb 2016 15:39:51 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0511A930A for ; Mon, 15 Feb 2016 15:39:51 -0800 (PST) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 523FA1215DF; Mon, 15 Feb 2016 18:41:01 -0500 (EST) Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.99]) by mail-azure.research.att.com (Postfix) with ESMTP id 9F5B6E0520; Mon, 15 Feb 2016 18:37:37 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by njmtcas1.research.att.com ([fe80::f1f7:6c06:d0d0:d48c%10]) with mapi; Mon, 15 Feb 2016 18:37:37 -0500 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder Date: Mon, 15 Feb 2016 18:37:35 -0500 Thread-Topic: [lmap] milliseconds in ma-periodic-interval and ma-event-random-spread Thread-Index: AdFn9sq3OQG7E9pIQq6b6MLV3WTneQATUEmQ Message-ID: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30882@NJFPSRVEXG0.research.att.com> References: <20160211155559.GA55278@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D3FF3B4288C@NJFPSRVEXG0.research.att.com> <20160215134250.GA72079@elstar.local> In-Reply-To: <20160215134250.GA72079@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] milliseconds in ma-periodic-interval and ma-event-random-spread X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 23:39:53 -0000 Hi Juergen, please see [ACM] replies below. Al > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, February 15, 2016 8:43 AM > To: MORTON, ALFRED C (AL) > Cc: lmap@ietf.org > Subject: Re: [lmap] milliseconds in ma-periodic-interval and ma-event- > random-spread >=20 > On Mon, Feb 15, 2016 at 07:31:07AM -0500, MORTON, ALFRED C (AL) wrote: > > Hi Juergen, > > I understand the difference between these schedulers quite well. > > > > If we both send one packet per second, and we both use random > > Integer second offsets for our start times, say 12:00:01 and 12:00:07, > > then we both send packets at the same time on the integer second > > chime (after 6 seconds). As I said below, we cannot count on random > > time to start a test after the schedule says 'go'. >=20 > I do not understand your example. What are 12:00:01 and 12:00:07? > One-off absolute times without ma-event-random-spread?=20 [ACM]=20 Sorry, I was working on a soft keyboard during the break between appointmen= ts. I meant that 12:00:00 (HH:MM:SS) is the start time of the measurement inter= val (T0) and 12:00:01 is a random start time selected from the interval of=20 allowed start times, 12:00:00 to 12:00:00 + dT, where dT =3D 00:00:10 (10 s= econds) and the specific random value is 00:00:01 in this case. 12:00:07 is another start time, where the specific random value is 00:00:07= (7 seconds). > Or your concern > is that both packets will be aligned to the systems' notion of a > 'complete' second? Well, not really true, since the event is going to > start a task and the likelihood that the tasks start at exactly the > same time and get their first packet on the way is small.=20 [ACM]=20 It is an important point that the Metric Parameters describe when the=20 measurement stream starts and stops. The housekeeping time to start=20 a measurement process and arrange for a measurement peer to receive the stream should take place in advance of the start of the measurement=20 interval (when the first measurement packet is sent on the link). That's what is meant by the time parameters here https://tools.ietf.org/html/draft-morton-ippm-initial-registry-03#section-8= .3.5 (ignore the data format, please). > Again, I > question that it is realistic to schedule tasks to start once per > second in order to send one packet. [ACM]=20 I do too, because I don't understand why anyone would do that. The measurement system is supposed to send one packet per second in my example -- one sending process would send, wait, send, wait, ... So, we have two measurement streams, sending 1 packet per second as follows= : Stream 1 12:00:01, :02, :03, :04, :05, :06, :07, :08, :09, ... Stream 2 12:00:07, :08, :09, ... and the streams synchronize on one second clock ticks. >=20 > > The random offset is to deliberately avoid synchronization in cases > > like this. >=20 > The question is whether the granularity needs to be milliseconds. I > did not question to have ma-event-random-spread. Note that regular > crons do not even go to second resolution, they stop a minutes. OK, > this is not a strong argument but perhaps the disconnect here is what > kind of tasks we ultimately assume to be scheduled. >=20 > Anyway, my original proposal was primarily about ma-periodic-interval. [ACM]=20 I can live with one second resolution on ma-periodic-interval, as long as there is millisecond resolution on ma-event-random-spread. > If people feel strongly that the ma-event-random-spread should remain > with milliseconds resolution, I can probably live with that. Having > ma-periodic-interval at milliseconds resolution is however more of a > pain to implement. [ACM]=20 I understand, but it was possible when we implemented RFC 3432, back before it was published and in draft stage. thanks, Al >=20 > /js >=20 > > I get it, this is harder to do. > > Al > > ________________________________________ > > From: Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de] > > Sent: Monday, February 15, 2016 6:16 AM > > To: MORTON, ALFRED C (AL) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] milliseconds in ma-periodic-interval and ma-event- > random-spread > > > > Al, > > > > this is the scheduler starting measurement tasks, it is _not_ the task > > internal scheduler that sends packet streams. Some large existing > > measurement systems use cron for this purpose and cron does at most > > second granularity (at least those that I have seen in my life so > > far). This is _not_ about inter-packet intervals etc. > > > > /js > > > > On Thu, Feb 11, 2016 at 11:41:35AM -0500, MORTON, ALFRED C (AL) wrote: > > > Hi Juergen, > > > > > > Brief reply with reservations on your proposal, apologies in > advance. > > > > > > Many active measurements are conducted using periodic packet streams > > > at integer second intervals, and many use 1 second inter-packet > intervals. > > > Or, when emulating VoIP, 20ms inter-packet intervals. > > > Integer random spreads don't help these cases. > > > > > > The intent of the random spread is to assist multiple streams from > aligning. > > > We aren't just talking about 1 sender here. Large Scale. > > > > > > Even if some implementations have an unpredictable delay after the > > > task is initiated, others could anticipate the schedule and > > > prepare a measurement process so it actually begins sending > > > when scheduled. > > > > > > Perhaps we can work out another solution, but I feel that > > > changing to integer random spreads would be a mistake. > > > http://tools.ietf.org/html/rfc3432#section-3 > > > > > > Al > > > > > > > > > > -----Original Message----- > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > > > Schoenwaelder > > > > Sent: Thursday, February 11, 2016 10:56 AM > > > > To: lmap@ietf.org > > > > Subject: [lmap] milliseconds in ma-periodic-interval and ma-event- > > > > random-spread > > > > > > > > Hi, > > > > > > > > the timing objects use milliseconds for (a) the periodic timer > > > > interval and (b) for the random spread. Since timing objects are > used > > > > to start the execution of schedules (which then trigger tasks) and > > > > they are not used for packet timings (as this happens inside of > > > > measurement tasks), I find the millisecond resolution (i) awkward > to > > > > read and configure, (ii) somewhat painful to implement (can't > simply > > > > use a time_t internally), and (iii) pretty useless (since there > will > > > > be some additional unpredictable delay until a task has been > started > > > > and a first packet his a wire). > > > > > > > > Note also that timing events have a maximum resolution of > > > > seconds. Hence, my proposal is to change ma-periodic-interval and > > > > ma-event-random-spread from milliseconds to seconds. > > > > > > > > /js > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > Fax: +49 421 200 3103 > > > > > > > > _______________________________________________ > > > > lmap mailing list > > > > lmap@ietf.org > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Mon Feb 15 22:14:32 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B54D1A8713 for ; Mon, 15 Feb 2016 22:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2Gp7-zN0wvr for ; Mon, 15 Feb 2016 22:14:23 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02ADD1A8704 for ; Mon, 15 Feb 2016 22:14:23 -0800 (PST) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id D2922A2F23E37; Tue, 16 Feb 2016 06:14:20 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u1G6ELIn005584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Feb 2016 06:14:21 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u1G6ELk3030798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Feb 2016 06:14:21 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.121]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 16 Feb 2016 01:14:21 -0500 From: "Carey, Timothy (Nokia - US)" To: Ron Stana Thread-Topic: [lmap] Support for multiple report table formats from one task Thread-Index: AQHRZpkvpmDKnEpIoUqJmeiE7E+MV58tqpaggACGfbA= Date: Tue, 16 Feb 2016 06:14:20 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A5D0DBB@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A5CE3C2@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A5D0DBBUS70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Cc: "alissa@cooperw.in" , "lmap@ietf.org" Subject: Re: [lmap] Support for multiple report table formats from one task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 06:14:29 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A5D0DBBUS70UWXCHMBA0_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9uLA0KDQpJIHdhcyB0aGlua2luZyBhYm91dCB0aGlzIHNvbWUgbW9yZSBsYXN0IG5pZ2h0Lg0K DQpBcmUgeW91IGFza2luZyB0byBjYXRlZ29yaXplIHRoZSByZXBvcnRzIGJ5IHJlZ2lzdHJ5IGVu dHJ5PyAtIHdoaWNoIEkgdGhpbmsgeW91IGNhbGwgcmVwb3J0IHR5cGU/ICBJZiBzbyBJIGRvbuKA mXQgc2VlIGFuIGlzc3VlIHdpdGggdGhhdCDigJMgd2UgY2FuIHVzZSB0aGUgcmVnaXN0cnkgZW50 cnkgYXMgcGFydCBvZiB0aGUgcmVwb3J0IHJlc3VsdHPigKYNCg0KQlIsDQpUaW0NCg0KRnJvbTog Q2FyZXksIFRpbW90aHkgKE5va2lhIC0gVVMpDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE1LCAy MDE2IDEwOjMxIFBNDQpUbzogJ1JvbiBTdGFuYScNCkNjOiBhbGlzc2FAY29vcGVydy5pbjsgbG1h cEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtsbWFwXSBTdXBwb3J0IGZvciBtdWx0aXBsZSByZXBv cnQgdGFibGUgZm9ybWF0cyBmcm9tIG9uZSB0YXNrDQoNClJvbiwNCg0KSSB3b3VsZCB0YWxrIHRv IHRoZSBJUFBNIHRlYW0gdGhlbiDigJMgaXRzIHJlYWxseSBob3cgdGhleSBkZWZpbmUgdGhlIG1l dHJpY3MgdGhhdCBtYWtlIHVwIHRoZSByZWdpc3RyeS4NCg0KQXMgZm9yIGEgcmVwb3J0IHBlciB0 YXNrIGNvbnN0cmFpbnQg4oCTIEkgZG9u4oCZdCBrbm93IGlmIHNhdmluZyBpbnB1dHMgYW5kIG91 dHB1dHMgYXMgeW91IHN1Z2dlc3Qgd2FycmFudCBicmVha2luZyB0aGF0IGNvbnN0cmFpbnQg4oCT IHdoeSBub3QganVzdCBoYXZlIDIgdGFza3MgYW5kIGR1cGxpY2F0ZSB0aGUgcmVnaXN0cnkgZW50 cnkuDQoNCkkgbGlrZSB0aGUgd2hlbiB0aGUgdGFzayBpcyBjb21wbGV0ZSDigJMgZ2VuZXJhdGUg dGhlIHJlc3VsdHMgZm9yIHJlcG9ydGluZyBhbmQgdGhlbiByZXBvcnQgcmVzdWx0cyBiYXNlZCBv biB0aGUgc2NoZWR1bGUgdG8gdGhlIGNvbGxlY3Rvci4gSSBrbm93IGluIG91ciBCQkYgaW1wbGVt ZW50YXRpb24gdGhpcyB3b3JrcyBxdWl0ZSB3ZWxsLg0KDQpPdGhlcndpc2UgeW91IGdldCBpbnRv IHRoZSBuYXN0eSBwcm9ibGVtIG9mIGEgc3RhdGUgbWFjaGluZSB0aGF0IGNvcnJlbGF0ZXMgcnVu bmluZyB0aGUgdGVzdHMgd2l0aCByZXBvcnRpbmcgcmVzdWx0cyBpbiB0aGUgY29udGV4dCBvZiB0 aGUgb3ZlcmFyY2hpbmcgc2NoZWR1bGVkIHRhc2sgKFlvdSBjYWxsIGl0IHJ1bm5pbmcgYW5kIGZp bmFsIGJ1dCB0aGVyZSBpcyBhIGNvbnRleHQgdG8gdGhvc2Ugc3RhdGVzIGZvciB0aGF0IHBhcnRp Y3VsYXIgdGFzaykuDQoNCkJSLA0KVGltDQoNCg0KRnJvbTogUm9uIFN0YW5hIFttYWlsdG86cm9u LnN0YW5hQHZpYXZpc29sdXRpb25zLmNvbV0NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTUsIDIw MTYgNTo0MCBQTQ0KVG86IENhcmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKQ0KQ2M6IGFsaXNzYUBj b29wZXJ3LmluPG1haWx0bzphbGlzc2FAY29vcGVydy5pbj47IGxtYXBAaWV0Zi5vcmc8bWFpbHRv OmxtYXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2xtYXBdIFN1cHBvcnQgZm9yIG11bHRpcGxl IHJlcG9ydCB0YWJsZSBmb3JtYXRzIGZyb20gb25lIHRhc2sNCg0KVGltLA0KDQpXaGlsZSBtdWx0 aXBsZSByZWdpc3RyeSBlbnRyaWVzIGNvdWxkIGJlIHVzZWQgdG8gZGVmaW5lIGVhY2ggb2YgdGhl IHJlcG9ydCB0eXBlcyAodGFibGUgZm9ybWF0cyksIHRoaXMgd291bGQgcmVxdWlyZSB0aG9zZSBy ZWdpc3RyeSBlbnRyaWVzIHRvIHJlcGxpY2F0ZSB0aGUgaW5wdXRzICgnZml4ZWQgcGFyYW1ldGVy cycgaW4gcmVnaXN0cnkgdGVybXMpIGFuZCBhbnkgb3V0cHV0cyB0aGF0IGFyZSBjb21tb24gYWNy b3NzIHRoZSBkaWZmZXJlbnQgdHlwZXMuICBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gaGF2ZSBvbmUg cmVnaXN0cnkgZW50cnkgdGhhdCBkZWZpbmVkIHRoZSBpbnB1dHMgdG8gdGhlIHRhc2sgb25jZSwg YWxsIHBvc3NpYmxlIG91dHB1dHMgb25jZSBhbmQgdGhlbiBhbGxvd2VkIHRoZSBvdXRwdXRzIHRv IGJlIGdyb3VwZWQgaW50byBkaWZmZXJlbnQgcmVwb3J0IHR5cGVzLiBUaGUgcmVwb3J0IHR5cGUg aXMganVzdCBzb21lIHN0cmluZyB2YWx1ZS4gV2hlbiB0aGUgdGFibGVzIHdlcmUgc2VudCBmcm9t IHRoZSBNQSB0byB0aGUgQ29sbGVjdG9yIHRoZXkgd291bGQgdGhlbiBqdXN0IG5lZWQgdG8gaW5j bHVkZSB0aGUgcmVwb3J0IHR5cGUuDQoNCkV4YW1wbGU6DQoxKSBUYXNrIG1lYXN1cmVzIGJhbmR3 aWR0aCBmb3Igb25lIG9yIG1vcmUgc3RyZWFtcw0KMikgT25lIHJlZ2lzdHJ5IGVudHJ5IGlzIGRl ZmluZWQgZm9yIHRoZSB0YXNrLiBJdCBpbmNsdWRlczoNCiAgICBhKSB0aGUgbnVtZXJvdXMgaW5w dXRzIHRoYXQgZGVmaW5lIHRoZSBzdHJlYW0ncyBwYWNrZXQgZm9ybWF0DQogICAgYikgYW4gb3V0 cHV0IGRlZmluaXRpb24gZm9yIHRoZSAnbGFzdCBvbmUgc2Vjb25kIGJhbmR3aWR0aCcNCiAgICBj KSBhbiBvdXRwdXQgZGVmaW5pdGlvbiBmb3IgdGhlICdhdmVyYWdlIGJhbmR3aWR0aCBzaW5jZSB0 YXNrIHN0YXJ0Jw0KMykgVGhlICdsYXN0IG9uZSBzZWNvbmQgYmFuZHdpZHRoJyBpcyBvbmx5IHVz ZWZ1bCB3aGlsZSB0aGUgdGFzayBpcyBydW5uaW5nIHNvIGl0IGlzIGFzc2lnbmVkIHRvIHRoZSBy ZXBvcnQgdHlwZSAncnVubmluZycuICBUaGUgZGVzY3JpcHRpb24gb2YgdGhlIG91dHB1dA0KNCkg VGhlICdhdmVyYWdlIGJhbmR3aWR0aCBzaW5jZSB0YXNrIHN0YXJ0JyBpcyB1c2VmdWwgd2hpbGUg dGhlIHRhc2sgaXMgcnVubmluZyBhbmQgYXMgYSBmaW5hbCB2YWx1ZSB3aGVuIHRoZSB0YXNrIGNv bXBsZXRlcyBzbyBpdCBpcyBhc3NpZ25lZCB0byB0aGUgcmVwb3J0IHR5cGVzICdydW5uaW5nJyBh bmQgJ2ZpbmFsJy4NCjUpIFdoZW4gdGhlIHJlcG9ydHMgYXJlIHNlbnQgZnJvbSB0aGUgTUEsIHRo ZXkgaW5kaWNhdGUgdGhlIHJlcG9ydCB0eXBlLiBUaGlzIGlzIHdoZXJlIEkgc3VnZ2VzdGVkIHRo ZSAndGFnJyBvYmplY3QgaW4gdGhlIHJlcG9ydCBjb3VsZCBiZSB1c2VkLg0KDQpJbiB0aGUgZW5k IEkgYW0gYXNraW5nIGFib3V0IHRoZXNlIHRocmVlIGlzc3VlczoNCjEpIEhvdyBkb2VzIGEgdGFz ayBwcm9wZXJseSBkZWZpbmUgbXVsdGlwbGUgcmVwb3J0IHR5cGVzICh0YWJsZXMpPw0KMikgSG93 IGRvZXMgdGhlIE1BIGlkZW50aWZ5IHRoZSByZXBvcnQgdHlwZSBiZWluZyBzZW50Pw0KRXZlbiBp ZiAjMSBpcyBhZGRyZXNzZWQgdXNpbmcgbXVsdGlwbGUgcmVnaXN0cnkgZW50cmllcywgYW5kICMy IGlzIGFkZHJlc3NlZCBieSBpbmNsdWRpbmcgYSByZWZlcmVuY2UgdG8gdGhlIHJlZ2lzdHJ5IGVu dHJ5IGluIHRoZSAnbWV0cmljL3VyaScgb2JqZWN0IG9mIHRoZSB0YXNrIHdpdGhpbiB0aGUgcmVw b3J0LCB0aGVyZSBpcyBzdGlsbCB0aGlzIGlzc3VlOg0KMykgSG93IGRvZXMgdGhlIE1BIHNlbmQg bXVsdGlwbGUgcmVwb3J0IHR5cGVzIGF0IHRoZSBzYW1lIHRpbWU/IE15IHVuZGVyc3RhbmRpbmcg b2YgdGhlIGN1cnJlbnQgcmVwb3J0IGRlZmluaXRpb24gaXMgdGhhdCBpdCBsaW1pdHMgZWFjaCB0 YXNrIHRvIGhhdmluZyBvbmUgdGFibGUgZGVmaW5pdGlvbiBwZXIgUE9TVC4gIFRoZSBNQSBjb3Vs ZCBzZW5kIGVhY2ggdGFibGUgZGVmaW5pdGlvbiB0byB0aGUgY29sbGVjdG9yIHNlcGFyYXRlbHkg YnV0IGFsbG93aW5nIGVhY2ggdGFzayB0byBzZW5kIGFuIGFycmF5IG9mIHRhYmxlIGRlZmluaXRp b25zIHdvdWxkIGJlIG1vcmUgZWZmaWNpZW50Lg0KDQpZb3UgYnJvdWdodCB1cCBhIGZvdXJ0aCBp c3N1ZSB3aGljaCBpcyBob3cgdGhlIGRhdGEgaW4gZWFjaCB0YWJsZSBpcyBtYXBwZWQgdG8gdGhl IHJlZ2lzdHJ5LiAgSSBoYXZlIGJlZW4gbWFraW5nIHRoZSBhc3N1bXB0aW9uIHRoaXMgd2FzIGdv aW5nIHRvIGJlIGFjY29tcGxpc2hlZCBieSBzZXR0aW5nIHRoZSBjb2x1bW4gaGVhZGVyIHZhbHVl IGluIHRoZSByZXBvcnQgdG8gb25lIG9mIHRoZSBzdW1tYXJ5L25hbWUgdmFsdWVzIGRlZmluZWQg aW4gdGhlIHJlZ2lzdHJ5IGZvciB0aGUgbWV0cmljLg0KDQpSb24NCg0KT24gU3VuLCBGZWIgMTQs IDIwMTYgYXQgMTE6MTEgQU0sIENhcmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKSA8dGltb3RoeS5j YXJleUBub2tpYS5jb208bWFpbHRvOnRpbW90aHkuY2FyZXlAbm9raWEuY29tPj4gd3JvdGU6DQpS b24sDQoNClRoZSB0YXNrIGhhcyBtdWx0aXBsZSByZWdpc3RyeSBlbnRyaWVzIOKAkyBJIHdvdWxk IGFzc3VtZSB5b3VyIGV4YW1wbGUgaXMgdGhhdCB0aGlzIHRhc2sNCndvdWxkIGhhdmUgMyByZWdp c3RyeSBlbnRyaWVzLg0KDQpUaGUgY29sdW1ucyBhcmUgZm9yIHRoZSB0YXNrIGFuZCB3b3VsZCBo YXZlIHRvIGhhdmUgYSB1bmlvbiBvZiBhbGwgdGhlIG1ldHJpY3MgZm9yIHJlZ2lzdHJ5IGVudHJp ZXMuIOKAkyBJcyB0aGlzIHdoYXQgeW91IHdlcmUgYXNraW5nPw0KDQpJdCBzZWVtcyB0aGF0IHdl IGxvc2UgdGhlIGNvbnRleHQgb2YgdGhlIHJlZ2lzdHJ5IGVudHJ5IHRvIGNvbHVtbiB0aG91Z2ji gKYNCg0KQlIsDQpUaW0NCg0KRnJvbTogUm9uIFN0YW5hIFttYWlsdG86cm9uLnN0YW5hQHZpYXZp c29sdXRpb25zLmNvbTxtYWlsdG86cm9uLnN0YW5hQHZpYXZpc29sdXRpb25zLmNvbT5dDQpTZW50 OiBGcmlkYXksIEZlYnJ1YXJ5IDEyLCAyMDE2IDQ6MzEgUE0NClRvOiBsbWFwQGlldGYub3JnPG1h aWx0bzpsbWFwQGlldGYub3JnPg0KQ2M6IGFsaXNzYUBjb29wZXJ3LmluPG1haWx0bzphbGlzc2FA Y29vcGVydy5pbj4NClN1YmplY3Q6IFtsbWFwXSBTdXBwb3J0IGZvciBtdWx0aXBsZSByZXBvcnQg dGFibGUgZm9ybWF0cyBmcm9tIG9uZSB0YXNrDQoNCkxNQVAgVGVhbSwNCg0KTXkgdW5kZXJzdGFu ZGluZyBvZiB0aGUgTE1BUCBwcm9wb3NhbCBpcyBpZXRmLWxtYXAtcmVwb3J0OnJlcG9ydC90YXNr L25hbWUgaXMgc3VwcG9zZWQgdG8gY29udGFpbiBvbmUgb2YgdGhlIHZhbHVlcyBkZWZpbmVkIGlu IGlldGYtbG1hcC1jb250cm9sOmxtYXAvdGFza3MvdGFzay9uYW1lLg0KDQpJZiB0aGlzIGlzIGNv cnJlY3QsIGFuZCBzaW5jZSBlYWNoIHRhc2sgaW5zdGFuY2Ugd2l0aGluIGEgcmVwb3J0IGNhbiBv bmx5IGNvbnRhaW4gb25lIHRhYmxlIGRlZmluaXRpb24gKG9uZSBoZWFkZXIgKyBpdHMgcm93IGRh dGEpIHRoZW4gaG93IGRvZXMgYSB0YXNrIHNlbmQgbXVsdGlwbGUgdGFibGVzIG9mIHJlc3VsdHMg dGhhdCBjb250YWluIGRpZmZlcmVudCB0YWJsZSBmb3JtYXRzPw0KDQpVc2UgQ2FzZXM6DQoxKSBZ LjE1NjQgdGFzayBoYXMgcmVzdWx0cyBmb3IgdGhlIFNlcnZpY2UgQ29uZmlndXJhdGlvbiBhbmQg dGhlIFNlcnZpY2UgUGVyZm9ybWFuY2UgZGF0YSwgYW5kIGVhY2ggdGFibGUgaGFzIGEgZGlmZmVy ZW50IHNldCBvZiBjb2x1bW5zLg0KMikgQW4gUkZDLTI1NDQgdGFzayB3b3VsZCBuZWVkIGEgZGlm ZmVyZW50IHRhYmxlIGZvciB0aGUgVGhyb3VnaHB1dCwgTGF0ZW5jeSwgRnJhbWUgTG9zcyBhbmQg QmFjayB0byBCYWNrIHJlc3VsdCBzZXRzLg0KMykgQW55IHRhc2sgbWF5IHdhbnQgdG8gc2VuZCBh IG1pbmltYWwgcmVzdWx0IHNldCB3aGlsZSBpdCBpcyBleGVjdXRpbmcgdGhhdCBpcyB2ZXJ5IGRp ZmZlcmVudCBmcm9tIHRoZSBmaW5hbCByZXN1bHQgc2V0IHdoZW4gaXQgaGFzIGNvbXBsZXRlZC4N Cg0KVGhlIGlldGYtbG1hcC1yZXBvcnQ6cmVwb3J0L3Rhc2svdGFnIGNvdWxkIGJlIHVzZWQgdG8g ZGlmZmVyZW50aWF0ZSB0aGUgcmVzdWx0IHNldHMgc2VudCBieSB0aGUgc2FtZSB0YXNrLiBIb3dl dmVyIHRoaXMgaXMgbm90IHZlcnkgZWZmaWNpZW50IHNpbmNlIHRoaXMgYXBwcm9hY2ggcmVxdWly ZXMgdGhlIE1BIHRvIHNlbmQgZWFjaCByZXBvcnQgdG8gdGhlIGNvbGxlY3RvciBzZXBhcmF0ZWx5 IGJlY2F1c2UgZWFjaCByZXBvcnQgY2FuIG9ubHkgY29udGFpbiBvbmUgc2V0IG9mIHJlc3VsdHMg cGVyIHRhc2sgbmFtZS4NCg0KQW55IGd1aWRhbmNlIG9yIGNsYXJpZmljYXRpb24gb24gdGhlIExN QVAgcHJvcG9zYWwgd291bGQgYmUgYXBwcmVjaWF0ZWQsDQoNClJvbg0KDQoNCg0KDQoNCg0K --_000_9966516C6EB5FC4381E05BF80AA55F77012A5D0DBBUS70UWXCHMBA0_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1T IjsNCglwYW5vc2UtMToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Ry ZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg d2FzIHRoaW5raW5nIGFib3V0IHRoaXMgc29tZSBtb3JlIGxhc3QgbmlnaHQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+QXJlIHlvdSBhc2tpbmcgdG8gY2F0ZWdvcml6ZSB0aGUgcmVwb3J0cyBieSByZWdp c3RyeSBlbnRyeT8gLSB3aGljaCBJIHRoaW5rIHlvdSBjYWxsIHJlcG9ydCB0eXBlPyZuYnNwOyBJ ZiBzbyBJIGRvbuKAmXQgc2VlIGFuIGlzc3VlIHdpdGggdGhhdCDigJMgd2UgY2FuIHVzZSB0aGUN CiByZWdpc3RyeSBlbnRyeSBhcyBwYXJ0IG9mIHRoZSByZXBvcnQgcmVzdWx0c+KApjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkJSLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1 Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRpbTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQ2FyZXksIFRpbW90aHkgKE5va2lhIC0gVVMpDQo8YnI+ DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJydWFyeSAxNSwgMjAxNiAxMDozMSBQTTxicj4NCjxi PlRvOjwvYj4gJ1JvbiBTdGFuYSc8YnI+DQo8Yj5DYzo8L2I+IGFsaXNzYUBjb29wZXJ3LmluOyBs bWFwQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbbG1hcF0gU3VwcG9ydCBmb3Ig bXVsdGlwbGUgcmVwb3J0IHRhYmxlIGZvcm1hdHMgZnJvbSBvbmUgdGFzazxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNo ZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxk IHRhbGsgdG8gdGhlIElQUE0gdGVhbSB0aGVuIOKAkyBpdHMgcmVhbGx5IGhvdyB0aGV5IGRlZmlu ZSB0aGUgbWV0cmljcyB0aGF0IG1ha2UgdXAgdGhlIHJlZ2lzdHJ5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkFzIGZvciBhIHJlcG9ydCBwZXIgdGFzayBjb25zdHJhaW50IOKAkyBJIGRvbuKAmXQga25v dyBpZiBzYXZpbmcgaW5wdXRzIGFuZCBvdXRwdXRzIGFzIHlvdSBzdWdnZXN0IHdhcnJhbnQgYnJl YWtpbmcgdGhhdCBjb25zdHJhaW50IOKAkyB3aHkgbm90IGp1c3QgaGF2ZSAyIHRhc2tzDQogYW5k IGR1cGxpY2F0ZSB0aGUgcmVnaXN0cnkgZW50cnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVj aGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBsaWtl IHRoZSB3aGVuIHRoZSB0YXNrIGlzIGNvbXBsZXRlIOKAkyBnZW5lcmF0ZSB0aGUgcmVzdWx0cyBm b3IgcmVwb3J0aW5nIGFuZCB0aGVuIHJlcG9ydCByZXN1bHRzIGJhc2VkIG9uIHRoZSBzY2hlZHVs ZSB0byB0aGUgY29sbGVjdG9yLiBJIGtub3cgaW4gb3VyDQogQkJGIGltcGxlbWVudGF0aW9uIHRo aXMgd29ya3MgcXVpdGUgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtU cmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PdGhlcndpc2UgeW91IGdl dCBpbnRvIHRoZSBuYXN0eSBwcm9ibGVtIG9mIGEgc3RhdGUgbWFjaGluZSB0aGF0IGNvcnJlbGF0 ZXMgcnVubmluZyB0aGUgdGVzdHMgd2l0aCByZXBvcnRpbmcgcmVzdWx0cyBpbiB0aGUgY29udGV4 dCBvZiB0aGUgb3ZlcmFyY2hpbmcNCiBzY2hlZHVsZWQgdGFzayAoWW91IGNhbGwgaXQgcnVubmlu ZyBhbmQgZmluYWwgYnV0IHRoZXJlIGlzIGEgY29udGV4dCB0byB0aG9zZSBzdGF0ZXMgZm9yIHRo YXQgcGFydGljdWxhciB0YXNrKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtU cmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUiw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQg TVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUm9uIFN0YW5hIFs8YSBocmVmPSJtYWlsdG86 cm9uLnN0YW5hQHZpYXZpc29sdXRpb25zLmNvbSI+bWFpbHRvOnJvbi5zdGFuYUB2aWF2aXNvbHV0 aW9ucy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMTUsIDIw MTYgNTo0MCBQTTxicj4NCjxiPlRvOjwvYj4gQ2FyZXksIFRpbW90aHkgKE5va2lhIC0gVVMpPGJy Pg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86YWxpc3NhQGNvb3BlcncuaW4iPmFsaXNzYUBj b29wZXJ3LmluPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmxtYXBAaWV0Zi5vcmciPg0KbG1hcEBpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtsbWFwXSBTdXBwb3J0IGZvciBtdWx0 aXBsZSByZXBvcnQgdGFibGUgZm9ybWF0cyBmcm9tIG9uZSB0YXNrPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaW0sPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGlsZSBtdWx0aXBsZSByZWdpc3RyeSBlbnRyaWVzIGNv dWxkIGJlIHVzZWQgdG8gZGVmaW5lIGVhY2ggb2YgdGhlIHJlcG9ydCB0eXBlcyAodGFibGUgZm9y bWF0cyksIHRoaXMgd291bGQgcmVxdWlyZSB0aG9zZSByZWdpc3RyeSBlbnRyaWVzIHRvIHJlcGxp Y2F0ZSB0aGUgaW5wdXRzICgnZml4ZWQgcGFyYW1ldGVycycgaW4gcmVnaXN0cnkgdGVybXMpIGFu ZCBhbnkgb3V0cHV0cyB0aGF0IGFyZSBjb21tb24gYWNyb3NzDQogdGhlIGRpZmZlcmVudCB0eXBl cy4mbmJzcDsgSXQgd291bGQgYmUgYmV0dGVyIHRvIGhhdmUgb25lIHJlZ2lzdHJ5IGVudHJ5IHRo YXQgZGVmaW5lZCB0aGUgaW5wdXRzIHRvIHRoZSB0YXNrIG9uY2UsIGFsbCBwb3NzaWJsZSBvdXRw dXRzIG9uY2UgYW5kIHRoZW4gYWxsb3dlZCB0aGUgb3V0cHV0cyB0byBiZSBncm91cGVkIGludG8g ZGlmZmVyZW50IHJlcG9ydCB0eXBlcy4gVGhlIHJlcG9ydCB0eXBlIGlzIGp1c3Qgc29tZSBzdHJp bmcgdmFsdWUuIFdoZW4NCiB0aGUgdGFibGVzIHdlcmUgc2VudCBmcm9tIHRoZSBNQSB0byB0aGUg Q29sbGVjdG9yIHRoZXkgd291bGQgdGhlbiBqdXN0IG5lZWQgdG8gaW5jbHVkZSB0aGUgcmVwb3J0 IHR5cGUuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5FeGFtcGxlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+MSkgVGFzayBtZWFzdXJlcyBiYW5kd2lkdGggZm9yIG9uZSBvciBtb3Jl IHN0cmVhbXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjIpIE9uZSByZWdpc3RyeSBlbnRyeSBpcyBkZWZpbmVkIGZvciB0aGUgdGFzay4gSXQgaW5j bHVkZXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7IGEpIHRoZSBudW1lcm91cyBpbnB1dHMgdGhhdCBkZWZpbmUgdGhlIHN0 cmVhbSdzIHBhY2tldCBmb3JtYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgYikgYW4gb3V0cHV0IGRlZmluaXRpb24gZm9y IHRoZSAnbGFzdCBvbmUgc2Vjb25kIGJhbmR3aWR0aCc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgYykgYW4gb3V0cHV0IGRl ZmluaXRpb24gZm9yIHRoZSAnYXZlcmFnZSBiYW5kd2lkdGggc2luY2UgdGFzayBzdGFydCc8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMpIFRoZSAn bGFzdCBvbmUgc2Vjb25kIGJhbmR3aWR0aCcgaXMgb25seSB1c2VmdWwgd2hpbGUgdGhlIHRhc2sg aXMgcnVubmluZyBzbyBpdCBpcyBhc3NpZ25lZCB0byB0aGUgcmVwb3J0IHR5cGUgJ3J1bm5pbmcn LiZuYnNwOyBUaGUgZGVzY3JpcHRpb24gb2YgdGhlIG91dHB1dCZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NCkgVGhlICdhdmVyYWdlIGJh bmR3aWR0aCBzaW5jZSB0YXNrIHN0YXJ0JyBpcyB1c2VmdWwgd2hpbGUgdGhlIHRhc2sgaXMgcnVu bmluZyBhbmQgYXMgYSBmaW5hbCB2YWx1ZSB3aGVuIHRoZSB0YXNrIGNvbXBsZXRlcyBzbyBpdCBp cyBhc3NpZ25lZCB0byB0aGUgcmVwb3J0IHR5cGVzICdydW5uaW5nJyBhbmQgJ2ZpbmFsJy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUpIFdoZW4g dGhlIHJlcG9ydHMgYXJlIHNlbnQgZnJvbSB0aGUgTUEsIHRoZXkgaW5kaWNhdGUgdGhlIHJlcG9y dCB0eXBlLiBUaGlzIGlzIHdoZXJlIEkgc3VnZ2VzdGVkIHRoZSAndGFnJyBvYmplY3QgaW4gdGhl IHJlcG9ydCBjb3VsZCBiZSB1c2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgZW5kIEkgYW0gYXNraW5nIGFib3V0IHRoZXNlIHRo cmVlIGlzc3Vlczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjEpIEhvdyBkb2VzIGEgdGFzayBwcm9wZXJseSBkZWZpbmUgbXVsdGlwbGUgcmVwb3J0 IHR5cGVzICh0YWJsZXMpPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+MikgSG93IGRvZXMgdGhlIE1BIGlkZW50aWZ5IHRoZSByZXBvcnQgdHlwZSBi ZWluZyBzZW50PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+RXZlbiBpZiAjMSBpcyBhZGRyZXNzZWQgdXNpbmcgbXVsdGlwbGUgcmVnaXN0cnkgZW50 cmllcywgYW5kICMyIGlzIGFkZHJlc3NlZCBieSBpbmNsdWRpbmcgYSByZWZlcmVuY2UgdG8gdGhl IHJlZ2lzdHJ5IGVudHJ5IGluIHRoZSAnbWV0cmljL3VyaScgb2JqZWN0IG9mIHRoZSB0YXNrIHdp dGhpbiB0aGUgcmVwb3J0LCB0aGVyZSBpcyBzdGlsbCB0aGlzIGlzc3VlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MykgSG93IGRvZXMgdGhlIE1B IHNlbmQgbXVsdGlwbGUgcmVwb3J0IHR5cGVzIGF0IHRoZSBzYW1lIHRpbWU/IE15IHVuZGVyc3Rh bmRpbmcgb2YgdGhlIGN1cnJlbnQgcmVwb3J0IGRlZmluaXRpb24gaXMgdGhhdCBpdCBsaW1pdHMg ZWFjaCB0YXNrIHRvIGhhdmluZyBvbmUgdGFibGUgZGVmaW5pdGlvbiBwZXIgUE9TVC4mbmJzcDsg VGhlIE1BIGNvdWxkIHNlbmQgZWFjaCB0YWJsZSBkZWZpbml0aW9uIHRvIHRoZSBjb2xsZWN0b3IN CiBzZXBhcmF0ZWx5IGJ1dCBhbGxvd2luZyBlYWNoIHRhc2sgdG8gc2VuZCBhbiBhcnJheSBvZiB0 YWJsZSBkZWZpbml0aW9ucyB3b3VsZCBiZSBtb3JlIGVmZmljaWVudC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGJyb3VnaHQgdXAgYSBm b3VydGggaXNzdWUgd2hpY2ggaXMgaG93IHRoZSBkYXRhIGluIGVhY2ggdGFibGUgaXMgbWFwcGVk IHRvIHRoZSByZWdpc3RyeS4mbmJzcDsgSSBoYXZlIGJlZW4gbWFraW5nIHRoZSBhc3N1bXB0aW9u IHRoaXMgd2FzIGdvaW5nIHRvIGJlIGFjY29tcGxpc2hlZCBieSBzZXR0aW5nIHRoZSBjb2x1bW4g aGVhZGVyIHZhbHVlIGluIHRoZSByZXBvcnQgdG8gb25lIG9mIHRoZSBzdW1tYXJ5L25hbWUNCiB2 YWx1ZXMgZGVmaW5lZCBpbiB0aGUgcmVnaXN0cnkgZm9yIHRoZSBtZXRyaWMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIEZlYiAx NCwgMjAxNiBhdCAxMToxMSBBTSwgQ2FyZXksIFRpbW90aHkgKE5va2lhIC0gVVMpICZsdDs8YSBo cmVmPSJtYWlsdG86dGltb3RoeS5jYXJleUBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj50aW1v dGh5LmNhcmV5QG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvbiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVj aGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHRh c2sgaGFzIG11bHRpcGxlIHJlZ2lzdHJ5IGVudHJpZXMg4oCTIEkgd291bGQgYXNzdW1lIHlvdXIg ZXhhbXBsZSBpcyB0aGF0IHRoaXMgdGFzazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+d291bGQgaGF2ZSAzIHJlZ2lzdHJ5IGVudHJpZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoZSBjb2x1bW5zIGFyZSBmb3IgdGhlIHRhc2sgYW5kIHdvdWxkIGhhdmUgdG8gaGF2ZSBh IHVuaW9uIG9mIGFsbCB0aGUgbWV0cmljcyBmb3IgcmVnaXN0cnkNCiBlbnRyaWVzLiDigJMgSXMg dGhpcyB3aGF0IHlvdSB3ZXJlIGFza2luZz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVj aGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgc2Vl bXMgdGhhdCB3ZSBsb3NlIHRoZSBjb250ZXh0IG9mIHRoZSByZWdpc3RyeSBlbnRyeSB0byBjb2x1 bW4gdGhvdWdo4oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNo ZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGltPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSb24gU3RhbmEg W21haWx0bzo8YSBocmVmPSJtYWlsdG86cm9uLnN0YW5hQHZpYXZpc29sdXRpb25zLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnJvbi5zdGFuYUB2aWF2aXNvbHV0aW9ucy5jb208L2E+XQ0KPGJyPg0KPGI+ U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMTIsIDIwMTYgNDozMSBQTTxicj4NCjxiPlRvOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOmxtYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sbWFwQGll dGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmFsaXNzYUBjb29wZXJ3 LmluIiB0YXJnZXQ9Il9ibGFuayI+YWxpc3NhQGNvb3BlcncuaW48L2E+PGJyPg0KPGI+U3ViamVj dDo8L2I+IFtsbWFwXSBTdXBwb3J0IGZvciBtdWx0aXBsZSByZXBvcnQgdGFibGUgZm9ybWF0cyBm cm9tIG9uZSB0YXNrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+TE1BUCBUZWFtLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIExNQVAgcHJvcG9zYWwgaXMgaWV0Zi1s bWFwLXJlcG9ydDpyZXBvcnQvdGFzay9uYW1lIGlzIHN1cHBvc2VkIHRvIGNvbnRhaW4gb25lIG9m IHRoZSB2YWx1ZXMgZGVmaW5lZCBpbiBpZXRmLWxtYXAtY29udHJvbDpsbWFwL3Rhc2tzL3Rhc2sv bmFtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPklmIHRoaXMgaXMgY29ycmVjdCwgYW5kIHNpbmNlIGVhY2ggdGFzayBpbnN0YW5jZSB3 aXRoaW4gYSByZXBvcnQgY2FuIG9ubHkgY29udGFpbiBvbmUgdGFibGUgZGVmaW5pdGlvbiAob25l IGhlYWRlciAmIzQzOyBpdHMgcm93IGRhdGEpIHRoZW4gaG93IGRvZXMgYSB0YXNrIHNlbmQgbXVs dGlwbGUgdGFibGVzIG9mIHJlc3VsdHMNCiB0aGF0IGNvbnRhaW4gZGlmZmVyZW50IHRhYmxlIGZv cm1hdHM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5Vc2UgQ2FzZXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjEpIFkuMTU2NCB0YXNrIGhhcyByZXN1bHRzIGZvciB0aGUgU2Vydmlj ZSBDb25maWd1cmF0aW9uIGFuZCB0aGUgU2VydmljZSBQZXJmb3JtYW5jZSBkYXRhLCBhbmQgZWFj aCB0YWJsZSBoYXMgYSBkaWZmZXJlbnQgc2V0IG9mIGNvbHVtbnMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIpIEFuIFJGQy0yNTQ0IHRhc2sg d291bGQgbmVlZCBhIGRpZmZlcmVudCB0YWJsZSBmb3IgdGhlIFRocm91Z2hwdXQsIExhdGVuY3ks IEZyYW1lIExvc3MgYW5kIEJhY2sgdG8gQmFjayByZXN1bHQgc2V0cy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MykgQW55IHRhc2sgbWF5IHdh bnQgdG8gc2VuZCBhIG1pbmltYWwgcmVzdWx0IHNldCB3aGlsZSBpdCBpcyBleGVjdXRpbmcgdGhh dCBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIHRoZSBmaW5hbCByZXN1bHQgc2V0IHdoZW4gaXQgaGFz IGNvbXBsZXRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoZSBpZXRmLWxtYXAtcmVwb3J0OnJlcG9ydC90YXNrL3RhZyBjb3VsZCBi ZSB1c2VkIHRvIGRpZmZlcmVudGlhdGUgdGhlIHJlc3VsdCBzZXRzIHNlbnQgYnkgdGhlIHNhbWUg dGFzay4gSG93ZXZlciB0aGlzIGlzIG5vdCB2ZXJ5IGVmZmljaWVudCBzaW5jZSB0aGlzIGFwcHJv YWNoIHJlcXVpcmVzIHRoZSBNQQ0KIHRvIHNlbmQgZWFjaCByZXBvcnQgdG8gdGhlIGNvbGxlY3Rv ciBzZXBhcmF0ZWx5IGJlY2F1c2UgZWFjaCByZXBvcnQgY2FuIG9ubHkgY29udGFpbiBvbmUgc2V0 IG9mIHJlc3VsdHMgcGVyIHRhc2sgbmFtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFueSBndWlkYW5jZSBvciBjbGFyaWZpY2F0aW9u IG9uIHRoZSBMTUFQIHByb3Bvc2FsIHdvdWxkIGJlIGFwcHJlY2lhdGVkLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Um9uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9966516C6EB5FC4381E05BF80AA55F77012A5D0DBBUS70UWXCHMBA0_-- From nobody Tue Feb 16 01:30:38 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77E61B2D25 for ; Tue, 16 Feb 2016 01:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.905 X-Spam-Level: X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzGe1aIzqs-p for ; Tue, 16 Feb 2016 01:30:34 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11231B2D4E for ; Tue, 16 Feb 2016 01:30:29 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AhBQDV68JW/xUHmMZeGQEBAQEPAQEBAYI+IStSc7gLgiGBZyOFagKBOTkTAQEBAQEBAX8LhEMBAQMSG14BFRVWJgEEGxqHeAENmXSFEplLAQoBAQEYBIYSiEcBAR0tgn6BDwWWfwGPNIRDgxkMhS+OQCEBQINjiBY0AXsBAQE X-IPAS-Result: A2AhBQDV68JW/xUHmMZeGQEBAQEPAQEBAYI+IStSc7gLgiGBZyOFagKBOTkTAQEBAQEBAX8LhEMBAQMSG14BFRVWJgEEGxqHeAENmXSFEplLAQoBAQEYBIYSiEcBAR0tgn6BDwWWfwGPNIRDgxkMhS+OQCEBQINjiBY0AXsBAQE X-IronPort-AV: E=Sophos;i="5.22,454,1449550800"; d="scan'208,217";a="142809815" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Feb 2016 04:30:26 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 16 Feb 2016 04:30:25 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Tue, 16 Feb 2016 10:30:24 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: draft agenda for the 2/22 LMAP virtual interim meeting Thread-Index: AdFonKjMF3Pp/l29S0aUtuVEBgNqrg== Date: Tue, 16 Feb 2016 09:30:23 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF19E5F@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BF19E5FAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] draft agenda for the 2/22 LMAP virtual interim meeting X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 09:30:37 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF19E5FAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have uploaded the draft agenda for the virtual interim meeting of the LMA= P WG scheduled for 2/22, noon ET at https://www.ietf.org/proceedings/interi= m/2016/02/22/lmap/agenda/agenda-interim-2016-lmap-2. The principal item on the agenda is 'changes in the YANG and in the informa= tion model , discussion on the differences based on concrete details, open = issues' which will be run by Juergen. The goal is to make as much progress = by discussing and clarifying the open issues. The active participation of t= he WG participants is essential. Please read the documents and the mail thr= eads, provide feedback and comments. We will need two note takers. Please volunteer. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF19E5FAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have uploaded the draft agenda for the virtual int= erim meeting of the LMAP WG scheduled for 2/22, noon ET at https://www.ietf.org/proceedings/interim/2016/02/22/lmap/agenda/agenda-inte= rim-2016-lmap-2.

 

The principal item on the agenda is ‘changes in the YANG and in the information model , discussion=
 on the differences based on concrete details, open issues’ which wil=
l be run by Juergen. The goal is to make as much progress by discussing and=
 clarifying the open issues. The active participation of the WG participant=
s is essential. Please read the documents and the mail threads, provide fee=
dback and comments. 
 
We will need two note takers. Please voluntee=
r. 
 
Thanks and Regards,
 
Dan
 
--_000_9904FB1B0159DA42B0B887B7FA8119CA6BF19E5FAZFFEXMB04globa_-- From nobody Tue Feb 16 06:46:30 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263331A1B0B for ; Tue, 16 Feb 2016 06:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VixVZfc60y1s for ; Tue, 16 Feb 2016 06:46:25 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013C91A1A9A for ; Tue, 16 Feb 2016 06:46:24 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id a4so103553341wme.1 for ; Tue, 16 Feb 2016 06:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viavisolutions-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hFIeUJr2cKqBOtpVTtG6EvxdlF/k0xrV0UmlwIPDauc=; b=p+Cbd9kuOj8cgR+GNXafVRkdJc0Ha3KTGLq+4p1ZIsK5i48BrbgwRo7waoZRoPBAeG DCP/qEBCLXp+j9IIPznfEx8ETWibODGT+utQybwwKM+fvJJ3ERhNJsDYw3dlB7PY9oiS SHevQy7eyXwW5Iw33eOAiclYeHsiZW+aNg2kfeFmg6Mxu2bvO59P/SyHdoMlcfisrNcf sdMjVLIDSHbSjqcjBECBZp4Nv3qgZWUOfhH1GC/kAxepQvvnOz7LvCx0nQE3NP6hnMND x/mXy+uz/oc3c1zQd7EGJz1cWXqrtov5TgL22n6NT70Hbxq+fPRPFNQoYfvqxn9/bhQq lT5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hFIeUJr2cKqBOtpVTtG6EvxdlF/k0xrV0UmlwIPDauc=; b=IQohrgOeOecdyWziRcKOEsdpr2XbI/+uSKJPlZLLPkjJEdeCW5IEjPk/bafE+XETmU i0zKIUNgaIAxpOlu+r542Z+8NMtWCDWZHAINugGbQw1GKDcKCRqIi/hvTfhXo/nP+WJA AirguhuX+/tLJp/WQH1ebrH6FlrZBet692l//hu+JnYSG3JpwYQ6aaboI/O+sFlNdhmc 3Li1EBW7okCqKQ7WPoa7gXvxlD4IACieRuUuJb12bZxKWSDxlukH0C3k0rsiNL9u/Dc8 zpluiw2vfSURq7sxf8R7WFhoHr+WKuKe+T8DkVvAYWJsfff573G/m99zi9ZJssELBnPe KfuQ== X-Gm-Message-State: AG10YOSvjHePlDobSJspZRwOACClW5V2AcauKIAyjdzTJjPFp21rWzBuKxSXWJA6DDAJhTQn3RRO0sjdIbHXNyKo MIME-Version: 1.0 X-Received: by 10.194.250.103 with SMTP id zb7mr25049159wjc.65.1455633983480; Tue, 16 Feb 2016 06:46:23 -0800 (PST) Received: by 10.28.165.147 with HTTP; Tue, 16 Feb 2016 06:46:23 -0800 (PST) In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A5D0DBB@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A5CE3C2@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77012A5D0DBB@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Tue, 16 Feb 2016 09:46:23 -0500 Message-ID: From: Ron Stana To: "Carey, Timothy (Nokia - US)" Content-Type: multipart/alternative; boundary=001a11c26cca825054052be4322b Archived-At: Cc: "alissa@cooperw.in" , "lmap@ietf.org" Subject: Re: [lmap] Support for multiple report table formats from one task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 14:46:28 -0000 --001a11c26cca825054052be4322b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tim, I am trying to determine how one task can produce results that require multiple table formats (what I called report types) and send them to the collector at the same time. Most tasks we have will require this type of functionality. This is my understanding of what we have discussed so far: 1) The registry would be used to define the different table formats...for the purpose of this discussion let's go with your suggestion that there would be one entry for each table format. 2) The multiple registry entries are then assigned to a single task using multiple instances of the the lmap/tasks/task/metric object. 3) When the task goes to send these different tables of results to the Collector, it identifies the table that is being sent using a single instance of the the report/task/metric object. If we agree thus far then the part that remains is how to send multiple tables to the collector at one time. The current report model only allows each task to have one entry so the MA would have to POST a separate report for each table. I am asking if the tables could all be sent together. Ron On Tue, Feb 16, 2016 at 1:14 AM, Carey, Timothy (Nokia - US) < timothy.carey@nokia.com> wrote: > Ron, > > > > I was thinking about this some more last night. > > > > Are you asking to categorize the reports by registry entry? - which I > think you call report type? If so I don=E2=80=99t see an issue with that= =E2=80=93 we can > use the registry entry as part of the report results=E2=80=A6 > > > > BR, > > Tim > > > > *From:* Carey, Timothy (Nokia - US) > *Sent:* Monday, February 15, 2016 10:31 PM > *To:* 'Ron Stana' > *Cc:* alissa@cooperw.in; lmap@ietf.org > *Subject:* RE: [lmap] Support for multiple report table formats from one > task > > > > Ron, > > > > I would talk to the IPPM team then =E2=80=93 its really how they define t= he > metrics that make up the registry. > > > > As for a report per task constraint =E2=80=93 I don=E2=80=99t know if sav= ing inputs and > outputs as you suggest warrant breaking that constraint =E2=80=93 why not= just have > 2 tasks and duplicate the registry entry. > > > > I like the when the task is complete =E2=80=93 generate the results for r= eporting > and then report results based on the schedule to the collector. I know in > our BBF implementation this works quite well. > > > > Otherwise you get into the nasty problem of a state machine that > correlates running the tests with reporting results in the context of the > overarching scheduled task (You call it running and final but there is a > context to those states for that particular task). > > > > BR, > > Tim > > > > > > *From:* Ron Stana [mailto:ron.stana@viavisolutions.com > ] > *Sent:* Monday, February 15, 2016 5:40 PM > *To:* Carey, Timothy (Nokia - US) > *Cc:* alissa@cooperw.in; lmap@ietf.org > *Subject:* Re: [lmap] Support for multiple report table formats from one > task > > > > Tim, > > > > While multiple registry entries could be used to define each of the repor= t > types (table formats), this would require those registry entries to > replicate the inputs ('fixed parameters' in registry terms) and any outpu= ts > that are common across the different types. It would be better to have o= ne > registry entry that defined the inputs to the task once, all possible > outputs once and then allowed the outputs to be grouped into different > report types. The report type is just some string value. When the tables > were sent from the MA to the Collector they would then just need to inclu= de > the report type. > > > > Example: > > 1) Task measures bandwidth for one or more streams > > 2) One registry entry is defined for the task. It includes: > > a) the numerous inputs that define the stream's packet format > > b) an output definition for the 'last one second bandwidth' > > c) an output definition for the 'average bandwidth since task start' > > 3) The 'last one second bandwidth' is only useful while the task is > running so it is assigned to the report type 'running'. The description = of > the output > > 4) The 'average bandwidth since task start' is useful while the task is > running and as a final value when the task completes so it is assigned to > the report types 'running' and 'final'. > > 5) When the reports are sent from the MA, they indicate the report type. > This is where I suggested the 'tag' object in the report could be used. > > > > In the end I am asking about these three issues: > > 1) How does a task properly define multiple report types (tables)? > > 2) How does the MA identify the report type being sent? > > Even if #1 is addressed using multiple registry entries, and #2 is > addressed by including a reference to the registry entry in the > 'metric/uri' object of the task within the report, there is still this > issue: > > 3) How does the MA send multiple report types at the same time? My > understanding of the current report definition is that it limits each tas= k > to having one table definition per POST. The MA could send each table > definition to the collector separately but allowing each task to send an > array of table definitions would be more efficient. > > > > You brought up a fourth issue which is how the data in each table is > mapped to the registry. I have been making the assumption this was going > to be accomplished by setting the column header value in the report to on= e > of the summary/name values defined in the registry for the metric. > > > > Ron > > > > On Sun, Feb 14, 2016 at 11:11 AM, Carey, Timothy (Nokia - US) < > timothy.carey@nokia.com> wrote: > > Ron, > > > > The task has multiple registry entries =E2=80=93 I would assume your exam= ple is > that this task > > would have 3 registry entries. > > > > The columns are for the task and would have to have a union of all the > metrics for registry entries. =E2=80=93 Is this what you were asking? > > > > It seems that we lose the context of the registry entry to column though= =E2=80=A6 > > > > BR, > > Tim > > > > *From:* Ron Stana [mailto:ron.stana@viavisolutions.com] > *Sent:* Friday, February 12, 2016 4:31 PM > *To:* lmap@ietf.org > *Cc:* alissa@cooperw.in > *Subject:* [lmap] Support for multiple report table formats from one task > > > > LMAP Team, > > > > My understanding of the LMAP proposal is ietf-lmap-report:report/task/nam= e > is supposed to contain one of the values defined in > ietf-lmap-control:lmap/tasks/task/name. > > > > If this is correct, and since each task instance within a report can only > contain one table definition (one header + its row data) then how does a > task send multiple tables of results that contain different table formats= ? > > > > Use Cases: > > 1) Y.1564 task has results for the Service Configuration and the Service > Performance data, and each table has a different set of columns. > > 2) An RFC-2544 task would need a different table for the Throughput, > Latency, Frame Loss and Back to Back result sets. > > 3) Any task may want to send a minimal result set while it is executing > that is very different from the final result set when it has completed. > > > > The ietf-lmap-report:report/task/tag could be used to differentiate the > result sets sent by the same task. However this is not very efficient sin= ce > this approach requires the MA to send each report to the collector > separately because each report can only contain one set of results per ta= sk > name. > > > > Any guidance or clarification on the LMAP proposal would be appreciated, > > > > Ron > > > > > > > > > > > > > --001a11c26cca825054052be4322b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tim,

I am trying to determine how one t= ask can produce results that require multiple table formats (what I called = report types) and send them to the collector at the same time.=C2=A0 Most t= asks we have will require this type of functionality.

<= div>This is my understanding of what we have discussed so far:
1)= The registry would be used to define the different table formats...for the= purpose of this discussion let's go with your suggestion that there wo= uld be one entry for each table format.
2) The multiple registry = entries are then assigned to a single task using multiple instances of the = the lmap/tasks/task/metric object.=C2=A0
3) When the task goes to= send these different tables of results to the Collector, it identifies the= table that is being sent using a single instance of the the report/task/me= tric object.

If we agree thus far then the part th= at remains is how to send multiple tables to the collector at one time.=C2= =A0 The current report model only allows each task to have one entry so the= MA would have to POST a separate report for each table.=C2=A0 I am asking = if the tables could all be sent together. =C2=A0

R= on=C2=A0

On Tue, Feb 16, 2016 at 1:14 AM, Carey, Timothy (Nokia - US) <t= imothy.carey@nokia.com> wrote:

Ron,

=C2=A0=

I was thinking about= this some more last night.

=C2=A0=

Are you asking to ca= tegorize the reports by registry entry? - which I think you call report typ= e?=C2=A0 If so I don=E2=80=99t see an issue with that =E2=80=93 we can use = the registry entry as part of the report results=E2=80=A6=

=C2=A0=

BR,

Tim

=C2=A0=

From: Carey, T= imothy (Nokia - US)
Sent: Monday, February 15, 2016 10:31 PM
To: 'Ron Stana'
Cc: alissa@co= operw.in; lmap@ietf.= org
Subject: RE: [lmap] Support for multiple report table formats from o= ne task

=C2=A0

Ron,

=C2=A0=

I would talk to the = IPPM team then =E2=80=93 its really how they define the metrics that make u= p the registry.

=C2=A0=

As for a report per = task constraint =E2=80=93 I don=E2=80=99t know if saving inputs and outputs= as you suggest warrant breaking that constraint =E2=80=93 why not just hav= e 2 tasks and duplicate the registry entry.

=C2=A0=

I like the when the = task is complete =E2=80=93 generate the results for reporting and then repo= rt results based on the schedule to the collector. I know in our BBF implementation this works quite well.

=C2=A0=

Otherwise you get in= to the nasty problem of a state machine that correlates running the tests w= ith reporting results in the context of the overarching scheduled task (You call it running and final but there is a context to th= ose states for that particular task).

=C2=A0=

BR,

Tim

=C2=A0=

=C2=A0=

From: Ron Stan= a [mailto= :ron.stana@viavisolutions.com]
Sent: Monday, February 15, 2016 5:40 PM
To: Carey, Timothy (Nokia - US)
Cc: alissa@co= operw.in; lmap@ietf.org
Subject: Re: [lmap] Support for multiple report table formats from o= ne task

=C2=A0

Tim,

=C2=A0

While multiple registry entries could be used to def= ine each of the report types (table formats), this would require those regi= stry entries to replicate the inputs ('fixed parameters' in registr= y terms) and any outputs that are common across the different types.=C2=A0 It would be better to have one registry entry t= hat defined the inputs to the task once, all possible outputs once and then= allowed the outputs to be grouped into different report types. The report = type is just some string value. When the tables were sent from the MA to the Collector they would then just nee= d to include the report type. =C2=A0

=C2=A0

Example:

1) Task measures bandwidth for one or more streams

2) One registry entry is defined for the task. It in= cludes:

=C2=A0 =C2=A0 a) the numerous inputs that define the= stream's packet format

=C2=A0 =C2=A0 b) an output definition for the 'l= ast one second bandwidth'

=C2=A0 =C2=A0 c) an output definition for the 'a= verage bandwidth since task start'

3) The 'last one second bandwidth' is only u= seful while the task is running so it is assigned to the report type 'r= unning'.=C2=A0 The description of the output=C2=A0

4) The 'average bandwidth since task start' = is useful while the task is running and as a final value when the task comp= letes so it is assigned to the report types 'running' and 'fina= l'.

5) When the reports are sent from the MA, they indic= ate the report type. This is where I suggested the 'tag' object in = the report could be used.

=C2=A0

In the end I am asking about these three issues:<= /u>

1) How does a task properly define multiple report t= ypes (tables)?

2) How does the MA identify the report type being se= nt?

Even if #1 is addressed using multiple registry entr= ies, and #2 is addressed by including a reference to the registry entry in = the 'metric/uri' object of the task within the report, there is sti= ll this issue:

3) How does the MA send multiple report types at the= same time? My understanding of the current report definition is that it li= mits each task to having one table definition per POST.=C2=A0 The MA could = send each table definition to the collector separately but allowing each task to send an array of table definitions wo= uld be more efficient.

=C2=A0

You brought up a fourth issue which is how the data = in each table is mapped to the registry.=C2=A0 I have been making the assum= ption this was going to be accomplished by setting the column header value = in the report to one of the summary/name values defined in the registry for the metric.

=C2=A0

Ron

=C2=A0

On Sun, Feb 14, 2016 at 11:11 AM, Carey, Timothy (No= kia - US) <= timothy.carey@nokia.com> wrote:

Ron,

=C2=A0=

The task has multipl= e registry entries =E2=80=93 I would assume your example is that this task<= /span>

would have 3 registr= y entries.

=C2=A0=

The columns are for = the task and would have to have a union of all the metrics for registry entries. =E2=80=93 Is this what you were asking?

=C2=A0=

It seems that we los= e the context of the registry entry to column though=E2=80=A6=

=C2=A0=

BR,=

Tim=

=C2=A0=

From: Ron Stan= a [mailto:ron.stana@viavisolutions.com]
Sent: Friday, February 12, 2016 4:31 PM
To: lmap@ietf.org=
Cc: alissa@co= operw.in
Subject: [lmap] Support for multiple report table formats from one t= ask

=C2=A0

LMAP Team,

=C2=A0

My understanding of the LMAP proposal is ietf-lmap-r= eport:report/task/name is supposed to contain one of the values defined in = ietf-lmap-control:lmap/tasks/task/name.

=C2=A0

If this is correct, and since each task instance wit= hin a report can only contain one table definition (one header + its row da= ta) then how does a task send multiple tables of results that contain different table formats?

=C2=A0

Use Cases:

1) Y.1564 task has results for the Service Configura= tion and the Service Performance data, and each table has a different set o= f columns.

2) An RFC-2544 task would need a different table for= the Throughput, Latency, Frame Loss and Back to Back result sets.

3) Any task may want to send a minimal result set wh= ile it is executing that is very different from the final result set when i= t has completed.

=C2=A0

The ietf-lmap-report:report/task/tag could be used t= o differentiate the result sets sent by the same task. However this is not = very efficient since this approach requires the MA to send each report to the collector separately because each report can on= ly contain one set of results per task name.

=C2=A0

Any guidance or clarification on the LMAP proposal w= ould be appreciated,

=C2=A0

Ron

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--001a11c26cca825054052be4322b-- From nobody Tue Feb 16 06:54:53 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680141A9239 for ; Tue, 16 Feb 2016 06:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vgu3uAaXtAH5 for ; Tue, 16 Feb 2016 06:54:42 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A851A9238 for ; Tue, 16 Feb 2016 06:54:42 -0800 (PST) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 5EAA36573C4C; Tue, 16 Feb 2016 14:54:38 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u1GEse9h001708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Feb 2016 14:54:40 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u1GEsddb007821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Feb 2016 14:54:39 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.121]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 16 Feb 2016 09:54:39 -0500 From: "Carey, Timothy (Nokia - US)" To: EXT Ron Stana Thread-Topic: [lmap] Support for multiple report table formats from one task Thread-Index: AQHRZpkvpmDKnEpIoUqJmeiE7E+MV58tqpaggACGfbCAAOcogP//rGyA Date: Tue, 16 Feb 2016 14:54:38 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A5D2616@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A5CE3C2@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77012A5D0DBB@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A5D2616US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Cc: "alissa@cooperw.in" , "lmap@ietf.org" Subject: Re: [lmap] Support for multiple report table formats from one task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 14:54:51 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A5D2616US70UWXCHMBA0_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIDxUQUM+DQoNCg0KDQpGcm9tOiBFWFQgUm9uIFN0YW5hIFttYWlsdG86cm9uLnN0YW5h QHZpYXZpc29sdXRpb25zLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDE2LCAyMDE2IDI6 NDYgUE0NClRvOiBDYXJleSwgVGltb3RoeSAoTm9raWEgLSBVUykNCkNjOiBhbGlzc2FAY29vcGVy dy5pbjsgbG1hcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtsbWFwXSBTdXBwb3J0IGZvciBtdWx0 aXBsZSByZXBvcnQgdGFibGUgZm9ybWF0cyBmcm9tIG9uZSB0YXNrDQoNClRpbSwNCg0KSSBhbSB0 cnlpbmcgdG8gZGV0ZXJtaW5lIGhvdyBvbmUgdGFzayBjYW4gcHJvZHVjZSByZXN1bHRzIHRoYXQg cmVxdWlyZSBtdWx0aXBsZSB0YWJsZSBmb3JtYXRzICh3aGF0IEkgY2FsbGVkIHJlcG9ydCB0eXBl cykgYW5kIHNlbmQgdGhlbSB0byB0aGUgY29sbGVjdG9yIGF0IHRoZSBzYW1lIHRpbWUuICBNb3N0 IHRhc2tzIHdlIGhhdmUgd2lsbCByZXF1aXJlIHRoaXMgdHlwZSBvZiBmdW5jdGlvbmFsaXR5Lg0K DQpUaGlzIGlzIG15IHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCB3ZSBoYXZlIGRpc2N1c3NlZCBzbyBm YXI6DQoNCjEpICAgICAgVGhlIHJlZ2lzdHJ5IHdvdWxkIGJlIHVzZWQgdG8gZGVmaW5lIHRoZSBk aWZmZXJlbnQgdGFibGUgZm9ybWF0cy4uLmZvciB0aGUgcHVycG9zZSBvZiB0aGlzIGRpc2N1c3Np b24gbGV0J3MgZ28gd2l0aCB5b3VyIHN1Z2dlc3Rpb24gdGhhdCB0aGVyZSB3b3VsZCBiZSBvbmUg ZW50cnkgZm9yIGVhY2ggdGFibGUgZm9ybWF0Lg0KPFRBQz4gQWdyZWVkDQoNCjIpICAgICAgVGhl IG11bHRpcGxlIHJlZ2lzdHJ5IGVudHJpZXMgYXJlIHRoZW4gYXNzaWduZWQgdG8gYSBzaW5nbGUg dGFzayB1c2luZyBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHRoZSBsbWFwL3Rhc2tzL3Rhc2sv bWV0cmljIG9iamVjdC4NCjxUQUM+IEFncmVlZA0KMykgV2hlbiB0aGUgdGFzayBnb2VzIHRvIHNl bmQgdGhlc2UgZGlmZmVyZW50IHRhYmxlcyBvZiByZXN1bHRzIHRvIHRoZSBDb2xsZWN0b3IsIGl0 IGlkZW50aWZpZXMgdGhlIHRhYmxlIHRoYXQgaXMgYmVpbmcgc2VudCB1c2luZyBhIHNpbmdsZSBp bnN0YW5jZSBvZiB0aGUgdGhlIHJlcG9ydC90YXNrL21ldHJpYyBvYmplY3QuDQo8VEFDPiBBZ3Jl ZWQNCg0KSWYgd2UgYWdyZWUgdGh1cyBmYXIgdGhlbiB0aGUgcGFydCB0aGF0IHJlbWFpbnMgaXMg aG93IHRvIHNlbmQgbXVsdGlwbGUgdGFibGVzIHRvIHRoZSBjb2xsZWN0b3IgYXQgb25lIHRpbWUu ICBUaGUgY3VycmVudCByZXBvcnQgbW9kZWwgb25seSBhbGxvd3MgZWFjaCB0YXNrIHRvIGhhdmUg b25lIGVudHJ5IHNvIHRoZSBNQSB3b3VsZCBoYXZlIHRvIFBPU1QgYSBzZXBhcmF0ZSByZXBvcnQg Zm9yIGVhY2ggdGFibGUuICBJIGFtIGFza2luZyBpZiB0aGUgdGFibGVzIGNvdWxkIGFsbCBiZSBz ZW50IHRvZ2V0aGVyLg0KPFRBQz4gQ29ycmVjdCDigJMgdGhlIGluZm9ybWF0aW9uIG1vZGVsIGZv ciB0aGUgcmVwb3J0IG9iamVjdCB3b3VsZCBuZWVkIHRvIGJlIG1vZGlmaWVkIGFuZCByZW9yZ2Fu aXplZCB0b2Z1cnRoZXIgcXVhbGlmeSB0aGUgcmVzdWx0cyBieSB0aGUgbWV0cmljIChyZWdpc3Ry eSBlbnRyeSkgaW4gYWRkaXRpb24gdG8gdGhlIHRhc2sgbmFtZS4NClJvbg0KDQpPbiBUdWUsIEZl YiAxNiwgMjAxNiBhdCAxOjE0IEFNLCBDYXJleSwgVGltb3RoeSAoTm9raWEgLSBVUykgPHRpbW90 aHkuY2FyZXlAbm9raWEuY29tPG1haWx0bzp0aW1vdGh5LmNhcmV5QG5va2lhLmNvbT4+IHdyb3Rl Og0KUm9uLA0KDQpJIHdhcyB0aGlua2luZyBhYm91dCB0aGlzIHNvbWUgbW9yZSBsYXN0IG5pZ2h0 Lg0KDQpBcmUgeW91IGFza2luZyB0byBjYXRlZ29yaXplIHRoZSByZXBvcnRzIGJ5IHJlZ2lzdHJ5 IGVudHJ5PyAtIHdoaWNoIEkgdGhpbmsgeW91IGNhbGwgcmVwb3J0IHR5cGU/ICBJZiBzbyBJIGRv buKAmXQgc2VlIGFuIGlzc3VlIHdpdGggdGhhdCDigJMgd2UgY2FuIHVzZSB0aGUgcmVnaXN0cnkg ZW50cnkgYXMgcGFydCBvZiB0aGUgcmVwb3J0IHJlc3VsdHPigKYNCg0KQlIsDQpUaW0NCg0KRnJv bTogQ2FyZXksIFRpbW90aHkgKE5va2lhIC0gVVMpDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE1 LCAyMDE2IDEwOjMxIFBNDQpUbzogJ1JvbiBTdGFuYScNCkNjOiBhbGlzc2FAY29vcGVydy5pbjxt YWlsdG86YWxpc3NhQGNvb3BlcncuaW4+OyBsbWFwQGlldGYub3JnPG1haWx0bzpsbWFwQGlldGYu b3JnPg0KU3ViamVjdDogUkU6IFtsbWFwXSBTdXBwb3J0IGZvciBtdWx0aXBsZSByZXBvcnQgdGFi bGUgZm9ybWF0cyBmcm9tIG9uZSB0YXNrDQoNClJvbiwNCg0KSSB3b3VsZCB0YWxrIHRvIHRoZSBJ UFBNIHRlYW0gdGhlbiDigJMgaXRzIHJlYWxseSBob3cgdGhleSBkZWZpbmUgdGhlIG1ldHJpY3Mg dGhhdCBtYWtlIHVwIHRoZSByZWdpc3RyeS4NCg0KQXMgZm9yIGEgcmVwb3J0IHBlciB0YXNrIGNv bnN0cmFpbnQg4oCTIEkgZG9u4oCZdCBrbm93IGlmIHNhdmluZyBpbnB1dHMgYW5kIG91dHB1dHMg YXMgeW91IHN1Z2dlc3Qgd2FycmFudCBicmVha2luZyB0aGF0IGNvbnN0cmFpbnQg4oCTIHdoeSBu b3QganVzdCBoYXZlIDIgdGFza3MgYW5kIGR1cGxpY2F0ZSB0aGUgcmVnaXN0cnkgZW50cnkuDQoN CkkgbGlrZSB0aGUgd2hlbiB0aGUgdGFzayBpcyBjb21wbGV0ZSDigJMgZ2VuZXJhdGUgdGhlIHJl c3VsdHMgZm9yIHJlcG9ydGluZyBhbmQgdGhlbiByZXBvcnQgcmVzdWx0cyBiYXNlZCBvbiB0aGUg c2NoZWR1bGUgdG8gdGhlIGNvbGxlY3Rvci4gSSBrbm93IGluIG91ciBCQkYgaW1wbGVtZW50YXRp b24gdGhpcyB3b3JrcyBxdWl0ZSB3ZWxsLg0KDQpPdGhlcndpc2UgeW91IGdldCBpbnRvIHRoZSBu YXN0eSBwcm9ibGVtIG9mIGEgc3RhdGUgbWFjaGluZSB0aGF0IGNvcnJlbGF0ZXMgcnVubmluZyB0 aGUgdGVzdHMgd2l0aCByZXBvcnRpbmcgcmVzdWx0cyBpbiB0aGUgY29udGV4dCBvZiB0aGUgb3Zl cmFyY2hpbmcgc2NoZWR1bGVkIHRhc2sgKFlvdSBjYWxsIGl0IHJ1bm5pbmcgYW5kIGZpbmFsIGJ1 dCB0aGVyZSBpcyBhIGNvbnRleHQgdG8gdGhvc2Ugc3RhdGVzIGZvciB0aGF0IHBhcnRpY3VsYXIg dGFzaykuDQoNCkJSLA0KVGltDQoNCg0KRnJvbTogUm9uIFN0YW5hIFttYWlsdG86cm9uLnN0YW5h QHZpYXZpc29sdXRpb25zLmNvbV0NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTUsIDIwMTYgNTo0 MCBQTQ0KVG86IENhcmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKQ0KQ2M6IGFsaXNzYUBjb29wZXJ3 LmluPG1haWx0bzphbGlzc2FAY29vcGVydy5pbj47IGxtYXBAaWV0Zi5vcmc8bWFpbHRvOmxtYXBA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2xtYXBdIFN1cHBvcnQgZm9yIG11bHRpcGxlIHJlcG9y dCB0YWJsZSBmb3JtYXRzIGZyb20gb25lIHRhc2sNCg0KVGltLA0KDQpXaGlsZSBtdWx0aXBsZSBy ZWdpc3RyeSBlbnRyaWVzIGNvdWxkIGJlIHVzZWQgdG8gZGVmaW5lIGVhY2ggb2YgdGhlIHJlcG9y dCB0eXBlcyAodGFibGUgZm9ybWF0cyksIHRoaXMgd291bGQgcmVxdWlyZSB0aG9zZSByZWdpc3Ry eSBlbnRyaWVzIHRvIHJlcGxpY2F0ZSB0aGUgaW5wdXRzICgnZml4ZWQgcGFyYW1ldGVycycgaW4g cmVnaXN0cnkgdGVybXMpIGFuZCBhbnkgb3V0cHV0cyB0aGF0IGFyZSBjb21tb24gYWNyb3NzIHRo ZSBkaWZmZXJlbnQgdHlwZXMuICBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gaGF2ZSBvbmUgcmVnaXN0 cnkgZW50cnkgdGhhdCBkZWZpbmVkIHRoZSBpbnB1dHMgdG8gdGhlIHRhc2sgb25jZSwgYWxsIHBv c3NpYmxlIG91dHB1dHMgb25jZSBhbmQgdGhlbiBhbGxvd2VkIHRoZSBvdXRwdXRzIHRvIGJlIGdy b3VwZWQgaW50byBkaWZmZXJlbnQgcmVwb3J0IHR5cGVzLiBUaGUgcmVwb3J0IHR5cGUgaXMganVz dCBzb21lIHN0cmluZyB2YWx1ZS4gV2hlbiB0aGUgdGFibGVzIHdlcmUgc2VudCBmcm9tIHRoZSBN QSB0byB0aGUgQ29sbGVjdG9yIHRoZXkgd291bGQgdGhlbiBqdXN0IG5lZWQgdG8gaW5jbHVkZSB0 aGUgcmVwb3J0IHR5cGUuDQoNCkV4YW1wbGU6DQoxKSBUYXNrIG1lYXN1cmVzIGJhbmR3aWR0aCBm b3Igb25lIG9yIG1vcmUgc3RyZWFtcw0KMikgT25lIHJlZ2lzdHJ5IGVudHJ5IGlzIGRlZmluZWQg Zm9yIHRoZSB0YXNrLiBJdCBpbmNsdWRlczoNCiAgICBhKSB0aGUgbnVtZXJvdXMgaW5wdXRzIHRo YXQgZGVmaW5lIHRoZSBzdHJlYW0ncyBwYWNrZXQgZm9ybWF0DQogICAgYikgYW4gb3V0cHV0IGRl ZmluaXRpb24gZm9yIHRoZSAnbGFzdCBvbmUgc2Vjb25kIGJhbmR3aWR0aCcNCiAgICBjKSBhbiBv dXRwdXQgZGVmaW5pdGlvbiBmb3IgdGhlICdhdmVyYWdlIGJhbmR3aWR0aCBzaW5jZSB0YXNrIHN0 YXJ0Jw0KMykgVGhlICdsYXN0IG9uZSBzZWNvbmQgYmFuZHdpZHRoJyBpcyBvbmx5IHVzZWZ1bCB3 aGlsZSB0aGUgdGFzayBpcyBydW5uaW5nIHNvIGl0IGlzIGFzc2lnbmVkIHRvIHRoZSByZXBvcnQg dHlwZSAncnVubmluZycuICBUaGUgZGVzY3JpcHRpb24gb2YgdGhlIG91dHB1dA0KNCkgVGhlICdh dmVyYWdlIGJhbmR3aWR0aCBzaW5jZSB0YXNrIHN0YXJ0JyBpcyB1c2VmdWwgd2hpbGUgdGhlIHRh c2sgaXMgcnVubmluZyBhbmQgYXMgYSBmaW5hbCB2YWx1ZSB3aGVuIHRoZSB0YXNrIGNvbXBsZXRl cyBzbyBpdCBpcyBhc3NpZ25lZCB0byB0aGUgcmVwb3J0IHR5cGVzICdydW5uaW5nJyBhbmQgJ2Zp bmFsJy4NCjUpIFdoZW4gdGhlIHJlcG9ydHMgYXJlIHNlbnQgZnJvbSB0aGUgTUEsIHRoZXkgaW5k aWNhdGUgdGhlIHJlcG9ydCB0eXBlLiBUaGlzIGlzIHdoZXJlIEkgc3VnZ2VzdGVkIHRoZSAndGFn JyBvYmplY3QgaW4gdGhlIHJlcG9ydCBjb3VsZCBiZSB1c2VkLg0KDQpJbiB0aGUgZW5kIEkgYW0g YXNraW5nIGFib3V0IHRoZXNlIHRocmVlIGlzc3VlczoNCjEpIEhvdyBkb2VzIGEgdGFzayBwcm9w ZXJseSBkZWZpbmUgbXVsdGlwbGUgcmVwb3J0IHR5cGVzICh0YWJsZXMpPw0KMikgSG93IGRvZXMg dGhlIE1BIGlkZW50aWZ5IHRoZSByZXBvcnQgdHlwZSBiZWluZyBzZW50Pw0KRXZlbiBpZiAjMSBp cyBhZGRyZXNzZWQgdXNpbmcgbXVsdGlwbGUgcmVnaXN0cnkgZW50cmllcywgYW5kICMyIGlzIGFk ZHJlc3NlZCBieSBpbmNsdWRpbmcgYSByZWZlcmVuY2UgdG8gdGhlIHJlZ2lzdHJ5IGVudHJ5IGlu IHRoZSAnbWV0cmljL3VyaScgb2JqZWN0IG9mIHRoZSB0YXNrIHdpdGhpbiB0aGUgcmVwb3J0LCB0 aGVyZSBpcyBzdGlsbCB0aGlzIGlzc3VlOg0KMykgSG93IGRvZXMgdGhlIE1BIHNlbmQgbXVsdGlw bGUgcmVwb3J0IHR5cGVzIGF0IHRoZSBzYW1lIHRpbWU/IE15IHVuZGVyc3RhbmRpbmcgb2YgdGhl IGN1cnJlbnQgcmVwb3J0IGRlZmluaXRpb24gaXMgdGhhdCBpdCBsaW1pdHMgZWFjaCB0YXNrIHRv IGhhdmluZyBvbmUgdGFibGUgZGVmaW5pdGlvbiBwZXIgUE9TVC4gIFRoZSBNQSBjb3VsZCBzZW5k IGVhY2ggdGFibGUgZGVmaW5pdGlvbiB0byB0aGUgY29sbGVjdG9yIHNlcGFyYXRlbHkgYnV0IGFs bG93aW5nIGVhY2ggdGFzayB0byBzZW5kIGFuIGFycmF5IG9mIHRhYmxlIGRlZmluaXRpb25zIHdv dWxkIGJlIG1vcmUgZWZmaWNpZW50Lg0KDQpZb3UgYnJvdWdodCB1cCBhIGZvdXJ0aCBpc3N1ZSB3 aGljaCBpcyBob3cgdGhlIGRhdGEgaW4gZWFjaCB0YWJsZSBpcyBtYXBwZWQgdG8gdGhlIHJlZ2lz dHJ5LiAgSSBoYXZlIGJlZW4gbWFraW5nIHRoZSBhc3N1bXB0aW9uIHRoaXMgd2FzIGdvaW5nIHRv IGJlIGFjY29tcGxpc2hlZCBieSBzZXR0aW5nIHRoZSBjb2x1bW4gaGVhZGVyIHZhbHVlIGluIHRo ZSByZXBvcnQgdG8gb25lIG9mIHRoZSBzdW1tYXJ5L25hbWUgdmFsdWVzIGRlZmluZWQgaW4gdGhl IHJlZ2lzdHJ5IGZvciB0aGUgbWV0cmljLg0KDQpSb24NCg0KT24gU3VuLCBGZWIgMTQsIDIwMTYg YXQgMTE6MTEgQU0sIENhcmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKSA8dGltb3RoeS5jYXJleUBu b2tpYS5jb208bWFpbHRvOnRpbW90aHkuY2FyZXlAbm9raWEuY29tPj4gd3JvdGU6DQpSb24sDQoN ClRoZSB0YXNrIGhhcyBtdWx0aXBsZSByZWdpc3RyeSBlbnRyaWVzIOKAkyBJIHdvdWxkIGFzc3Vt ZSB5b3VyIGV4YW1wbGUgaXMgdGhhdCB0aGlzIHRhc2sNCndvdWxkIGhhdmUgMyByZWdpc3RyeSBl bnRyaWVzLg0KDQpUaGUgY29sdW1ucyBhcmUgZm9yIHRoZSB0YXNrIGFuZCB3b3VsZCBoYXZlIHRv IGhhdmUgYSB1bmlvbiBvZiBhbGwgdGhlIG1ldHJpY3MgZm9yIHJlZ2lzdHJ5IGVudHJpZXMuIOKA kyBJcyB0aGlzIHdoYXQgeW91IHdlcmUgYXNraW5nPw0KDQpJdCBzZWVtcyB0aGF0IHdlIGxvc2Ug dGhlIGNvbnRleHQgb2YgdGhlIHJlZ2lzdHJ5IGVudHJ5IHRvIGNvbHVtbiB0aG91Z2jigKYNCg0K QlIsDQpUaW0NCg0KRnJvbTogUm9uIFN0YW5hIFttYWlsdG86cm9uLnN0YW5hQHZpYXZpc29sdXRp b25zLmNvbTxtYWlsdG86cm9uLnN0YW5hQHZpYXZpc29sdXRpb25zLmNvbT5dDQpTZW50OiBGcmlk YXksIEZlYnJ1YXJ5IDEyLCAyMDE2IDQ6MzEgUE0NClRvOiBsbWFwQGlldGYub3JnPG1haWx0bzps bWFwQGlldGYub3JnPg0KQ2M6IGFsaXNzYUBjb29wZXJ3LmluPG1haWx0bzphbGlzc2FAY29vcGVy dy5pbj4NClN1YmplY3Q6IFtsbWFwXSBTdXBwb3J0IGZvciBtdWx0aXBsZSByZXBvcnQgdGFibGUg Zm9ybWF0cyBmcm9tIG9uZSB0YXNrDQoNCkxNQVAgVGVhbSwNCg0KTXkgdW5kZXJzdGFuZGluZyBv ZiB0aGUgTE1BUCBwcm9wb3NhbCBpcyBpZXRmLWxtYXAtcmVwb3J0OnJlcG9ydC90YXNrL25hbWUg aXMgc3VwcG9zZWQgdG8gY29udGFpbiBvbmUgb2YgdGhlIHZhbHVlcyBkZWZpbmVkIGluIGlldGYt bG1hcC1jb250cm9sOmxtYXAvdGFza3MvdGFzay9uYW1lLg0KDQpJZiB0aGlzIGlzIGNvcnJlY3Qs IGFuZCBzaW5jZSBlYWNoIHRhc2sgaW5zdGFuY2Ugd2l0aGluIGEgcmVwb3J0IGNhbiBvbmx5IGNv bnRhaW4gb25lIHRhYmxlIGRlZmluaXRpb24gKG9uZSBoZWFkZXIgKyBpdHMgcm93IGRhdGEpIHRo ZW4gaG93IGRvZXMgYSB0YXNrIHNlbmQgbXVsdGlwbGUgdGFibGVzIG9mIHJlc3VsdHMgdGhhdCBj b250YWluIGRpZmZlcmVudCB0YWJsZSBmb3JtYXRzPw0KDQpVc2UgQ2FzZXM6DQoxKSBZLjE1NjQg dGFzayBoYXMgcmVzdWx0cyBmb3IgdGhlIFNlcnZpY2UgQ29uZmlndXJhdGlvbiBhbmQgdGhlIFNl cnZpY2UgUGVyZm9ybWFuY2UgZGF0YSwgYW5kIGVhY2ggdGFibGUgaGFzIGEgZGlmZmVyZW50IHNl dCBvZiBjb2x1bW5zLg0KMikgQW4gUkZDLTI1NDQgdGFzayB3b3VsZCBuZWVkIGEgZGlmZmVyZW50 IHRhYmxlIGZvciB0aGUgVGhyb3VnaHB1dCwgTGF0ZW5jeSwgRnJhbWUgTG9zcyBhbmQgQmFjayB0 byBCYWNrIHJlc3VsdCBzZXRzLg0KMykgQW55IHRhc2sgbWF5IHdhbnQgdG8gc2VuZCBhIG1pbmlt YWwgcmVzdWx0IHNldCB3aGlsZSBpdCBpcyBleGVjdXRpbmcgdGhhdCBpcyB2ZXJ5IGRpZmZlcmVu dCBmcm9tIHRoZSBmaW5hbCByZXN1bHQgc2V0IHdoZW4gaXQgaGFzIGNvbXBsZXRlZC4NCg0KVGhl IGlldGYtbG1hcC1yZXBvcnQ6cmVwb3J0L3Rhc2svdGFnIGNvdWxkIGJlIHVzZWQgdG8gZGlmZmVy ZW50aWF0ZSB0aGUgcmVzdWx0IHNldHMgc2VudCBieSB0aGUgc2FtZSB0YXNrLiBIb3dldmVyIHRo aXMgaXMgbm90IHZlcnkgZWZmaWNpZW50IHNpbmNlIHRoaXMgYXBwcm9hY2ggcmVxdWlyZXMgdGhl IE1BIHRvIHNlbmQgZWFjaCByZXBvcnQgdG8gdGhlIGNvbGxlY3RvciBzZXBhcmF0ZWx5IGJlY2F1 c2UgZWFjaCByZXBvcnQgY2FuIG9ubHkgY29udGFpbiBvbmUgc2V0IG9mIHJlc3VsdHMgcGVyIHRh c2sgbmFtZS4NCg0KQW55IGd1aWRhbmNlIG9yIGNsYXJpZmljYXRpb24gb24gdGhlIExNQVAgcHJv cG9zYWwgd291bGQgYmUgYXBwcmVjaWF0ZWQsDQoNClJvbg0KDQoNCg0KDQoNCg0KDQo= --_000_9966516C6EB5FC4381E05BF80AA55F77012A5D2616US70UWXCHMBA0_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1T IjsNCglwYW5vc2UtMToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTUzNTQ2MTk4 Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMDM3OTQ0 NzM2IDY3Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Oi4yNWluOw0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0 IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW5saW5lICZs dDtUQUMmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1T JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEVY VCBSb24gU3RhbmEgW21haWx0bzpyb24uc3RhbmFAdmlhdmlzb2x1dGlvbnMuY29tXQ0KPGJyPg0K PGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDE2LCAyMDE2IDI6NDYgUE08YnI+DQo8Yj5U bzo8L2I+IENhcmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKTxicj4NCjxiPkNjOjwvYj4gYWxpc3Nh QGNvb3BlcncuaW47IGxtYXBAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtsbWFw XSBTdXBwb3J0IGZvciBtdWx0aXBsZSByZXBvcnQgdGFibGUgZm9ybWF0cyBmcm9tIG9uZSB0YXNr PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaW0sPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIHRyeWluZyB0byBk ZXRlcm1pbmUgaG93IG9uZSB0YXNrIGNhbiBwcm9kdWNlIHJlc3VsdHMgdGhhdCByZXF1aXJlIG11 bHRpcGxlIHRhYmxlIGZvcm1hdHMgKHdoYXQgSSBjYWxsZWQgcmVwb3J0IHR5cGVzKSBhbmQgc2Vu ZCB0aGVtIHRvIHRoZSBjb2xsZWN0b3IgYXQgdGhlIHNhbWUgdGltZS4mbmJzcDsgTW9zdCB0YXNr cyB3ZSBoYXZlIHdpbGwgcmVxdWlyZSB0aGlzIHR5cGUgb2YgZnVuY3Rpb25hbGl0eS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBt eSB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgd2UgaGF2ZSBkaXNjdXNzZWQgc28gZmFyOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDouMjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+MSk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ VGhlIHJlZ2lzdHJ5IHdvdWxkIGJlIHVzZWQgdG8gZGVmaW5lIHRoZSBkaWZmZXJlbnQgdGFibGUg Zm9ybWF0cy4uLmZvciB0aGUgcHVycG9zZSBvZiB0aGlzIGRpc2N1c3Npb24gbGV0J3MgZ28gd2l0 aCB5b3VyIHN1Z2dlc3Rpb24gdGhhdCB0aGVyZSB3b3VsZCBiZSBvbmUgZW50cnkgZm9yIGVhY2gg dGFibGUgZm9ybWF0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDtUQUMmZ3Q7IEFncmVlZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PjIpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRo ZSBtdWx0aXBsZSByZWdpc3RyeSBlbnRyaWVzIGFyZSB0aGVuIGFzc2lnbmVkIHRvIGEgc2luZ2xl IHRhc2sgdXNpbmcgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSB0aGUgbG1hcC90YXNrcy90YXNr L21ldHJpYyBvYmplY3QuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0O1RBQyZndDsgQWdyZWVkPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MykgV2hl biB0aGUgdGFzayBnb2VzIHRvIHNlbmQgdGhlc2UgZGlmZmVyZW50IHRhYmxlcyBvZiByZXN1bHRz IHRvIHRoZSBDb2xsZWN0b3IsIGl0IGlkZW50aWZpZXMgdGhlIHRhYmxlIHRoYXQgaXMgYmVpbmcg c2VudCB1c2luZyBhIHNpbmdsZSBpbnN0YW5jZSBvZiB0aGUgdGhlIHJlcG9ydC90YXNrL21ldHJp YyBvYmplY3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0O1RBQyZndDsgQWdyZWVkPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2UgYWdyZWUgdGh1cyBm YXIgdGhlbiB0aGUgcGFydCB0aGF0IHJlbWFpbnMgaXMgaG93IHRvIHNlbmQgbXVsdGlwbGUgdGFi bGVzIHRvIHRoZSBjb2xsZWN0b3IgYXQgb25lIHRpbWUuJm5ic3A7IFRoZSBjdXJyZW50IHJlcG9y dCBtb2RlbCBvbmx5IGFsbG93cyBlYWNoIHRhc2sgdG8gaGF2ZSBvbmUgZW50cnkgc28gdGhlIE1B IHdvdWxkIGhhdmUgdG8gUE9TVCBhIHNlcGFyYXRlIHJlcG9ydCBmb3IgZWFjaCB0YWJsZS4mbmJz cDsNCiBJIGFtIGFza2luZyBpZiB0aGUgdGFibGVzIGNvdWxkIGFsbCBiZSBzZW50IHRvZ2V0aGVy LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbHQ7VEFDJmd0OyBDb3JyZWN0IOKAkyB0 aGUgaW5mb3JtYXRpb24gbW9kZWwgZm9yIHRoZSByZXBvcnQgb2JqZWN0IHdvdWxkIG5lZWQgdG8g YmUgbW9kaWZpZWQgYW5kIHJlb3JnYW5pemVkIHRvZnVydGhlciBxdWFsaWZ5IHRoZSByZXN1bHRz IGJ5IHRoZSBtZXRyaWMgKHJlZ2lzdHJ5IGVudHJ5KSBpbiBhZGRpdGlvbiB0byB0aGUgdGFzayBu YW1lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJvbiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiAxNiwgMjAxNiBhdCAxOjE0IEFNLCBDYXJleSwgVGlt b3RoeSAoTm9raWEgLSBVUykgJmx0OzxhIGhyZWY9Im1haWx0bzp0aW1vdGh5LmNhcmV5QG5va2lh LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpbW90aHkuY2FyZXlAbm9raWEuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0 IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9uLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JIHdhcyB0aGlua2luZyBhYm91dCB0aGlzIHNvbWUgbW9yZSBs YXN0IG5pZ2h0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0 IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcmUgeW91IGFza2luZyB0byBjYXRl Z29yaXplIHRoZSByZXBvcnRzIGJ5IHJlZ2lzdHJ5IGVudHJ5PyAtIHdoaWNoIEkgdGhpbmsgeW91 IGNhbGwgcmVwb3J0DQogdHlwZT8mbmJzcDsgSWYgc28gSSBkb27igJl0IHNlZSBhbiBpc3N1ZSB3 aXRoIHRoYXQg4oCTIHdlIGNhbiB1c2UgdGhlIHJlZ2lzdHJ5IGVudHJ5IGFzIHBhcnQgb2YgdGhl IHJlcG9ydCByZXN1bHRz4oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtU cmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGltPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gQ2FyZXksIFRpbW90aHkgKE5va2lhIC0gVVMpDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBGZWJydWFyeSAxNSwgMjAxNiAxMDozMSBQTTxicj4NCjxiPlRvOjwvYj4gJ1JvbiBTdGFuYSc8 YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzphbGlzc2FAY29vcGVydy5pbiIgdGFyZ2V0 PSJfYmxhbmsiPmFsaXNzYUBjb29wZXJ3LmluPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpsbWFwQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bG1hcEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUkU6IFtsbWFwXSBTdXBwb3J0IGZvciBtdWx0aXBsZSByZXBvcnQgdGFibGUgZm9ybWF0 cyBmcm9tIG9uZSB0YXNrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlJvbiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3b3VsZCB0YWxrIHRvIHRoZSBJUFBNIHRl YW0gdGhlbiDigJMgaXRzIHJlYWxseSBob3cgdGhleSBkZWZpbmUgdGhlIG1ldHJpY3MgdGhhdCBt YWtlIHVwIHRoZQ0KIHJlZ2lzdHJ5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQg TVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBmb3IgYSBy ZXBvcnQgcGVyIHRhc2sgY29uc3RyYWludCDigJMgSSBkb27igJl0IGtub3cgaWYgc2F2aW5nIGlu cHV0cyBhbmQgb3V0cHV0cyBhcyB5b3Ugc3VnZ2VzdA0KIHdhcnJhbnQgYnJlYWtpbmcgdGhhdCBj b25zdHJhaW50IOKAkyB3aHkgbm90IGp1c3QgaGF2ZSAyIHRhc2tzIGFuZCBkdXBsaWNhdGUgdGhl IHJlZ2lzdHJ5IGVudHJ5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJl YnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGxpa2UgdGhlIHdoZW4g dGhlIHRhc2sgaXMgY29tcGxldGUg4oCTIGdlbmVyYXRlIHRoZSByZXN1bHRzIGZvciByZXBvcnRp bmcgYW5kIHRoZW4gcmVwb3J0IHJlc3VsdHMNCiBiYXNlZCBvbiB0aGUgc2NoZWR1bGUgdG8gdGhl IGNvbGxlY3Rvci4gSSBrbm93IGluIG91ciBCQkYgaW1wbGVtZW50YXRpb24gdGhpcyB3b3JrcyBx dWl0ZSB3ZWxsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0 IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PdGhlcndpc2UgeW91IGdldCBpbnRv IHRoZSBuYXN0eSBwcm9ibGVtIG9mIGEgc3RhdGUgbWFjaGluZSB0aGF0IGNvcnJlbGF0ZXMgcnVu bmluZyB0aGUgdGVzdHMNCiB3aXRoIHJlcG9ydGluZyByZXN1bHRzIGluIHRoZSBjb250ZXh0IG9m IHRoZSBvdmVyYXJjaGluZyBzY2hlZHVsZWQgdGFzayAoWW91IGNhbGwgaXQgcnVubmluZyBhbmQg ZmluYWwgYnV0IHRoZXJlIGlzIGEgY29udGV4dCB0byB0aG9zZSBzdGF0ZXMgZm9yIHRoYXQgcGFy dGljdWxhciB0YXNrKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1 Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QlIsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaW08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVj aGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUm9uIFN0YW5hIFs8YSBocmVmPSJt YWlsdG86cm9uLnN0YW5hQHZpYXZpc29sdXRpb25zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0 bzpyb24uc3RhbmFAdmlhdmlzb2x1dGlvbnMuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBN b25kYXksIEZlYnJ1YXJ5IDE1LCAyMDE2IDU6NDAgUE08YnI+DQo8Yj5Ubzo8L2I+IENhcmV5LCBU aW1vdGh5IChOb2tpYSAtIFVTKTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmFsaXNz YUBjb29wZXJ3LmluIiB0YXJnZXQ9Il9ibGFuayI+YWxpc3NhQGNvb3BlcncuaW48L2E+Ow0KPGEg aHJlZj0ibWFpbHRvOmxtYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sbWFwQGlldGYub3Jn PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2xtYXBdIFN1cHBvcnQgZm9yIG11bHRpcGxl IHJlcG9ydCB0YWJsZSBmb3JtYXRzIGZyb20gb25lIHRhc2s8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaW0sPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hpbGUgbXVsdGlwbGUgcmVnaXN0cnkgZW50cmll cyBjb3VsZCBiZSB1c2VkIHRvIGRlZmluZSBlYWNoIG9mIHRoZSByZXBvcnQgdHlwZXMgKHRhYmxl IGZvcm1hdHMpLCB0aGlzIHdvdWxkIHJlcXVpcmUgdGhvc2UgcmVnaXN0cnkgZW50cmllcyB0byBy ZXBsaWNhdGUgdGhlIGlucHV0cyAoJ2ZpeGVkIHBhcmFtZXRlcnMnDQogaW4gcmVnaXN0cnkgdGVy bXMpIGFuZCBhbnkgb3V0cHV0cyB0aGF0IGFyZSBjb21tb24gYWNyb3NzIHRoZSBkaWZmZXJlbnQg dHlwZXMuJm5ic3A7IEl0IHdvdWxkIGJlIGJldHRlciB0byBoYXZlIG9uZSByZWdpc3RyeSBlbnRy eSB0aGF0IGRlZmluZWQgdGhlIGlucHV0cyB0byB0aGUgdGFzayBvbmNlLCBhbGwgcG9zc2libGUg b3V0cHV0cyBvbmNlIGFuZCB0aGVuIGFsbG93ZWQgdGhlIG91dHB1dHMgdG8gYmUgZ3JvdXBlZCBp bnRvIGRpZmZlcmVudCByZXBvcnQNCiB0eXBlcy4gVGhlIHJlcG9ydCB0eXBlIGlzIGp1c3Qgc29t ZSBzdHJpbmcgdmFsdWUuIFdoZW4gdGhlIHRhYmxlcyB3ZXJlIHNlbnQgZnJvbSB0aGUgTUEgdG8g dGhlIENvbGxlY3RvciB0aGV5IHdvdWxkIHRoZW4ganVzdCBuZWVkIHRvIGluY2x1ZGUgdGhlIHJl cG9ydCB0eXBlLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkV4YW1wbGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEpIFRhc2sgbWVhc3VyZXMgYmFuZHdpZHRoIGZvciBv bmUgb3IgbW9yZSBzdHJlYW1zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjIpIE9uZSByZWdpc3RyeSBlbnRyeSBpcyBkZWZpbmVkIGZvciB0aGUg dGFzay4gSXQgaW5jbHVkZXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgYSkgdGhlIG51bWVyb3VzIGlucHV0cyB0aGF0 IGRlZmluZSB0aGUgc3RyZWFtJ3MgcGFja2V0IGZvcm1hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IGIpIGFuIG91dHB1 dCBkZWZpbml0aW9uIGZvciB0aGUgJ2xhc3Qgb25lIHNlY29uZCBiYW5kd2lkdGgnPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJz cDsgYykgYW4gb3V0cHV0IGRlZmluaXRpb24gZm9yIHRoZSAnYXZlcmFnZSBiYW5kd2lkdGggc2lu Y2UgdGFzayBzdGFydCc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+MykgVGhlICdsYXN0IG9uZSBzZWNvbmQgYmFuZHdpZHRoJyBpcyBvbmx5IHVz ZWZ1bCB3aGlsZSB0aGUgdGFzayBpcyBydW5uaW5nIHNvIGl0IGlzIGFzc2lnbmVkIHRvIHRoZSBy ZXBvcnQgdHlwZSAncnVubmluZycuJm5ic3A7IFRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgb3V0cHV0 Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjQpIFRoZSAnYXZlcmFnZSBiYW5kd2lkdGggc2luY2UgdGFzayBzdGFydCcgaXMgdXNlZnVs IHdoaWxlIHRoZSB0YXNrIGlzIHJ1bm5pbmcgYW5kIGFzIGEgZmluYWwgdmFsdWUgd2hlbiB0aGUg dGFzayBjb21wbGV0ZXMgc28gaXQgaXMgYXNzaWduZWQgdG8gdGhlIHJlcG9ydCB0eXBlcyAncnVu bmluZycgYW5kDQogJ2ZpbmFsJy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+NSkgV2hlbiB0aGUgcmVwb3J0cyBhcmUgc2VudCBmcm9tIHRoZSBN QSwgdGhleSBpbmRpY2F0ZSB0aGUgcmVwb3J0IHR5cGUuIFRoaXMgaXMgd2hlcmUgSSBzdWdnZXN0 ZWQgdGhlICd0YWcnIG9iamVjdCBpbiB0aGUgcmVwb3J0IGNvdWxkIGJlIHVzZWQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiB0aGUg ZW5kIEkgYW0gYXNraW5nIGFib3V0IHRoZXNlIHRocmVlIGlzc3Vlczo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MSkgSG93IGRvZXMgYSB0YXNr IHByb3Blcmx5IGRlZmluZSBtdWx0aXBsZSByZXBvcnQgdHlwZXMgKHRhYmxlcyk/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIpIEhvdyBkb2Vz IHRoZSBNQSBpZGVudGlmeSB0aGUgcmVwb3J0IHR5cGUgYmVpbmcgc2VudD88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RXZlbiBpZiAjMSBpcyBh ZGRyZXNzZWQgdXNpbmcgbXVsdGlwbGUgcmVnaXN0cnkgZW50cmllcywgYW5kICMyIGlzIGFkZHJl c3NlZCBieSBpbmNsdWRpbmcgYSByZWZlcmVuY2UgdG8gdGhlIHJlZ2lzdHJ5IGVudHJ5IGluIHRo ZSAnbWV0cmljL3VyaScgb2JqZWN0IG9mIHRoZSB0YXNrIHdpdGhpbiB0aGUgcmVwb3J0LA0KIHRo ZXJlIGlzIHN0aWxsIHRoaXMgaXNzdWU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjMpIEhvdyBkb2VzIHRoZSBNQSBzZW5kIG11bHRpcGxlIHJl cG9ydCB0eXBlcyBhdCB0aGUgc2FtZSB0aW1lPyBNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBjdXJy ZW50IHJlcG9ydCBkZWZpbml0aW9uIGlzIHRoYXQgaXQgbGltaXRzIGVhY2ggdGFzayB0byBoYXZp bmcgb25lIHRhYmxlIGRlZmluaXRpb24gcGVyDQogUE9TVC4mbmJzcDsgVGhlIE1BIGNvdWxkIHNl bmQgZWFjaCB0YWJsZSBkZWZpbml0aW9uIHRvIHRoZSBjb2xsZWN0b3Igc2VwYXJhdGVseSBidXQg YWxsb3dpbmcgZWFjaCB0YXNrIHRvIHNlbmQgYW4gYXJyYXkgb2YgdGFibGUgZGVmaW5pdGlvbnMg d291bGQgYmUgbW9yZSBlZmZpY2llbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Zb3UgYnJvdWdodCB1cCBhIGZvdXJ0aCBpc3N1ZSB3 aGljaCBpcyBob3cgdGhlIGRhdGEgaW4gZWFjaCB0YWJsZSBpcyBtYXBwZWQgdG8gdGhlIHJlZ2lz dHJ5LiZuYnNwOyBJIGhhdmUgYmVlbiBtYWtpbmcgdGhlIGFzc3VtcHRpb24gdGhpcyB3YXMgZ29p bmcgdG8gYmUgYWNjb21wbGlzaGVkIGJ5IHNldHRpbmcgdGhlDQogY29sdW1uIGhlYWRlciB2YWx1 ZSBpbiB0aGUgcmVwb3J0IHRvIG9uZSBvZiB0aGUgc3VtbWFyeS9uYW1lIHZhbHVlcyBkZWZpbmVk IGluIHRoZSByZWdpc3RyeSBmb3IgdGhlIG1ldHJpYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJvbjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU3VuLCBGZWIgMTQsIDIw MTYgYXQgMTE6MTEgQU0sIENhcmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnRpbW90aHkuY2FyZXlAbm9raWEuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGltb3RoeS5j YXJleUBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5Sb24sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBN UyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSB0YXNrIGhh cyBtdWx0aXBsZSByZWdpc3RyeSBlbnRyaWVzIOKAkyBJIHdvdWxkIGFzc3VtZSB5b3VyIGV4YW1w bGUgaXMgdGhhdCB0aGlzIHRhc2s8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PndvdWxkIGhhdmUgMyByZWdpc3RyeSBlbnRyaWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtU cmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGUgY29sdW1ucyBhcmUgZm9yIHRoZSB0YXNrIGFuZCB3b3VsZCBoYXZlIHRvIGhhdmUgYSB1bmlv biBvZiBhbGwgdGhlIG1ldHJpY3MgZm9yIHJlZ2lzdHJ5DQogZW50cmllcy4g4oCTIElzIHRoaXMg d2hhdCB5b3Ugd2VyZSBhc2tpbmc/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBN UyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IHNlZW1zIHRo YXQgd2UgbG9zZSB0aGUgY29udGV4dCBvZiB0aGUgcmVnaXN0cnkgZW50cnkgdG8gY29sdW1uIHRo b3VnaOKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1T JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUiw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRpbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUm9uIFN0YW5hIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOnJvbi5zdGFuYUB2aWF2aXNvbHV0aW9ucy5jb20iIHRhcmdldD0i X2JsYW5rIj5yb24uc3RhbmFAdmlhdmlzb2x1dGlvbnMuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDEyLCAyMDE2IDQ6MzEgUE08YnI+DQo8Yj5Ubzo8L2I+IDxh IGhyZWY9Im1haWx0bzpsbWFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bG1hcEBpZXRmLm9y ZzwvYT48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzphbGlzc2FAY29vcGVydy5pbiIg dGFyZ2V0PSJfYmxhbmsiPmFsaXNzYUBjb29wZXJ3LmluPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBbbG1hcF0gU3VwcG9ydCBmb3IgbXVsdGlwbGUgcmVwb3J0IHRhYmxlIGZvcm1hdHMgZnJvbSBv bmUgdGFzazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkxNQVAgVGVhbSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5NeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBMTUFQIHByb3Bvc2FsIGlzIGlldGYtbG1hcC1y ZXBvcnQ6cmVwb3J0L3Rhc2svbmFtZSBpcyBzdXBwb3NlZCB0byBjb250YWluIG9uZSBvZiB0aGUg dmFsdWVzIGRlZmluZWQgaW4gaWV0Zi1sbWFwLWNvbnRyb2w6bG1hcC90YXNrcy90YXNrL25hbWUu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5JZiB0aGlzIGlzIGNvcnJlY3QsIGFuZCBzaW5jZSBlYWNoIHRhc2sgaW5zdGFuY2Ugd2l0aGlu IGEgcmVwb3J0IGNhbiBvbmx5IGNvbnRhaW4gb25lIHRhYmxlIGRlZmluaXRpb24gKG9uZSBoZWFk ZXIgJiM0MzsgaXRzIHJvdyBkYXRhKSB0aGVuIGhvdyBkb2VzIGEgdGFzayBzZW5kIG11bHRpcGxl IHRhYmxlcyBvZiByZXN1bHRzDQogdGhhdCBjb250YWluIGRpZmZlcmVudCB0YWJsZSBmb3JtYXRz PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+VXNlIENhc2VzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4xKSBZLjE1NjQgdGFzayBoYXMgcmVzdWx0cyBmb3IgdGhlIFNlcnZpY2UgQ29u ZmlndXJhdGlvbiBhbmQgdGhlIFNlcnZpY2UgUGVyZm9ybWFuY2UgZGF0YSwgYW5kIGVhY2ggdGFi bGUgaGFzIGEgZGlmZmVyZW50IHNldCBvZiBjb2x1bW5zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4yKSBBbiBSRkMtMjU0NCB0YXNrIHdvdWxk IG5lZWQgYSBkaWZmZXJlbnQgdGFibGUgZm9yIHRoZSBUaHJvdWdocHV0LCBMYXRlbmN5LCBGcmFt ZSBMb3NzIGFuZCBCYWNrIHRvIEJhY2sgcmVzdWx0IHNldHMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMpIEFueSB0YXNrIG1heSB3YW50IHRv IHNlbmQgYSBtaW5pbWFsIHJlc3VsdCBzZXQgd2hpbGUgaXQgaXMgZXhlY3V0aW5nIHRoYXQgaXMg dmVyeSBkaWZmZXJlbnQgZnJvbSB0aGUgZmluYWwgcmVzdWx0IHNldCB3aGVuIGl0IGhhcyBjb21w bGV0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGUgaWV0Zi1sbWFwLXJlcG9ydDpyZXBvcnQvdGFzay90YWcgY291bGQgYmUgdXNl ZCB0byBkaWZmZXJlbnRpYXRlIHRoZSByZXN1bHQgc2V0cyBzZW50IGJ5IHRoZSBzYW1lIHRhc2su IEhvd2V2ZXIgdGhpcyBpcyBub3QgdmVyeSBlZmZpY2llbnQgc2luY2UgdGhpcyBhcHByb2FjaCBy ZXF1aXJlcyB0aGUgTUENCiB0byBzZW5kIGVhY2ggcmVwb3J0IHRvIHRoZSBjb2xsZWN0b3Igc2Vw YXJhdGVseSBiZWNhdXNlIGVhY2ggcmVwb3J0IGNhbiBvbmx5IGNvbnRhaW4gb25lIHNldCBvZiBy ZXN1bHRzIHBlciB0YXNrIG5hbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbnkgZ3VpZGFuY2Ugb3IgY2xhcmlmaWNhdGlvbiBvbiB0 aGUgTE1BUCBwcm9wb3NhbCB3b3VsZCBiZSBhcHByZWNpYXRlZCw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJvbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9966516C6EB5FC4381E05BF80AA55F77012A5D2616US70UWXCHMBA0_-- From nobody Thu Feb 18 02:06:00 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13351B35EC; Thu, 18 Feb 2016 02:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.906 X-Spam-Level: X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRNPSp7jvEoT; Thu, 18 Feb 2016 02:05:54 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5339A1B3106; Thu, 18 Feb 2016 02:05:54 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D3AQDTlsVW/xUHmMZeGQEBAQEPAQEBAYJfK4E/BroYAQ2BZ4YNAoFgOBQBAQEBAQEBZCeEQQEBAQEDEgsdNAQHDAQCAQgNAQMEAQEBChQJBzIUCQgCBAENBQgah3gBoh2ZQQEBAQEBAQEDAQEBAQEBAQEBARaGE4Q6hDWDK4EPBZcFAYhAhnWEQ4MZhTuORx4BAUKDY2qIIwF7AQEB X-IPAS-Result: A2D3AQDTlsVW/xUHmMZeGQEBAQEPAQEBAYJfK4E/BroYAQ2BZ4YNAoFgOBQBAQEBAQEBZCeEQQEBAQEDEgsdNAQHDAQCAQgNAQMEAQEBChQJBzIUCQgCBAENBQgah3gBoh2ZQQEBAQEBAQEDAQEBAQEBAQEBARaGE4Q6hDWDK4EPBZcFAYhAhnWEQ4MZhTuORx4BAUKDY2qIIwF7AQEB X-IronPort-AV: E=Sophos;i="5.22,464,1449550800"; d="scan'208";a="161463848" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Feb 2016 05:05:53 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 18 Feb 2016 05:05:53 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Thu, 18 Feb 2016 11:05:30 +0100 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "ippm@ietf.org" Thread-Topic: [ippm] Call for adoption: draft-morton-ippm-initial-registry Thread-Index: AQHRM1Gj3Ombx6Ev3Ea0YhNXsTtcjJ7EomaAgGxcs0CAAMj+gIAAODiw Date: Thu, 18 Feb 2016 10:05:29 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF1EDD7@AZ-FFEXMB04.global.avaya.com> References: <2D09D61DDFA73D4C884805CC7865E611425E355A@GAALPA1MSGUSRBF.ITServices.sbc.com> <20160218074115.GA4397@elstar.local> In-Reply-To: <20160218074115.GA4397@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] [ippm] Call for adoption: draft-morton-ippm-initial-registry X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 10:05:57 -0000 (cross-posting LMAP) I suggest that we discuss the LMAP perspective at the LMAP WG interim on Mo= nday.=20 Concrete examples would be indeed very useful. Regards, Dan > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Thursday, February 18, 2016 9:41 AM > To: ippm@ietf.org > Subject: Re: [ippm] Call for adoption: draft-morton-ippm-initial-registry >=20 > Hi, >=20 > since an empty registry is of little value, I think having a initial cont= ent defined > somewhere is essential. In fact, I believe initial content _and_ at least= one > concrete use case example is essential in order to know that the registry > itself is practically useful. >=20 > I am mostly active in LMAP and not too closely following IPPM so please > forgive my ignorance. But I generally do believe that a proof of practica= l > usability is essential for good specifications. Hence, concrete metric re= gistry > examples might help to convince us that the registry is a cool thing to h= ave or > they might show us how to make the registry simpler or easier to use. >=20 > /js >=20 > On Wed, Feb 17, 2016 at 06:45:00PM +0000, STARK, BARBARA H wrote: > > +1 > > And I'm sorry I totally missed replying to this call in my get-ready-fo= r- > holidays frenzied mode (in December). > > Barbara > > > > > I support the adoption of this draft as a WG item. It is needed to > > > create entries for the currently defined IPPM metrics into the > > > metric registry and is complementary to work coming out of the LMAP > WG. > > > > > > Jason > > > > > > On 12/10/15, 8:49 AM, "ippm on behalf of Brian Trammell" > > > wrote: > > > > > > >Greetings, all, > > > > > > > >Following support in the room for the adoption of > > > >draft-morton-ippm-initial-registry in Yokohama, this message starts > > > >a formal call for adoption of the following milestone: > > > > > > > >July 2016: submit a Standards Track document to the IESG defining > > > >initial contents of performance metric registry > > > > > > > >in support of paragraph 7 of our charter: > > > > > > > > Agreement about the definitions of metrics and methods of > > > >measurement > > > > enables accurate, reproducible, and equivalent results across > > > >different > > > > implementations. To this end, the WG will define and maintain a > > > >registry of > > > > metric definitions. The WG encourages work which assesses the > > > >comparability > > > > of measurements of IPPM metrics with metrics developed elsewhere. > > > >The WG > > > > also encourages work which improves the availability of > > > >information about > > > > the context in which measurements were taken. > > > > > > > >and to adopt draft-morton-ippm-initial-registry as the document for > > > >this milestone. > > > > > > > >Please express support or concerns with adopting this document by > > > >31 December 2015 to the IPPM working group mailing list, > > > >ippm@ietf.org > > > > > > > >Many thanks, best regards, > > > > > > > >Brian Trammell (chair hat) > > > > > > > > > ________________________________ > > > > > > This E-mail and any of its attachments may contain Time Warner Cable > > > proprietary information, which is privileged, confidential, or > > > subject to copyright belonging to Time Warner Cable. This E-mail is > > > intended solely for the use of the individual or entity to which it > > > is addressed. If you are not the intended recipient of this E-mail, > > > you are hereby notified that any dissemination, distribution, > > > copying, or action taken in relation to the contents of and > > > attachments to this E-mail is strictly prohibited and may be > > > unlawful. If you have received this E-mail in error, please notify > > > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. From nobody Thu Feb 18 04:30:31 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1D51B3EEC for ; Thu, 18 Feb 2016 04:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0mKZrYargob for ; Thu, 18 Feb 2016 04:30:27 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD611B3EE7 for ; Thu, 18 Feb 2016 04:30:26 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E5757FEC for ; Thu, 18 Feb 2016 13:30:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4oJcOZUfrpGW for ; Thu, 18 Feb 2016 13:30:07 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 18 Feb 2016 13:30:24 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 140522002C for ; Thu, 18 Feb 2016 13:30:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KpQ_CyvGYu8V; Thu, 18 Feb 2016 13:30:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B91EB2002B; Thu, 18 Feb 2016 13:30:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 51F9B39F6065; Thu, 18 Feb 2016 13:30:22 +0100 (CET) Date: Thu, 18 Feb 2016 13:30:22 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20160218123022.GA4899@elstar.local> Mail-Followup-To: lmap@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [lmap] remove ma-task form ma-instruction-obj X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 12:30:29 -0000 Hi, while implementing things, I figured out that my daemon 'lmapd' needs, in addition to instructions received from the controller, some basic configuration information. In particular, configuration is needed about the programs that are considered measurement tasks and 'safe' to execute. (It does not make sense to allow a controller to execute /bin/sh as a measurement task for obvious reasons). This configuration information should not generally be writable. Looking at the current information model, it seems this can be very easily be achieved by removing ma-task from ma-instruction-obj into the ma-config-obj. As a consequence of this change, the ma-task-obj is not something that is exposed to be messed around with by a controller. The controller is essentially restricted to 'play' with schedules and suppressions (and we likely should add events to the ma-instruction-obj). Note that with this cange, we would not really need the recently added ma-capability-task-obj anymore since a controller can read the (for the controller read-only) configured tasks and then create schedules with actions referring to the configured tasks. In terms of implementation, what this boils down to is having a setup where you have in /etc/lmapd/lmapd.conf the configuration of the lmapd itself including the configuration of the tasks that the lmapd allows to be use. Instructions (locally generated or received from remote controllers) would go into /var/spool/lmapd/instructions/*.conf. Upon startup, the lmapd would read and merge all these conf files to produce the configuration that is executed. (There is likely a bit more work to support multiple controllers with proper isolation but that is outside the scope of LMAP for now I think.) For the YANG data model, my preferred solution would be to tag the leafs in the /lmap/tasks/ subtree with nacm:default-deny-write (RFC 6536) to document that this part of the configuration model usually is not writable for controllers. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 18 12:40:23 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE421B30B3 for ; Thu, 18 Feb 2016 12:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbL1jEuYog-9 for ; Thu, 18 Feb 2016 12:40:15 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89F41B2C63 for ; Thu, 18 Feb 2016 12:40:15 -0800 (PST) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id DA68F63330DD6; Thu, 18 Feb 2016 20:40:11 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u1IKeD06024638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Feb 2016 20:40:13 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u1IKeCqS024257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Feb 2016 20:40:13 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.121]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 18 Feb 2016 15:40:12 -0500 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder , "lmap@ietf.org" Thread-Topic: [lmap] remove ma-task form ma-instruction-obj Thread-Index: AQHRaocTgRk/svInGUqRedOWCRVa0p8yQmLQ Date: Thu, 18 Feb 2016 20:40:11 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A5D59D4@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20160218123022.GA4899@elstar.local> In-Reply-To: <20160218123022.GA4899@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] remove ma-task form ma-instruction-obj X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 20:40:23 -0000 Juergen, An instruction gets sent down by the controller as part of a testing cycle;= a config object (which includes is general configuration or preconfigurati= on) - I think you are blurring the lines - Note that there are control task= s in the config so these are the "safe config" tasks. The tasks in the inst= ruction are testing tasks so they should be "safe" for testing. I don't thi= nk we should say or enforce anything more than that. That being said in the BBF TR-069 implementation an MA has tasks some of wh= ich are referenced by the current instruction - these are known as test tas= ks by their reference to the instruction. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, February 18, 2016 12:30 PM To: lmap@ietf.org Subject: [lmap] remove ma-task form ma-instruction-obj Hi, while implementing things, I figured out that my daemon 'lmapd' needs, in a= ddition to instructions received from the controller, some basic configurat= ion information. In particular, configuration is needed about the programs = that are considered measurement tasks and 'safe' to execute. (It does not m= ake sense to allow a controller to execute /bin/sh as a measurement task fo= r obvious reasons). This configuration information should not generally be = writable. Looking at the current information model, it seems this can be very easily = be achieved by removing ma-task from ma-instruction-obj into the ma-config-= obj. As a consequence of this change, the ma-task-obj is not something that= is exposed to be messed around with by a controller. The controller is ess= entially restricted to 'play' with schedules and suppressions (and we likel= y should add events to the ma-instruction-obj). Note that with this cange, = we would not really need the recently added ma-capability-task-obj anymore = since a controller can read the (for the controller read-only) configured t= asks and then create schedules with actions referring to the configured tas= ks. In terms of implementation, what this boils down to is having a setup where= you have in /etc/lmapd/lmapd.conf the configuration of the lmapd itself in= cluding the configuration of the tasks that the lmapd allows to be use. Ins= tructions (locally generated or received from remote controllers) would go into /var/spool/lmapd/instructions/*.conf. Upon start= up, the lmapd would read and merge all these conf files to produce the conf= iguration that is executed. (There is likely a bit more work to support mul= tiple controllers with proper isolation but that is outside the scope of LM= AP for now I think.) For the YANG data model, my preferred solution would be to tag the leafs in= the /lmap/tasks/ subtree with nacm:default-deny-write (RFC 6536) to document that this part of the configuration model usually is not = writable for controllers. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 19 09:19:52 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202451B2F7A for ; Fri, 19 Feb 2016 09:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1s7ejH3t1K7c for ; Fri, 19 Feb 2016 09:19:49 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6811B32E9 for ; Fri, 19 Feb 2016 09:19:49 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E0C411921 for ; Fri, 19 Feb 2016 18:19:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id XPEOsq6ZZJzY for ; Fri, 19 Feb 2016 18:19:24 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 19 Feb 2016 18:19:47 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4366620047 for ; Fri, 19 Feb 2016 18:19:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xIPG08yRQV1F; Fri, 19 Feb 2016 18:19:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5036320067; Fri, 19 Feb 2016 18:19:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 24CF039F7BA9; Fri, 19 Feb 2016 18:19:44 +0100 (CET) Date: Fri, 19 Feb 2016 18:19:43 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20160219171943.GA7927@elstar.local> Mail-Followup-To: lmap@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [lmap] are overlapping actions of a schedule allowed ? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 17:19:51 -0000 Hi, supposed you have a period event triggering a schedule with an action every minute. What should happen if the action triggered at t0 is still running at t1? Our code currently skips the execution of the action in this case (well it should probably skip the execution of the whole schedule if at least one action of the schedule is still running). The reason is that we want to avoid running out of resources just because someone agressively triggers actions. Should LMAP specify how an implementation is expected to behave in this situation? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Feb 21 17:28:46 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C46B1AD0CA for ; Sun, 21 Feb 2016 17:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y3YjTUczsnv for ; Sun, 21 Feb 2016 17:28:43 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1974E1ACE43 for ; Sun, 21 Feb 2016 17:28:43 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id D7B4312161E for ; Sun, 21 Feb 2016 20:31:28 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg11.research.att.com [135.207.255.123]) by mail-green.research.att.com (Postfix) with ESMTP id 07CA4E0349 for ; Sun, 21 Feb 2016 20:24:33 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG11.research.att.com ([fe80::516e:6eec:2697:ec78%17]) with mapi; Sun, 21 Feb 2016 20:27:49 -0500 From: "MORTON, ALFRED C (AL)" To: "lmap@ietf.org" Date: Sun, 21 Feb 2016 20:27:48 -0500 Thread-Topic: I-D Action: draft-morton-ippm-initial-registry-04.txt Thread-Index: AdFtDsiIjqMQ+PDMSVmhl5r5X9Kr7QAAVJ9w Message-ID: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30E82@NJFPSRVEXG0.research.att.com> References: <20160222011705.23301.53115.idtracker@ietfa.amsl.com> In-Reply-To: <20160222011705.23301.53115.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lmap] FW: I-D Action: draft-morton-ippm-initial-registry-04.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 01:28:45 -0000 A few updates in Section 4 for tomorrow's LMAP Interim. Al -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Sunday, February 21, 2016 8:17 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-morton-ippm-initial-registry-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Initial Performance Metric Registry Entries Authors : Al Morton Marcelo Bagnulo Philip Eardley Kevin D'Souza Filename : draft-morton-ippm-initial-registry-04.txt Pages : 62 Date : 2016-02-21 Abstract: This memo defines the Initial Entries for the Performance Metrics Registry. Version 04 * All section 4 parameters reference YANG types for alternate data formats. * Discussion has concluded that usecase(s) for machine parse-able registry columns are not needed. Still need: * suggestion of standard naming format for parameters. * revisions that follow section 4 changes in other proposed metrics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-morton-ippm-initial-registry/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-morton-ippm-initial-registry-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-morton-ippm-initial-registry-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Feb 22 00:56:23 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF00C1B2BB4 for ; Mon, 22 Feb 2016 00:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3P950Z6TVcL for ; Mon, 22 Feb 2016 00:56:18 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7101B2BA2 for ; Mon, 22 Feb 2016 00:56:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3FA3B21E1; Mon, 22 Feb 2016 09:56:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Z7OEW8Gvi0Dp; Mon, 22 Feb 2016 09:56:12 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Feb 2016 09:56:14 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 505662003B; Mon, 22 Feb 2016 09:56:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rMjxzklEIodz; Mon, 22 Feb 2016 09:56:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E4BB2003A; Mon, 22 Feb 2016 09:56:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2584739FA13B; Mon, 22 Feb 2016 09:56:11 +0100 (CET) Date: Mon, 22 Feb 2016 09:56:11 +0100 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20160222085611.GA12467@elstar.local> Mail-Followup-To: Ron Stana , "Carey, Timothy (Nokia - US)" , "alissa@cooperw.in" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A5CE3C2@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77012A5D0DBB@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "Carey, Timothy \(Nokia - US\)" , "alissa@cooperw.in" , "lmap@ietf.org" Subject: Re: [lmap] Support for multiple report table formats from one task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 08:56:22 -0000 Ron, the YANG data model already has a tag to distinguish multiple 'tables'. But even with that tag in place, I think the reporting model is not working well yet. I agree that there is room for improvement. One of the odd things is also that results are produced by actions, not by claim to report by tasks. This alone causes trouble because actions may use options that impact the result format. Originally, we did not have the notion of actions and somehow the result model simply lags behind. I need to think more about how to do this properly. I do not have a solution proposal yet but I agree that the reporting model needs some more work (once we have the configuration/instruction model stable). /js On Tue, Feb 16, 2016 at 09:46:23AM -0500, Ron Stana wrote: > Tim, > > I am trying to determine how one task can produce results that require > multiple table formats (what I called report types) and send them to the > collector at the same time. Most tasks we have will require this type of > functionality. > > This is my understanding of what we have discussed so far: > 1) The registry would be used to define the different table formats...for > the purpose of this discussion let's go with your suggestion that there > would be one entry for each table format. > 2) The multiple registry entries are then assigned to a single task using > multiple instances of the the lmap/tasks/task/metric object. > 3) When the task goes to send these different tables of results to the > Collector, it identifies the table that is being sent using a single > instance of the the report/task/metric object. > > If we agree thus far then the part that remains is how to send multiple > tables to the collector at one time. The current report model only allows > each task to have one entry so the MA would have to POST a separate report > for each table. I am asking if the tables could all be sent together. > > Ron > > On Tue, Feb 16, 2016 at 1:14 AM, Carey, Timothy (Nokia - US) < > timothy.carey@nokia.com> wrote: > > > Ron, > > > > > > > > I was thinking about this some more last night. > > > > > > > > Are you asking to categorize the reports by registry entry? - which I > > think you call report type? If so I don’t see an issue with that – we can > > use the registry entry as part of the report results… > > > > > > > > BR, > > > > Tim > > > > > > > > *From:* Carey, Timothy (Nokia - US) > > *Sent:* Monday, February 15, 2016 10:31 PM > > *To:* 'Ron Stana' > > *Cc:* alissa@cooperw.in; lmap@ietf.org > > *Subject:* RE: [lmap] Support for multiple report table formats from one > > task > > > > > > > > Ron, > > > > > > > > I would talk to the IPPM team then – its really how they define the > > metrics that make up the registry. > > > > > > > > As for a report per task constraint – I don’t know if saving inputs and > > outputs as you suggest warrant breaking that constraint – why not just have > > 2 tasks and duplicate the registry entry. > > > > > > > > I like the when the task is complete – generate the results for reporting > > and then report results based on the schedule to the collector. I know in > > our BBF implementation this works quite well. > > > > > > > > Otherwise you get into the nasty problem of a state machine that > > correlates running the tests with reporting results in the context of the > > overarching scheduled task (You call it running and final but there is a > > context to those states for that particular task). > > > > > > > > BR, > > > > Tim > > > > > > > > > > > > *From:* Ron Stana [mailto:ron.stana@viavisolutions.com > > ] > > *Sent:* Monday, February 15, 2016 5:40 PM > > *To:* Carey, Timothy (Nokia - US) > > *Cc:* alissa@cooperw.in; lmap@ietf.org > > *Subject:* Re: [lmap] Support for multiple report table formats from one > > task > > > > > > > > Tim, > > > > > > > > While multiple registry entries could be used to define each of the report > > types (table formats), this would require those registry entries to > > replicate the inputs ('fixed parameters' in registry terms) and any outputs > > that are common across the different types. It would be better to have one > > registry entry that defined the inputs to the task once, all possible > > outputs once and then allowed the outputs to be grouped into different > > report types. The report type is just some string value. When the tables > > were sent from the MA to the Collector they would then just need to include > > the report type. > > > > > > > > Example: > > > > 1) Task measures bandwidth for one or more streams > > > > 2) One registry entry is defined for the task. It includes: > > > > a) the numerous inputs that define the stream's packet format > > > > b) an output definition for the 'last one second bandwidth' > > > > c) an output definition for the 'average bandwidth since task start' > > > > 3) The 'last one second bandwidth' is only useful while the task is > > running so it is assigned to the report type 'running'. The description of > > the output > > > > 4) The 'average bandwidth since task start' is useful while the task is > > running and as a final value when the task completes so it is assigned to > > the report types 'running' and 'final'. > > > > 5) When the reports are sent from the MA, they indicate the report type. > > This is where I suggested the 'tag' object in the report could be used. > > > > > > > > In the end I am asking about these three issues: > > > > 1) How does a task properly define multiple report types (tables)? > > > > 2) How does the MA identify the report type being sent? > > > > Even if #1 is addressed using multiple registry entries, and #2 is > > addressed by including a reference to the registry entry in the > > 'metric/uri' object of the task within the report, there is still this > > issue: > > > > 3) How does the MA send multiple report types at the same time? My > > understanding of the current report definition is that it limits each task > > to having one table definition per POST. The MA could send each table > > definition to the collector separately but allowing each task to send an > > array of table definitions would be more efficient. > > > > > > > > You brought up a fourth issue which is how the data in each table is > > mapped to the registry. I have been making the assumption this was going > > to be accomplished by setting the column header value in the report to one > > of the summary/name values defined in the registry for the metric. > > > > > > > > Ron > > > > > > > > On Sun, Feb 14, 2016 at 11:11 AM, Carey, Timothy (Nokia - US) < > > timothy.carey@nokia.com> wrote: > > > > Ron, > > > > > > > > The task has multiple registry entries – I would assume your example is > > that this task > > > > would have 3 registry entries. > > > > > > > > The columns are for the task and would have to have a union of all the > > metrics for registry entries. – Is this what you were asking? > > > > > > > > It seems that we lose the context of the registry entry to column though… > > > > > > > > BR, > > > > Tim > > > > > > > > *From:* Ron Stana [mailto:ron.stana@viavisolutions.com] > > *Sent:* Friday, February 12, 2016 4:31 PM > > *To:* lmap@ietf.org > > *Cc:* alissa@cooperw.in > > *Subject:* [lmap] Support for multiple report table formats from one task > > > > > > > > LMAP Team, > > > > > > > > My understanding of the LMAP proposal is ietf-lmap-report:report/task/name > > is supposed to contain one of the values defined in > > ietf-lmap-control:lmap/tasks/task/name. > > > > > > > > If this is correct, and since each task instance within a report can only > > contain one table definition (one header + its row data) then how does a > > task send multiple tables of results that contain different table formats? > > > > > > > > Use Cases: > > > > 1) Y.1564 task has results for the Service Configuration and the Service > > Performance data, and each table has a different set of columns. > > > > 2) An RFC-2544 task would need a different table for the Throughput, > > Latency, Frame Loss and Back to Back result sets. > > > > 3) Any task may want to send a minimal result set while it is executing > > that is very different from the final result set when it has completed. > > > > > > > > The ietf-lmap-report:report/task/tag could be used to differentiate the > > result sets sent by the same task. However this is not very efficient since > > this approach requires the MA to send each report to the collector > > separately because each report can only contain one set of results per task > > name. > > > > > > > > Any guidance or clarification on the LMAP proposal would be appreciated, > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 22 03:38:42 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BB91B2C42 for ; Mon, 22 Feb 2016 03:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.905 X-Spam-Level: X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA4pdNci7C02 for ; Mon, 22 Feb 2016 03:38:32 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D188F1A6FF0 for ; Mon, 22 Feb 2016 03:38:31 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DkBgDc8spW/xUHmMZeGQEBAQEPAQEBAYI+ISsiMG0GuDiCIYFcChcBC4VqAoE4OhIBAQEBAQEBZBwLhEMBAQMSG14BDAkVViYBBBsBGYd4AQ2ZE4USmRYBAQgBAQEBHIYThDmEFgEBHS2CGwtAGIEPBZcHAY85hEODGYU7jkknAjmDZGoBhn40AXwBAQE X-IPAS-Result: A2DkBgDc8spW/xUHmMZeGQEBAQEPAQEBAYI+ISsiMG0GuDiCIYFcChcBC4VqAoE4OhIBAQEBAQEBZBwLhEMBAQMSG14BDAkVViYBBBsBGYd4AQ2ZE4USmRYBAQgBAQEBHIYThDmEFgEBHS2CGwtAGIEPBZcHAY85hEODGYU7jkknAjmDZGoBhn40AXwBAQE X-IronPort-AV: E=Sophos;i="5.22,484,1449550800"; d="scan'208,217";a="143620594" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Feb 2016 06:38:29 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 22 Feb 2016 06:38:28 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Mon, 22 Feb 2016 12:38:27 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: reminder: LMAP WG interim - today at noon EST Thread-Index: AdFtZXv79wVUFUF/RgOJ+wgiaVweBw== Date: Mon, 22 Feb 2016 11:38:26 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF2380D@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BF2380DAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] reminder: LMAP WG interim - today at noon EST X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 11:38:34 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF2380DAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is a reminder that the LMAP WG interim meeting is scheduled for today = at noon EST. The meeting information is available at http://www.ietf.org/mail-archive/we= b/lmap/current/msg02397.html. The draft agenda is available at https://www.ietf.org/proceedings/interim/2= 016/02/22/lmap/agenda/agenda-interim-2016-lmap-2. If you plan to use any slides, please send them to Jason or me for uploadin= g prior to the meeting. We need volunteers to take notes for the minutes. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF2380DAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

This is a reminder that the LMAP WG interim meeting = is scheduled for today at noon EST.

 

The meeting information is available at http://www.ietf.org/mail-archive/web/lmap/current/msg02397.html. <= /o:p>

 

The draft agenda is available at https://www.ietf.org/proceedings/interim/2016/02/22/lmap/agenda/agenda-inte= rim-2016-lmap-2.

 

If you plan to use any slides, please send them to J= ason or me for uploading prior to the meeting.

 

We need volunteers to take notes for the minutes.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BF2380DAZFFEXMB04globa_-- From nobody Mon Feb 22 04:09:29 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E2F1A0120 for ; Mon, 22 Feb 2016 04:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imQ336B8igKn for ; Mon, 22 Feb 2016 04:09:25 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF1E1A0338 for ; Mon, 22 Feb 2016 04:09:24 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A933D1C3C; Mon, 22 Feb 2016 13:09:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3uK9REPESGvd; Mon, 22 Feb 2016 13:09:20 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Feb 2016 13:09:22 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7273B2003F; Mon, 22 Feb 2016 13:09:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ueObfPvt9Rih; Mon, 22 Feb 2016 13:09:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4443520043; Mon, 22 Feb 2016 13:09:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D252039FA470; Mon, 22 Feb 2016 13:09:18 +0100 (CET) Date: Mon, 22 Feb 2016 13:09:18 +0100 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160222120918.GA12837@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20160218123022.GA4899@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5D59D4@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A5D59D4@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] remove ma-task form ma-instruction-obj X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 12:09:27 -0000 On Thu, Feb 18, 2016 at 08:40:11PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > An instruction gets sent down by the controller as part of a testing cycle; a config object (which includes is general configuration or preconfiguration) - I think you are blurring the lines - Note that there are control tasks in the config so these are the "safe config" tasks. The tasks in the instruction are testing tasks so they should be "safe" for testing. I don't think we should say or enforce anything more than that. > Why does it make sense for a controller to send a task as part of an instruction to the measurement agent? How does a measurement agent decide whether such a task should be accepted or rejected? > That being said in the BBF TR-069 implementation an MA has tasks some of which are referenced by the current instruction - these are known as test tasks by their reference to the instruction. Referencing tasks is just fine. The question is whether a controller should be allowed to send tasks down to the measurement agent. /js > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, February 18, 2016 12:30 PM > To: lmap@ietf.org > Subject: [lmap] remove ma-task form ma-instruction-obj > > Hi, > > while implementing things, I figured out that my daemon 'lmapd' needs, in addition to instructions received from the controller, some basic configuration information. In particular, configuration is needed about the programs that are considered measurement tasks and 'safe' to execute. (It does not make sense to allow a controller to execute /bin/sh as a measurement task for obvious reasons). This configuration information should not generally be writable. > > Looking at the current information model, it seems this can be very easily be achieved by removing ma-task from ma-instruction-obj into the ma-config-obj. As a consequence of this change, the ma-task-obj is not something that is exposed to be messed around with by a controller. The controller is essentially restricted to 'play' with schedules and suppressions (and we likely should add events to the ma-instruction-obj). Note that with this cange, we would not really need the recently added ma-capability-task-obj anymore since a controller can read the (for the controller read-only) configured tasks and then create schedules with actions referring to the configured tasks. > > In terms of implementation, what this boils down to is having a setup where you have in /etc/lmapd/lmapd.conf the configuration of the lmapd itself including the configuration of the tasks that the lmapd allows to be use. Instructions (locally generated or received from remote > controllers) would go into /var/spool/lmapd/instructions/*.conf. Upon startup, the lmapd would read and merge all these conf files to produce the configuration that is executed. (There is likely a bit more work to support multiple controllers with proper isolation but that is outside the scope of LMAP for now I think.) > > For the YANG data model, my preferred solution would be to tag the leafs in the /lmap/tasks/ subtree with nacm:default-deny-write (RFC > 6536) to document that this part of the configuration model usually is not writable for controllers. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 22 04:38:25 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EBC1A1B0E for ; Mon, 22 Feb 2016 04:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVabNz2i66Bn for ; Mon, 22 Feb 2016 04:38:21 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6AD1A1B03 for ; Mon, 22 Feb 2016 04:38:21 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 497CB12EB; Mon, 22 Feb 2016 13:38:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id DjIG_2lNIIKc; Mon, 22 Feb 2016 13:38:17 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Feb 2016 13:38:19 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 566292002B; Mon, 22 Feb 2016 13:38:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id L9chC6Ls0iU8; Mon, 22 Feb 2016 13:38:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2D5E20031; Mon, 22 Feb 2016 13:38:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8B4F539FA4ED; Mon, 22 Feb 2016 13:38:16 +0100 (CET) Date: Mon, 22 Feb 2016 13:38:16 +0100 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20160222123816.GB12837@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <20160211155559.GA55278@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D3FF3B4288C@NJFPSRVEXG0.research.att.com> <20160215134250.GA72079@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D3FF3A30882@NJFPSRVEXG0.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30882@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] milliseconds in ma-periodic-interval and ma-event-random-spread X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 12:38:23 -0000 On Mon, Feb 15, 2016 at 06:37:35PM -0500, MORTON, ALFRED C (AL) wrote: > > Again, I > > question that it is realistic to schedule tasks to start once per > > second in order to send one packet. > [ACM] > I do too, because I don't understand why anyone would do that. > The measurement system is supposed to send one packet per second > in my example -- one sending process would send, wait, send, wait, ... > > So, we have two measurement streams, sending 1 packet per second as follows: > > Stream 1 12:00:01, :02, :03, :04, :05, :06, :07, :08, :09, ... > Stream 2 12:00:07, :08, :09, ... > > and the streams synchronize on one second clock ticks. We need to distinguish the start of the task(s) creating streams and the timing of the streams generated by the tasks. > > Anyway, my original proposal was primarily about ma-periodic-interval. > [ACM] > I can live with one second resolution on ma-periodic-interval, > as long as there is millisecond resolution on ma-event-random-spread. > > > If people feel strongly that the ma-event-random-spread should remain > > with milliseconds resolution, I can probably live with that. Having > > ma-periodic-interval at milliseconds resolution is however more of a > > pain to implement. > [ACM] > I understand, but it was possible when we implemented RFC 3432, > back before it was published and in draft stage. Is RFC 3432 scheduling the invocation of arbitrary tasks or is it about sending packets from within a measurement task? The LMAP scheduler is by design a coarse grained scheduler, if you need precision for your packet trains, you have to implement that fine grained scheduling in the measurement tasks (to minimize the many possible sources of extra delays). t0 scheduled invocation as per instruction t1=t0+ds invocation of the scheduled action t2=t1+do measurement task starts running t3=t2+dm time first packet is given to the OS kernel t4=t3+dk time packet hits the wire To achieve reasonable precision, you have to control t3 (t4 is usually hard without special OS support) from within the measurement task. ds = delay by the lmap scheduler (which is also depending on the load of the OS) do = delay by the OS to load and start a measurement task (which is also depending on the load of the OS) dm = delay by the measurement task (time to initialize and generate the first test packet) dk = delay by the kernel to move the packet on the wire (may include media access specific delays) My point is that making the LMAP scheduler highly precise is a non-goal since ds+do+dm may add notable delays. The only way to achieve precision where it is needed is to not depend on the LMAP scheduler but to do the fine grained scheduling inside the measurement task. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 22 04:56:21 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BB51A3BA6 for ; Mon, 22 Feb 2016 04:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0U6Y9qgulE6 for ; Mon, 22 Feb 2016 04:56:17 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB521A21C0 for ; Mon, 22 Feb 2016 04:56:17 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EE628104B; Mon, 22 Feb 2016 13:56:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ZXkcSyi31OEv; Mon, 22 Feb 2016 13:56:12 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Feb 2016 13:56:15 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42F7D20035; Mon, 22 Feb 2016 13:56:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SdNU_shipCH9; Mon, 22 Feb 2016 13:56:14 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 167F72002B; Mon, 22 Feb 2016 13:56:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0091F39FA59D; Mon, 22 Feb 2016 13:56:13 +0100 (CET) Date: Mon, 22 Feb 2016 13:56:13 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" , "Weil, Jason" Message-ID: <20160222125613.GA13087@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "Weil, Jason" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA6BF2380D@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BF2380D@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] reminder: LMAP WG interim - today at noon EST X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 12:56:20 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Feb 22, 2016 at 11:38:26AM +0000, Romascanu, Dan (Dan) wrote: > > If you plan to use any slides, please send them to Jason or me for uploading prior to the meeting. > Dan and Jason, I have put some of the issues on slides. Note that I got a bad cold over the weekend and I am not sure how 'usable' I will be at the virtual interim meeting later today. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 --WIyZ46R2i8wDzkSu Content-Type: application/pdf Content-Disposition: attachment; filename="lmap-interim-2016-02-22.pdf" X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGFVdtuEzEQffdXDIWC07KOx17vhTttyqXAQ6WV eKA8RVQINUgh/y8x9nrGm0QLiVRP7bmeOTPZwg1swYI1lj7Ouzp0CC32pqcPhNrCnx/wFX7D 8nKHsN4Bpu9uTUbBZ7WNWCi5u5e77Nzbtvedh3sJV25+wt1ZjOBiBMqGvru12lKoKCI0aDAl 5ENnWusbWG/gYoC6Tgp0NJ0JGBoHFf0zbGA5DI4Mhzv4BvrBQlXW1KBPHi4oGxIe5fN0AfSC oB/HCwf6ST5vNQuLLJwlVadEhU3yQ/HBD+L8/GmypbiVid5IWKZTaZteAmjMYcjoOwzXcDWk 1hwjYJuIQHuEADpnLGIbEVCHCJQMHKfiWagkzzpdEQohCT6mqVK6otKwiiTephuCsIsV0CmO 5SULk2olACFTymWOMQOImrP1q5EBRIWoTUfdBtN3RLAjBmjKfvg1IiokM8G3LtQ95ZwlqpTv iN4ldI+msb0NgE1reiSO5dBuDO3AofHoAlTeMfcUc6/PfX2WYJLOg34eHwhiZoRwRLB+kUyC EmRfso9XSSBjMXqdw7x5OxqBvmBlDsC9vIyqxDiJwymuuIPSnSv2Ia3MRkq/i16oHMlACPH+ oLCR6qDFh2hWH5ITFVMpLCjI157H3hnvgmXkcUQ+HRX9Fbarcd5PpADJTtBYjTEn5fO48ikl fmQoGUGBg0sSqq/4ZsZ72Rp7i6UULdQXDhY2Finykpg1LsX/o4M1Gte1CHsgxaU4joRKS+Yf I1GGg/bxZCSOQudpLI1BWsMzUQ9XmwueNq/PLT7yREPXxNma9jnv9fPr1CGag08sSM9O086n dSTrOfc1/hzEpU/cnf85+JzZ/SWeOEvQ4EaGSvZ5NZD7+HMKwxqmkMT10cVK9vezvp1uqJu/ Zz9vWQplbmRzdHJlYW0KZW5kb2JqCjUgMCBvYmoKNjgyCmVuZG9iagoyIDAgb2JqCjw8IC9U eXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA2IDAgUiAvQ29udGVudHMgNCAw IFIgL01lZGlhQm94IFswIDAgNzIwIDU0MF0KPj4KZW5kb2JqCjYgMCBvYmoKPDwgL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBS ID4+IC9Gb250IDw8Ci9UVDIgMTAgMCBSID4+ID4+CmVuZG9iagoxMSAwIG9iago8PCAvTGVu Z3RoIDEyIDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PgpzdHJlYW0KeAGFVVuIG1UY/pM5yQq7ztPa1S2kQ710KbtLthXdpbSaW5O0axqy 2dUWQbOTk2TM7CTOTNILfSqC4ourvklBvL0tCILSesHWB/tSqVBWd+siKD60eEEo9EW38TuT ZCZZaptlz3zz/d/5b+efGaKBtUK9rvsVoiXDNnPJqPLc0WPKwDr56SEapFEaLKhWPZLNzhJ+ Qiuu/b9bP5BPMFcn7mzvV2+5GyxySyXy3Qe+VrTUJeATRIGzat20iQaGwU8ft+sCixyGTSQI /KLA5TaGjYYX2/g1R5PPxaA5CyyrlUIReAV4fLGHL/fgdg5QwE+SG9zUVEX0ImvWSprOHUN7 uYe5R3k3uKQ3ULPz24F1yKrOHcZ1DLW/UizEBZ4EXlELiTngR4CvNbWFTAffrtvRHPBjRP6d jep8BHg3cKpkHpwHhh+/WWmkuvidU5X8s+C3gf/GWMwc6exdU60Yekk7wd+u8LTob4hIUjQ7 nQeGH+mAWcsJPXKQSkUeTwCPA79erR0WOcCn9JnVnBO8yGftVCUm8hT85ZcKh7LAo8C/cj0p 9Igl/Vu3s50cWMjQMyIuYrE4t5x64YeF7Eo+BR5xmW6b+c5etlzSDqY7+k8qZkrwYu+1uu7M KHIL+M1GTtSOWIHJgplIAsNnIMuNedFPgZu04CsQpxotYlXJoE1SKEdJiuJaJxOWEmmkg+Gw cjAcd13NhLPPoip4jZqOzcKadZTtnV2tQmWwBl13tCrFQh9RA54q9AfYiutToRjuGuDK/+On ncuNjp8aG2Fhthf/+9gs28+m2Qwp7Cn2NDvA4mBn2D7XdxZ7uhWJfG4gStvPy4jIHd0Car+I Gm0qYP0FihpZroe+riyPNsY8yxnzBU298sbfPb3SsLPqKib6OnrkXj0P/Ba4HljFuh7YcH0o gZ8CG/hbR2+8WmqevdNlcVIaTrTWp9t6Fl1VBJXqzs4ldEFDzbyn5oleH5dOf/mgF22VnXv+ 6tCl0yVjedRjRRf4q5lbGToz7rHhH8N/hlfD74U/DP8uvS19Kn0lnZc+ly6TIl2QLkpfS99K H0tfuPq7zZB79iQyF3Ml8hbT1a2wt9eYWDkqb5cfluPyDvlRedZVKfKIPCWn5F2wbHfPzZtv pbdy9OUoonX7c+dY4lnRXE84A9/9mADNi9g3A/PIWKPj8Gmi32LeDDoJbe+T16mIhdgUS2+Z 7mkx813fwUQwHoyQEtwdnAlOBQ8J3H2Wg7tgm8Ga6M0N8+Eq+irlNj8hvicUq9VPmlq5Yit7 wuEnlQg+fVxJG+rkuFLQdcUxWYrJLW42eXGSxHdT7CO6mXO+h75tVzzOfoZo/194933vccca RCsW0cjjHjeGd+UD7xKde0JtmM22P/L5viOySnv3OPe+oSjeXz+3WjfxHht4i2jzzVbrn/db rc0P4H+D6IL+H6CffFUKZW5kc3RyZWFtCmVuZG9iagoxMiAwIG9iagoxMDc5CmVuZG9iago3 IDAgb2JqClsgL0lDQ0Jhc2VkIDExIDAgUiBdCmVuZG9iagoxMyAwIG9iago8PCAvTGVuZ3Ro IDE0IDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAGdlndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVG FBEpVmRUwAFHhyJjRRQLg4Ji1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oA UPyCBMJ0WAGANKFYFO7rwVwSE8vE9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS7 2yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan 5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjAShXJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlf zOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHimZ+SKBIlJYqYR15hp5ejIZvrxs1P5YjEr lMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW5mj5v9nfHn5T/T3IevtV8Sbsz55B jJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC03pzzHoZsXpLE4gwnC4vs7Gxz AZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TMzAwOl89k/fcQ/+PAOWnN ycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRodV8AfYU5ULhJB8hv PQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9kciWiLBmj34Rs wQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2g2pwANSB etAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQOBQD xUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKp RZqQDqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGm WCesP3YJNhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4Sbx eLwq3hTvgg/Bc/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahP dCKGEHnEXGIpsY7YQbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSf IF8lD5I/UJQoJhRPShxFQtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mt k6uRa5Xrl3slT5TXl3eXXy6fJ18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppi iWKD4jXFUSW8koGStxJPqUDpsNIlpSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99All JWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyTjLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaV AZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uuq43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o9 6pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoLtQRa5VrntV4wlZnuzFRmJbOLOaGtru2n LdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0svWC9fr1HvoT5Rn62fpL9Hv1t/ysDQ INpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+41smsImdSZJJjclNU9jU3lRg us+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIudFt0WXyztLFMt6ywfWSlZ BVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtOu8/2DvYi+yb7MQc9 h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX1C0YctFx4bgc cpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrPC16Il69X kVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARGBFYH PgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS 3UuH4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7 kufGK+eN8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmE tPi000IlYYqwK10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy 3mdHZZ/KUcwR5vTkmuRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7r j20gbUjZ8MtGy41lG99uit7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe 0fViy+KK4k8l3JLr31l9V/ndzPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3 u1fsvlZhW3FgD2mPZI+0MqiyvUqvakfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+ HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2S xrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibak Nml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HOFZybOZ93fvJCxoXxi4kXhzpXdD66tOTS na6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9jdYeu56WX+x+aem172296XCz/Zbj rY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3RB6kPXj/Mejj9aP1j7OOiJwpP Kp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0RupHrUfPjPmM3Xqx9MXw y4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk03dp76anit6rvj/2 gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/sKZW5kc3RyZWFtCmVuZG9iagoxNCAw IG9iagoyNjEyCmVuZG9iago4IDAgb2JqClsgL0lDQ0Jhc2VkIDEzIDAgUiBdCmVuZG9iagox NiAwIG9iago8PCAvTGVuZ3RoIDE3IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeAGtV92O3TQQvvdTzBZafFqSje14nQi4YHtWQKEtiyJxAVwdUSHURVr2mfo+faSOHc/n JMf7J3WPtHb8MzOe+ebz+Jou6Zo66tqO/6yzvR8MBTO2I/+R7zv6/2/6nf6j05c3hg43ZNLv 5sCbvMvLrrBDYew9xrJw14XRDY7eQ10Z+YfePY8abNTA1vDv5qCuWVXsGupda5JB/Ti2IfQj Ha7ofKK+Twu4sUMbfD8M1PDHdEWn02R54/SO/iD9eqe61pA+3bEtPen91ztqUs9J5/vU8Twn izoZaX7M256mEaO0iQOW1z5PI9yzqcOi27z2SIpPKxzpc1na7RQbwSqHuIfNgzSohp3NVu4P cQ9L22fDlWbr/qLpFV1MKabHrjPxxLPfnE1+S03D/2eHueQwpT/saPp3liNRl5gwWB4o2JjW ds5YYvlqlu/ngOiTIv/B4myYEboQV+L7IiSfsgvRQWDFcW9yYFZuipBTC8gtjhfGDDkXLPxm h+S31DSub8PWdR/L0e5w3T2yjW99sDbwWaOK2723zZiHm29t62PCr1UUj36bHMrYhB8vBLZA KXwtLp5xrDSgDvgC8+x9xjwH6puMX8mTakrm/Lg/JUn3STBnIpSL5KxSFWw0EPhWzIGlYhcM bfY4568ZQiElLh8Ci5CwWMtTtWw0HacFOQdIqRWk+GPLXeLcSzH1iGqy7YsDwhxhCRECgxu4 CUPYZCJbLjkN3ChihP/kG95rIE3iqQrfYU58fLRdBiR0Qm6kwXIbLiYN3ThRMQJzIlja8xTB BV0vAVqLGy4gOw5ggzWLju1Z4DsqZ+vMpfRYLq2LX3DpWsvDGLUudMGoa6GFBb7MgJd4wMXA IEYAfImZ0m9uY9zlJV+jLOuRHnyvbxl34+CPj2PcuuzPyrh1Ffcx7m9CYN+lzqpK2SYMMimz sypZgCwuWQBqPAqj5DHkSepDClIfHUwh4pJUUsZkTCyMQnZhDzRWiAiLiuC5fAPYkNdVwbX8 xY1rDWNLzVXQMbZWhRDpx2KrKnuDrayikrnb23xR/67Nz0VcMX+DraM75GRLd/tbLwYERrBR atx8WZbyF1BAPASoqBEEcnIdLMpfn4ziElY0YRMAAJoRMYKIPQKf7VV6XwAvAmEfwIsOpqBL RA/5rXAH2FhnDWPz3W6CwQXBpQ4XWb2aDmseq1zzp220hGuKqJebaCk3McG5ia5Pcyo20d3c rMzghwQXqp5fRrUeP9cqlTZXIc76jivg9JjiWj29tmLT8Me2Enlyh0v2872cXiFzgfcssj9X EdICWD+x9enZIx6/SANMeBJlsBrqtKNbX6R+lbX8qaWzy52ldxaZZL2LBVg+ec6kcvKz0J5Z Xz3+i1fJTqf0z3OHNI6CwwHDGDmR0z35IlrGx5Rb9amUkb/kidex3Qa2xM3b+RW8tX5GGT8T DlQOYvrQjoafw9tA6mdsmjzvLj8BoH8GsQplbmRzdHJlYW0KZW5kb2JqCjE3IDAgb2JqCjEx MDIKZW5kb2JqCjE1IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291 cmNlcyAxOCAwIFIgL0NvbnRlbnRzIDE2IDAgUiAvTWVkaWFCb3gKWzAgMCA3MjAgNTQwXSA+ PgplbmRvYmoKMTggMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3Bh Y2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+IC9Gb250IDw8Ci9UVDMgMTkgMCBSIC9U VDUgMjEgMCBSIC9UVDIgMTAgMCBSID4+ID4+CmVuZG9iagoyMyAwIG9iago8PCAvTGVuZ3Ro IDI0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGlWO2O1TYQ/e+nMLRQ X5ZkYzu5SUSrCsiqQMuiVUNpy9JWuipCiK203WfifXikjj/mODfO/VgVhK5x7JkzM2fGY1/L C3ktK1mVFf0x1tRNp2Wr+7KnP7KpK/nv3/KN/EeePr3RcnMjtf97s6FNjY3LrrBDYO4T5qJw W7W97az8BHVp5oN8/8BpME4DoaG/NxtxTarcUMvaltoDqvu+bNu6l5sr+WSUde0X0I+u6rK1 NCjo33glT8fR0MbxvXwr1cuVqEot1eOVLKqykarxAyvVmR/UUj3wAyNV6we0uHi2IuT0CbtK PyHUPSwZHrkpkoMp7SZIzFB0bkRyvmMVlR+Q9oc888jhCrvfyfGFPBt9OHKrtQMSTLbGm+x/ CtOVrffLeCXIYhssVp9XcvwYpHHY2KkU7SPFa12aymojoUUEvzZRy52k5Wihpg1Ey4SmYJ0g AhhYdliIgFTnPhLe7clxjj9iwp+JqW0f+WPbNTxpOu9J/1NYXfYmEie4UagvycA9bjwgWzdl 0xrTyqBitw/n9D8evjFl47J3W0Xy6LdMPHbfjNFSMVdf+ZVE2pggInEVDEfu1H4xcR2f8oAZ jpxZCUo9yqbTGDrGgj0YIE+gCQkTNQlVDCyHM5DlFZADWBCYfypdBhIqLCmQriyQFUHcAPdh AFw/s0/G1zzCPpgzkZjYm1JIV5R50lJxrUXI+S2mmoa+zivcAC3ABJOi1eQ0LAKUPIZs9oXH T1RACCeSXSypkDFtoCpp2FMHWQNw/cIkAb4f/QxVRkQDKvIYAuBpDCas+8FxjaRg8xPWNMMw 4TAHZyAmRMryYv5EMPfEraK4xVqdxS1mf0rNiU/j0cSOA+aC1QN8dJNQb9hNvARBw+4zthgz uUo66UIWwP+gMQtGiDjdMPHU+Zi4gL2VdxvNJDJAdx48pDaClrahZuAb9mMA0TAU9jH2iIz4 DzkAy95eOK5pze4om7a7TXYCEwZAEC0RSCZQnvEj7jgGIYWXwB3JVrQmHDFeC3GA8L0LIdVx +DIVwXsrccAJkeq+gaS6tJGJ9KY3ZdUaS4d9qFmuR4ncV3VH1YO7lHnx8+7Nkoi609L06z7I y3IJLVyqvWDpjmCirzR1iudWh2WpX+i2+gJ52/ZqWXZqr6YqjuutliWm3moqMdWar+PJy2UM 2bAnz9JZdx53b3ky71kEd5doi0x1dMsl5y3XoXZuWfas5YrRawgaXQfUnUS7HD6a4wPwD7Vc v3K2ob4NXGr4C9KPPwyRwCLdQZDxOOMw4CiyOJQADFCIEWiAQaoUKBPYBlzTculOQuoF5lAn 16WjoU7Mg05UnkWouyuQXt+mSQL6/G4WjRYKJ99vfLZe+AEZD5BwI5dWuCy1YdodqdOaClux G7YyLg4lh/a11+wb7MUqDI5q1ytm5bKK94FZ9fqyElx2j7nVLMuepdj/u9UsqziUYl/FgoTD EAM4lg82xCcETKQrPZaecZ+EtQjYrocA1/PEvEBWDr8zbebBRNjPUyENSTWGFmryrvA2AzNg e358X15Gie8gOcJiIqXdzFhGByMnbdyedKvMLbqeTAeU8ZeH3GG/8gZTjqXzBtHkZxgEhtMl 69nEMSnKp+AfrBK345M/SUU0XrhnMT7KwoVMO+OzJLN0jtfdOvU42y9PtbeQUhjxW0R/wOVB q0idVe3O1Ma/zSzdBlHEJhXEXS/IwZHnQnEM0G4O2W0JycE8Sv6hdyrq+m1rmrqnQhdHaY6e 7yYORJtlTWlNQy8V4V5LBvj3PfdT0H/CK1bqWO4CAdwH+g8ZL+47+pOrw+8knZ77UNONhG2O TkiPETi88Kwwky6iVKm+iVouFQ9WcbDlncQe01hCNbFc0MNlsnzdlmvTRPO3yXPywgOnCyzu wzCFlLmAivRwGWd8g0Of6FHjLpdI5jyW/OQg04qX7pdY4aCL/AGyMeHddYrePbuSeP/eRN1+ MkTXbdnrzlmy3Zqrv0g8HzkX/wFIlDOACmVuZHN0cmVhbQplbmRvYmoKMjQgMCBvYmoKMTQ5 NwplbmRvYmoKMjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3Vy Y2VzIDI1IDAgUiAvQ29udGVudHMgMjMgMCBSIC9NZWRpYUJveApbMCAwIDcyMCA1NDBdID4+ CmVuZG9iagoyNSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFj ZSA8PCAvQ3MxIDcgMCBSIC9DczIgOCAwIFIgPj4gL0ZvbnQgPDwKL1RUMyAxOSAwIFIgL1RU NSAyMSAwIFIgL1RUMiAxMCAwIFIgPj4gPj4KZW5kb2JqCjI3IDAgb2JqCjw8IC9MZW5ndGgg MjggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AaVY/47cNBD+308xLZRm 2yYX25vLrgpCtKmAlpZWigAJ+AOtqBDqIR33TLxPH4mxM/PZ63ivbOlJjc+x5+f3zUzumt7Q NfXUdz3/c95th52l0e67Pf+jYdvT37/Tj/QXXTy9sXS4IRt/bg58afBy7Ao3DPbeYU+E+37c +52nd1CXdv6gtw+CBhc0sDX8c3Mw16wqLC1tfWejQdv92Plxu6fDFT2Zic0LP/ywQze6fqSW 1/MVXcyz43vzW/qZms83pu27gZr2YsPGbKnp5DnZsHDUfLWh5Uivi0dxkZ29Fzesadrpcbjl qRmXLWrkHTUTrj3R+3iH0355ZRqnZ7AoDcQdLGDgEC+zFY+ie2wpNNUt/JXm5/RsjhlfB9aG wByuDEfVuxjV+Gj5/yWefoln88+G5j8XOYqJJQuMiVrGgmCzpCsJtrZzvbeOkvxB5N9J8v+z ODcu+M3EpfQ/ROywkAwEIJgIiFcCCA5hClMJyMy9cS+A9KOLcWM0GreLcYuP1m8ZkEXo3ifX bgndsWwJXZLNSB9G5xjquYpK9ErzMz4dqxAyJRXOdUMoB8cqUkRBKMQRAMYC8FRIt6fhaRJ0 zyEQVQm0JFQZjpRjUSNQIH+NQKZCcTgGqmeOQctrARQ27kWW2lMlIqEugd72zBLyHgijlKKe WrczZaWDtl1Qz8q+0Aqj8UBZQuqk9BkURQiBX7clZVJV30dVrHOInsbCJHGFxB/UHIh+oVXs ZFE1zaQQUidwWzfUBriLJOkJ8TtD2pchRFz6gYcWtyE/bakcfiWpMqFzah1dUuX2Oy0GZapW TenYpwxoZWK4bcGe40vUqN9w90LqGdKM0D8N7nIPhCy8gUJwVxamKfXhDhaIHkyo0eJxMKve MEsVsA9yIFnjkKCq/iNzOKv5QiBy6IFsWUnEiOEuByQxNSzmG087l2OYiur9kPFwS1H/gPis H4oW4XalrifUfUBo1hWPhaZK/qmUKc0C4gcsYAcpn1AxXsntRAoeLsq2k7EEbcfZE0SJLU1c 14Hj/Xldsy676Jqno/vx5hddc1WcP5FoAZJYAPNpcMOWhD1hvkUicEZLGWig6Ne06u9yg2fY 1dFvUi65GYY+deIyNTo0C/ez2gXTUBbAYp2Z2QTQrwYNOzI0VkNPoN//H6jqsgtoCL0rxCuh kVUPIDuqOHug+knnUA0tWPd1SAtXziKDKQnTg9hBuZGlfC0j0JrCeqLFnXZCyl4LAPBuKa6m UWRoscW3ktqEG8j6Gtk8QoSPMB6y1u/U6eRK3SzgJgv80nitP1FPeGAqZyR1Y3HLoIee49aq mQbint/iJjBYQyB5X3denFQeafBBMN3QJKcyjbv6So8CIfAd05weUcOW3w1/bMpMF5oxEhJG C/4SGvjDvLaqfxnyXOvd0DshO38Mxo/98Gj5lzJvd8EJ2AAoTZpMuPpZQDOTQp948W10gAch 9fCZeqTRkXkomzuVARCiUu+Lll8aXWxkwUcRnQyubvBhpBfPpU4kzy/H7tINVfcfPo92etNg ZIYrsAtMxM4d9e6uth9t+fgg+S6YzMR8GZ5c+HPTswo9uOWPMKX1zOrwrWjmAyVH7Hbs9na3 9qT5jcXr3w/e/AsyKnRPCmVuZHN0cmVhbQplbmRvYmoKMjggMCBvYmoKMTIxOQplbmRvYmoK MjYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDI5IDAg UiAvQ29udGVudHMgMjcgMCBSIC9NZWRpYUJveApbMCAwIDcyMCA1NDBdID4+CmVuZG9iagoy OSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3Mx IDcgMCBSIC9DczIgOCAwIFIgPj4gL0ZvbnQgPDwKL1RUMyAxOSAwIFIgL1RUNSAyMSAwIFIg L1RUMiAxMCAwIFIgPj4gPj4KZW5kb2JqCjMxIDAgb2JqCjw8IC9MZW5ndGggMzIgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa1Y224bNxB951dMkjpdJd71klyaWhRF UWeNpGmb2oCQtmjyUqFBUcQFXH9T/yeflOFlDne1q0iBIwEmRXIunDlzoW/pmm6ppbZp+WOs 6dxak9d90/OHXNfSf3/Rr/QvnT2707S9Ix2/d1smcjYfuwGFwtp7rGXmtvW9XVt6D3Fl5W96 9yRIMEECa8Pfu626ZVFhqqmzjY4Kdb1vrO962t7QxYZYvfDlQdvGtbbXVPOPzQ2dbTaGCTfv 6A+qfmtWqm06qvSKlTFUuRXVbWOpeh4WeGzCyAdO4oYuJ4cncYVp6sGnTVVd5dPYyztU2XiE GZnZ5CwTiShwAzHYXQrxi11BF7IjXLq4wOoNdqX4Tiz6+7jkWGO+zVvavKTLTXTz3Jo6ECRT WhNNGYfaGpVsaJMNq/9XtPkn8REgJNMzEJbctMhY68a0Vhsq/F3m/6DwP5qd8Qm0I3bF5U9h VUzgG7Hdq+L0YqaAQjVC4eh6vs8otN7AbmYd7RaH2naNNxl+yXSq+lCu9gnTHeCtXeO8MZ7v GkRk7yxYbzeIjlffGI4gzgFTEcWi54I0Md/vcYGD5zROGHmtIO+XOOEwyoGmyhlEGA7DQfMt cF4HV0V+AeQsUyIZcQbUi3q1TMD2W9ETWn0X2HLw4IjQXMsFBpFcQ4AEJYguJPKEehyUIdEc E5S65eggaxlZKkVkzMmcwrY0wRj/2M1v3hrD6YXtwxrwX+9bd3rS+pP29Lm7WilsXLxmpQvW S6gBfqZffwLaO1nhM6G9zPuLQntZxCFo/xi9zagCQsST8HE9fBOwwmdkzPgdQVt2QCQgFW6C JYgZAHBwQzQI8YzbcJXzlrAFCY6CWygBDMAEgAhEqWJUzXBcoyyCalRvUgWdB71owTRLyEq4 Nm4PrMw6Y6okmhrmGbFOlxiWFEuVO8ecCoVwKeYSA5gKh5BAMCmFOl0ZNJhk8yK9jVIgFAQ7 JBskEJALHkaeWDIhuh9juhicilufab3um3MfGrZ7Ve3IPiefwn5UtadSFqpPSShTnWdMR7V7 yrTA4KuMcnEH7LhrWc53AvIBNn6VqSeo3C2Oow4TCVD7PUid13Ya1XZ1TG1f5v1FE+CyiEMJ EKjlTjmFk2QfpIQ9nbJCJV7olOkzO+XcwIrHRRe4F5ODnbKqRplrkiBipzxLEM/CtbllhiEW un1IxyGJ35LGJ3Ar0ZCSoLYMrRwKh0r6pSQxMQKEygIn8mAvTu3IJ0D/KKGkI/PyJWyyndTo 6vD5TKagAtkTEodRu5XVksP3BIYqb6l7AuOtmr+FsmfalFjDm/KQZ2AwseDx3R5DjJ8Ojp+v CzO1/JTihtAax215agr59RSfxGGo+cduK/gQaRKtBSJhmMHicYA9978ywuE/RPhxQMjLGXgU HwACg6zs5f51lvKmCs9wFvdmlVdY3lLBM86GXnjfzc99c25cuP6sd3j6MirObRp6OlwFl0P2 wMoD6eAfPgqacb8u1QdHfsobP4eRg26P6s6kf1VA+xzvHIbxccXdfHGh7nzT6/XckdWfzF4e 3NcfAXbJVSgKZW5kc3RyZWFtCmVuZG9iagozMiAwIG9iagoxMTY3CmVuZG9iagozMCAwIG9i ago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMzMgMCBSIC9Db250 ZW50cyAzMSAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjMzIDAgb2Jq Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIg L0NzMiA4IDAgUiA+PiAvRm9udCA8PAovVFQzIDE5IDAgUiAvVFQ1IDIxIDAgUiAvVFQyIDEw IDAgUiA+PiA+PgplbmRvYmoKMzUgMCBvYmoKPDwgL0xlbmd0aCAzNiAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrVjbjtxEEH3vr6gkLOlJxl53tz0eK0JogyNIgCwr WeKBwMuQFUJZpGW/if/JJ1F9qdMeX5hZid0H97TbdTl16mLf0w3dU0VVWfGfdbZu9oZa05Ud /1FTV/T3R/qZ/qLLbx4MHR7IhP+HAz/UuHTsDk8o7H3CXhLuqrZze0efoC7v/EG3L7wG6zWw Nfz/cFD3rMovDdWuNMGguuvKtq07OtzR64HqOhzgi7Plvqp3HRX8Y7ijy2Gw/OBwS7+Q/m2j iqo0pL/dsDGOdOmvNenLdL3aEB9oSPc2rPgWFpXc28ZbSr9KUi7CBottZbH3d3jjq3g0K3ot G04WSaWCLRACsYdw1pLGTi8KrsMt1tSEBbu0DT6y4WM5v9Lwjt4MIchzLI3HIALpbAAyXApn VUTQRQT1Pxsa/oxyhAYSJGbPmYKNKW3ljKUsv0nyn2T5Z4uzbaTsSFwO+EuAgAWAl9i/T7Fn cDNMnoNqxMGRe22XOOhaC9zsPuAWLoWry9Ym8kXolP6cXfsP6E7INk3ZtNa27KtXkaKzgN40 hc4339qy8RXgWEVG9J3w7EaYJzgKJQEwuLmeMH26dS61fXYytS8kj5/l2MXE/tpvcKYg8ZC1 SG2xNyWT0j3SCrku9UDOSr2ANKQbvG3FJij6bmocOFj0oqAQDSgMnoZqnq2m4rQhx+VNUvWI cvxjWuxSjVAacYDRc9RnQALAHlYDdTwOgQUghEPioUkRAXRgQ4+zY+djHAU7gScrEJqNqZOq +u+BkswPBAVK5amfUkzWgqQ07ojqfmxdrhC5QMXQ2G6/FpqUpzmJCgAH3AQu0QrUcTQ5pdCs xCd5BLKmj5AueulVcjjJV76nLDmFTmt3Dfw67g5duWv9cJB6hApd9rE9Yln8qEckLeu1Lgfi hM2jTnEsNAfmi0QPiQaQRGXADgLUJ8Yo/T4nfIb0nFJszQp3xmVemvDnx3WSZdn/aydZVnGq k0jJQXphASKjQKDZSB1QusgVSjZHM08vBQRhykLxYMyFkAKx6khyQJ1sSKqhsKzW1JE0UKUO dens+S01OTQUWA6BQs+V3I0FybQrpLL7WUECSuLoBCPSCA4gAO0FJAiBwSi/81vYkYpchf7J ozdSDQtRABvmCqYQqyxGwBIpZ/VyHwOeqpMipeEJep+IQVAEun6VG56fqVXBA0wCYh7fycUj 17YU0zoX4/CqZtRwoFOTQHt9dXXBMLBDbruttq9WdGD6NFx/axXfCI6Ezydbeuxkuyx7Uo9S Tzljsh29HB6bn15osvmTejSbl55tVBguwTIscrCw+uhLPZNVyIWswHQDosypI734NgmBVCRF kWcjTF0LQwPOC/dOpu3CfAMhMCOPVgsQiKproTISAB6PJWYuM178xtTwO/vCSvGHhEx2NHIe d51t+G0kcpFfGsN3AH8p+Md05H2abFH8FpyqKDxAR4CbX3r4uSrLFTfehoc5umWixBuRNgs3 0lf6DYSI1OdJywfthbG6D5u0w0czOtl52zg/6a95vmvLnW28+7Mq/hIvZ98Hg/lrAFyBXS/C rXEzehIiyWPzU2nJMgbhoR+8yXziR3+NdXHJ9MbG7zOwPtUQLqbhnZJrVQ6hqduyM/t5IBkh ViwfGm7+BTDmfaEKZW5kc3RyZWFtCmVuZG9iagozNiAwIG9iagoxMjMxCmVuZG9iagozNCAw IG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMzcgMCBSIC9D b250ZW50cyAzNSAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjM3IDAg b2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAw IFIgL0NzMiA4IDAgUiA+PiAvRm9udCA8PAovVFQzIDE5IDAgUiAvVFQ1IDIxIDAgUiAvVFQy IDEwIDAgUiA+PiA+PgplbmRvYmoKMzkgMCBvYmoKPDwgL0xlbmd0aCA0MCAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrVjbbtw2EH3nVzBJ3XIdSxZJUVqhKIImMnJp mzTFAn1o+rRtmqZxAdfflP/JJ3V4mUNdd20nNmDREjkznDlnZsgr+VpeyUpWZUU/xprabbVs dVd29CNdXcn//pS/yn/l+ZNrLffXUoff6z0tcjZNu8QKgXcf8C4Jt1Xb2a2VH6Auv3kn3556 DcZrIGvo93ovrkiVH2pZ21IHg+quLW1bd3J/KR/vJJnnf+mhLe3AbRtZ0D+7S3m+2xlauHsr f5PqwUZUZS3V440sxoOT8EZLtd2QmfR04YWVyvLcMx4UpZ9TC3UenlK1vBhSCizHK+0nG6n6 0zCbRlhW9IXdiGgRXmJazya9YjUQDpNo8u9y90Je7HwcxTF3hShbudsPHOearrS6dmPHCXKc chd/beTufZJ+i2A0piL81NrLFKNgKPLLIYnahyfG1sbYhkdhWgqqoKDaGFT1McthZMb5hMwl 3CwKppeuMp2VJD/Z6ZL8e1n+jcWZNrJoIC5j8CEijAEgFoEl1csELHJSDqunhRjQYrC9tku0 sO0WfjNN4ER4FKYrmzrxIbpOqE95awdcd0S2rsvadR3xLahY996U1Tc33xiKDiWlsYrs0R8C L4iq34UB8Zv9yATl/0HGPn4RmIkvoBRIhk/MQ3xB3M6YvSk1yAOpoQpGOqmgCdkofRJIQj0o j8nfemjQXmEVNg2zHqVMcxKsolxWB5WUcab++IMdhp2wp6Cv+D7aK9SzJVBmTuhKU3qzNeEh EXcMQFvakLkjfXP0bpLewBTsej2Ac/8+TS6Dg35OO+HNpgAI9cR/oNBAzSHn+hIyLBTvkpoo VeT4QloBcax54NMoDTN6trpMNStL4cUcTa4s8533wCO2SGJySplFTzdHo5cqqi8MVFERGSCI WcJPthYzMUiwFLnEJqxJhQE7aBaZHggFfYB3OBERz5Q4HDWwUmQM3DFqvkXwSPJ1nWCCSNwh agGQPmoi1ndU4Mg5s11L+plz4z7okccU5QMgJu8RMOsxQvroMR/xQd/C2+Jwr+AM1cQ0ucKP E4WvVKmMcJH/dLtKtSz7i1aqZRXHKtUvnIgBTNAGcJ4BJfFlgEimFqSAUgWC1iNEnB4GsxmT mA3tmJQRgaBj0qQGCXUxqyPZEJCRkQHDDK+CGdQ2e9OG5Y1X9dgj7IEgThKQA5dBRd4XTVpP gMY4JMDQJFPPtJdjfCZSjftZSoVn7uy0NZaIQHSvnG1PyHYaxhfxr4uP9mRoxdL5RtP5huvo qAG2NRE3ttLMjo9ghzjQx+HotCw6t8BJg2+yb9YELwvMTbAXOPPWV6kGk0NCokSA5iFD5BnT Yr1BHp4blzpM7dZy5eennWXZXzTtLKs4lnYeJB+jUmIwZczguJtoJlTRXzBRwThmJdbPUtJi Younbw454voy2Qdpf2MEsiP5xL5I5AM6q87NMrCERVA16yNIVcqGh8tcujBg29kBE8GDJJ33 AHOggba3noO0sYH6gu41FjPP7FoDRsDpIFEa5LuKmeFYzF/m4JgGQShuTrG1OwYhuf6IryaN Nitng2NMRG4a++n2B50OIDEpYqMp3ixq3ljR5+wyIGI92F2uN8djLajKvGcugiKju6ZbanKm 1Kbp6NKHQBfOZ7NEze3D2r1VIgZgNLy3Ir5TAXwVTKYB/IggjO+tJn3twDfxwkqMarGxlMqp zmbbx8RYu7aKTbMXLuIFU3a8aTXdV7V0X8XumIgkp/OtFR0UbWscXUFiRNvld8u3T9aU1tBN UzogaxNuaMKjoL/DGzIf6/tzh4Gc/azp+dpnUWrq+QmAPA8Zjo61TJgLxhBnM+SNdKyWw8N+ ZB9L/SYdHd6opO7NJg1I3xL6jLP+XmBt501bNobwp+ctwsMXwU7qBnHD8zy8GZ7QATds917Y LtH3Ptc97jUw5cdUcH7yTwLmiumOUOCvm2F9Agx5JNxHERxzCHXdlp3e+p2MAinVPySeUfP6 f+tEY6MKZW5kc3RyZWFtCmVuZG9iago0MCAwIG9iagoxNDkyCmVuZG9iagozOCAwIG9iago8 PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNDEgMCBSIC9Db250ZW50 cyAzOSAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjQxIDAgb2JqCjw8 IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgL0Nz MiA4IDAgUiA+PiAvRm9udCA8PAovVFQzIDE5IDAgUiAvVFQ1IDIxIDAgUiAvVFQyIDEwIDAg UiA+PiA+PgplbmRvYmoKNDMgMCBvYmoKPDwgL0xlbmd0aCA0NCAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBvVntktREFP3fT9GgaAZINukkk00pZQnZUlAXKEcsZfk1 gpa1axXuM/E+PJK3P87pznQyLPxwl6r0Jt19v86993TzVj/Xb3Wt66qWH9Oarj9t9NCM1Sg/ uu9q/e9r/av+R588um70/lo37vd6L4v6Nky74grFd5d8FzZv62FsT1t9SXHxzV/6zV0rwVgJ oo38Xu/VWxFlh43u2qpxCnXjULVDN+r9lX6406Ke/ZXHWA2jGbejLuWP3ZU+2e2MLNy90S91 ce/hRpV11emi2og28ry/0f7FUzdodPGbG7RxykmYOmDGHT9QRecGRhc91mBumKILLmrdFJGI KXiGtar4ysoRuVMJ5bjLs6ACPny/opIsvg8LH0IgdykniKBW8u2V3j3RZzsX/9zNpqsGcbPy bm69m92jNF3wb+v9W7zb6N3ffiuAxM8XkCyFcG3vpq762oytjiL6IOJWFPExO5rBwzrZMQEF vcEBg1VtlIPJeXD4zF+HOE2MHMaA03bcOgcKTpXg1GwdTt2jtFq1Nrs8TOHG99HGI27MJIQQ RQlNV3X9OG7F6LmgBWfOTFGzeGWCQspFQcZIvKRoZIKMQuJ97cDY64KeBfzxZAoBo1kaqOKj 0iDk9XIaSFQl0xhvpsgEdZBp/IIXXBMG6kgpmb6F2Rwgc7kv9ytPAtZqLGJtgks490WW2z+4 N2LTA/9JFdyGq2bgjenT1E1ldLvtAVRbUGN0awlrLUVVftRhPV0wkHH8xqaM1MZUvJRaqbBB MxWLLyveofu5+KkzSxZnTgme/D/QQW2I4lNrpGgVvK4LxnUKk1V89Xq52C763/VhKbD7JBKd GSWjhyPxePFiL/+6vn+zkYJZ3OnFn/Z5VHAn0Y0lfjHwWSMVU6RI6+KS9u5dgCTeWYv9zs4V ZHIGQ0g3Mj04EANEQOK8ki6eSgo9hMsfHvxJmWEWILuQx9yDMxorUgww2ITKYA1moCvQkHIi Pol/fiRqKLLkpDuuW0uIyumZFZ8wE5m91JoDWppPyFYqQgthGGBMX8TEDkqrAnPWS2Rqlq2+ YtaE4NPi2lks0MkLM6XTdX+6UAh2DhUN7laReXENvTz9jtUTdIeP6YnoZGX5b8Z/zOiTI/S8 Gf9pbdmct+53tnUrR6aOtG6S2NXdIwOyQkLZXWjbH6Nx5EDJnpEFfR7gh5RiwAgWvqH3gBJV nIfV0Z/CJ2ekQnh84mCSCtN7gpmRCtt2Am0J9n8iP5pLULG+fTI/+oApGRFb50ee1dqDCeEr NMDXgeBuFROF5RJwRlZEyHNUgmgwfChanHL09LJUerKg5ZbKQbAZt5a5zylnxBnBQ2u8wYoH I+IMtCdjgvpDTDDpG3IgOsoExdmLTBD9Rsl5bIbqmHO+FBsJr+2fiwgOxAn9k3wYmaMLNhma vU6cOIWHPK5GuBndiSOghavRxs68ZxKqSF8d62fcmBsSSWxn1AsQZS3GC8CceHhkcS99gds/ wEkWthHKpALYjHov7Wah7GvyYegauUS4aeiYqi3UolB2MqiT2ZaFADOQlNSb1h/DLQWyY/pU SSJZ5jv+7MItBAdq8hSBROMLieNSAfCAX/WaXLtUpk74aQZ7RDIaB9Hnoeqtz7jr1U9spBtg ECPy1M0V/rF0mUPLknulRcscB5cWn3Lwvh6q03aQ6yUciuZGFr9IBHELkuFtuFGpULM7q4uL 4Jqc3MJuxpp2h9RMjlgRWMxNLmMicxJTjZ8GMlVIpfu5aoEArsVTFSGeCRGkLKRL3A/5QpVf BaesIJWtqulO11N83qNaX52L9zGAR0jchyXk/GKdyN2EKs1NSYjMDfjFZ8FdjH1y4vY3XMyd WPrB3RHwc/o8sHvEiYFjXyIQuS3bPXYjaviFwQ1lLUEvygQXcS75EmshRWIRocvVZ77zJefE eKaciGsOuA7l+jnqC/OEjqUacA5fHNAIQZu9HW10qD2NvSjsb8Ii2IpCEFVBfaIZFEt3xGyi PSA56AkJb6KDES/Yw3AhJymJnDPsH8+MCUACGeP2XE1vQyD2F0DaS3up5ke2eYmIimwWeEso 2kEOAGMcCdrxbnYi4aGsNVVr5P45RKIxPkz2Ucof6RWYEuZ+O1eKlkyofnT4FzaFpAXjyQ+P nY1Cf2D9GQyCG+h3HsBXd//S3iSKlIsiiLvYhMHMO7E9mb6V+auWb4dqa3prfnYDeO+J01Mo NG8gH7s3KZNjqae5t0CibqMy4fzJKT+GavOTfUrwV1Tvjf8vIWofDiWCGHcnLd07hrDphmps TrNA6uJKtkfbfv4flAEIOAplbmRzdHJlYW0KZW5kb2JqCjQ0IDAgb2JqCjE3MjUKZW5kb2Jq CjQyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA0NSAw IFIgL0NvbnRlbnRzIDQzIDAgUiAvTWVkaWFCb3gKWzAgMCA3MjAgNTQwXSA+PgplbmRvYmoK NDUgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0Nz MSA3IDAgUiAvQ3MyIDggMCBSID4+IC9Gb250IDw8Ci9UVDMgMTkgMCBSIC9UVDUgMjEgMCBS IC9UVDIgMTAgMCBSID4+ID4+CmVuZG9iago0OCAwIG9iago8PCAvTGVuZ3RoIDQ5IDAgUiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtWNtu3DYQfedXTNIm5caVLJHiaoWg KOKskTbNpS6EFkXSp22DoohduP6m/E8+KcPLHHIla71B4wUsrniZM2eu3Gu6oGtqqKkb/jPW dG7TUt8O9cB/5LqG/vuLfqMrOn1609LuhtrwudnxJmfTskvsUHj3Hu/S4bbpB7ux9B7i8pu/ 6d0jL8F4CYyGPzc7dc2i/LClztZtANQNQ9333UC7SzobqevCAn5YW7t1bzdU8Zfxkk7H0fDG 8R29If3LSlVNbUhvn6yIR450vWJYHelvwwsenMlge5qmHoQ3LeleBnGT0q1f4Y/D7teyZOOn yj04RWYAgQWpgKEJmxnU72FgScvaLc51MgWRfPAfND6n89HbUM2pMl1JlTWBqvCo+H/kyEaO 9IcVjf/Eo7yhVWEG9o/jz27b2jS2NZRFOIbGZtD3sojPOdH00TX9iWpq2BOYBgMbiGKDioVf ZXNmvryvLSjZD8nX7GZdEmg2gcDwqCxzW3CovIIfs4ISLOLKBYd3H9+62vXG9Kyxl5KUdslS BY3TgLlbispKGFM7H/JJyixmMrXw4C1GG++57OX/M56imyv93dRmCEZYE1EjZgWW71MwpihS usJxWIOAfRQkcegiwmYHI8DOQtZgT0JGwG54W4W5CsKurniYXS07e9twdJDtolupmMKyRRqq +MvUxY+DHhNJAd2nuVuhC3/ztUkBVaQ12AHKZYuDOMwhR4kFFIJwllOR6gQPjoNMkAxgeCOb MukVhPPqA+S3JsT0keRPfIv0HCVCQVRcxE/6sXdVTu/AisyfrKGwBKTuKcZG5agDdyJS6MAm F1yXJckKzMDswFC9kehbYA7F13Du8sU3kbdfUYZ63fuW4WBdKct7ka3ullDUlX1Bt6TFHHB3 n1tUl/1zc/PwdaofQmUiTmkjvIFK+GeOkldL1aekouh0UB64Fzu2+oTyKtVHXaBVO1R9Fo// otVnX8pnVJ+fArfswMjlEx9X+k+hHzVClsAMr8MSjhhYCO6PgGhCqHDzhV2YkuifYZD8lpuM 6BxKY+9xaftADxoz+nEVB1JzQ4os9CDoxxzwouW82A7L3paLUuzkuKH+0tqJ5WCeAr6vZBF+ HKDixk0F59Nsmqs80jZ8BdbGpme+p2GPEyy/in+B3ROMsgNgO6D/HCK+gJUXy9E/5KQQdQIa uBo81koXAh1Kbg5Y1Plk7dJFadJlzBrpc1FWIEJVzABR1ictUnrOgvRXQH2Q+VgW63Qfeurp 4YgEhlkgQp6IAW/Y0/rDuNEThXJogOyZnKyZ7IKG23NhCDw88zALh4FogQuUIOGJJBtee8B0 xi2bLjeI/tLBsQjHE8xTXFK4gK+SNwD4OPm+NChylCwsYyHjZiPZ3ji+jd8yUvwTwS2VmKua NY6vHbH75ZtiuOH7R8Vfpt3v/cS2ymrC/bezMHroLcI2lyc0/jEYL1z7Y149F2uKhnBPpJfF 079JUt7q5GJvV+nNglWNs77vX9J83ddr47z6s7A8eR5wspOhIEIVKIcagTf3JGfc/8oj43uA NDFY8iJNvPTP5ergTPzlBehT78dpK1wexx1lE7ZdXw8t/wQzNaT+l+XK7wsXnwBz23BrCmVu ZHN0cmVhbQplbmRvYmoKNDkgMCBvYmoKMTIwOQplbmRvYmoKNDYgMCBvYmoKPDwgL1R5cGUg L1BhZ2UgL1BhcmVudCA0NyAwIFIgL1Jlc291cmNlcyA1MCAwIFIgL0NvbnRlbnRzIDQ4IDAg UiAvTWVkaWFCb3gKWzAgMCA3MjAgNTQwXSA+PgplbmRvYmoKNTAgMCBvYmoKPDwgL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBS ID4+IC9Gb250IDw8Ci9UVDMgMTkgMCBSIC9UVDUgMjEgMCBSIC9UVDIgMTAgMCBSID4+ID4+ CmVuZG9iago1MiAwIG9iago8PCAvTGVuZ3RoIDUzIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAGtWe2O3DQU/e+ncFugmW0nEzvxZCKoVrSzAgq0WhjojxYJWFEhtAvd 7jP1fXgkrj/uuU48me6gbaUmE9v389xzbfdan+tr3eimbuiPbW3nNkb3ZqgH+qNd1+j3f+hX +m+9enZj9MWNNuHvzQUtcm2adoUVCt8u8S0Jb5t+aDetvoQ6+fKnfnviNVivgayhvzcX6ppU +Veju7Y2waBuGOq+7wZ9caWf7nTXhQn0MLbedK7XS3rfXenVbmdp3e6tfq2r+26hlk3d6mq1 IGM6XdXp+elC04DR1avwQjN45JxHmvDidHUWXjpVfclfeC6kbLxYkrYtpjyOi3X1lF+2q4UK tmB1H4ZoOYt5wnNZERa3PJIUKdgNIa95Csn/Re+e67NdyHUZUttlIVXWhZCGx9I2KZhtDGb1 YaF3f0VRDAhOF+FoVraK6RLZm7p3tuuMFhUuqbgnKo6RaPsI4UyiIOARwoIXhLBOeXghmJB4 TTGZOdkPjMmm4QAqwqS1MYD+sbQEy95XUsQkh/Ff8fFAGAsNHEZoINTb1rWuULQnmCNXFBWw RLdQlMpLXCE/nCeIQpFVXGU/BMDZW6M/ViLQz2n4yqchK0RUzjKbGteiRi1jXeo71hayjReU swtrSBEUYA4UUY16TVJdGBFF0RQU/PZlkEtVPHUEpfq1AC2Szxmbv4UJMJO5IENnXPQ4cBpx GRyBcZACjCNAeMEqdlHC2wVzKJGTOboiDVIaAh/TmNrqto88UoCUysD0tQv8PaVmjuMWWfh8 lH9VwZlnfoB4GG5iCezEEBZlEfAtgMI1FwFd3TICPvwKnWTOcC2Gw6pT7wHFFcldPuEkYg4s XzLpw2AakuiXtEGFGJvlOB1FKbdrCqMd2rmsUIBVxvGjlpxxBloy8Q/Tn2/JwvGe/tZqTHwf bkV8M7Kz3pT1j3Xi1j2UJxAtJDJK0e2y/sESpX98kkqW4QrEpeQoqRUkUDYBWe2OEjgXWtBx a2No2Vjw/p11llkNd91ZWFGCIxURtRPaql1k/bJsMgk9kogHnkWJXNPD54F+nfryoadJv1d1 +uDTQ9/DZ1Wd1ivPbfTB0wI9kpQ0ufb9hL6mRavap5J+p4evWvqVZHnykbEXJEJSK7CLpWiH flQheRqZGceeepLjGiyk9e5IabQFfmem3AP2BEWCcS4fpsmRclX1pkoffh8N6OrX9Hu8QFe/ Tea/u6BwEfep6ig7DkfV/Y9+czAOqUOUcTiJ1uuK/f8n+Zfc0tMIqYo9JlCmuWD9Q5E/7HE7 TweMo+Lwc5zHuzmPCEIYmvNIhboKXVZieNgjopnsOCf7zWzPcPvKMIM5UlpeGb6ww84T+aH2 7D/RpuHyUHmz2oKlN6Z2/drQoXQ2O1t0d24tCSbZMRPoQ2sptgYIN6fmjC3nbTWJnyco9qDY K1jr6rYb1uLBOBs+fgUsDgZS4KD8zcN4z2J6nKTCVmIfUY4BHolSTc62aKCm89cFrvDrUP/M Nz/hxmPPAfejCsr2mQK3Z5cyOpjRvUcWlv16lNRJ2TLH8aEEfcu4BprBRH3YflIbo6wQ0OmF 8bMtDilL9AlGKuokrc726gzQJSALDVCO5UsABpNgGB9/ZDOVzmT79telaFgmpcymQVe5av4A ZPxdgT/ivuSAwXa4A8EcS0zB9U20IStxrPkxyPUaIA+raNKBEiYkENILDsqItECG3/6EIxXH ZAvPTwIyyA7MQZiQ0tsmN929wUeILNVCNiZDbYqHEqweyOl18IwO9w988yUCf++fdHj83j8F 8LIfmUtSFoGfODc/hxeSmmcku62UqqWD8Vx7o3zN3gxFPiuPeKDLj2u4cwIauXIcA33BOAOF oOtZPgAj/swuchov8wyYMIISXFQlNyhA0BZvQDcv25akxkN0CI6MOAVgRpalYVA1AaCaA6Aw LgKAemdTUC/pSjeUgDAB4brtraM78X1vo3Yip2Bbt9Y1NtGFiY02PJb07/SWhi7Qp3sjWJk6 RVaXn6UNLz8RlG8YB+zZGRcSJz0BhPLIX4o+xFL5yIGzyZtF0kv6EJ2sKi3dU9AtVfI8bQnE 83Vfr+nuYp/7j55H95X0UrgC57BLw5d77N19ZiG+RgC4vvMmE5FktATTs22Ao3sA//8fU+sJ of5SVtEpWhwxnak3rRtKV+iU8pCs44Pl+X9EzuuwCmVuZHN0cmVhbQplbmRvYmoKNTMgMCBv YmoKMTYzOAplbmRvYmoKNTEgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA0NyAwIFIg L1Jlc291cmNlcyA1NCAwIFIgL0NvbnRlbnRzIDUyIDAgUiAvTWVkaWFCb3gKWzAgMCA3MjAg NTQwXSA+PgplbmRvYmoKNTQgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0Nv bG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+IC9Gb250IDw8Ci9UVDMgMTkg MCBSIC9UVDUgMjEgMCBSIC9UVDIgMTAgMCBSID4+ID4+CmVuZG9iago1NiAwIG9iago8PCAv TGVuZ3RoIDU3IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtWeuO3DQU /u+ncAsLmZaksZ1MJkJVRTsroIVtVwz38mvVglCLtN1n4n14JD47Pp+d20y7sCs12fj43M93 jt1rfamvda3rqsaPdbZpd0Z3pq96/Oi2qfW7V/pH/Zd+8OTG6KsbbcLvzRU2tS6SveUOxW9v +C0yd3XXu53TbygufflDv77nJVgvAdrg9+ZKXUOUfzW6cZUJCjV9X3Vd0+urt/rxQTdNIMDD NLbadu1Ol/jj8FY/OBwsNh5e61918VO7UWVdOV18sdF4aXVRbaBWo4uz8MHoog0vIGnCi82W jKfFh/29YUkV5b6TfS8iI6z9pg9P9fkhuPSU5sHhTh2uMhsa11RNt93ObSja8983+vDnSe5q 6pemNxWiahd4wvRjHG0TPB05uiEq4VHaLrrYDS4u/k6sJE8kikivuS/WeBvEpra900lEG0Xc SSI+hKPthszOOKa8uM8o8sWFuCIxqo0KCXKREiXFd5qqmZFdH1PV9VZSVSFV7TakaniUtq+2 kqbiw3+SgUd8OGMf45PYGyRR2/fIolzKghunRmT1NpMS6y1JsRaRAmKMpYhrVfFRdNtn4k8W Wh2+oASlrKyQzIpzoFAsVjIr98/DprxuuUhJ/CLFLjF9LBIZdu4piQP8dC7UwiauqGLnjVzU 4eewB2jyuSfBk3n1IDpGmEVdVEKiR54CcPNQ5NJjIo8r0CQlZSoLUxswcO0ur+AUuxpBc5UL gDqFygVky5zkURT27qdG0Fekpb2MLl+ih1UhXMqJLzLolZVSTP9BnEKRzwTb6RXZRBLJNAFw vQbgag7gY1/GOhjQWwO9k1dd31VmGyoiOleNnLuG4esC0L5yAY2rq671FbfIH33uzMKliA8c gH9/+So8zozbPTyeKJ4xmuoMSo4lCiMt3pZofhkyPhUtCRmOkpFiZs+JmC4uxBeILAK4wlLl btElz5KlAuE84eoBpJe6HLqx/W99bpV76nOZkAWITiV9WuPU6TKeAsi6+DjijniRzrPiX36h O/dE5Iu4e5RH0wair5W0ejYQu2UX9ANbKhefW0e6oLrkxLkwSZxmP+mCsRQXXDw3gvPKihSV jDjeBXXxTNoAM14yNBaDYhc8iU0Lw+VMwZjGS/BkWgzrrm/Hbo/5sYZNawKSB0zvqtYZP7Fl 0Uxpx6KflnrW8F755MJAQBI2bnYGyVqupNR87Qc17KYkaRXMZ2463ZUxV8QeN99NAXsy5CCB tSWcGbDd2ts0YqB3GEAJd3TPzlvs2zDLky+yibpSVdpTcm3IRVVchiwFQ4oiMaFA8ja3eBgG 8okp+m49AqUEkhKoOl9ELSGlDlScRzRyEVqSTFRQBR3xXkngT4lwCPlz99lGHQl0PTTS2bS8 1kgVmvZ3wfuY91Jb3KcYMej0wpNYLTRVpuTbIEhM0JHeSC5M9m48fJhuV9W7HudrmT7Gp+w1 BBkLmE0Y1phquzP+sLI2kdLOqSsyBGF4GLDkQSY1p9a0FsnVwqF/NoVnQUmRkrKAkjEt0LhS 1x6sN92RHrhmdh2ACLhG29aznvPtc6lk+iHuznwlxCRhSYsxrES6XqoJiONLHFqRhnlJYsaJ mpOG5R+PB+kItaq5Lrj7e6mUhfFu5Ha2LYOxKbsuSm3r2PShwhXO+5zBV9n/r9PHWMoHTB/3 GQDGJs/c4X6DS9fBuziqytH9XQSab/0TYEjKhQzyWREuTYaexexYAavsCPkitjlyh4oTblwS wR+AdPOJdOxO6DsHuwazTGNtPxlqwAv3iWtIdzrpmq2ratPIzcz4eOiPb1K9dJ9U5J61z2Ig 8QBUKk1PKcagWW9Wph5dpY5rY+2EyYzaCyRITC5iHGdoElVXxZ53ArSvjDequphtoyQZaUj6 yI8/6JfS84k3flq8hb0WYXHbxo+wi2b7uMhFKbDPdbbFBfTSG27FE/anE5vFDSyuNWPzM3a4 1PaPEn+MLgmQBXcJzHQBnbMfnJGh+Sfe7XCGPJkWX4dkAlJLDp2HD9k5mhjMxiiuJhPh+mmU 8rKQl018ASldnl0g2tb5G6hoeZyHkuXbrtpaHEUWzL//dMAhlQ5PNIV6MRf45Y5Yd1fgSw68 mNiGYe4brzLsz/CMqmdxa5EF/j8bptqDib/w9Ff2yRDTmGrnWiDF1JTiJX6hnmTO5b9WytR/ CmVuZHN0cmVhbQplbmRvYmoKNTcgMCBvYmoKMTYyOQplbmRvYmoKNTUgMCBvYmoKPDwgL1R5 cGUgL1BhZ2UgL1BhcmVudCA0NyAwIFIgL1Jlc291cmNlcyA1OCAwIFIgL0NvbnRlbnRzIDU2 IDAgUiAvTWVkaWFCb3gKWzAgMCA3MjAgNTQwXSA+PgplbmRvYmoKNTggMCBvYmoKPDwgL1By b2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDgg MCBSID4+IC9Gb250IDw8Ci9UVDMgMTkgMCBSIC9UVDUgMjEgMCBSIC9UVDIgMTAgMCBSID4+ ID4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvUGFyZW50IDU5IDAgUiAvQ291 bnQgOCAvS2lkcyBbIDIgMCBSIDE1IDAgUiAyMiAwIFIgMjYgMCBSCjMwIDAgUiAzNCAwIFIg MzggMCBSIDQyIDAgUiBdID4+CmVuZG9iago0NyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL1Bh cmVudCA1OSAwIFIgL0NvdW50IDMgL0tpZHMgWyA0NiAwIFIgNTEgMCBSIDU1IDAgUiBdID4+ CmVuZG9iago1OSAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFswIDAgNzIwIDU0 MF0gL0NvdW50IDExIC9LaWRzIFsgMyAwIFIgNDcgMCBSIF0gPj4KZW5kb2JqCjYwIDAgb2Jq Cjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyA1OSAwIFIgPj4KZW5kb2JqCjEwIDAgb2JqCjw8 IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0xISUhUVytDYWxp YnJpIC9Gb250RGVzY3JpcHRvcgo2MSAwIFIgL1RvVW5pY29kZSA2MiAwIFIgL0ZpcnN0Q2hh ciAzMyAvTGFzdENoYXIgMTE0IC9XaWR0aHMgWyA0MjAgODU1IDU3OQo1MTcgMjI2IDUwNyA1 MDcgNTA3IDUwNyAzMDYgMjUyIDUyNSAzMzUgNDk4IDM0OSAyMjkgNzk5IDUyNSA1MjUgMzA1 IDUyNyA2MTUKMzkxIDQyMyAzMTkgNTI1IDQ3MSA0NTkgNTI1IDUyNyA3MTUgNDc5IDIyOSA1 MjUgMjUwIDQ3OSA1MjUgNjQyIDQ1MiA0NTMgNDU5CjQ4OCA0ODcgODkwIDYzMSAyNjggNTU3 IDQ1NSA0MzMgNTMzIDMwMyA0OTggMzAzIDI1MiA1MjkgNTQzIDUyOSA2MzQgNDYzIDMwNwoz MDcgNjYyIDUxOSA1MDcgNTA3IDUwNyAzODYgNTI1IDI1MCAyNTAgMjM5IDYxNiA0OTggNjkw IDUwNyA0OTggNTA3IDQ5OCA1MDcKNDk4IDQ4NyA2NDYgXSA+PgplbmRvYmoKNjIgMCBvYmoK PDwgL0xlbmd0aCA2MyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBXZTL btswEEX3+gou00VgWhSVBBAEBCkCeNEH6vYD9KAMAbUsyPLCf99zx2laZHEMXM8MOZccavOy +7ybxtVtvi+nbp9WN4xTv6Tz6bJ0ybXpME7ZNnf92K1vyv7rjs2cbSjeX89rOu6m4eSqKnNu 84OS87pc3d1zf2rTJ/33benTMk4Hd/frZW//7C/z/Dsd07Q6n9W169PAcl+a+WtzTG5jpfe7 nvi4Xu+p+pfx8zonR0dUbG8tdac+neemS0szHVJWeV9Xr691lqb+Qyj6W0U7vKXm27rK85qS oquzKg9IQG4lCyR4H71kRIL3/kmyRIL3IZd8QD6atOQnJBAtFW2Q4H3eS7ZIYCNbqkOC92VS tEeC9w+FZEIC0Sg5IIGo9g24FUS1VMCRQGojWjNIVlcBcwKppQLmBMlqMmBOIAdJzAmaVBsB g4LaIIlXQbJJvAbzWzSK4lV4P+hgA14FyQ+SeBUcrNXiNZjf8lFRvApqrSu8hptf1RZ4Fd4n dcVFGaysjQr8CqRF8VqYX46XKF6Lm0Hdb4E5QRs6jQJzAoPat8CcQOpguSiD07Ao5nBKlAWJ Yk6wlO2LOSZK0nrGXGEGWZ9kzAlmQ2fFcBn03EriSLCvTiPiRrCRzooDMxgki+KIHYkyXUQx J5DqOWJOIJkr3sPfwc/Dh4dAm5UYWq+hivgW9G8S7xGI6twiRgX9a04iRgXJ1j9Go5nllyhG Bf1bMjcZ7TZZP6tKvJfmjrFE4k7QsJK5Q4Oj0L6Mf8WgVrnfWi39Mk4kl/LO+BvU2lJcDv+T zCMlSr+CnnUFDIuB1IvjrRhIW5l+eYlKlgVeg4HUqfKSDKSGitYM7FsUNzxMarni/89cnyN9 Nt8/c91lWfjC2bfVPn76qI1Tev/8zqdZCxh/AN9sZvUKZW5kc3RyZWFtCmVuZG9iago2MyAw IG9iago2ODUKZW5kb2JqCjYxIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9u dE5hbWUgL0xISUhUVytDYWxpYnJpIC9GbGFncyA0IC9Gb250QkJveCBbLTUwMyAtMzA3IDEy NDAgOTY0XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDk1MiAvRGVzY2VudCAtMjY5IC9DYXBI ZWlnaHQgNjMyIC9TdGVtViAwIC9YSGVpZ2h0CjQ2NCAvQXZnV2lkdGggNTIxIC9NYXhXaWR0 aCAxMzI4IC9Gb250RmlsZTIgNjQgMCBSID4+CmVuZG9iago2NCAwIG9iago8PCAvTGVuZ3Ro IDY1IDAgUiAvTGVuZ3RoMSAzNTIyNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAHUvXl8lcXZPj7zPGff9yUnZ8tJzklysu8JkBwgKyFAgEAChH1V2UEUUHFX1GrdWq11qa1a sRoCSlBbaUtrN6xtXbpp9e2itaXVbtYlyfeamTMhoH2/7+/z++f9Jty5rplnOc/cz8w999wz c9i1Y/c6YiYHiEoq1mxetY3wn1r299k1F+6K8SQp2EiINnf9tg2bRbr4KkKMORsuuHi9SNfh ugW6jetWrRVp8jGwbiMyRJrWAPM3bt51kUhX308IXXnB1jXZ47XPIn9486qLsp9Pfo10bMuq zevE+dez62LbdqzLHqf9uJ1DHBN/KZ2cYtyGjwD00xhxkG8TPVGA5QR3dN5CryAaHGXHtfeO 3PT+D50r7FP/SYIGZBDyzJ/2/4jh89c+csNHH47eYPyz/ikkjbiD+MF1+ntHf0mI6f6PPvzw fuOf+Z2yBzn0DxvV2Ihy1VFjgM4CuVKSKyS5XJIDklwmyaWSXCLJfkn2SbJXkosluUiSPZJc KMluSXZJslOS7ZJsk2SrJFsk2SzJBZKcL8l5kmySZKMkGyRZL8k6SdZKskaS1ZKskmSlJCsk WS7JoCTLJFkqyRJJBiTpl2SxJIsk6ZNkoSQLJJkvSa8k8ySZK8kcSXokmS1JtySzJOmSpFOS DknaJWmTpFWSmZLMkGS6JBlJWiRplmSaJFMlmSJJkySNkjRIUi9JnSS1ktRIUi1JlSSVklRI Ui5JmSSlkpRIkpakWJIiSQolSUmSlKRAknxJEpLkSRKXJCZJVJKIJGFJciUJSZIjSVCSgCR+ SXySeCXxSOKWxCWJUxKHJHZJbJJYJbFIYpbEJIlREoMkekl0kmgl0UiiSqJIQiUhWULHJRmT ZFSSjyX5SJIPJflAkn9L8r4k/5Lkn5L8Q5K/S/I3Sd6T5F1J/irJXyQ5LcmfJfmTJO9I8kdJ 3pbkLUn+IMnvJfmdJL+V5L8keVOSNyT5jSSvS/KaJL+W5FeS/FKSX0jyc0leleQVSV6W5CVJ fibJTyX5iSQvSvJjSV6Q5JQkP5Lkh5L8QJLvS/I9SZ6X5LuSfEeSk5J8W5JvSfJNSU5I8pwk 35Dk65I8K8kzkjwtyXFJRiQ5JslTkjwpyVFJjkgyLMlhSYYkeUKSxyX5miSPSXJIkkcl+aok j0jysCQPSfIVSb4syYOSfEmSByS5X5L7JLlXki9Kco8kX5DkbknukuTzknxOkjsluUOS2yW5 TZJbJfmsJLdIcrMkn5HkJklulOQGSQ5Kcr0k10lyrSTXSHK1JFdJcqUkV0hyuSQHJLlMkksl uUSS/ZLsk2SvJBdLcpEkeyS5UJLdkuySZKckOyTZLsk2SbZKskWSzZJcIMn5kpwnySZJNkqy QZL1kqyTZK0kayRZLckqSVZKskKS5ZIMSrJMkqWSLJFkQJJ+SRZLskiSPkkWSrJAkvmSzJNk riRzJJktSbcksyTpkqRTkg5J2iVpk6RVkplHmLcMr3k40hyFzzwc8QKuEKnLhyNNSB0QqcsE XDocsSDzEpHaL2CfgL0CLh4OT8cpFw2HZwL2CLhQwG5xbJdI7RSwQ2RuHw7PwAXbBGwVsEWc slnABQLOH85tw5nnCdgkYKOADQLWD+e24pR1IrVWwBoBqwWsErBSwAoBy8V1gyK1TMBSAUsE DAjoF7BYwCIBfQIWClggYL6AXgHzBMwVMEdAj4DZAroFzBoOdaEMXQI6h0OzkOoQ0D4c6kaq bTg0G9AqYKaAGeLYdHFdRkCLuK5ZwDQBU8WZUwQ0icsbBTQIqBdQJ6BW3KxGQLW4S5WASgEV 4mblAsrEdaUCSgSkBRQLKBJQKCAlbp0UUCDumS8gISBP3DouICauiwqICAgLyBUQEpAznDMH ygoKCAznzEXKL8AnMr0CPCLTLcAlwCmOOQTYRaZNgFWARRwzCzAJMIpjBgF6Abrh4Dx8unY4 2AvQCFBFpiJSVADhQMcFjPFT6KhIfSzgIwEfimMfiNS/Bbwv4F8C/jkcWBgdof8YDiwA/F2k /ibgPQHvimN/Fam/CDgt4M/i2J8EvCMy/yjgbQFvCfiDOOX3IvU7kfqtSP2XgDcFvCGO/UbA 6yLzNQG/FvArAb8Up/xCpH4u4NVh/2IU5ZVh/yLAywJeEpk/E/BTAT8R8KI45ccCXhCZpwT8 SMAPBfxAnPJ9Ad8Tmc8L+K6A7wg4KeDb4sxvidQ3BZwQ8Jw49g0BXxeZzwp4RsDTAo4LGBFn HhOppwQ8KeCogCPDvhYUenjYtxRwWMCQgCcEPC7gawIeE3BIwKPDPlh9+lVxl0cEPCyOPSTg KwK+LOBBAV8S8ICA+wXcJ252r7jLFwXcI459QcDdAu4S8HlxwedE6k4Bdwi4XRy7TdzlVgGf FcduEXCzgM8IuEnAjeLMG0TqoIDrBVwn4FoB1wx7V6HsVw97VwOuEnDlsHc9UlcIuHzY24fU gWEvOht62bC3DnCpgEvE5fvFdfsE7B32rsUpF4vLLxKwR8CFAnYL2CVgp7j1DnH5dgHbhr1r cJet4mZbxJmbBVwg4HwB5wnYJK7bKGCDeLL14vJ1AtaKM9cIWC1glYCVAlYIWC4KPSiebJmA paLQS8StB8QH9QtYLB53kfigPnGXhQIWCJgvoHfYk0HB5g17mFrnDntYg50z7LkS0DPsKQXM Fqd0C5g17IEjQbtEqlNAh8hsH/ZcimNtw55rAa3DnssAM4c9BwAzhl3tgOkCMgJaBDQPu+AX 0GkiNXXYOYDUFAFNw07WjhoFNAw7O5CqH3b2A+qGnUsAteJYjYDqYWcJMqvEmZXDTlawimEn M0jlAsrE5aXiE0oEpMXNigUUiZsVCkgJSAooGHYyLeULSIh75ol7xsXNYuIuUQERcV1YQK6A kIAcAcFhxyDuGRh2LAf4hx0rAD4BXgEeAW4BLnGBU1zgEJl2ATYBVgEWcaZZnGkSmUYBBgF6 ATpxplacqRGZqgBFABVAMuP21VEmY/Y10VH72ujH4B9BPoR8gLx/I+99yL8g/4T8A/l/h/wN x95D+l3IXyF/gZxG/p8hf8Kxd5D+I+RtyFuQP9g2RH9v2xj9HeS3kP+CvIm8N4C/gbwOeQ3p XwN/Bfkl5BeQn1vPj75qrYy+AnzZekH0JWsy+jPIT8F/Yk1HX4T8GPICjp9C3o+sm6M/BP8B +PfBv2c9L/q8dVP0u9aN0e9YN0RP4tpv437fgnwTkhk/gb/PQb4B+bple/RZy47oM5ad0act u6LHISOQY8h/CvIkjh3FsSPIG4YchgxBnjBfHH3cvDf6NfP+6GPmS6KHzJdGH4V8FfII5GHI Q5CvmEujXwY+CPkSrnkAeL/5/Oh94PeCfxFyD/gXcK+7ca+7cK/PI+9zkDshd0Buh9wGuRXX fRb3u8U0J3qzaW70M6YN0ZtMX4neaHo4erVaEL1KbYheSRuiV/Qd6Lv80IG+y/ou6bv00CV9 5kuo+ZLQJd2X7Lvk0CW/uiTj0pn29+3t23dob9/FfXv6Ljq0p+9p5RqyXrk6M7XvwkO7+zS7 Pbt37Vb/sZse2k1bd9OK3VQhux27Y7tVy66+HX07D+3oIzvm7TiwY2iHZsrQjjd2KGQHNY2M nziyIxRpB2b277A62rf3be3bdmhr35b1m/vOwwNuatjQt/HQhr71DWv71h1a27emYXXfqoaV fSsaBvuWHxrsW9awpG/poSV9Aw39fYtx/qKGhX19hxb2LWjo7Zt/qLdvbsOcvjnI72no7pt9 qLtvVkNnX9ehzr6Ohva+NhSe5DpyY7mqgz3AnFw8CQnRGRWhTOiN0LshDQkNhU6EVJc9J5qj FNmDdObcIN0avCx4c1C1B34cUDKBopJ2u//H/t/4/+rXuDP+orJ24nP4Yj7Vy8rm61nIynbE 19IqsLKWl7XHl0i2273U7o16lbaolxLnG853nar3OcePHYrdTu32cbuSseN0uy1qU9ifcZua sVXWt9utUavC/oxbVV/Gihz28CnLvIXtdnPUrPS1mOealYy5ZWZ7xlxa0U5UGsNcEXUAVAN7 GuqNto9QcsRHtXSE3nJ44YJ0unvEQOZ3DxnmLR2i1w0VLGB/M71LhnTXDZG+JUv7D1P6mYHD VJm5cMjT3btEpK++6SYyI9w9FF7QP3R/eKB76ABIhpFxEBI+7CMzBtLLd+7emU7vWo4/y3fu SvN/SNHdLIUfHMC/nbuQZr8ApAk78p9/xGk4b8VO/PDbiLv/50v+HzhC/x94xv/lj3iYoIr2 Tx9XriJrlSshV0AuhxyAXAa5FHIJZD9kH2Qv5GLIRZA9kAshuyG7IDsh2yHbIFshWyCbIRdA zoecB9kE2QjZAFkPWQdZC1kDWQ1ZBVkJWQFZDhmELIMshSyBDED6IYshiyB9kIWQBZD5kF7I PMhcyBxID2Q2pBsyC9IF6YR0QNohbZBWyEzIDMh0SAbSAmmGTINMhUyBNEEaIQ2QekgdpBZS A6mGVEEqIRWQckgZpBRSAklDiiFFkEJICpKEFEDyIQlIHiQOiUGikAgkDMmFhCA5kCAkAPFD fBAvxANxQ1wQJ8QBsUNsECvEAjFDTBAjxADRQ3QQLUQzfRx/VYgCoRBC1lLk0THIKORjyEeQ DyEfQP4NeR/yL8g/If+A/B3yN8h7kHchf4X8BXIa8mfInyDvQP4IeRvyFuQPkN9Dfgf5LeS/ IG9C3oD8BvI65DXIryG/gvwS8gvIzyGvQl6BvAx5CfIzyE8hP4G8CPkx5AXIKciPID+E/ADy fcj3IM9Dvgv5DuQk5NuQb0G+CTkBeQ7yDcjXIc9CnoE8DTkOGYEcgzwFeRJyFHIEMgw5DBmC PAF5HPI1yGOQQ5BHIV+FPAJ5GPIQ5CuQL0MehHwJ8gDkfsh9kHshX4TcA/kC5G7IXZDPQz4H uRNyB+R2yG2QWyGfhdwCuRnyGchNkBshN0AOQq6HXAe5FnIN5GqydvoBehXYlZArIJdDDkAu g1wKuQSyH7IPshdyMeQiyB7IhZDdkF2QnZAdkO2QbZCtkC2QzZALIOdDzoNsgmyEbICsh6yD rIWsgayGrIKshKyALIcMQpZBlkKWQAYg/ZDFkEWQPshCyALIfMg8yFzIHMhsSDdkFqQL0gnp gLRD2iCtkJlk7f9yM/2//fEG/rc/4P/y5wusWM5WDBEydtvkRUJkHjmP7CQH8HsNuYncRp4j vyKryZVgd5H7yUPkq2SIfJN8n7x61lX/PxNjF2s3E4t6jOiIm5DxD8dPjz0EGdHaJuXchpRb EzuTM+4Y/8s5eX8Zu23cMTaicxETv9aq/BR3+zsdHf8Q/auOWMfrWFq5FtzOP+k9/b1jT4w9 fFYB5pFesoQsJcvIIFlJVqH8a8lGsgmaOZ9cQDaTLTy1Bcc2gK9HagXOgi3h/MxZW8k2spXs ILvIbnIhfreB78ym2LHtPL2b7MHvReRispfsI/vJJdm/e3jOfhzZy3MvwpFLyWV4M5eTKziT KHKuJFeRq/HWriXXkevxxv5z6vqJsw6SG8iNeM+fITeT/8RvOuvILeQW8llyK+rD7eQOcif5 POrFF8g95+R+juffTe4l96HOsCvuQM59nN1JPkeeJd8lT5LHyRPkKa7LNdCt0IjUy3qu6W3Q wX6U+cpJTyy0uWdCW5dCG6zcB7Plvgj6u2LSFRdm9ci0dyXOZNo5mH0P7C6XZHOkJm5ByQQ/ U06mI1aGm88qp7zi/5bLSsz0dA/0JTXDdHYn8u7+RO7kMybzO8kX0QIfwF+mVca+BC7YfZxP zr934tz7+bEHyZfJV/AuHiaMSRQ5DyHvYfII2vaj5BB5DL9n+GQmjj5Ovsbf3BA5TIbJEXIU b/IpcoyM8Pz/7tgTsB3nXnMke6/hibscJ0+TZ1BDvkFOwNJ8C78y5+vIey6be5KfJdLfwlrK k/wsdvRbqFvPw0L9gPyQ/Ij8mHwHqRf43+8h9SL5KfkZeZVawX5C/oi/o+RF7e+wNHM6Fl4+ jbdxD1lOlmc61q5YPrhs6ZKB/r6FC+b3zps7p2d296yuzo72ttaZM6ZnWpqnTZ3S1NhQX1db XlZaUpgsyE/kRQMep8NuNZuMBr1Oq1Hh2Za0JdpXxoaSK4c0yURnZylLJ1YhY9WkjJVDMWS1 n33OUIxdtwqHzjozgzPXn3NmRpyZmTiTOmJTydTSklhbIjZ0qjURG6FLevvBb2pNDMSGTnPe w7kmyRNWJOJxXBFrC2xsjQ3RlbG2ofYLNx5sW9laWkIPm00zEzPXmUpLyGGTGdQMNlSY2HaY FjZTTpTCtqbDCjFY2ccOqQVtq9YOzevtb2sNxeMDPI/M5Pca0s0c0vN7xTYN4ZnJDbHDJScO 3jjiIKtXpi1rE2tXLesfUlfhooNq28GD1w4500NFidahor2/C0CB64ZKEq1tQ+kEHqx7/sQH 0CFtgSMRO/hPgodPnP4znnpSzqpsjq7A8U/CDrIiTqhpiK6SnODZ8IQoXzzOnuWGkQxZjcTQ gd5+kY6R1aFhkilPDwwpK9mRE/KIt48dOSCPTFy+MgHNtiXaVmb/XbgxMHRgday0BG+W/ysY 0hTgeGxITa5cvWYjw1XrDiZaUULokixE0KYVJLMqq8y2wxXlOH/VShRiE1NDb/9QeWLbkCcx Q2gbGbhJQdumBf38EpHbNuSZOURWrsleNVTehmtRRdoOshfDHpDdK9Hbf5xUj79xuCYWOlJN asgAe44h30y8lGTbwf6164eiK0NrUT/Xx/pD8aHMANQ3kOhfN8DeUsIxVPQGPg4/eIH8KpTt nLPlySj2kL7AEOtXQuoAe1vIiLXjT2LGVBxwDOlEkr3RGVNj/TRE5Gn4lOwZjJ11HyTUgpmd uBiIS2d2huKo3Pznv3mkkCgAHmPIMPFMGjyE9swzic/5j48mzmYPVBRrW9c66QHPuikS/AGz d/v051SYLrLKwCMY2OvsZGUoLVHAYzhsGFJQTp7F3mIgNkTmxfoT6xIDCdShzLx+9nKYrvn7 7V6QYIFB/raztWThWSlxvEEcGyLx7oX9MsFiNkPtaf5e2Wvl6Q6enkh2nnO4Sx6OHTQkuhcc ZB+eyN6QxNCC8HJ0ya5VNzS4atBY22EoE+2rEjFHrP3gqpHxA6sPHs5kDm5rW7mxCc3gYKJr 7cHEgv6peJe83V8S2ss+2kW6affCGaUlsD0zDifodb2HM/S6BUv6j2Mxfuy6hf3DCoKiK2cM HM7Hsf7jMUIyPFdhuSyTnRJjCXan+UgY+Pmh4xlCDvCjGp7B02sQl+V54iTkUbJmRBF5Dnme gjyNyMvwvAH8oIUFNuIVwA63xday17N/YOPBlQOscREfXiX+0SGaaCZDSqIZoVydZciUWDdj yJyYwfJbWH6LyNexfH1ixhD1UShnBDbp4MoE7BSqXD9C5AOoHQ5W+5WC2Mj4+ML++KnQ6YE4 msQyyJL+IWMa/YC2YBbO62CyEtkdQwfWrGLPQfrQ1FnL7FozgLYgb4hTuoaMuIMxewec0c6v YdURF63Bu8EL5NcfQGLowMDQQJp9aP8m9kSxmGOIdCaa8NrFPbVJ9kHlAwddiSpWsXHqkKng WgZGPBtBkJrnhJDEh8HgshLpLXjyNQkcWrMyhjegIWsWoKoLW2pi7w0562ASNcl1XEyh7EHC iqUWmK2mIWMZboh/jJvLcEP80w9AKazwPHVt9gR8tmPIjCdKTlJl9gJoB4e62LPg37V4eHbq N9ltekfI/MRFMI3soflH6XF4yFrQtQrGX1xvRk6iQV6MexkKWBa7x0mRq2clt0DvasHCkfGH ExczCyB/SksSrHNgFZOEjqNik4GD52YMLU2XlhjOzbXy7IMHDdZPv0Doy2CdQHaXWBv6GkI0 bBvLj4EPkISmlazS/Jk8pr4N+Rp5TGshSxUNeUy5iejVQfKY7lXkFUNmkzWaPPKYpp+f16H+ gdi1eeRRfYRM06RIBdIR9WWyjImmhtylriZLgCvVj8igsp0UaKZm5TQpUE+SWnYOYnFX03fG X1Yf5Pwu3VpyF8vXNOBaJozjHsoPcL846VUeJ3HNbiFaN7CG3A65Xv0iydOOkFp1DylS7yN5 aj7K9woh6pO4/zgpVvLJM4hafk57DbkT6RtZnuonFNHnNkSbr4bsRTT6OcgS9WNyLyQfOjof Mh/SCXkcsgOyAVIBWQdhx9dA2Dnzcc1ySBtkHV6m2AdEiAXj1MeRjpP5xIQ9UQr8VEp6SDeZ jTHqDGIgKVJGQqSE5JEkKSZVJJcUovaXkiD2BlUTts8oTopILfGTApJDphAfCRAX+vR63FlL nBhv68lU7EHKJ3XYbzWTdJBWMo1EMDoOk0rSRNpIO7ESD5lD5iI2MJ2kSQuqWYJESSdpxlMt JgtIH1lIFhEvnpb9PEAeoOX0MSWo3KGMqV9R39X0aR7UztP+SbdG92v9tYYBwwljt/HXplbT UfMa8xaL3nKbtdj6Q9sc25v2TQ6/U+O8zkVd17nz3Os87Z5Xveu8230G3wP+HP8bgWWBjYHX g7fkxHJKcn4beia3O3co989hR/ja8EiERPIimyNfjLwQ+Vc0GF0dHY7+MRaJ7Y3nxn+Q927i wfwl+R8W/CV5JLUxta3QXugvfLHIXNRWdCWeWIsoyE71p1obNKAnjdDvHLL0WWJFaM9HmuiT T3pbWw2l+m8gbKeQGAJ/BkLpzIxdo1iP5eS0JI7V6m5SnV0jtPRoi/4mhLRbRl8ffaF89PXT rsby07T8tTdff9Px3gvOxvLqN196s7KCOuNOLh6botd7dIm8MqU2layrrq5qVmprkok8m8Lz aurqm9Xqqoii4kyR06ywNFV/+vESde6oTrk00bKoWhvJsXusOq2SG3CVTi1wLFhaMLUsrFf1 OlVr0BfWz8jrvqAt75d6Z9jrC7sMBlfY5w079aO/0to+/JvW9tFMzQUf3a7qpixryVc/bzIo Gp1uJBIIFk+Jdy2yux0as9vh9Bn0LqelsHXZ6DXeXHaPXK9X3Gu0B2pJjH+ouVTr4fXwi8dJ /vjbRy0OOjsxkiXJkfF3j5qRY5YEc8vvZnJYVoGD/bXyvxb+N1NIC9jhEjPtyU8kC/5hMVsC eeGEyUp9GguxOCzKE4nnEj9OqAlLwuIKz3f1aftIS0uLq7GxvHxw0OlvdII6qx2nq5zV0Hh6 UMTjMGtZ4PPpuMpTaly1qYm8ZLKungo9+/UJFTbCQB0F0WiB26jZOvqH81STO5EbLrBTAx3W WIOpSKw4x6bZR39DvzXNF7JpVL3FSKeMfd9oNWq0tpBPM2y2GVTVYDffNLqPteVV4+9qLNoI atbqI7lkSho6OeKgPcB3j9g5/vmIleNfjlg4vn0EBU9/Q6lGew/QcrThJC0Zdi/QPEOL0Zgr aNlh4yJUs5dOM6Hlb/LSOV45WVlR4LGJClXDq4rOm606rFJ5PRFUH1GFNBZFa/BkVuzruvSH N/csuPMnlzWct6Q9ZNCqGoPZYKuau33uopvW1teuuWVpz87eGrvepFOPOQIum6coFVr45fe+ +MDHTyzzxopDNneOy5PrNqbKU23XfHP/vq9fNj1ZntQ5I6gVj6GXuBntygV7sScTbolTdwAl dztQbLcHZXa7UGB3AKV1P6NUoS3mCN3kZHXDEecB/8V0A+S6yXlGccLCBahl2NYbGqHJw9qF pOV0y4QuXhIqqawYpEwB8bxkrbOmrjqOxqOvKVMSCSdThObmRV9596Gxv/iLivy04JG3v9j7 ZM3WR6954vD+R3c0Knc/8tFX5kdTmitS0cUPvn3XpievmvWxs/nAN9k7RcnU/ShZCbnwcE4q +0aB/I1yxFMD+VPz4yhjakRxZoxGd8wdw8PnjFBDxnogSU8k6YtJmkzqgiMoj7U3BTisE+WB BRncvgPFKudV2yGKVcXf89nF4i867mQlnETV/RqT1TB6Gyuhst5gNWi1+DOmo8MGVFeNEXyO Qg1Wk6bDFXIZRGkNrpDHFXIaxs4zOnLdrhyHfqzS4Azxco9/qC5EuVNk2WG9O1tuIC83R/ZW s+Xmx9m7RbmftIZJJKxH0Y643UHdCC08ktcbZI02ayXLTzobJ0onXtrkwkgLKN+iuhAF049B e3o8POcZgyeWE8jzGFDUdp570p2LUnTqHSGvO+Q0jv5eb9VrtfijeTwVhRlkJVo6/hfNRdoY +rUvZcK5ufYAq6EBVkMDDpQlYEK1CzhQigB7e1byXIrGUpnUypSasmfLD+TlB/KWDOQtmR/H lfYRpepoeQ2tCYxQ09G8vMby5meoCf2OiRYNNy7wjNCSw+Voz7w1w3CxTmNQ6OKlwcGTgiEb huwTrbmu3skqN2vt/NU7PTbNpK5Co7lIY0Af27D8yiXnP3phS9ver66buq927CWnU2OE3fqC 2ecyuZqWrV5beeefH1w0+NXTt8y6Yl1bjkmz3B12G5JlyTkHv7F1/4mrWsNhenFePtRoMDhy XWPunGQ4L2AZfOzd2+/+cGhVTqIoJ4+1i/EPaT/6AS+Zd6zFP9f/hF8lWS0BuZY4QrNA3jr4 cWiJPI02bRo/ccxLe0yO+dyg0/K0KD0aMiyb6ASdwrQpXtpv8MSD7I0bvXF/MO4x5KCseMEW g+aXkrF3rB//C/0dnqqQILRBhIn5Hz1OGI/jpD1hW2K+8RlaBXcpANurzdpetMqJx8u+GR1/ E2iDvC8/86S/y23dOj+3vizPrNcqKiysIZgoi+ZVxByiCG4jbe85sKTSaHdaLM6gy4f+2e6y O8t6p6v3svKwt5i1O90oSQ7pPE68oiRYycQVyxGKBXLFArmx9KLiHiVG+3zvCE1nDQstPyUV y/UqDKToGry83andsA7G0ZP+IoMnL8CUS19kXVy3J+Q2wk48LhX80QNGZ27WNujSsA1TyWMZ x8rmbc2KtaLCX15uKgsEuOFGw+IGHW2LI54VeLZhZ40skl9psZhYOzSxdmhi7dDE2qGJ9RQm Vk8IllQFWaXJr+s1B/zW8kBlmS5a2Bvtk65AiwtOQHULLX8p+47gCUjz6ax2Nk4rr65mvsGk epWgzB8oU1I0gWYkKxvzyyKKn1YzJ4FRry5t8ESD/rjboIxVq2Zv2OONeMzKWAeFBQoGYm59 SWhjrCI/YKR7tPQac040GdxsD7ktZ6rnho9u15v0qgbdKpyvu6QuNQ8V51tyCkMfL1YfihQH zUZ32CtaFbwrJzzzq4+k7HZPtkVxhII4QkfAd1kvydNQjocrM2IqK6tiyqwK4NyqAE6scuCs KqbMKnaKg0Qa5pvK7ClNkNlk1vXAlfI3MuWJWjJJd+XQGa8yQlPJZCrh83k/RV8R1V+dZN1u tlZpLrV6c6z1OalEwju2MTY9V1EUgzsaCERdhpKc+eFUNOykTeG6qsoARZfkjgZ9MZehwwNv 0xyuSilvNF4ypfPOWR//fcKIP1qYZ/IXRUe/V7Nm5WD53ENzlW/AF0OvhqYC72PN+GnN29o4 Gm2K7M/keJgOPKxCeZjr4WGuh4fpAGqqzhhjpAJzayqJZJUL5K0KyI06kBt1fhxXRZ6Be2Yi QZhw+4IEa1nMLEx2QbIm/IzVlraBeyCT/DHN27Nue/32W1++oXXW7a/ffvNLN7U9mVr6+W3b Pr+iKLnkczu23728ULnzix8fXrH4oX/df9eHT6xY9JW/f3XL12+Ys/DGZzbsOHFDz8Kbn2Xe Fvrm59H+cjHiu+hwvi5bECAvCEcUHMibHD+OguhYFfA7w0w9YaaesMNipbPDMRwLo+caJs4C 9FtHdDoLimk+4u21TOq2RQWRDStb1rObD/olzSSnS30+s+drF91mdMeDzKoU51Bvcc+mzbOL npyyeLDkvi/M2dCer9626p4tU8fKJtoFXrXe37Ls4sVzz6uxjX5Q2LGGvWGUWGNGieswav1s JuIoc9Yb8NT1rBT1vBT1rFT17C3X4y0fK8ogWdTiZCoB44hzOUI1QK4aILecTqhmOLfMAU/t qW0Zmsn4p0EDT8Z7/dnxBvNdBk83Sg+8StoaOGvZVsLMiVqmwuGcbFHiVT5/RGV+mh7NxO3z 0ZpkKpmUbqlZ58mP5MQ9Zs0eb2nzwik7pbLgprorp+d075yTSsxY1hirKS307LIZxkZb5wVb qj/7SOuaGVEYGXQXRjTxyprFLYnRX0woEU6PVrU2LNo6c/qGuU0eW3rqnMqx3+aH1atnb/Lr dWOz41Pmwdp0jJ9W16DddJG3jpPpGMDZMTybzlQGFXGE6jiiBQG5qqaPKCWZdFXG7aGzqzLo M/Or8qssoQC7NsQMeMiBq0LM8ITY6wg9jZVrsOJHQtwTOHEkmEWPwKfsTiylsZQ9Q1MIVpho MmN2xuppfcZsobPxfk5kTIzVO+udvqnwKp+cHtIWLfCN0KJsO8QrOO1kw8F0etBx2gGX6iU2 ShL2jDvTMjHRQDWygYqBeJnszM8dROnUNTP3PDA4feviKX4zOmaDrXre9lkNgzPzq+Zv2rJx fvWUTZ9dmF7cM9Wt0yiqzqw3l7cONtXNq8mpWnDelvMWVNPzl35mTZUvlhcoiGJErs8rTETq 51XXz5lSWd28cPvc3ssWldqDUbfZGXC7MLbKTYTDFTMK6uZMraqetmA73pEdbf1V1Pw8su5Y IAP1BpxwaE4cBSO8YUPZvMGjdnPEAeDZDZ91pM7xE0/imFPnYi55ONu2q+B4vccHld9JO06m sxqKn6nDcRazkE6n+iofSNwuvbGx2+VAQ72KDzO4H/7RvRMVcbXBmet2i/AB8xwehaW+GF5N mtyVCa8spTHWamOsFcdY1Ymxvj/Gag2+t8aRcZIMXESScbM/qGnEl7V0QG7pOOI6IC8wP46r fU9jpSI8zCPMw2RVyIhbmJLzHfMxhJT1Bp2erBiswkgvSYwjWaknOjRndjh9JkdzcduBkd3n D13aKoYibkPJgt1d3bt74TDAUY3Dy3v9wuMHZjRf/NQeNSHV8fHfllyD2YH+KxarfpnHtDJt /EPdG9DKVLLhSHIqrRoZ/3dmJqv0BXg9BkYKyymCJyyngOYFGCnKo4EYI6WVtLSClubT0gSt n188P1FhVicHStC7t8D5wQ8LjmR/Cyb8Hx4ZYZ4QoiN1k/yfM55QFeIoeu2VGkduUSSazrVp xt5TPlRtOUWxeEmuXR17VEedyVg0361XaIJSj2r0FERy4x6jSosUGlZ17kQ4knBQbdLmZH22 06b+5ONyyTWH/AiyqAab+aOTmiaznTnAdvNH39VMMYFrbTl+pqEKtIJ/QUPlpCITLiqnRWU0 GaBJP035aCGhRfMTZmd4vvNMcAhFpqzMg4NnwkCUe308CjSptDwixIpI1d9Zta6ivFi+16wZ e2PsNa3Fmx+JJ+1aK1019oRF70DjTfpMOkzFeLQmd144mnJqLGNDzb4cuxauvlFRR0fhkqha e45PWaC0+EJ2BI0w8s6lvzNYkY+g0eh3WHkivAf3IJI78P9tnGJBpfbTHgur1Oi8eywF80M6 13wd66hdzI87U5HpmUZ8prjogfzVdXX1bhYHY6VWuoTX7zWM3WrW2lPxSIHPrD0SrMpR/JXB o6rZnZeTX+TQmun7YxMVmb6m/JK9Ng0G32M31u6a0ri9nl5osunZC/Ohv16GnqVF/QEi0xky lInZZ0RnlM9QzUZ/jQUtvIa19RrWzGscrNuoGaHvZxBqSNkJtRBmDUgTa+E4Ffg264044gKG vJtqGlEMGY/T/x1S46hRppyooQTj7pqy6cUjNJSxv5hH8/I04XfKZk37taVHQ8qZw8b7cDbs Hty+fFBGkE6mlw82lgu/pgqd+XKME1jcEB5trYgfcvNXXcuiSRMB22YNHyDoRbTNV11VV6+2 OHJDOVHblM/2duzsLW3e9cim/b7KOY3TVnVVWgxwV/WhGYvW16y6bmHyyze1rp0RHZg3feu0 gMUCf8uypKW9oH399NnbZhW018yrDYUTYYMjaA+GcxJhd0nfpQtP+ktbitoXzGgdHxfa1Uaw ytuHSJqONAwyH+ku6Pxl7XbUKYwenmxpoaZ4XdYuAnmfDuR9OEtzLdaN0H9nQt40c5HTMeg5 zd5KmlnlNHsP6RHFlDESr6muNq7RVoxQ7VPJWaF2x+xG0MPaHuYHs8COH55RdgRxRpMTljQl Y5NnDKhTxGGlg6x3+qDDZkV9uXrNLYPprvb2FGJTXgwJdHp3LBDE+KCwu7OzcPUNiwsf99Ys ysSaM22p1v0zm/vrg/St3c9c1e5MNhVtgVVFpbQYtA3cN8Kf0d8XNSQcc64c2t12xdppruIZ VWN3LVg8dc0+tMIl0FhM/T4CrdcfzmW9KnMVgW+wGgd8+yiUQXhQDwd4sA86AfLxwZlg3/g7 7AIE/cwZa7mN2oJvRTMma2c0f4QqR92z1D9Vsh7baO2sLBmhusNGqG30pTQLAqXPBIBOog8S 4b5zwro8mciDbyKCDaziqTFFqw9O7e4vX3Xnutrp2+8aSPe21gaMOsVltaem9jXtuSyeGZza uKglbWHDzy85g05rsCDsyuw7svvq5/ZOceTkBWzugCsVjRfGjz2++Mr+dH46YXAjUqaQldDL PVipmUQk+4ZMtGUKNYcaWZttZP1zI/PvGlntaGSVpfEZrNsnpFxorZzVMBwH8h6aIy7i+Ti7 nFUokzvebm5MhTQ2NFbtcGAWDIDmiK0Hk4eoTLw6wZKJDlmOS9EyzwzgJzdMONgTHbUKz3rS cKtevUfvzPWwaYyOu5auuXFxYdXqz66Ye2VG74myOmV8aOYlrS2oQahR0+PTMu2poKxAe3oW 9Vx5ePWuZ67qaJupmOVIdLQNdWf1/kzrFetQl2bCsVXIILR1F2xdGrNtj2eKy+ta6rbWqW7W mtwxaMntjpcwb7iEaauEqbGEWz3UhQ+ebE1/Oa2wCYInWWur0WQrH5DXMZ7GZUBh9jRMf/F4 yfMHNLdolBMa+qKGajS55b9Ozgq8s9K2zabYjO/k8go2mLV4PKrMlVn1WloMVWEC0/D10EB1 ifikaoV2OrnyKd5UHVeoXr0rFRwdjrRv682s7Sq36M06VVH15rpF2zNbH97RNHX7/WvOu2Nl 6UPqxXumLWvOw4A/Fe++aFGZN8ertwVdVrfdYg4G3M17R/buOn55W+vOL/S7r7i9bPa6etYb FmDV7jXai+D/rB32OVgD5A0vlLVaDLm1AuFuHpCbMThzHwxXFGMG6cWMy4FhRIHpdF1HTvJ0 RWdstqOTBTdOV7GpgvTJau7knkxXY+bkrNiql9tx6GHSuA3GX9p8HtLQKNdotAad3hspChXU xGzfR1+vddm/b4BpQhDIcJnDwQYHlyU6N89KzMi3GOABuP02rdFsDFT3Nq3WO3Pc+bGP/4Ro ILwbs0H1xvLdOU794PJrFxVZ7RY3Iu4K04L6lPZiRDH6yMzDbZiL3oKwQxRF7OvFur4PMt66 ipLezp7TUztiJafr7Nq6zuTsIGsyLS+dwvwXWg6CfdVvVr323ktvvnCmmHKsMzG3iFnJiSHq uUWFlZmwN14MXr3qU0ZfKhJO+U0mfyocSfmMLlnssQskkwrI79jU6ivJDyHWpZgsBmdOQW5b k6LPCWp+lJtkd0jm5hYEjcZgwUeVZ5TxScWsGrx6UZHGYDSZHQFnLFdv0K/ftiYUyNYV9cuo K/NI89FoNNFuYnVgXhABiw8ynsbq8u529+mWjkT56cbOotnBTm5SRDXIauelN6swQXtm0F7r FL08Nxz/o9rgF32XV/2yLL9i0Jsrait8zfPKnMdZV+90HJfHpG6KF18zmNNQm/LbVKp3Yv4C FScolaD5jqqicgRr5tf/x9qycvCaviKNXq83GUwWzISgxvG281fNY9DHOjJwODOLdeeWdYkE qVm3ztLeX02gliM+h2UODGzGu6In01nd2dTkKz2d2zGLWE77OnXc5Fah8sAmsPYiqtBLJ5Gs hjjeRJ80yZM8t75oZNcu1BeXlc07WZO8axftLDtn4aTnnaufRMdm+D4RuM+qzoAZS9bWqmE/ 7zS4WKjVZfgDG2u67G/VdfoKcr16nITYR6So3NexNhNWyz5Zi3jzslvRvNyTW+MrMnT4imiX Y6bBFUaTUWsLuMJ5DptRV4CoC3a4qaR27Db1evV7WP8wByv/X8x4XaUdrN/rMMCcd8Qcbjq7 o7oFozXmqQJ5jwd84yl2qEU/FzRjtbvo7Lkhjb1CrdbrmX1H9wgLdiJjBSmt1odC+upSDbN6 mRqYetLPPqI/5sBl/cUFGTOwwF6hVxtm/dKy4G2vd2WD+sepncWxGb9omLX0F7G5PBYJ3/80 n1B6RThj6epT6fTJtB9hERYYccJDc5xK419a/mEGAlYPIV1uDJIpHdq+z5+NVsmZpXq4wVid wP4yU+jzwyYghDXh9jYrbgS0UjaEuIQDd73bfnkit2rwwJz6NSGXf3rdn2Zum19Wc/5D2zff tbrEEa+MVZZXFUTza5ZdPruoI0odTufY2LrBio5y/7qllZ3l/gUrev8YKwoYr7qwe11zSN2V iOYvLp9z0YKSsM9VFkmUKSYlPm1gSvO2vsqCzEBNvLmhOhicXTJtZbJgcEbP3oWlRkN87L1l G2INXYUD66P1naPLm1oUQ7C0qNA7fWa4oplZkbtga++Hr1xFLj7aUkOLz0xgZruaSTOb3HN2 s5blj5iZA2RmfbiZ9eZm3pGb2TETyeAQQSwfQUTdsdJZ+e3B2dL6uOAeZ2eQhHt8ljfj5CML nf6MVZaRdKcYknvV+9EIuBccKOuqaN7fKtqEWy+d445bupbsmx2fsCeKvWd5a35/3+gN0sJM 9oi7u6atv34V63Ouxixer7Ycs3hxcuOxlsTcxNaE6mPdK4oIPBNVQQAFaV55gTL6wrth3zNY uZWLSSquqU9OSmVVikmpfz9limZQu/E1G81Hg44urp9XTqezzl7W12OeySfnAN2sY2KVEbWQ Np+rAHfJlKY0kwkVqFfJ2TRa0VRc1AhBicdfHruNrkWJ8zELcM2RuVVs/Ql334F/Y+0YKFwt kHfZ8owC9k1saQsaKD8PyLUCFF4JCFcDs7UZUzBIqspYGctQxiOF0S5M+moOa3krRUmd1dXZ wp4UpUVZtaI3zgYleTM6M1A6q9i9kczajlhpwKihqt6o1yX88fKITVpSpoPi9JQpxfa1+xam DSar02Vlc/paT2lnl3rok+oQ7WA/2kENuSNjaamjRZW0MuOiPRiwvMhdLhA+GgK+w7TD01BK 5TPYZ5xHLFkdIB7BXz6QKwfIdWJhTSPHV1pKmEpEE/HlmbWFXbntTtk8EKOl5Rj+oLfhXlrV GzwgCc1MVIPUpC5oonFk1/LAY9FT6vOp+w2IVYQSAbtu7Kpz6wddaHAFMbuZ5zVa7WNP0y1W Mw+fIzxjpH8bs36ymXz8U0Q0rEYVbq7REnCMPT1W4PRmbQdths68JMNnvrfymW9e/El1I1sl JuoI/fdRk6OdV/hsBfjUWv7Jmj1Roc+04OxTaF/EqGMeeScTcrFlC3x1TZJHCVM8RLhtPm2f ZMf4EyHNJ0Q44pUAea3m9i0S8aHZRyJVYg6WmTkxEcvNHPO0js1jcdh5zRj78vc8aQzMb4s0 Nw0ccXnqGfpvGFkH1Q13z8JwWJexTp/V3F7a0FUK1zVrHvH+2ahPjvgas3Mr8NKyQVlmLfnX UEyyCiwYc5bJ/ERGdjbSmw1rZp027YvClLoNnpLWssadbaz1YIZX7yuZWda4a8Ky6ly5fl/Y oZ99c1fDQGuFo7S3uyN/8YVd0Yn3oSQaz7Gxn8xBWNyMKmQ0G/b0zc0pn15Y2VrshvGdLfsg vMEqcnvGLt4ge43Z7ujct5TthYTa8daybxPNKxQxO+BJiF6J+Q6ik+L9E5rfsWzHxLqljKl0 VnEwv0uqnnkNEz1TOju3l9X2f6frs1X7n7unCSV+ruf/0j2dpSgoaCXrnVh85nVoiM3rPpLJ bSmihS5a5KRJK01aaNJAk3pazKPMfK4WSgDy+gfkZgt49lwuGz5Hyk3UNGmSmI3UJ00SP41v M8B81TE76dmG14S1WnTYPgsDDCUb8ILKBrM1U67eYbYq+yNHl9ITliEuGb5RX2/a+bUdW7+y pa5x52M7gfWPh5rPm9u1qTUeajlvbud5rTH6+y3Hr+mecenRHcBZwP1dV6xurFlxRc+sK1Y1 1iy/AjFArhseAyxE9EVPGrCXkensrrHb1ZehMxYFPMCigPE6tgCT9edA3mhZmht3EF6N0LLh 3HhFAJCHAvlsnogFfmoEsMsx9z9GAD8tAPhJ18b7nwOAty4vbJ2eyZcmHJXI4w259EWze3pL Vx9kAcBqHgBsT7Xundk8UJ9D/3jhs1d2OPJqEmPNMu6n+SMaHRZnmo0XFzcXeWdf9cTutsvX TnUXzawcuxu7S9buZ9paCW3dk9XWNZkQ1BU1p5ndSzNHTyiAG780i3IVY7cUr07V2WoG5NYT yKNeHNGGq3mUy1vQZZ6WjmoccAW0wzmzGliUy9HDfIFPj3Kx8PNE0LQW8yTSC2djJ7+sUN5P RrmMzDuMevRFszq7UkxFVWs+u6Kwva2jmC3f9eQ69Z+IdI0dlZqip4oaE3YZ7XIWTCnaLFU3 9k8R7hKhU4S7uMegPAyNVZM1R7fV0qQ9W6mAvC4BReVihNU6O6tcrkmTeKy5kRzUuYKMMT0r affGurxsFMq7Ae4IiMY1WRlsvPEp/rGoRDrlYUVnNBj84XxvsKK2KTGp5nAbXjC9qTFsjeeH LRqVqqt9EafRaDR4ymbXjw7Jjv+MAbqyrjVlVw0mk9HGV0L2jp9WXkCJu8gLGUt5d0v33O7L up/o1k6aKOfNiqdhfoEnjsBd5mnYJI6oFNNH6K8zUTFbzqpYiFWx7GQ5DoeY6Q49jS8+YUue TEgQSwb5fKonifu1WJ6wKJay1+pNf3LOc650bnOqYlL8V2xGfJbvbRGOhxrFdHh2MhwLoict VijPhlVF9M/Glj79jyfDlReql18xp2JxW4XPpGGT3emWRQ3FrVWhVGZeX28mVTR/3/z8zqYi L4bwKtY7GfPqusqLM0Xewsz8vgWZFLW1XYD37Q968qNu+KWhWMiVqCtI1hRG89LNi6bWruoq sbi8Dovd53AGHXpf0OdOVOSmagtjecVTFzKvJz7+V2Wz5mvYr7DsaBFxJkqzDZEjdArk7wLI GyRHKLGUVUKL31p6OtEZtp72d1Yyr1zP5y9On2KdYLUIN1edOimC8GJtpfPceIfy6YENZbPB ESsq87cjFHGp3cWW3l4ix2ZvsYAQ4hb1Hf78XI9Ba9Rqlk4ONIhY4H+OShBYe5Rb/au2HDM+ FdzaNyr4RgehD/XX0Md0Mm24fDq6+H8fTUciabS5DzIWtTY9vdORPj2ltpMNQo4U9BhFgP0U goW0vOq1N0WAhy03RaTvjI1GfPBTQjafogr1kYgP/pM/iFjWWPmkAv5nbajHQjkff26i1Xkn R1/izonoy7lKEWXV/ETzc0S6VqKsNpR1OD2nn5U0ap1hzcUvqU0vJHM6p3dOmRLrrOhUOvtt 6dO1nVjwoBku6Fk26ZUjLlx1EtN+MPjlJ1mgC3EStmqwCv9EbDD7/s9RBY+N1n5arYhPTEJg wTlbmc0jyhNq1PzE4BSxqpbI2PRJmkIY3R4p/PSaQ5+TQ7s/8Dpke6uuYyL2tTQcd9hM2WDV JC06PU6r1SqjWOfqkVK58GBs/NzwF3R8O5v5UZ+FT3or5n1qqDnFLFWKWaoUW3CV4p1hivmp WLz+wVNiWUY0a+qBvPUB/80dDEbYEJqdIDP4mBoBgA+wKKO0K2XWBrswMNCemf5h/YAcC0yY LtYZTHikcvrnjMr5HAZWSMuxISZ+XGGvP+zU9dzJXU+9R4Tq/eWdFc372jABxGKKxglnfk/f nKkbrl+t5El/ffQfc1fMLOjvU3bLHNYOr+czY2zmle1hYF7X9bwd5iGetA96KyG/PY4tMvCm 2NKMKF+7URClEUEilIdOoBC+ghcoF3C6s72nK4tOKCxTjxPq4e06acpBC7U0rxAZ0/Jofh6N M4pdFvlxGuO5MZofoyk7vTBO42w6xOj0dsZj6DWQejtjRDcUj6FLYSk2jAe+m7HgHvHCrrg5 p8ssOmDonQ+9SXqQe7TpQawXGUzzlRT8AF8/kmYurn5iCW12fRBzUdx+sbAAE5T7qKIqY6c0 1pzCSKQwiFUjL2i0bLGnP5zAfpsxjfqRgnnAkD/i1Kv3aYwmi/7jr7L9NBqDzaQutriMKmoq VlBbjKM5FovyByOmVRSDmVm92vEPtVdB223k9eNYxHYiMw1Fw4wvVvw10HqGBVgfEqfJGE1G aTJCk2GayqWFGlqk0qYpdEoTnVJKp5ZQRwwLhPCVkzysxRDTtsiI4Q4O+C88myFfamFn2fbp Xfw8pswWx1zHVsdlDo0j4/J1Oqq7CrqabimhJexYCQvwOty+zg0le0qUNuT6Z3Pr+zL0mR48 2dJyCroU+uY6r6wgbACRXbQChsNQNEIb2aU6ako/aa2OdAYnqXwS1V6l0Y69r1r9hZFocdCi fl1RnlCtOVi/k0Jq7AOthlnt3DyXQf2FojyvGF1oDlidq7yq0FcUrEHMCWBZunqf3mM/81KU m4zG0Z1nXpHdozea8YYQQRnNMRrxhrDEBXukDKMBmVIMGEpRUoTW0Y33VU6uOU4qoRgnah4W NiFIxizJlDIaQH18CrQmQP1Zm8GaCs/yUSOrrcU4TNg1UwltSNA6MzXH2LCXvRWzubKiqIut AeqSUSVmRZwuKiY6oVrK1M7+4Q+2hvElHmzF5pmdYZMWyUysjqHqTIM7FY0ksCTo569qzN48 bBBzUiMNjL1voO5ULJzwmDSnXtSYnNFQuMClGMc+KLG5LVpEjfR03dgXAKrW4rbRY/Rhm9uq UXUm/dhhOhegaswe+9hy6CcPo5D90E8+mX+chFDWWhSzPkSLQjTAhvFsqZOtzqakjDSHuYRN OTTYAJwSpNGuoMndZerWzMVeUczfsEVAaLooJatJrPHGVTG/Ve/GCm6arJlY5eXmAX2fR69U X6SrrMqJORXdfqNDHXvO4MiPRPI8Ri2l6r91zrxYbr5TN/akw6m1eGy0UeMyqcu8ARvWPNmt o2XKK26zls2eYMaEqMeU+7EDzox9qAGS/yyx4CsSXUSnzB4mXiO+bfqIXQ1gYvb1qtNY2vbm K2yT5KS4rnYSp7S5sK4umcLkA10t2ehKzTfrC1O1DYWFtVkc+ybGcfhcHsc2Y2+qByuqlO1H dUbVwj7pFD7n7E+htFdGi8ee0JzKBofH8IWViIf/S12sXY54aCdJZmz5+VGj54hWW2FsbWJB a3oY3+KKsdtrbI8nn29hd560uVNNQqnZRaWfWC10bmRAXVy15NIefSLljbgMOmp05bp805c1 5sQyq2Y0Lc4UmfSYEtR5GntX1Zx/99qKsZPGQFEkVsjmTwtjEUyRqL/pv25lnfY9u501O4r+ zq0val1W1biiLRmMBHTOsC8QdEdzXNM23vjxlHg6ZDaH0th+HzSbg6Wod8Vjr9Od5A3sKzYN m/25xPHSKTEvqtcLo1PvlnaG7tTZ/M7rtVZ30O30m6jmanMgPyeY7zffHK0pKw2+gFlJ3vip +0Ao5tDpHDE2vn5m/H16k3oHj+CEDhMswN93zBRJIP5kx7s51YKXgwlrocTJg90JXzTbodOb UOZorBCWJVAYiwodnJVWY7ESVr6SWF4pw9LRwrjIQIHRgeRgQzsln8PzbEGJUT8Ps+WzJ56C 9UBNQfeHR0l/kxV/0jTDlvLmqWVMNneUl7VBUNHInePva94lr/M6niDFz5GAsh8bqS34ElMX yrz/mC7uNYbs7J7V1aeqWD1nv2ffenJNn8zppvKpTWVM6LfLGJuCnuqkzLugvbys9VMEJbtR 3U1fwjxwiBiHdb4OlAdalZOz7C3W8y3GPrR3OtsSyA+ydyfeqcUddLmwvlnTflkohtlwZywU qSkrC7xgMOnZplf8z5SoK7j/zuz9zf7s/XnV/59XFW0yWl1eGnhBzyZ52WZa92U5MZdO50Jd oYSOvaWatN9AXN1w2KEl5fDDMVfOaoXctat/RGP1hL3BuEujUwY1VnfEi1U8Gu17ViwV1Vvd Vt0+q92IO3usuF8bPaqUKdOww912lOjNp7EI8DRmt4Ut4FvpxDZRpczlHFvuwg/9EhYxa+kH qUg0mYzonDm4y9VjD9O/a2/ATvi8jFdl3ZXKBuoq33SgeqPmq0lLOWoxehXcWQfH3+Wf2Hhc pnLNi1AX/euKwRVLtdQWDrpy3Ba1bn5DbrRxfjXF3kufP9ehaFd/f2zglVfHlvzQ4jRrFUxw r//Jz1/bvv3Xv/jpBuzURteBbzqhZC+e6C08UZxUHycuBFnwTPAbedyT4ZNsU4cLUxEnWPeJ SIt4wnSVeET2zpha2TrYOldtjZJiNot5bz4XfSu3obdOtWCnb07YSrXLli9frlEcuX4vtlcq G3Yrwe2v/fwn67EWRtGanZYf0IdffYU+/H2jA3uGdTrNqbG5eL7nxk4oIe0e7AS2PRn8nj3n eab48tNS73Jhtdi/ykZJ7MOVkN02Tiw+l9ns8lko0cH02W0PPshw7ON4CDs7Pbo0NiXqdfjq gFjuh1N1dr4yeMnYCfpU9tMc3wvan9dlP43Pqk2MWc8M2fBhXvqU2eW3jNsQ5jHrH3xQ4LjF 7zJ/6AkhMBF3+u067cncmNPvwCRDCF9WSMm9yj3oG66DFxPI2CKF0VS5X2936EzmhBmVFRPs KCEW1Op0qZTbx4xIvVuvY5s96uux57++rs7vV7H3v8qnV+vrfKgker3aZVP8/rDl5Vw1VlYW U3NfskT8fmp77z0bxUy85SWZ/7Il7PcrtvfUh3WJVKHL+IWxD+0O1EPdF4yuwlRCd/556EZS LuPdVOvAz9hHdyM/mdCfBxucD+/rVaydHsC3HDZmwvPmL5rW9ZsltbolNfqlv4kUOyNL8Js/ c35+n//M1nrMU2JJEXaDcWCrqVFvEgm2aJgblUTWF613i731aKTuCWULhu103I+CvtV4lunZ DbRI4ongLl5ZuMvu1mFp9NXFVIdq5o84dLR47J1iRWvP9QdYqoifYTFcU3Sx3e22X1eExTMR fyDXrimmvhQ1OCIBf9impYU77e7Rw4XYYqRe6AzY9WNHI3kcH2UuGHfHFo1N4mF21EBnR2KJ CJ2Oc7Bu1Kwb+8ZkHl05dpTOZv3Y+Rj3fR17h5lfcNdxMgs+rN+u9KycRdO7W+j6Fjqzhda0 0PwW2jKizMx4LLm5lr219Lxa2l1Lm2ppupbW4sBTmFCIoSqxoQWMCJs5PobbkAoLRZjvQ0T9 lB5L03hFhTaJrx8adg+0jlDvYe2K7BIPZr/Sg9isMDj4JhssDPL4DWfoQ+HysXckAnpsefJZ u1n058Tbs6v+1K/XXPDQ9t79y6YVOFxlc/c8tKVgdqYEC7kVinlPc7Kup5otO1Jzpvcsqtx0 y0DycX/dkhkFs9pacuIty1syy5vD9MG++y7uKpx1wcEvL1/w6L03bJhqtLvMVrvbhslng81p m33gq8vskYC9cd31K5tWzMi3+qOuyx/fVFrRi69AUcl86PZp7EJi23866BXHSR0LFmA1Xx2M 2VFmzGoZYTmcsJwamcMJy0Ho/d0jmJvkCN12MfvHXlEXrZD34YQtOJ+c8waznxX4z7AyQU8h t+qFPMiR5WxzXOGIEsjkROyJCEqBQTv/E/FETA38/AY24PaGMQTlF2Yz2YUNTyszEc596Qh7 yWde+okj2b1P2fXGJ1icnBlsvuxxBh43Y2JlmlGBm7Ikj51wwrPZnXD3GayqOU1sRGCqnaYt HQ0OtI1OVBbMqWcnqfh2qHQ2wUNd6TRAzNOIv6z28BlWNsqf7KfWiy5MhLTQc0RUVaxWYdNZ /ro6N1Jy9U+d+vTU7Q+dv/beLU2F3Vvapi7LxCvX3LV+9c2DJWwxcsfW7tTPww0Lai/YGmpc PHXdBcV5bRtaW1ZMi1591YEr6eyFVy4pK55/Uc+09Yu686JtvcvqWvf0V5f3bmmpXr6wK5aY 1bdCWVHcWhFc3ZeaObUxWnPp6JfKuqdPi0ebZ3SVrDrvfLTTTtSl5/lO0DTmxYPnTBcWyOlC hIVPZApY7SilkyYC2ey3h8W6POzleQKMPaPAcSQxEU6OsUqGGgDk8z5AHvACvs08ScRgsHGp NGM0sU2mGaKyqbaMEVeUm+aaFMIjM0hhtzOvECzOD2Ii+L5FLGY1YYMp24EpN5iy8Svf18aG rY432cgVy7dEoJoF8GEHxM/kN8ZeFeYcEb+c+B4Qjfp8+eahy/c+vD5dccHQgX3AIVsoPbWn ou+8ab7I9HWdDX3T4FsrB+/41+FVi7/6/v23v8/xsVV3X9hXH5x347MXfPaHB5ryZy7fcTXM F76pSL1P68c3Ev0+k58foflhmp9LEyGan0Pzg9mdOUV8qtbFxuhobljtxtRdQQlTLSlicSgc AXKFcoT2gVyhQB44LGJbVm0R7HTCxjcz+2tGaIwbTyBvV8AT7FaT8k+wEBfSUD2uuB/fweNG DLjlSGJ+EULkerEzvqplFC6/0Gn6FNbKiSXC6e9wzRIR9BLq5YHHMxvh4IPoxIK4+gJhVb3c h1Hv0+GbKkaX6S1mnQ5fuEFtH7J1h9gXaKTFGosr4ELIUfeOwWbUtrL5D70jB9+54TSqP7/D pLFG/M6Aw6J7TtVgRTe6oo9uNsIBhbZ3QNv3oE43Y52AtaiOpiO0KMyiWhmmVt4NZaiPbdnA Qk9YDR9Tkw/V8KnqAvySxqyuG5/Gf7tghrKgHHw5zxsZM2qi2dnQGIs1ovKVPVXt05UtcGBe t1BqCFYCc0nsG0lYYPDN9ClWHXkF5AaDR6vOUg4L/52zUUY3YTv0zOVDUYx242itzWvXqya7 5aPFmxpdubXzavg2GdYP4+tqAlMGzp+y/KbBMl/HNVtPKdXYEaadxfZH6h0RnwcukpWalt16 0ep0uqcpL68wz+CKeDFpZPPmJwK1y/a2Ne+7+YkdrxhdfP5uA2zCrdBfP9Uex7T5iUwuq4lL aKUBKqtkznwl11sl01vliFKbMc1ZkJwzJ4DoKVT8diaJU5IsqJdBbjKj2kLsSjFfx68MsSux pJNX2RA0/yQPVKG5YyUZ2rctW2WBvLYDT2TceA22KRncdgoLL84un0J5VUYGQ9EDTHFOcfqw ScecMXUtKPl7LKbtYltfzRNbX7HO2TGx+xWmm8USYe+FjYBPyld/Yvln1tpP8hJ0fCldRHx/ BbPpE+PvT4lfnHmJXvQAtzbvevT86dv7m+wGnWqzGmsXbG2dsbY1L73g4p59eFd6ndlm3D5j U1cqp6a3tmnV7CqEMvQqRjTupr6tmSXXLS2NNS+ZMnPrvFK6Y+Dm9fXecNRmw8guPzdWEMtr 7quq78/koXl43UG7Pi8zUF/YVRdNFCa09pDP7nfa3HjPZQt3d0zb1NtoVvS185jtZ3sEfwY/ txh26aNMEwsBl9JUCc1P0fwkLcilyRBNcANVEKAFfpr00aSXJj006cA0Ns3X0nwNTYeYu3Ai 4xLWqtQXAPExI4Z4JLc7DI/h3flyy7BffPzjTBhnOFjzYw45/rAIMutEHGyw6GDfX5QiGmGr sI3jRdb82LaOjAmHNZqK8lQI6wPwgjXpuMNhis83ib18aHXVzAMXMcx0dn4yDZecLeJlW4XQ ZU+KF8u+gG/qmLSZQdotOYhmtsqHjZpx9Wce163yeyxG37E4rBhzmvT0p1p3pCQSr4w4bnV6 xx5QxpbSh+m2eHLsXTlrRx06uN3uSNBvVV1YRoAvH7MaP/5uQvnjaBOzWOvQ4u7EnuVm8s2M NVVPU3V8sY7KLRZ3yjK0PmuVgPi+MNT/erZJuRCqL4QqC1m7KLTNrdpadVmVWvXpX1nwNL6X gX3HC2tieGdsBw2WGYAdYz6e2x1AwynJWEqa/hFjuwG1Jb34Wp5JTWcQm8XZIjPqeCXbYk4O viQaj1Au0262a0VrEaPkM42Dx4nktxSx+b54drmuemf7gcMXTL1gYR0Gkew7YPSm4o5NnTO3 9ZalevcvmtafzA1Ew8o0g92k9bjGwomuiq0PbW2k92/80tYmZzBgszhzXE58/w52/8VaN8xq XtESteQUKPZ4DDFCd37h2B1apXbVQcxHZccl+P9WuuCl4BtK0QaegOaj5NXj2PH9dsbkjNPZ TgdUCqMCVYl+kfmbPI26CMTqZdTFXXyqCVU6exXGkai/2auAfDUHP2xmk1u70Wqwro/l42JM KAl3O85GN7xDBv6cO7SY7OKdDpAvEeGIJwG+8SRenlfrxFfqHcnpNfOvm0DAjFVw1HL2FlgI m/1kYdLcE9/IO/krkdQnVK1RN1amtfvzc/KSCGfTd0Zvc7u1JptR+ZvNa9ZpTrrCoaDtoxcs CBPpEDDSzCrMd6NfwRojaDM7EoE2Z0GbCk8/hJ6jAt/A+PWMG5uOi7W0iM8iFeN7vEy0FSXD 7lZ0J63oTqBU0ZOE91bSxsquyk2VahoLatkXJhiJzRbDfwXAfECYEV5j3zjKauwU1m/gUuC7 /2cOQqCaoNSa0czazTrNmlkFOFe1g0nbgU9fFbha5pOCArvZF61gYCrm2MgOOYME2AMEdgrB 3UHQen9t8FZWYFEAHOxBpGFwKgZNaKMs9TBH2t0KO7gD3mY0Y14mYhBYvbJAO9BRB7iVGzgO w61hG2Sc2B2hw2Q6JSFncqS6UdaSosDaGAd1wfVKTgn2jjHWMpIWUU7ePUy7QtbM786w5hYQ EpKXEpPiYwWecORdtyxG3sA6rSc4bHaZm6ZvbtdCt4b1OQb6/imm1kkuqsBmNhNDHKMF81xm TwZe4Dim7BYGPnZR7j2MXMCDLgWBpARwZOca0LfAQVXQeAQww0HWgwO3JAii8JjnivP/Ba4i ERFk+iIkgsxmZtaQl9dQUVL6Fw6allRVUgLlGleGWObpLGrAkzB5NovzSwLHHs9CRsKB7TzQ xnjwIB6jGXjkA7jUGFgDTmfh4uf+84aLB7gMm41ZUFwQOAvG87eGqQE4Esm8SBJ4LxwbYx+r mgrwAC1eJsYebgl9WSVg+vt39N8pdm5RZVAZCTwHdAeLIjCn8mwWkhEAjlqB7QQVN+yM8PYl IyOo/2UGHC4CLXDewcLGxfbnPbcAJwtwDI+bqfVvPdA+JuA2GG5mES5eJjtBaRFu5n8loDFG 4OyeKA8roy2jKRu3mLIscDiPie1fMas6MGEDASNwqJoRzGJj4GNg8PHw9AgJ13ZOzMlMKsoE AI110RQKZW5kc3RyZWFtCmVuZG9iago2NSAwIG9iagoyMDQ3MQplbmRvYmoKMjEgMCBvYmoK PDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvVFhIR0NBK0hl bHZldGljYSAvRm9udERlc2NyaXB0b3IKNjYgMCBSIC9Ub1VuaWNvZGUgNjcgMCBSIC9GaXJz dENoYXIgMzMgL0xhc3RDaGFyIDMzIC9XaWR0aHMgWyAxMzkgXSA+PgplbmRvYmoKNjcgMCBv YmoKPDwgL0xlbmd0aCA2OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB XZDBbsMgEETvfMUek0OE7TNCqlJF8qFtVCcfgGGxkGpAa3zw3xeIk0o97IGZeTAsP/fvvXcJ +JWCHjCBdd4QLmEljTDi5DxrOzBOp/1UNT2ryHiGh21JOPfeBhCCAfDvjCyJNji8mTDisWhf ZJCcn+BwPw9VGdYYf3BGn6BhUoJBm6/7UPFTzQi8oqfeZN+l7ZSpv8Rtiwi5USbaRyUdDC5R aSTlJ2SiaaS4XCRDb/5ZOzDaPdm1UtRpOlvzT6eg5YuvSnolym3qHmrRUsB5fK0qhlgerPML ftpwSgplbmRzdHJlYW0KZW5kb2JqCjY4IDAgb2JqCjIyMgplbmRvYmoKNjYgMCBvYmoKPDwg L1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvVFhIR0NBK0hlbHZldGljYSAvRmxh Z3MgNCAvRm9udEJCb3ggWy05NTEgLTQ4MSAxNDQ1IDExMjJdCi9JdGFsaWNBbmdsZSAwIC9B c2NlbnQgNzcwIC9EZXNjZW50IC0yMzAgL0NhcEhlaWdodCA3MTcgL1N0ZW1WIDk4IC9YSGVp Z2h0CjUyMyAvU3RlbUggODUgL0F2Z1dpZHRoIDQ0MSAvTWF4V2lkdGggMTUwMCAvRm9udEZp bGUyIDY5IDAgUiA+PgplbmRvYmoKNjkgMCBvYmoKPDwgL0xlbmd0aCA3MCAwIFIgL0xlbmd0 aDEgNTA2OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG9WH9wFNUd/779cXch oSYB5JJw7F6XI7+FRKVAKFwudyEhAQMBeocgd0kuJjGRDIZUsNAbC1YOpCpCFRyV/rACRZYL QzdQaWR01GlV0NGqZUapvzodGfuLjopm+3l7yUmYyuQPxn3z9vvzvfd5n/fu7e71rF0XpbEU I5EaVkS6W8m6xj0BUdLcFelO2tm/h8xt7u1Rk7ZcQCR2tnbf2pW0HQ8RjXHd2rl+qH32e/B3 tkUjLck4fQk5ow2OpM1ugJzS1tVzZ9LOPgrp6FzTPBTPfgu2rSty59D4dBa2enukK5rMH/cj yCnda+7oGbLrIad3r40O5bMg8L1KDF6BHqQ0uo3s0DJRVhHZ/zbGRRKiPI6rdu7ZyauvmXOB shyWvXrhzyx5ZunL938W/TI//QHH53CkDedzaSscLCTKYIifT38gFbHa4SYY1FhsUC3qPNQb UYuLK50UY0/S/ahPoIrUzrbRetStqI+gSiltP6x+ti0hObzH2XrKZQu86ZKydHyO4hyTrrxm MNvRx5S3ne+fYDlYvXMsJzGW0irHsCfY49RCCvs1edgGqqECtqevsFMJI7SfulFjqKJ1Z2x/ YnK5cpKVkEdiaDOVJkvsmPJxWanyYZkhsIRyKt+QIJ6dDMt7jTLgekz5g+tW5STqwWToQCEy jin7XZ3KzskG25NQHnQZDG0eSIp1LjQ9pnQV7lZayqx4/W5DOJhQZiG+3JuuzJjpVm50faBM yzccDHapq14pKntZmYKGSFPRqcebpUxy7VRmIzTZFcifjXqCHWB7qYjtTXgWKMehYrp9tYUz dxvsrr6agjKPwTZ4Z9QU7C6syfcU1iuewur8fOjLX7Rvtt9sr7SX24vtBfapdrc9zz7eke3I dHzHkeEY43A47Ab7bWKeYjvBDtI80HKwz2FzyAZ7Gk7pBDtkOQ/9ziE5BAc5xhvme9i8jMYb 7ODRTK5BOWazNJvBDvUlXYe8isQ1yQpkClzHDXcSmEOgBaSz+wwbbbm2d55zXvbcrFnV/m+6 ha3I8L34my8nc+m76xqD+gFXSC/niukKDac7h5VvlD3rEIr6iovrlqzv6+3uaA1EtUBYC0RR w/q23janHmtS1SMd3Tyg6uLUcFNzG5eRqN6tRf16h+ZXj/Ra7S4Lt/Jwr+Y/Qq2BpcEjrd6o P9Hr7Q1oEX+or8m3dtWIsbamxlrr+z9j+Xhna/lYTVa7y8ZaxcNNfKxVfKxVfKwmb5M1Fp98 oL3Rd0cPdqcaaK9T9YJGvXbxiqCuRkJ+gz0Jp38dyQOUKT9DBXKMcqVppBCZb6O+w+XgMvMj +QXKHOwy/ylWYFH7eRUG582hAbqP9tJhstFT0AvoFnqYXmId+G2vpKP0JptM1+HslcigevoT M80z1Eq/Qn4PnaJddIQy0KaLJiC6g3nMDbC90Jtos/kLmkIz6R56hmah1x103txv9iG6hJbR ATqI9n9kmnBEGmc+bX5ADlqMPjcjcsasNw9TNpWQjxrg3UwnmUd8x2wjJ1UA3aP0OO2jZ+kT djc7araZveZp8xy2qpMmUSPKRnaUnRMPS/eYj5p/NwfBRAEVYdQw7aRfov/DKAM4WgPsNtbD drJdgle4WzgqbZEnDn4FHgppPkoNraF7wUA/PUf/os/Zp4JTzBR7xOfNG81/UzrVYZZ8JlHq Rfkpyg7M6QSzsemsijWwjewhtou9LhQJy4Sg8EPhTuEjcZG4Ulwvvi7dISXk7fLDtvTBC+YJ 8wXzDZpILrqZ1tImzO4Unab/0BdMRF+TmIdVMB+7BSXG9gr9bB/rFxrYADstHGDvsvfZp+yi IAsZwgShWOgRdgoHhVPCK2K7uEt8RHxXvCDNlQV5n/yhzWP/y2DT4NbBV8wK85z5GY5YB7mx Mj5aRKspgtl20w30Y8ziEMphrNpz9Dy9ZJX32SQ6T5+BBWLZLJeVs4Uoi9hNrJW1s8fYcZST Fpb/ClgIIU3IEiYKk4RGoUnoEmLCG0JMzBOLxAXiCvEwyovim+JF8aIkS+OkCdJ8qZa2S13S HpQnpaekhPSqPEueKy+Sl8sxeau8XWyWz8hv2jbZdtgStk9t/8CxWG9fY9+O1XkJe/ZZ7OWv L4lNAfpyup2amZ810W6sxj4WoTh2Vwu7F3x1U4G5StwkzhemYzecpLuwW/fQRtoqrqR95lvi AfozdkonuozRbyQfueSfY3XupunYRUPFW1hUWJA/1TNF+65bxZE/KS83xznx2gnjx2VnZY7N SB+T5rDbZEkUGJUEtOqwqk8N69JUraamlNtaBI7IJY4wfsqqXj0yR1d5uwhCIzK9yGy9LNOb zPSmMlmmOofmlJaoAU3VX/ZrqsFWLA5Cv8+vhVT9vKUvtPT7LX0sdLcbDdSAs82v6iysBvTq 3rZ4IOwvLWH9XtAxprSEHxxeSucd61QV2YgDlqp4RkDP1fwBPUeDjpjoCURa9IbFwYA/z+0O wQfXkiDGKC1p14GTtmW0aC3bDC81hbkWWRnUxUhIF8K8r6xifaLm1ydu+ND5tTmsBbZfEtQF T3UkGq/WveFtIJebYW5FtsOqa1TRrbAlFNTZliEQHGMHkHK4yWeCJ9yh6mmaT2uLd4RBLi0J JnK9udbhq1NDMJHjzbGM0pJ+56YKN2bfX1pZWsllhdu5KSk//knS/9oAl85Nz70HWbckRQDj DGi1wKmrzdYgGsDO5LfoTIo3zwRPuEIM02wHnipdwJ4RPbrsqY3oscZhGG3+JLhwhz+RlpNr PYR8IeSH45mzsVLIz9TU+AU8rcPa+U9GeiJDHpsn8wLxIF/o1F7RWWRY7+UPSw9m3ebU2vj6 9lprCltzBi5xwObUcMz6eDzAG4JuXQ3BgbfJkjqD0hqCRxjbETKYucUgv6sf76ji6lsQLuFb rd2P8WGUlsBR5IZ2XYlajZGr+V5R42q8tiWuVqtt2EySx5IIROOhaWCwMQieaClG9IbyUmo0 FJqNfqbxftAE6fEQeugY6gHSck37CknTS/AwFac2BBcH9Zg/T/f6Q1gFbN+BhqA+gJ0bCiGr LIUUiDe2O4cwlwNzWRHi1yd7wbtLDF2E4nHeZ2NQc+sD8XhenP/ekrbB6HKHd8hhEE/hlBss 1oC2EJo7z1oDt+YGrBDn9AZs6eEdhXf2KzM8I4UbLb8HtDMshmdeJYZnjYbh2aNiuCKFdATD c4C5gjP8/W+P4bkjGJ53ZYa9KdwAWQm0Xoth31ViuGo0DPtHxXAghXQEw9XAHOAMz//2GK4Z wXDtlRlekMINkHVAu8BiuP4qMbxwNAwvGhXDN6WQjmC4AZhv4gwv/vYYXjKC4cYrM7w0hRsg lwHtUovh5VeJ4R+MhuHgqBgOpZCOYHgFMIc4wzenGPbm6XTpORy77Nilq34wr7yEcrwpydnk Yy4o/PMZH9C4MvBlkQHpTnnwfxMK///HRySdxrebiP+AqpL/yzimGSShOjINotOo3IYunoUO aYcUIdPO0nG0IlpefBw9yZDTy67Pcmflo/qkHcaXf5Wf+aLKkBZexHc+MqzLjOK75f9diDPB vu729vLp5dVWAsOXWHIGNvw3hcdtzfyqyuKaaGdvtKe9OYKcZJQnI06TzKGLO1I6U6dx+3+c qWTxCmVuZHN0cmVhbQplbmRvYmoKNzAgMCBvYmoKMjcxOAplbmRvYmoKMTkgMCBvYmoKPDwg L1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvQUlaRUdDK0FyaWFs TVQgL0ZvbnREZXNjcmlwdG9yCjcxIDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2Rpbmcg L0ZpcnN0Q2hhciAxNjUgL0xhc3RDaGFyIDIwOCAvV2lkdGhzIFsKMzUwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMAowIDAgMCAwIDAgMCAwIDU1NiBdID4+CmVuZG9iago3MSAwIG9iago8PCAvVHlwZSAv Rm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9BSVpFR0MrQXJpYWxNVCAvRmxhZ3MgMzIgL0Zv bnRCQm94IFstNjY1IC0zMjUgMjAwMCAxMDA2XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDkw NSAvRGVzY2VudCAtMjEyIC9DYXBIZWlnaHQgNzE2IC9TdGVtViA5NSAvTGVhZGluZwozMyAv WEhlaWdodCA1MTkgL1N0ZW1IIDg0IC9BdmdXaWR0aCA0NDEgL01heFdpZHRoIDIwMDAgL0Zv bnRGaWxlMiA3MiAwIFIgPj4KZW5kb2JqCjcyIDAgb2JqCjw8IC9MZW5ndGggNzMgMCBSIC9M ZW5ndGgxIDcwMDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrVl5eBRVtj/3 3uolG+kEyNpJV9OkkXRiIIABwiSdpQNMZA/ajUE6hEiCYKJhc4NmFIFmU0YZwQWXUVFHqXSQ 6YAOUdQZUZanjI4ruMyg8w2Cfp86bqn3u9UNguM3759XN79zzj3n3O3UqVu3OouvW9JCyRQi Qd7mRU0dZFzZn4J1NC9drMbqKVlE5oarOuYvitX7L0T9mvkLr78qVs8Jgj/d2tI0L1anH8Av aYUiVmcjwQe3Llq8PFbPfg88eWF7c9ye40fduqhpeXx8knb1mqZFLTH/3NGy3tHeuThet4Ff 1HFdS9yfoX3Sn7ZA6Y05gPYjYmCCvqRxdB9ZiJONSugyIuUPSh6ZUJd2U2rjb/c+NnpO6riv rLlWo/VDHw8plMJL98y9/LtdP863kTUZ1QTDXxrQzlLRN5lqbPTdru9uwGRkT+dfoocaxEXd 7izH0WfFUDoBcDE04slz9IghIi9S7vBGhas7fWBpalWxUNG+xKAqaDuwC9gPKDRH5MNqA10J hIBdwH7gKGDGAvMNqwreDuwATgBmkSfsEdVhqxoistE2G+tNFZl0GtABQQ7QEmAKMAfYDOwA zIaf1LQDK4H9wBnATF6RGdkyAnPPjKw3WPeChaVGtSlWbZxtVLsvD8T4pGkxXjsx5jY25jZ8 ZEx9cXWMDymK8fSC0hA6705MKe2tyhAZWGQGJt4ByviLlMoYOegBMZA0gAtM1dB4RXr3YHfp jv1CISa4YDSPHHqvYJGUtNKqRK7z05RODv45PxWz8FPd/dJKd1T9mn9Eu4D9gOAfoXzIP6SV /ISMOWglsAPYDxwBTgNmfgLlOMoH/ANK5e9TCVAJzAF2APuB04CFvw9q4+/J/DColCsBzt8D tfF3sax3QVP5O5De4e/ovfyNSNmY0h5D8JTEBUdBXMjMjQvpGaVR/nrk26HIKDfuNDJqnxhE FTRCDIoUDHdERVZkXJsjyj/uVj2OB6qG8WOkARwzOYaRj5EKTAWCQAdghvQmpDcpBNwOPABo ALIM1Aao/CDwGvAmDQO8wFTAyo9GMEyUH4m4qx1VGfww/zNlIuKH+F8M/hp/2eCv8pcM/gp4 PuwH+cuRfAdVJcFOaGMDt4GXwG7iz3cPTnfoVWl8PyLoAC0BKoEpwBxgM2Dm+/mgyDxHOjrZ RwfxDDt4hD4z+KP0kJW8Cxxedw0SUJXEPfZXkEB2qDvc3Oveug1VSdybtkCSxH3rBkiSuG9Y BUkS98KlkCRxz1sASRL3rDmQJHFPaYAEEuX3/3HwEEfZlKuZWpXKlyFKyxClZYjSMlL4Mlno W0XO8Z5IYSEitt3rGVroCO1loWdZaDoLPcRCLSy0goVWsdA4FrqShTwsZGehfBbystA+Nhqh CDHv7guqY7xZLHSQhZ5ioU4WcrNQAQsNZiGVlXmj3BmZiKcOzGew7ir50HFn968qsPukcici 6kTOO7En7Ac9AuhGzQsndVDMOTtf8kHdhZWx+sVjS9urJvADaHgAt+EAHQcU3KADSKMD6OQA uksFrQTmAL3AaUAHzPAehHVsNmgqaAlQCcwBVgKnAbMxndOYCqd2UDnFXcbESkArgSmyxg+g DEJxcqc3z2a3eWwTxGY7S81nU/L1fF5GGRnYm9PTrGlRlrLnm5R/f5NCCVUJfBPfTHm4EbfH +ebIt3mOKLs74t7nqBrIfkf5CrKOjSE3KwAfTZ1GfRTZrVI/kuz8SfDSiP0yNEuNuIsce1k/ 2WqP41v7J47P7FEO8VP7PsdbalRhEcdfoXlyj+OYfZ3jlZKoFZpn3VEGtlc1XHvsox1PHTRc V8GwPeJYIdkex8328Y6r7YahJWa4shM1b6pjunuWYwL6q7XPdXg70eceR6X9Sse4mNco2WaP Yxim4ImJhZjsULsxqCvf6HBmWZS1eossWy1+yxTLJZZSS5HFaXFY8iy5lgHWdKvN2s+abE20 Wq1mq2LlVrIOiOonvB751htgNl5+ZiQ0I8WQbdhhmNxmQIkzK6dfk9Zf1PP6GdWsXuttpvq5 qvb1DFeUJU6bpZlc1UxLr6f6hmpttKc+atGna2Wees0y9Qp/F2ObAtBqfG2UUYM/ynSpWp2r pdf4e4ixtNUbcyW/aPXGQICyMpZWZlWmV6SNqav9BRI0lMFaz09X1k+iJ8uTp22tn+HXnsgL aKVS0PMC9dpvZ6iN/h72JTvjq+1hX0gW8PeICvalb7rUi4raQKA+yi4z/EhlX8APGQMGP2s+ qdKPVGt+zG97zK8A7eE3WDL4JSRQgeFXkJBg+ClM+nV1DvbVdg0GgU+mSp2GT2emer7PwQL4 FIDAJyNEBw2fgxkh6aNVGN3Y7XDJB4ELyyG74WJnOYaLMfMuw6Uk7rLunMs6YyQRm43hIwm6 STlx1iflBHzOC+R/F1uqPR7WXR5obvS1uHxBl68FCGrrl7ZmaaG5qtrVHJAGVRPu4NzmVsmb WrSAq6VWa3bVql3lRrufmRuludxV20WNvgZ/V6O3pTZS7i33uZpqA93jp44su2CsdefGGjn1 F8aaKjsbKccab7T72Vhl0jxejlUmxyqTY433jjfGIiPHp/q7rFQdqMH9k7ybJyUiX4O5zkB1 hq2jwkjecmfWity9OK3spCRPQEt2VWspgMzr4qriKmnCMyVN/aBOjZuyVpQ7c/eynXGTDeo0 VzV5Fi/pXEJZvrba2F8nLqgWL5G3IkY9UveLF1x8mrepVp6t67XCGfVa5bRZ/i6LBdpgbQC6 sWd1SUm+qN4bU14M5VjpKMQ5R6kbJ3UJCXHH/8wFY05QIzo9OGjs62befLaYOgNCy69v4NgK GmYhDI2z/HtxlpIvic4AFtjJPKzzbG9yHYZMMQ1h2Z1nsXhJXIrHYnGcG66dHvJ0ng3J2e48 MlgGMWK12IOtzbSXsoEc02OUrbgpi0g/CeC7SD/Z16Z/Ku2S839io4vGQbSTnmJt9BTtpxfY GbTaRT20m+QRqJbupZvoTlqD19osaNbRdBQT9HeybH03vkwexAvzQToE38tpBe2lDJalf0Yr abV4A61WUwoNoiqaSu20kV2qL6FGOq7cQmV0KV1DHSyk+/VN+hb99/QI9Yi/6D9SEuVQM8oh /XPT3/T3qBgt7qJtdJxtSXiGvBglBM/76DraLmYrTJ+vf4cZOGkZ5qDQJDrEerkHvbfQSZbF bhI16OVhXdNfhJedZlMrbae9bBQbz52mRn2SfogyMMZy9LqNIrQHJUrP0Tss2XRG/71+hrKp iCZiPbvpMOsVfT+u6qtE3EyI0lAaA0s7/Yn+TEeZiz3P203JplKT13SDfowG0HCaidk+hpb/ YN/wFSgrxctKnV6Nj7zVdIeMNr1EH7IcVsKmsMv4UN7O7xfXkRUjDkeZR22I993o/QOk0R6e zI+Ih5Unle/NeX0n9H64I266h+6j51kKVqqyTvYb9ib7mNfwOfwe/pG4U3lced3ShFVfSYto Iz1J37B0NppNY1ewVnYTW8PuYNvYIXaUfcqreAO/mp8WreJa8ZxSjTJD6VRuMd1mWm/+tM/f 92Lf//R9o5fqt9E05MMqzP4uuh8r66Ej9DbKcfqImVgS64eiMiebyW5EWcE2sofYTvY4241R jrKP2Gd4JX3Fvud403Izz8XhRx6BXPw6nDDv5PfyIyhH+b/4tyJTDBIeMUqMEwHRjlmtEbej PCM+VHKUI4qOOJeatpp2mHaanjS9YDpjTrb8Bu/41354+MfCHz/oo761fVv7In279Q9pIO4h 3h74BBuH2TehLMD93oqM20VvsGTELocVsgp2KSIzhy1g17LliOStbDt7xJj70+xZROktdhpz TuF2Y84X81G8mk9BuZK38GtxGNvCd/M3+XfCIpJEqhgoCsV4MVu0iMXierFVaOI18b74SHwt fkDRlUTFoQxS3IpHGa/MUZYo9ysnlZOmRtOrpr+bE82LzLeZo+YvcKqpsEy1TLPMtmy27LEc swaRnQfoGfojMvDcxU6IVcInnqFNfISSjU+Yw8jnOTRPTOLIVL6TreU3s918sGm5uZyXs8l0 RnEj1i/zHfxrXi4msXo2gxbw4bEOzQOUJyCNUw7QKeVZrO0wel5uTmYr+GlzMkVwRhqDM9JL YpjiEa/SO+I4sygP0rtKIstkp/hjYiqy4DmlwuQnp7iXnhbXspvpGe4jSvzeugF5PJk9gX2h gZWyfwsdx+DJyKIy8THdQlfzv9EpPMdr6XdsnjKfNtEIdhOdpEfxVAw1XWMuNA9kr/A2Jcz7 s93ElcexujFsMBOmAXQrmy22m0/zt2kJHVES6QPxB8z+CH9aTFLOmKazVjwBN9NtdK2+iq43 +ZXX2XwS7DIqUE5gd7tJlCpO8JXYVRqxp+3B070X+0CVmARNFjLnUuTFTOwQ21Huxj6hIIPa 8Ixfjl3sMO02N/AozTf1Y9h18EvNq33TaZb+KG3T59M1+hYqxn6wRr8JPe6kv9Nm2slW991I HfiUfBvP9qWmOn7EVKcX8zB/m8/gWy+8v4h2Acuif6I8jTtTYdpHYeUtmkGV+gb9r8jui7DD bqO5OLB+glV+jhEmiF4a0TeZd+l1ogPrPU7T9Md0B0ukVn0hTaFn6RGLiZosHtxjjb2O9d5I LXy6vli09LUhDpsRBS+itQT7zzpvzcyGKm9lxa/GlY8dM7ps1MgRpcOHlVxcXOQpHHrREHfB YNcgp+rIz7Pn5mRnZWYMHNA/Pc2W2i8lOSkxwWoxmxTBGRX5XHVBVXMHNcXtmjChWNZdTVA0 nacIaipUdRf6aKps1wTTBZ5eeF71M09vzNN7zpPZ1HE0rrhI9blU7VCtS42yWdP8kDfWugKq dsqQJxny7YacAtnpRAPVl9Vaq2osqPq0uqWtYV+wtriIdSUl1rhqWhKLi6grMQliEiQt09XR xTIrmCHwTN/YLk7WFCxRy3HV+rRsF5qiG1Hga5qnTZ3m99XmOp2B4iKN1TS75mokT0oew4Vq jGE0c41mMYZR23DG0Wi92lXUG94QtdHcoCd5nmteU6NfE03ow6eleTBurZZ5wydZP1XROc5k a8635oqwL6tNlc7h8BpVe2Ca/7y2uU7ZQyCAPtCWF9QFw3UYegPuVL08i2t8dcCvsdUYEgfL AmNVsfXFTr0FwQWqluCqdrWGFwRxa3LCGk2/3hnJyfH26Ccox6eGG/wup1aZ6wo01dq7BlB4 +vXd2V41+0JLcVGXLS0W2K5+qXEhOeV8oQVBj9kMyXCXUv30c5Flco6uiTgJamqzipn4XVjT aElaRlO4eTRuAK4AQyttHu5Im5ZQEwzbxko9lsg0U4HNpYa/ImSA69S/LtQ0xTXmAttXJI0y T86lmsaazsqax6MVFsoUsdTgnmKOFUZ9VHHR0ih3uTps+H6WHw00FbFtCowtQfidTnmD10e9 NBcVLTTNH6urNDc3Qt4SnK15UFp6z1oGzpSW0FnLueZBFzJ5t/yepYGa1X3uL9WW0d/XOlZj Gf/F3BKz189w1eNorPrCwXjW1jdcUIvZZUARN9jikta/xi9yOXRS4rnCsMZOyGddcFz2J2tK Af7MRlLPi1qsyEpDw9Q6zRacEKOBRKcz/sz8X42i+hnZymA/NYsvQxvriU80Nm2t/IL6BdNL Dov6Bmw5HCf7cDjxAhtSLTbLiXGGjMeHvlOt0WgmnswC/OGTY7REIFfzImSwNOApMtSB3Hj1 AsfceKMALpmdxUV12DPD4TqXWhcOhpuiemiuS7W5wj38Bf5CuMOH3S6WOFF97/pcrW5DABFr ZWPxeHCq7nKxtdO6vGztjFn+HvzEoa5t8Ec44zXB6kDXYNj8PSqR19ByqZVK6aLKCtUzLDLC rYZ/bo+XKGRYFUNh1Jvx64ahizlBx6g5ymM621k/Dp0S03kNnVyf3GNqGvzx22IkhHz0kEP4 Dw264YdokdKpy//HMBR5JcMwF/wRnI5jGkP9/0i40ddAKsdbHa8secg3yf/EWIicac60AhD8 WkQ/qKL3B6+JvidV6ZXzW8SO8lachZLI0YNDxQxvvwTzayoNwxl3SfLlj2V5bF/PPkUlp4YP 6z/ykhGleEOaXYPci+5qbbvrrrbWu/jhtjvvbIOMvvQf2EGlnV+BUfO9qWwU8RyTiiGyle4b sjyTbZ/Mtv2DSiahKzHKOVBROtnBO+6Q047NnfQhONf+0iWgXINzi5xvejx+ZvnPpqqJs3zj azxV17U1LZzU8L9JrxxcCmVuZHN0cmVhbQplbmRvYmoKNzMgMCBvYmoKNDY3MAplbmRvYmoK NzQgMCBvYmoKKE1hYyBPUyBYIDEwLjExLjMgUXVhcnR6IFBERkNvbnRleHQpCmVuZG9iago3 NSAwIG9iagooUG93ZXJQb2ludCkKZW5kb2JqCjc2IDAgb2JqCihEOjIwMTYwMjIyMTI0OTMy WjAwJzAwJykKZW5kb2JqCjc3IDAgb2JqCigpCmVuZG9iago3OCAwIG9iagpbIF0KZW5kb2Jq CjEgMCBvYmoKPDwgL1Byb2R1Y2VyIDc0IDAgUiAvQ3JlYXRvciA3NSAwIFIgL0NyZWF0aW9u RGF0ZSA3NiAwIFIgL01vZERhdGUgNzYgMCBSIC9LZXl3b3Jkcwo3NyAwIFIgL0FBUEw6S2V5 d29yZHMgNzggMCBSID4+CmVuZG9iagp4cmVmCjAgNzkKMDAwMDAwMDAwMCA2NTUzNSBmIAow MDAwMDUzNzg1IDAwMDAwIG4gCjAwMDAwMDA3OTcgMDAwMDAgbiAKMDAwMDAyMjMxMyAwMDAw MCBuIAowMDAwMDAwMDIyIDAwMDAwIG4gCjAwMDAwMDA3NzggMDAwMDAgbiAKMDAwMDAwMDkw MSAwMDAwMCBuIAowMDAwMDAyMjEzIDAwMDAwIG4gCjAwMDAwMDQ5ODUgMDAwMDAgbiAKMDAw MDAwMDAwMCAwMDAwMCBuIAowMDAwMDIyNjY5IDAwMDAwIG4gCjAwMDAwMDEwMTAgMDAwMDAg biAKMDAwMDAwMjE5MiAwMDAwMCBuIAowMDAwMDAyMjQ5IDAwMDAwIG4gCjAwMDAwMDQ5NjQg MDAwMDAgbiAKMDAwMDAwNjIyMCAwMDAwMCBuIAowMDAwMDA1MDIxIDAwMDAwIG4gCjAwMDAw MDYxOTkgMDAwMDAgbiAKMDAwMDAwNjMyNyAwMDAwMCBuIAowMDAwMDQ4MzE4IDAwMDAwIG4g CjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDA0NDc1NyAwMDAwMCBuIAowMDAwMDA4MDU1IDAw MDAwIG4gCjAwMDAwMDY0NjEgMDAwMDAgbiAKMDAwMDAwODAzNCAwMDAwMCBuIAowMDAwMDA4 MTYyIDAwMDAwIG4gCjAwMDAwMDk2MTIgMDAwMDAgbiAKMDAwMDAwODI5NiAwMDAwMCBuIAow MDAwMDA5NTkxIDAwMDAwIG4gCjAwMDAwMDk3MTkgMDAwMDAgbiAKMDAwMDAxMTExNyAwMDAw MCBuIAowMDAwMDA5ODUzIDAwMDAwIG4gCjAwMDAwMTEwOTYgMDAwMDAgbiAKMDAwMDAxMTIy NCAwMDAwMCBuIAowMDAwMDEyNjg2IDAwMDAwIG4gCjAwMDAwMTEzNTggMDAwMDAgbiAKMDAw MDAxMjY2NSAwMDAwMCBuIAowMDAwMDEyNzkzIDAwMDAwIG4gCjAwMDAwMTQ1MTYgMDAwMDAg biAKMDAwMDAxMjkyNyAwMDAwMCBuIAowMDAwMDE0NDk1IDAwMDAwIG4gCjAwMDAwMTQ2MjMg MDAwMDAgbiAKMDAwMDAxNjU3OSAwMDAwMCBuIAowMDAwMDE0NzU3IDAwMDAwIG4gCjAwMDAw MTY1NTggMDAwMDAgbiAKMDAwMDAxNjY4NiAwMDAwMCBuIAowMDAwMDE4MTI2IDAwMDAwIG4g CjAwMDAwMjI0MzYgMDAwMDAgbiAKMDAwMDAxNjgyMCAwMDAwMCBuIAowMDAwMDE4MTA1IDAw MDAwIG4gCjAwMDAwMTgyMzQgMDAwMDAgbiAKMDAwMDAyMDEwMyAwMDAwMCBuIAowMDAwMDE4 MzY4IDAwMDAwIG4gCjAwMDAwMjAwODIgMDAwMDAgbiAKMDAwMDAyMDIxMSAwMDAwMCBuIAow MDAwMDIyMDcxIDAwMDAwIG4gCjAwMDAwMjAzNDUgMDAwMDAgbiAKMDAwMDAyMjA1MCAwMDAw MCBuIAowMDAwMDIyMTc5IDAwMDAwIG4gCjAwMDAwMjI1MjYgMDAwMDAgbiAKMDAwMDAyMjYx OCAwMDAwMCBuIAowMDAwMDIzOTM4IDAwMDAwIG4gCjAwMDAwMjMxNTcgMDAwMDAgbiAKMDAw MDAyMzkxOCAwMDAwMCBuIAowMDAwMDI0MTczIDAwMDAwIG4gCjAwMDAwNDQ3MzUgMDAwMDAg biAKMDAwMDA0NTI0MCAwMDAwMCBuIAowMDAwMDQ0OTIyIDAwMDAwIG4gCjAwMDAwNDUyMjAg MDAwMDAgbiAKMDAwMDA0NTQ4OSAwMDAwMCBuIAowMDAwMDQ4Mjk3IDAwMDAwIG4gCjAwMDAw NDg1ODEgMDAwMDAgbiAKMDAwMDA0ODg0MSAwMDAwMCBuIAowMDAwMDUzNjAxIDAwMDAwIG4g CjAwMDAwNTM2MjIgMDAwMDAgbiAKMDAwMDA1MzY3NSAwMDAwMCBuIAowMDAwMDUzNzA0IDAw MDAwIG4gCjAwMDAwNTM3NDYgMDAwMDAgbiAKMDAwMDA1Mzc2NSAwMDAwMCBuIAp0cmFpbGVy Cjw8IC9TaXplIDc5IC9Sb290IDYwIDAgUiAvSW5mbyAxIDAgUiAvSUQgWyA8OGYwYzk3NmE4 NmM5OGU0NmZlMjI0MDI5NWEyYzk0MWQ+Cjw4ZjBjOTc2YTg2Yzk4ZTQ2ZmUyMjQwMjk1YTJj OTQxZD4gXSA+PgpzdGFydHhyZWYKNTM5MTUKJSVFT0YK --WIyZ46R2i8wDzkSu-- From nobody Mon Feb 22 05:13:12 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568471A8703 for ; Mon, 22 Feb 2016 05:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.906 X-Spam-Level: X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXwzhcUKU8jJ for ; Mon, 22 Feb 2016 05:13:10 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC471A870B for ; Mon, 22 Feb 2016 05:13:09 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AXAgDuCMtW/yYyC4deGQEBAQEPAQEBAYJfK4E/Brg6ghMBDYFmhg0CgTw4FAEBAQEBAQFkJ4RBAQEBAQMSKD8MBAIBCA0BAwQBAQEKCwkJBzIUCQgBAQQOBQgah3gBnkeZHAEBAQEBAQQBAQEBAQEBAQEBARWGE4Q5hDU/gmyBDwWXBwGPOYRDgxmFO45JHgEBQoNkaoczAXwBAQE X-IPAS-Result: A2AXAgDuCMtW/yYyC4deGQEBAQEPAQEBAYJfK4E/Brg6ghMBDYFmhg0CgTw4FAEBAQEBAQFkJ4RBAQEBAQMSKD8MBAIBCA0BAwQBAQEKCwkJBzIUCQgBAQQOBQgah3gBnkeZHAEBAQEBAQQBAQEBAQEBAQEBARWGE4Q5hDU/gmyBDwWXBwGPOYRDgxmFO45JHgEBQoNkaoczAXwBAQE X-IronPort-AV: E=Sophos;i="5.22,484,1449550800"; d="scan'208";a="168494840" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Feb 2016 08:13:08 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 22 Feb 2016 08:13:08 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 22 Feb 2016 14:13:06 +0100 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "Weil, Jason" Thread-Topic: [lmap] reminder: LMAP WG interim - today at noon EST Thread-Index: AdFtZXv79wVUFUF/RgOJ+wgiaVweBwAAormAAAKZLSA= Date: Mon, 22 Feb 2016 13:13:06 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF238F9@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BF2380D@AZ-FFEXMB04.global.avaya.com> <20160222125613.GA13087@elstar.local> In-Reply-To: <20160222125613.GA13087@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] reminder: LMAP WG interim - today at noon EST X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 13:13:11 -0000 Hi, Thanks Juergen.=20 Taking into account Juergen's health - all, please have a look at the slide= s, they are pretty clear in raising the problems and asking the questions, = be prepared to provide input in the discussions.=20 Regards, Dan =20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Monday, February 22, 2016 2:56 PM > To: Romascanu, Dan (Dan); Weil, Jason > Cc: lmap@ietf.org > Subject: Re: [lmap] reminder: LMAP WG interim - today at noon EST >=20 > On Mon, Feb 22, 2016 at 11:38:26AM +0000, Romascanu, Dan (Dan) wrote: > > > > If you plan to use any slides, please send them to Jason or me for uplo= ading > prior to the meeting. > > >=20 > Dan and Jason, >=20 > I have put some of the issues on slides. Note that I got a bad cold over = the > weekend and I am not sure how 'usable' I will be at the virtual interim > meeting later today. >=20 > /js >=20 From nobody Mon Feb 22 08:53:33 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9C91B37E4 for ; Mon, 22 Feb 2016 08:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrSh_zdURstr for ; Mon, 22 Feb 2016 08:53:30 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 847A51B3806 for ; Mon, 22 Feb 2016 08:52:30 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id BEF6F1224BF; Mon, 22 Feb 2016 11:56:10 -0500 (EST) Received: from exchange.research.att.com (sentinel.research.att.com [135.207.255.38]) by mail-blue.research.att.com (Postfix) with ESMTP id 18E9EF0216; Mon, 22 Feb 2016 11:52:30 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by sentinel.research.att.com ([fe80::7914:9c7e:6a73:a8d6%10]) with mapi; Mon, 22 Feb 2016 11:52:30 -0500 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder Date: Mon, 22 Feb 2016 11:52:28 -0500 Thread-Topic: [lmap] milliseconds in ma-periodic-interval and ma-event-random-spread Thread-Index: AdFtbfCngMX4MCP4T9+vwftaG9BpwgAE3w2A Message-ID: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F0F@NJFPSRVEXG0.research.att.com> References: <20160211155559.GA55278@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D3FF3B4288C@NJFPSRVEXG0.research.att.com> <20160215134250.GA72079@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D3FF3A30882@NJFPSRVEXG0.research.att.com> <20160222123816.GB12837@elstar.local> In-Reply-To: <20160222123816.GB12837@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] milliseconds in ma-periodic-interval and ma-event-random-spread X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 16:53:32 -0000 Hi Juergen,=20 please see reply appended below, Al > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, February 22, 2016 7:38 AM > To: MORTON, ALFRED C (AL) > Cc: lmap@ietf.org > Subject: Re: [lmap] milliseconds in ma-periodic-interval and ma-event- > random-spread >=20 > On Mon, Feb 15, 2016 at 06:37:35PM -0500, MORTON, ALFRED C (AL) wrote: >=20 > > > Again, I > > > question that it is realistic to schedule tasks to start once per > > > second in order to send one packet. > > [ACM] > > I do too, because I don't understand why anyone would do that. > > The measurement system is supposed to send one packet per second > > in my example -- one sending process would send, wait, send, wait, ... > > > > So, we have two measurement streams, sending 1 packet per second as > follows: > > > > Stream 1 12:00:01, :02, :03, :04, :05, :06, :07, :08, :09, ... > > Stream 2 12:00:07, :08, :09, ... > > > > and the streams synchronize on one second clock ticks. >=20 > We need to distinguish the start of the task(s) creating streams and > the timing of the streams generated by the tasks. >=20 > > > Anyway, my original proposal was primarily about ma-periodic- > interval. > > [ACM] > > I can live with one second resolution on ma-periodic-interval, > > as long as there is millisecond resolution on ma-event-random-spread. > > > > > If people feel strongly that the ma-event-random-spread should > remain > > > with milliseconds resolution, I can probably live with that. Having > > > ma-periodic-interval at milliseconds resolution is however more of a > > > pain to implement. > > [ACM] > > I understand, but it was possible when we implemented RFC 3432, > > back before it was published and in draft stage. >=20 > Is RFC 3432 scheduling the invocation of arbitrary tasks or is it > about sending packets from within a measurement task? >=20 > The LMAP scheduler is by design a coarse grained scheduler, if you > need precision for your packet trains, you have to implement that fine > grained scheduling in the measurement tasks (to minimize the many > possible sources of extra delays). >=20 > t0 scheduled invocation as per instruction > t1=3Dt0+ds invocation of the scheduled action > t2=3Dt1+do measurement task starts running > t3=3Dt2+dm time first packet is given to the OS kernel > t4=3Dt3+dk time packet hits the wire >=20 > To achieve reasonable precision, you have to control t3 (t4 is usually > hard without special OS support) from within the measurement task. >=20 > ds =3D delay by the lmap scheduler (which is also depending on the load > of the OS) >=20 > do =3D delay by the OS to load and start a measurement task (which is > also depending on the load of the OS) >=20 > dm =3D delay by the measurement task (time to initialize and generate the > first test packet) >=20 > dk =3D delay by the kernel to move the packet on the wire (may include > media access specific delays) >=20 > My point is that making the LMAP scheduler highly precise is a > non-goal since ds+do+dm may add notable delays. The only way to > achieve precision where it is needed is to not depend on the LMAP > scheduler but to do the fine grained scheduling inside the measurement > task. >=20 [ACM]=20 You've sorted-out the schedule, task, and measurement packet timing=20 very nicely, and though it appears we've been talking about different schedules/processes, this overlap has existed for quite some time. I don't think it's useful to apply random time offsets to the=20 t0 scheduled invocation as per instruction but we do need to pass t3 t3=3Dt2+dm time first packet is given to the OS kernel and although dm will have a random component dm =3D delay by the measurement task (time to initialize and generate th= e first test packet) we need to pass a random offset to the measurement task that governs t3 to the extent possible. If we prefer, we could pass a time range for the random offsets and the measurement task selects the actual value (which could be a 10 second range, for example, with millisecond resolution). We also need to ensure that t3 is achievable by setting t0 far enough=20 in advance of t3 (+ plus random offset) and account for: > t1=3Dt0+ds invocation of the scheduled action > t2=3Dt1+do measurement task starts running The time needed between t2 and t3 may be significant, to account for a control protocol to arrange the tests with a Measurement Peer, as may be needed in OWAMP, TWAMP, and others. Al > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Mon Feb 22 09:00:36 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D051B37D1 for ; Mon, 22 Feb 2016 09:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbi8joWYvfJl for ; Mon, 22 Feb 2016 09:00:30 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807BB1B37B7 for ; Mon, 22 Feb 2016 09:00:25 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B4B4F1CF7; Mon, 22 Feb 2016 18:00:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3I2o5xktuWbd; Mon, 22 Feb 2016 18:00:18 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Feb 2016 18:00:21 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1FF32002C; Mon, 22 Feb 2016 18:00:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CgNzr-eyWQYJ; Mon, 22 Feb 2016 18:00:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F315C20031; Mon, 22 Feb 2016 18:00:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DF82839FA8DD; Mon, 22 Feb 2016 18:00:17 +0100 (CET) Date: Mon, 22 Feb 2016 18:00:17 +0100 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20160222170017.GA13596@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <20160211155559.GA55278@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D3FF3B4288C@NJFPSRVEXG0.research.att.com> <20160215134250.GA72079@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D3FF3A30882@NJFPSRVEXG0.research.att.com> <20160222123816.GB12837@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F0F@NJFPSRVEXG0.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F0F@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] milliseconds in ma-periodic-interval and ma-event-random-spread X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 17:00:33 -0000 On Mon, Feb 22, 2016 at 11:52:28AM -0500, MORTON, ALFRED C (AL) wrote: > > The LMAP scheduler is by design a coarse grained scheduler, if you > > need precision for your packet trains, you have to implement that fine > > grained scheduling in the measurement tasks (to minimize the many > > possible sources of extra delays). > > > > t0 scheduled invocation as per instruction > > t1=t0+ds invocation of the scheduled action > > t2=t1+do measurement task starts running > > t3=t2+dm time first packet is given to the OS kernel > > t4=t3+dk time packet hits the wire > > > > To achieve reasonable precision, you have to control t3 (t4 is usually > > hard without special OS support) from within the measurement task. > > > > ds = delay by the lmap scheduler (which is also depending on the load > > of the OS) > > > > do = delay by the OS to load and start a measurement task (which is > > also depending on the load of the OS) > > > > dm = delay by the measurement task (time to initialize and generate the > > first test packet) > > > > dk = delay by the kernel to move the packet on the wire (may include > > media access specific delays) > > > > My point is that making the LMAP scheduler highly precise is a > > non-goal since ds+do+dm may add notable delays. The only way to > > achieve precision where it is needed is to not depend on the LMAP > > scheduler but to do the fine grained scheduling inside the measurement > > task. > > > [ACM] > You've sorted-out the schedule, task, and measurement packet timing > very nicely, and though it appears we've been talking about different > schedules/processes, this overlap has existed for quite some time. > > I don't think it's useful to apply random time offsets to the > t0 scheduled invocation as per instruction But this is what ma-event-random-spread is all about. I think it is useful to have so that you can schedule report tasks randomized at a course grained level. Again, seconds resolution is what I find sufficient. The idea is to have the same event configured on 1000s of devices to trigger reporting but they do not all report at the same time; the spread may in the order of an hour. > but we do need to pass t3 > t3=t2+dm time first packet is given to the OS kernel > > and although dm will have a random component > dm = delay by the measurement task (time to initialize and generate the > first test packet) > > we need to pass a random offset to the measurement task that governs > t3 to the extent possible. If we prefer, we could pass a time range for > the random offsets and the measurement task selects the actual value > (which could be a 10 second range, for example, with millisecond > resolution). This sounds like just like one more parameter to pass to the task, not something we need to take special care of at the info/data model. > We also need to ensure that t3 is achievable by setting t0 far enough > in advance of t3 (+ plus random offset) and account for: > > t1=t0+ds invocation of the scheduled action > > t2=t1+do measurement task starts running > > The time needed between t2 and t3 may be significant, to account for > a control protocol to arrange the tests with a Measurement Peer, > as may be needed in OWAMP, TWAMP, and others. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 22 09:20:43 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3111B380C for ; Mon, 22 Feb 2016 09:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlJs1bJffqVc for ; Mon, 22 Feb 2016 09:20:31 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A261B380B for ; Mon, 22 Feb 2016 09:20:31 -0800 (PST) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 44E0F41640FEC; Mon, 22 Feb 2016 17:20:28 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u1MHKTAU016355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Feb 2016 17:20:29 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u1MHKKlg014841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Feb 2016 17:20:29 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.7]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 22 Feb 2016 12:20:25 -0500 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] remove ma-task form ma-instruction-obj Thread-Index: AQHRaocTgRk/svInGUqRedOWCRVa0p8yQmLQgAYQFwCAAAHTYA== Date: Mon, 22 Feb 2016 17:20:24 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A5D8DBF@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20160218123022.GA4899@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5D59D4@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160222120918.GA12837@elstar.local> In-Reply-To: <20160222120918.GA12837@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] remove ma-task form ma-instruction-obj X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 17:20:36 -0000 Juergen, If a task is sent down as part of the configuration object; its meant for m= aintaining its ecosystem; if it sent as part of the instruction its meant f= or testing. The MA should indeed know what tasks it allows for what purpose= s. I didn't understand your comment - unless it is preconfigured a controller = always sends down the task to the measurement agent... BR, Tim=20 -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Monday, February 22, 2016 6:09 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] remove ma-task form ma-instruction-obj On Thu, Feb 18, 2016 at 08:40:11PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > An instruction gets sent down by the controller as part of a testing cycl= e; a config object (which includes is general configuration or preconfigura= tion) - I think you are blurring the lines - Note that there are control ta= sks in the config so these are the "safe config" tasks. The tasks in the in= struction are testing tasks so they should be "safe" for testing. I don't t= hink we should say or enforce anything more than that. > Why does it make sense for a controller to send a task as part of an instru= ction to the measurement agent? How does a measurement agent decide whether= such a task should be accepted or rejected? > That being said in the BBF TR-069 implementation an MA has tasks some of = which are referenced by the current instruction - these are known as test t= asks by their reference to the instruction. Referencing tasks is just fine. The question is whether a controller should= be allowed to send tasks down to the measurement agent. /js =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, February 18, 2016 12:30 PM > To: lmap@ietf.org > Subject: [lmap] remove ma-task form ma-instruction-obj >=20 > Hi, >=20 > while implementing things, I figured out that my daemon 'lmapd' needs, in= addition to instructions received from the controller, some basic configur= ation information. In particular, configuration is needed about the program= s that are considered measurement tasks and 'safe' to execute. (It does not= make sense to allow a controller to execute /bin/sh as a measurement task = for obvious reasons). This configuration information should not generally b= e writable. >=20 > Looking at the current information model, it seems this can be very easil= y be achieved by removing ma-task from ma-instruction-obj into the ma-confi= g-obj. As a consequence of this change, the ma-task-obj is not something th= at is exposed to be messed around with by a controller. The controller is e= ssentially restricted to 'play' with schedules and suppressions (and we lik= ely should add events to the ma-instruction-obj). Note that with this cange= , we would not really need the recently added ma-capability-task-obj anymor= e since a controller can read the (for the controller read-only) configured= tasks and then create schedules with actions referring to the configured t= asks. >=20 > In terms of implementation, what this boils down to is having a setup=20 > where you have in /etc/lmapd/lmapd.conf the configuration of the lmapd=20 > itself including the configuration of the tasks that the lmapd allows=20 > to be use. Instructions (locally generated or received from remote > controllers) would go into /var/spool/lmapd/instructions/*.conf. Upon=20 > startup, the lmapd would read and merge all these conf files to=20 > produce the configuration that is executed. (There is likely a bit=20 > more work to support multiple controllers with proper isolation but=20 > that is outside the scope of LMAP for now I think.) >=20 > For the YANG data model, my preferred solution would be to tag the=20 > leafs in the /lmap/tasks/ subtree with nacm:default-deny-write (RFC > 6536) to document that this part of the configuration model usually is no= t writable for controllers. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 22 11:21:24 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47CF1B29FC for ; Mon, 22 Feb 2016 11:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjgT4mSYz1hn for ; Mon, 22 Feb 2016 11:21:20 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1182A1A01EA for ; Mon, 22 Feb 2016 11:21:20 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id BE16712218D for ; Mon, 22 Feb 2016 14:25:00 -0500 (EST) Received: from exchange.research.att.com (sentinel.research.att.com [135.207.255.38]) by mail-blue.research.att.com (Postfix) with ESMTP id C1037F048E for ; Mon, 22 Feb 2016 14:21:16 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by sentinel.research.att.com ([fe80::7914:9c7e:6a73:a8d6%10]) with mapi; Mon, 22 Feb 2016 14:21:16 -0500 From: "MORTON, ALFRED C (AL)" To: "lmap@ietf.org" Date: Mon, 22 Feb 2016 14:21:14 -0500 Thread-Topic: First take on the Definition of Cycle_ID Thread-Index: AdFtpaQ4sad9WcjaTKOX8iqNJBtJzA== Message-ID: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F6E@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lmap] First take on the Definition of Cycle_ID X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 19:21:21 -0000 LMAP, please have a look, feel free to add aspects to the=20 definition that would be valuable. Al Cycle_ID The Cycle_ID is a special form of Tag that provides an easily distinguishable index for sets of results (or other aspect)=20 from each "cycle" of Repeating Tasks. Each repetition=20 of the task and its results (including measurements of multiple=20 metrics on a single packet stream, for example) have the=20 same Cycle_ID. Some portion of the Cycle_ID will be numerical. The Cycle_ID must be easily searchable, such that the values=20 assigned (by the MA?) should be predictable and meaningful to a human conducting a search for specific results. From nobody Mon Feb 22 11:49:24 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4944D1A00B8 for ; Mon, 22 Feb 2016 11:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9ooAN3YPaNO for ; Mon, 22 Feb 2016 11:49:22 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240061A0151 for ; Mon, 22 Feb 2016 11:49:21 -0800 (PST) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 16D7241A6C422; Mon, 22 Feb 2016 19:49:18 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u1MJnKp4006985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Feb 2016 19:49:20 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u1MJnKwl004780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Feb 2016 19:49:20 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.7]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Mon, 22 Feb 2016 14:49:20 -0500 From: "Carey, Timothy (Nokia - US)" To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" Thread-Topic: [lmap] First take on the Definition of Cycle_ID Thread-Index: AQHRbaY/H9xloonneUWcon4gUZ36Dp84dDag Date: Mon, 22 Feb 2016 19:49:20 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A5D9125@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F6E@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F6E@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] First take on the Definition of Cycle_ID X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 19:49:24 -0000 Al, >From the framework document: Cycle-ID: A tag that is sent by the Controller in an Instruction and echoed= by the MA in its Report. The same Cycle-ID is used by several MAs that use= the same Measurement Method for a Metric with the same Input Parameters. H= ence, the Cycle-ID allows the Collector to easily identify Measurement Resu= lts that should be comparable. Th information model says: In addition the Task Configuration may optionally also be given a Measureme= nt Cycle ID. The purpose of this ID is to easily identify a set of measurem= ent results that have been produced by Measurement Tasks with comparable Op= tions. This ID could be manually incremented or otherwise changed when an O= ption change is implemented which could mean that two sets of results shoul= d not be directly compared. What is wrong with the Information model definition - is it because the def= inition is missing the notion of "repetition" and the idea that it should b= e easily distinguishable? BR, Tim -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Monday, February 22, 2016 1:21 PM To: lmap@ietf.org Subject: [lmap] First take on the Definition of Cycle_ID LMAP, please have a look, feel free to add aspects to the definition that w= ould be valuable. Al Cycle_ID The Cycle_ID is a special form of Tag that provides an easily distinguishab= le index for sets of results (or other aspect) from each "cycle" of Repeati= ng Tasks. Each repetition of the task and its results (including measuremen= ts of multiple metrics on a single packet stream, for example) have the sam= e Cycle_ID. Some portion of the Cycle_ID will be numerical. The Cycle_ID must be easily searchable, such that the values assigned (by t= he MA?) should be predictable and meaningful to a human conducting a search= for specific results. From nobody Mon Feb 22 12:32:02 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257341A1ABC for ; Mon, 22 Feb 2016 12:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktqkNFmoDVai for ; Mon, 22 Feb 2016 12:31:57 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5771A1BA3 for ; Mon, 22 Feb 2016 12:31:53 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id CB7F612209C; Mon, 22 Feb 2016 15:35:33 -0500 (EST) Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.99]) by mail-green.research.att.com (Postfix) with ESMTP id 06BB8E051B; Mon, 22 Feb 2016 15:28:32 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by njmtcas1.research.att.com ([fe80::f1f7:6c06:d0d0:d48c%10]) with mapi; Mon, 22 Feb 2016 15:31:49 -0500 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" Date: Mon, 22 Feb 2016 15:31:47 -0500 Thread-Topic: [lmap] First take on the Definition of Cycle_ID Thread-Index: AQHRbaY/H9xloonneUWcon4gUZ36Dp84dDaggAAHNaA= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F9D@NJFPSRVEXG0.research.att.com> References: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F6E@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A5D9125@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A5D9125@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] First take on the Definition of Cycle_ID X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 20:32:00 -0000 Hi Tim, For the current Info model definition, I don't agree that=20 concept of a "cycle" matches the notion of modifying options. The modifications can be tracked with version numbers,=20 and the new versions are not cyclic in timing or in their nature. Yes, for me, a cycle requires repetition over time. So the framework definition almost gets there by mentioning results that are=20 comparable, but it only deals with repetition *across MAs*. In the Framework def, a repeated measurement task would have the same Cycle-ID for every repetition, in every MA that performs the=20 the same repeated task, and we lose the ability to distinguish the repetitions over time (without use of additional info, like time). In summary, there is value in the both of the "consolidating indexes" described in the Framework and the Info Model as "Cycle-ID",=20 but neither of these indexes have anything to do with Cycles! If we want to compare results, at same time and equivalent locations, we ha= ve to employ the Registered metric and all its parameters, and include the=20 location of the measurement points (http://tools.ietf.org/html/rfc7398 ). Many dimensions to keep equivalent. =20 Way beyond the notion of "cycle", IMO. Al > -----Original Message----- > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > Sent: Monday, February 22, 2016 2:49 PM > To: MORTON, ALFRED C (AL); lmap@ietf.org > Subject: RE: [lmap] First take on the Definition of Cycle_ID >=20 > Al, >=20 > From the framework document: > Cycle-ID: A tag that is sent by the Controller in an Instruction and > echoed by the MA in its Report. The same Cycle-ID is used by several MAs > that use the same Measurement Method for a Metric with the same Input > Parameters. Hence, the Cycle-ID allows the Collector to easily identify > Measurement Results that should be comparable. >=20 > Th information model says: >=20 > In addition the Task Configuration may optionally also be given a > Measurement Cycle ID. The purpose of this ID is to easily identify a set > of measurement results that have been produced by Measurement Tasks with > comparable Options. This ID could be manually incremented or otherwise > changed when an Option change is implemented which could mean that two > sets of results should not be directly compared. >=20 >=20 > What is wrong with the Information model definition - is it because the > definition is missing the notion of "repetition" and the idea that it > should be easily distinguishable? >=20 > BR, > Tim > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Monday, February 22, 2016 1:21 PM > To: lmap@ietf.org > Subject: [lmap] First take on the Definition of Cycle_ID >=20 > LMAP, please have a look, feel free to add aspects to the definition > that would be valuable. >=20 > Al >=20 > Cycle_ID >=20 > The Cycle_ID is a special form of Tag that provides an easily > distinguishable index for sets of results (or other aspect) from each > "cycle" of Repeating Tasks. Each repetition of the task and its results > (including measurements of multiple metrics on a single packet stream, > for example) have the same Cycle_ID. Some portion of the Cycle_ID will > be numerical. >=20 > The Cycle_ID must be easily searchable, such that the values assigned > (by the MA?) should be predictable and meaningful to a human conducting > a search for specific results. >=20 From nobody Tue Feb 23 09:51:45 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358F01A2119 for ; Tue, 23 Feb 2016 09:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.906 X-Spam-Level: X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMhmY5tus_jn for ; Tue, 23 Feb 2016 09:51:43 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7101A879F for ; Tue, 23 Feb 2016 09:51:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AIAgB+m8xW/yYyC4deGQEBAQEPAQEBAYJfK4E/BrpjAQ2BZoYNAoFJOBQBAQEBAQEBZCeEQQEBAQEDEihLBAIBCA0EBAEBCxQJBzIUCQgBAQQBEggah3sBo2OZOgEBAQEBBQEBAQEBAQEBGIYThDmENYMrgQ8FlwcBjzmEQ4MZhTlEjgUeAQFCg2RqhzgBfAEBAQ X-IPAS-Result: A2AIAgB+m8xW/yYyC4deGQEBAQEPAQEBAYJfK4E/BrpjAQ2BZoYNAoFJOBQBAQEBAQEBZCeEQQEBAQEDEihLBAIBCA0EBAEBCxQJBzIUCQgBAQQBEggah3sBo2OZOgEBAQEBBQEBAQEBAQEBGIYThDmENYMrgQ8FlwcBjzmEQ4MZhTlEjgUeAQFCg2RqhzgBfAEBAQ X-IronPort-AV: E=Sophos;i="5.22,490,1449550800"; d="scan'208";a="168809678" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 Feb 2016 12:51:41 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 23 Feb 2016 12:51:42 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Tue, 23 Feb 2016 18:51:39 +0100 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" Thread-Topic: First take on the Definition of Cycle_ID Thread-Index: AdFtpaQ4sad9WcjaTKOX8iqNJBtJzAAvQFpw Date: Tue, 23 Feb 2016 17:51:38 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF6AEA7@AZ-FFEXMB04.global.avaya.com> References: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F6E@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F6E@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] First take on the Definition of Cycle_ID X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 17:51:44 -0000 By 'predictable and meaningful' you mean what?=20 - some form of timestamp - some form of increasing integer index?=20 or .... Regards, Dan > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED > C (AL) > Sent: Monday, February 22, 2016 9:21 PM > To: lmap@ietf.org > Subject: [lmap] First take on the Definition of Cycle_ID >=20 > LMAP, please have a look, feel free to add aspects to the definition that > would be valuable. >=20 > Al >=20 > Cycle_ID >=20 > The Cycle_ID is a special form of Tag that provides an easily distinguish= able > index for sets of results (or other aspect) from each "cycle" of Repeatin= g > Tasks. Each repetition of the task and its results (including measurement= s of > multiple metrics on a single packet stream, for example) have the same > Cycle_ID. Some portion of the Cycle_ID will be numerical. >=20 > The Cycle_ID must be easily searchable, such that the values assigned (by= the > MA?) should be predictable and meaningful to a human conducting a search > for specific results. >=20 From nobody Tue Feb 23 11:02:39 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7E91A88A1 for ; Tue, 23 Feb 2016 11:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDkC6RrF5lQK for ; Tue, 23 Feb 2016 11:02:30 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB0B1A8892 for ; Tue, 23 Feb 2016 11:02:30 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id 9AC63122FF1; Tue, 23 Feb 2016 14:06:13 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg11.research.att.com [135.207.255.123]) by mail-green.research.att.com (Postfix) with ESMTP id 7C9EAE0FCC; Tue, 23 Feb 2016 13:59:08 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG11.research.att.com ([fe80::516e:6eec:2697:ec78%17]) with mapi; Tue, 23 Feb 2016 14:02:26 -0500 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Date: Tue, 23 Feb 2016 14:02:26 -0500 Thread-Topic: First take on the Definition of Cycle_ID Thread-Index: AdFtpaQ4sad9WcjaTKOX8iqNJBtJzAAvQFpwAAAlMeA= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D3FF3A310C3@NJFPSRVEXG0.research.att.com> References: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F6E@NJFPSRVEXG0.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA6BF6AEA7@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BF6AEA7@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] First take on the Definition of Cycle_ID X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 19:02:33 -0000 Hi Dan, Here's an example scenario for analyzing results=20 of tests repeated every 15 minutes (I don't intend=20 to require some specification for Cycle_ID,=20 just show its potential value): The Cycle_ID could include the=20 date, YYYY-MM-DD, time, HH:MM:SS (and perhaps the time zone, too) code, decimal number to distinguish between different repeating tests. ; HH:MM:SS ; YYY-MM-DD; (assuming Zulu time) The predictable and meaningful aspect is linked to "conducting a search". Suppose I wanted the results from a test that ran at the beginning of the scheduled LMAP interim meeting: I can easily construct the first and la= st Cycle_IDs and extract the inclusive data range.=20 0000001; 17:00:00 ; 2016-02-22; 0000001; 19:00:00 ; 2016-02-22; All the metrics collected as part of this repeating task would have the same unique Cycle_ID corresponding to that task. The task could be to run a quick traceroute, then measure one-way delay, delay variation, and lo= ss on the same measurement stream. All these metrics have the same Cycle_ID.= =20 With the above as a Cycle_ID, I don't need the scheduled time of the task. I can report the "Red" timestamps pertaining to the actual measurement=20 times with the table of results instead. (As I described yesterday, "Blue" timestamps refer to the schedule times for a task, and "Red" refer to the actual measurement time interval when packets are on the wire). OTOH, it's somewhat harder to find the results if *only* the "Red" timestam= ps are available, because they will have an unknown part in terms of the=20 exact minute, second, and possibly sub-second when the measurement interval= started. You have to compose your query with ranges just to find a single set of=20 results.=20 And, it may be easier to determine that results for some cycles are missing= . I could take the Cycle_ID one step further, and incorporate repeating tests= over space and time: ; HH:MM:SS ; YYY-MM-DD; ; where a single MA conducts periodic measurements with a list of target MPs. So, I'm thinking-up ways that LMAP users might want to index, collate, and = access the mass repeated measurement results once collected.=20 Does that help? Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) > Sent: Tuesday, February 23, 2016 12:52 PM > To: MORTON, ALFRED C (AL); lmap@ietf.org > Subject: Re: [lmap] First take on the Definition of Cycle_ID >=20 > By 'predictable and meaningful' you mean what? > - some form of timestamp > - some form of increasing integer index? > or .... >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED > > C (AL) > > Sent: Monday, February 22, 2016 9:21 PM > > To: lmap@ietf.org > > Subject: [lmap] First take on the Definition of Cycle_ID > > > > LMAP, please have a look, feel free to add aspects to the definition > that > > would be valuable. > > > > Al > > > > Cycle_ID > > > > The Cycle_ID is a special form of Tag that provides an easily > distinguishable > > index for sets of results (or other aspect) from each "cycle" of > Repeating > > Tasks. Each repetition of the task and its results (including > measurements of > > multiple metrics on a single packet stream, for example) have the same > > Cycle_ID. Some portion of the Cycle_ID will be numerical. > > > > The Cycle_ID must be easily searchable, such that the values assigned > (by the > > MA?) should be predictable and meaningful to a human conducting a > search > > for specific results. > > >=20 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Feb 24 02:22:06 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EAD1A01EA for ; Wed, 24 Feb 2016 02:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.906 X-Spam-Level: X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9iriAvvpAwm for ; Wed, 24 Feb 2016 02:22:03 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCE11A01A1 for ; Wed, 24 Feb 2016 02:22:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D3AQDbg81W/xUHmMZeGQEBAQEPAQEBAYJfK4E/BrpnAQ2BZoYNAoE8OBQBAQEBAQEBZCeEQQEBAQECARIoRAcEAgEIDQQEAQELFAkHMhQJCAEBBAESCBqHdAgBpEmZMgEBAQEBAQEDAQEBAQEBAQEBAQEVhhOEOYQ1gyuBDwWHWI8vAY88hESDGYU5RI4FHgEBQoNkaoZjAXwBAQE X-IPAS-Result: A2D3AQDbg81W/xUHmMZeGQEBAQEPAQEBAYJfK4E/BrpnAQ2BZoYNAoE8OBQBAQEBAQEBZCeEQQEBAQECARIoRAcEAgEIDQQEAQELFAkHMhQJCAEBBAESCBqHdAgBpEmZMgEBAQEBAQEDAQEBAQEBAQEBAQEVhhOEOYQ1gyuBDwWHWI8vAY88hESDGYU5RI4FHgEBQoNkaoZjAXwBAQE X-IronPort-AV: E=Sophos;i="5.22,493,1449550800"; d="scan'208";a="162381078" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Feb 2016 05:22:02 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 24 Feb 2016 05:22:02 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Wed, 24 Feb 2016 11:21:53 +0100 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" Thread-Topic: First take on the Definition of Cycle_ID Thread-Index: AdFtpaQ4sad9WcjaTKOX8iqNJBtJzAAvQFpwAAAlMeAAIl/LoA== Date: Wed, 24 Feb 2016 10:21:53 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF6B94C@AZ-FFEXMB04.global.avaya.com> References: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F6E@NJFPSRVEXG0.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA6BF6AEA7@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D3FF3A310C3@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D3FF3A310C3@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] First take on the Definition of Cycle_ID X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 10:22:05 -0000 > Does that help? It helps a lot.=20 The definition will need a little more text to explain and/or an example. Looks good to me on the user side. We need to hear also the coder side.=20 Regards, Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Tuesday, February 23, 2016 9:02 PM > To: Romascanu, Dan (Dan); lmap@ietf.org > Subject: RE: First take on the Definition of Cycle_ID >=20 > Hi Dan, >=20 > Here's an example scenario for analyzing results of tests repeated every = 15 > minutes (I don't intend to require some specification for Cycle_ID, just = show > its potential value): >=20 > The Cycle_ID could include the > date, YYYY-MM-DD, > time, HH:MM:SS (and perhaps the time zone, too) code, decimal number to > distinguish between different repeating tests. >=20 > ; HH:MM:SS ; YYY-MM-DD; (assuming Zulu time) >=20 > The predictable and meaningful aspect is linked to "conducting a search". >=20 > Suppose I wanted the results from a test that ran at the beginning of the > scheduled LMAP interim meeting: I can easily construct the first and last > Cycle_IDs and extract the inclusive data range. >=20 > 0000001; 17:00:00 ; 2016-02-22; > 0000001; 19:00:00 ; 2016-02-22; >=20 > All the metrics collected as part of this repeating task would have the s= ame > unique Cycle_ID corresponding to that task. The task could be to run a qu= ick > traceroute, then measure one-way delay, delay variation, and loss on the > same measurement stream. All these metrics have the same Cycle_ID. >=20 > With the above as a Cycle_ID, I don't need the scheduled time of the task= . > I can report the "Red" timestamps pertaining to the actual measurement > times with the table of results instead. (As I described yesterday, "Blue= " > timestamps refer to the schedule times for a task, and "Red" refer to the > actual measurement time interval when packets are on the wire). >=20 > OTOH, it's somewhat harder to find the results if *only* the "Red" > timestamps are available, because they will have an unknown part in terms > of the exact minute, second, and possibly sub-second when the > measurement interval started. > You have to compose your query with ranges just to find a single set of > results. >=20 > And, it may be easier to determine that results for some cycles are missi= ng. >=20 > I could take the Cycle_ID one step further, and incorporate repeating tes= ts > over space and time: >=20 > ; HH:MM:SS ; YYY-MM-DD; ; >=20 > where a single MA conducts periodic measurements with a list of target MP= s. >=20 > So, I'm thinking-up ways that LMAP users might want to index, collate, an= d > access the mass repeated measurement results once collected. >=20 > Does that help? > Al >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan > > (Dan) > > Sent: Tuesday, February 23, 2016 12:52 PM > > To: MORTON, ALFRED C (AL); lmap@ietf.org > > Subject: Re: [lmap] First take on the Definition of Cycle_ID > > > > By 'predictable and meaningful' you mean what? > > - some form of timestamp > > - some form of increasing integer index? > > or .... > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, > > > ALFRED C (AL) > > > Sent: Monday, February 22, 2016 9:21 PM > > > To: lmap@ietf.org > > > Subject: [lmap] First take on the Definition of Cycle_ID > > > > > > LMAP, please have a look, feel free to add aspects to the definition > > that > > > would be valuable. > > > > > > Al > > > > > > Cycle_ID > > > > > > The Cycle_ID is a special form of Tag that provides an easily > > distinguishable > > > index for sets of results (or other aspect) from each "cycle" of > > Repeating > > > Tasks. Each repetition of the task and its results (including > > measurements of > > > multiple metrics on a single packet stream, for example) have the > > > same Cycle_ID. Some portion of the Cycle_ID will be numerical. > > > > > > The Cycle_ID must be easily searchable, such that the values > > > assigned > > (by the > > > MA?) should be predictable and meaningful to a human conducting a > > search > > > for specific results. > > > > > From nobody Wed Feb 24 03:17:24 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9A81A87B8 for ; Wed, 24 Feb 2016 03:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GGnh5cAsUtp for ; Wed, 24 Feb 2016 03:17:21 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C4281A872C for ; Wed, 24 Feb 2016 03:17:21 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0AE6D1F2E for ; Wed, 24 Feb 2016 12:17:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EznDRZ9EEbZB for ; Wed, 24 Feb 2016 12:17:07 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 24 Feb 2016 12:17:19 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0069320033 for ; Wed, 24 Feb 2016 12:17:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yvoiREFNs4PV; Wed, 24 Feb 2016 12:17:17 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 225402002B; Wed, 24 Feb 2016 12:17:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 091E639FC691; Wed, 24 Feb 2016 12:17:16 +0100 (CET) Date: Wed, 24 Feb 2016 12:17:16 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20160224111716.GA17232@elstar.local> Mail-Followup-To: lmap@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [lmap] some thoughts about (additional) lmap monitoring objects X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 11:17:23 -0000 Hi, I have written a small monitoring interface that allows me to look at the status of our lmapd while it is running. The tool is essentially parsing the XML serialization of the YANG defined /lmap-state tree (with a few exceptions). Here is how it looks: ---8<--- agent-id: 550e8400-e29b-41d4-a716-446655440000 hardware: Linux x86_64 firmware: #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) version: lmapd version 0.3 last-started: 2016-02-23T19:31:34+01:00 SCHEDULE/ACTION S INV SUP OVR ERR SPACE LST LFS L-INVOKE L-COMPLETE L-FAILURE demo R 852 0 0 851 0 09:42:35 mtr R 852 0 0 0 0 0 0 09:42:35 09:41:42 happy E 851 0 0 851 0 1 1 09:41:42 09:41:43 09:41:43 report-primary D 0 0 0 0 1019K report E 0 0 0 0 0 0 0 report-backup D 0 0 0 0 0 report E 0 0 0 0 0 0 0 ---8<--- Explanation: S = state ([R]unning, [E]nabled, [D]isabled, [S]uppressed) INV = number of invocations (added as discussed at the interim) SUP = number of invocations suppressed due to suppression OVR = number of invocations suppressed due to overlaps ERR = number of failed completions LST = last status code LFS = last failed status code L-INVOKE = last invocation time L-COMPLETE = last completion time L-FAILURE = last failed completion time The demo schedule runs the two actions mtr and happy. The happy action always fails. The mtr action feeds data to report-primary while the hello action feeds data to both report-primary and report-backup. Unfortunately, report-backup is disabled for whatever reason. There are two issues that I like to bring up here. o I think we should have status information about suppressions as well. Suppressions can be active or inactive. They have a start and an end. I think the information model should have an ma-status-suppression-obj and the YANG data model a corresponding list so that I can obtain information which suppressions are currently active. o Talking about the buffers or queues that buffer results while results move from an action to a subsequent destination schedule has been controversial in the past. I still remember the Dublin interim meeting where we spent some cycles on this. Still these buffers exist and in the example above you see that data is piling up since the reporter is not delivering the data. So I implemented the SPACE column that shows how much data has been allocated by the schedule (usually incoming data) and the actions (usually data produced while running). Since this buffer space is somewhat important for the well being of an lmapd daemon, I would appreciate if we would have at least status reporting objects; ideally we would even have mechanism to control the usage of this space - but I recall that people did not like to go into that direction. /js PS: On another measurement system I am hosting, failure to deliver data due to a TLS cert issue did pile up more than 3GB of data. Luckily this runs on a host where there are still some plenty of GBs to allocate but thinking about CPEs, I believe it is crucial to be able to flush data or to control how data is aged out if space is getting tight or to suppress schedules in a well-defined manner (e.g., by defining additional events that trigger when available space crosses certain thresholds). -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 24 09:39:14 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EC71B3AC0 for ; Wed, 24 Feb 2016 09:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.905 X-Spam-Level: X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rc7RDY0bGuxM for ; Wed, 24 Feb 2016 09:39:08 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C891B3AA1 for ; Wed, 24 Feb 2016 09:39:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AHAgDb6c1W/xUHmMZeGQEBAQEPAQEBAYI+IStSc7heghMBDYFmhg4CgUU4FAEBAQEBAQFkHAuEQwEBAxILEF4BDAkVViYBBBsah30Bn3uFEpkyDAEdhhOIboMrgQ8FlwcBjzyERIMZhTmOSR4BAUKDZIdNAXwBAQE X-IPAS-Result: A2AHAgDb6c1W/xUHmMZeGQEBAQEPAQEBAYI+IStSc7heghMBDYFmhg4CgUU4FAEBAQEBAQFkHAuEQwEBAxILEF4BDAkVViYBBBsah30Bn3uFEpkyDAEdhhOIboMrgQ8FlwcBjzyERIMZhTmOSR4BAUKDZIdNAXwBAQE X-IronPort-AV: E=Sophos;i="5.22,494,1449550800"; d="scan'208,217";a="162454461" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Feb 2016 12:39:06 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 24 Feb 2016 12:39:06 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Wed, 24 Feb 2016 12:39:05 -0500 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: IETF 95 - call for agenda items Thread-Index: AdFvKkDqWobkyZULShGNQSlQqoxaDw== Date: Wed, 24 Feb 2016 17:39:04 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF6BEA3@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BF6BEA3AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] IETF 95 - call for agenda items X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 17:39:10 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF6BEA3AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The WG is scheduled to meet at IETF 95. No draft schedule was yet published= , but we suppose it will show up in the next week or so. Until then it's a = good time to propose items for the agenda. If you plan to drive any of the= discussions concerning the current chartered items, or if you have new ite= ms to propose, please send us a message. Thanks and Regards, Jason and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF6BEA3AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The WG is scheduled to meet at IETF 95. No draft sch= edule was yet published, but we suppose it will show up in the next week or= so. Until then it’s a good time to propose items for the agenda. If = you plan to drive any  of the discussions concerning the current chartered items, or if you have new items to propos= e, please send us a message.

 

Thanks and Regards,

 

Jason and Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BF6BEA3AZFFEXMB04globa_-- From nobody Thu Feb 25 09:28:07 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42631B2EB9 for ; Thu, 25 Feb 2016 09:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY6VZPd6162d for ; Thu, 25 Feb 2016 09:28:03 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810F21B2EB2 for ; Thu, 25 Feb 2016 09:28:01 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 532AE1B70 for ; Thu, 25 Feb 2016 18:28:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id sIa6IbOXn1wJ for ; Thu, 25 Feb 2016 18:27:41 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 25 Feb 2016 18:27:59 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FB4A20036 for ; Thu, 25 Feb 2016 18:27:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AFOZkLXq46Xi; Thu, 25 Feb 2016 18:27:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A4632002C; Thu, 25 Feb 2016 18:27:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E0A2639FDEC0; Thu, 25 Feb 2016 18:27:57 +0100 (CET) Date: Thu, 25 Feb 2016 18:27:57 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20160225172757.GA20410@elstar.local> Mail-Followup-To: lmap@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [lmap] large random spreads compared to periodicity X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 17:28:05 -0000 Hi, suppose I have a timer event triggering lets say every minute and I have a random spread that can be larger than 60 seconds. Lets assume the random spreads that I get are 20, 80, 10, 0. Is this the expected behavior? t0: event triggers 1st time t0+20: 1st schedule starts to run (due to 20 seconds random spread) t0+60: event triggers 2nd time t0+120: event triggers 3rd time t0+130: 3rd schedule starts to run (due to 10 seconds random spread) t0+140: 2nd schedule starts to run (due to 80 seconds random spread) Note that this means that I have to manage a potentially large number of future invocations. If someone configures a random spread interval of that is way larger than the periodicity, then I might queue up a potentially large number of future schedules. A more resource conserving interpretation would be to simply ignore any future schedules if the previous one not yet been executed, that is, in the sequence above, one would ignore the 3rd schedule at t0+130 since the 2nd scheduled for t0+140 did not run yet. The next one to run would be the 4th schedule at t0+180. I consider a random spread that is larger than the periodicity a somewhat dubious configuration and that means I prefer to not spent code complexity at it. Perhaps the solution is that say that the behaviour in this situation is simply undefined and implementation dependent. This allows implementations to do what is sensible from the way the code works and at the same time tells people to not use random spreads that can exceed the periodicity. Or is there a use case for this? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 25 17:55:42 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF141A1BDC for ; Thu, 25 Feb 2016 17:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giQx-lUeBbea for ; Thu, 25 Feb 2016 17:55:39 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 73EE31A1BDA for ; Thu, 25 Feb 2016 17:55:39 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 9E69AD8166; Thu, 25 Feb 2016 20:59:29 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg11.research.att.com [135.207.255.123]) by mail-blue.research.att.com (Postfix) with ESMTP id DA825F0478; Thu, 25 Feb 2016 20:55:38 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG11.research.att.com ([fe80::516e:6eec:2697:ec78%17]) with mapi; Thu, 25 Feb 2016 20:55:38 -0500 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , "lmap@ietf.org" Date: Thu, 25 Feb 2016 20:55:37 -0500 Thread-Topic: [lmap] large random spreads compared to periodicity Thread-Index: AdFv8eqce8rzXwiRRymwpkJVgIDZRQARUwVg Message-ID: <4AF73AA205019A4C8A1DDD32C034631D3FF3CBB88E@NJFPSRVEXG0.research.att.com> References: <20160225172757.GA20410@elstar.local> In-Reply-To: <20160225172757.GA20410@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] large random spreads compared to periodicity X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 01:55:41 -0000 js wrote: > I consider a random spread that is larger than the periodicity a > somewhat dubious configuration and that means I prefer to not spent > code complexity at it. > I agree, in fact let's say a task takes 20 seconds to complete and needs to run every 60 seconds as in your example. Then the schedule says start on each minute:00 seconds, and the random spread can be no larger than 40 seconds to allow the task to complete and start the next minute=20 in the clear, with any random spread possible in the=20 next minute. So, Max(random_spread) =3D period - max_task_duration Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Thursday, February 25, 2016 12:28 PM > To: lmap@ietf.org > Subject: [lmap] large random spreads compared to periodicity >=20 > Hi, >=20 > suppose I have a timer event triggering lets say every minute and I > have a random spread that can be larger than 60 seconds. Lets assume > the random spreads that I get are 20, 80, 10, 0. Is this the expected > behavior? >=20 > t0: event triggers 1st time > t0+20: 1st schedule starts to run (due to 20 seconds random spread) > t0+60: event triggers 2nd time > t0+120: event triggers 3rd time > t0+130: 3rd schedule starts to run (due to 10 seconds random spread) > t0+140: 2nd schedule starts to run (due to 80 seconds random spread) >=20 > Note that this means that I have to manage a potentially large number > of future invocations. If someone configures a random spread interval > of that is way larger than the periodicity, then I might queue up a > potentially large number of future schedules. >=20 > A more resource conserving interpretation would be to simply ignore > any future schedules if the previous one not yet been executed, that > is, in the sequence above, one would ignore the 3rd schedule at t0+130 > since the 2nd scheduled for t0+140 did not run yet. The next one to > run would be the 4th schedule at t0+180. >=20 > I consider a random spread that is larger than the periodicity a > somewhat dubious configuration and that means I prefer to not spent > code complexity at it. >=20 > Perhaps the solution is that say that the behaviour in this situation > is simply undefined and implementation dependent. This allows > implementations to do what is sensible from the way the code works and > at the same time tells people to not use random spreads that can > exceed the periodicity. Or is there a use case for this? >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap