From nobody Fri Apr 1 17:00:13 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9BD12D1E9 for ; Fri, 1 Apr 2016 17:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 dZlzacs8btEF for ; Fri, 1 Apr 2016 17:00:07 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE9412D191 for ; Fri, 1 Apr 2016 17:00:06 -0700 (PDT) Received: from EVMHT03-UKBR.domain1.systemhost.net (193.113.108.56) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 2 Apr 2016 01:00:03 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVMHT03-UKBR.domain1.systemhost.net (193.113.108.56) with Microsoft SMTP Server (TLS) id 8.3.342.0; Sat, 2 Apr 2016 01:00:04 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 2 Apr 2016 01:00:03 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1104.000; Sat, 2 Apr 2016 01:00:04 +0100 From: To: , Thread-Topic: [lmap] Question on multiple outstanding suppressions Thread-Index: AdGF3V4xmgrf/a4tTNWOZo/M3lKnUgAAFPfwAOxpyAAAER67AAAA2uaAAABZtIAABjjJAAAXtT4AAIfjPSA= Date: Sat, 2 Apr 2016 00:00:03 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329084814.GA38204@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329173257.GB40617@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A619A6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160330074956.GC41707@elstar.local> In-Reply-To: <20160330074956.GC41707@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.187.101.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: bs7652@att.com, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 02 Apr 2016 00:00:11 -0000 Let me check if I understand how suppression would now work, or my likely t= o reveal my misunderstanding.=20 For each schedule there's a tag ma-schedule-suppression-tags<0..*> Example of this tag would be "suppress-by-default" When ma-suppression-obj is sent, then the ma-suppression-match string can b= e set to "suppress-by-default". Then all schedules with this tag are suppre= ssed. Did I get that right? Similarly, each action can have a tag ma-action-suppression-tags<0..*.> Similarly, another example of the tag is "suppress-if-controller-seems-dead= " However, Tasks have a Boolean ma-task-suppress-by-default ...? Thanks, phil -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: 30 March 2016 04:50 To: Carey, Timothy (Nokia - US) Cc: bs7652@att.com; KEN KO ; lmap@ietf.org Subject: Re: [lmap] Question on multiple outstanding suppressions On Tue, Mar 29, 2016 at 08:31:06PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > Looking at the text of section 3.3 > The new multi-instance model doesn't seem to support this text. I disagree. =20 > For example - can't just turn-on/turn-off suppression by setting enabled = to false and the unsuppression. This question is orthogonal to the question whether there are multiple supp= ressions or just effectively two. > Honestly it worked better when it was a single object with an enable and/= or endtime... > Why? There were two mechanisms, the traditional suppression and the reactio= n to loss of the controller. We now have a single mechanism that covers bot= h cases and at the same time is more flexible and supports provisioned supp= ressions. The question whether we add enable/disable leafs in random places or everyw= here is a separate question. When it comes to YANG, I am not a big fan, I r= ather would like to see a generic solution for this problem. /js > BR, > Tim >=20 > -----Original Message----- > From: EXT Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, March 29, 2016 12:33 PM > To: KEN KO > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > Subject: Re: [lmap] Question on multiple outstanding suppressions >=20 > You can still use suppressions as a panic button. You can have multiple p= anic buttons if you want to (but you do not have to use it in that way). Yo= u can have automatic pre-configured panic buttons (the new years evening ex= ample) but you do not have to use it that way. >=20 > If you read the emails, you will note that we had not only panic buttons = but also a second mechanism to handle the loss of the controller. Instead o= f having multiple hardwired mechanisms to disable 'things', the proposal ba= ck then was to generalize _one_ mechanism so that it can do it all. The sup= pressions we have now makes code simpler, extensible and more powerful at t= he same time. I do not see a good reason to go back. >=20 > /js >=20 > On Tue, Mar 29, 2016 at 05:22:55PM +0000, KEN KO wrote: > > TR-304 (from BBF) and RFC 7594 both document suppression as a single in= stance. It is intended to be used as a fairly blunt instrument, for instanc= e to prevent measurement traffic from exacerbating network congestion durin= g an unusual event. > >=20 > > From TR-304 section 5.2: "Suppression might be used when the measuremen= t system wants to minimize inessential traffic, for example after a major n= etwork incident. Only one suppression message can exist at a time in a give= n MA. A new suppression message completely replaces the previous one." > >=20 > > From RFC 7594 section 5.2.2.1: "The main motivation for Suppression is = to enable the Measurement System to eliminate Measurement Traffic, because = there is some unexpected network issue, for example. There may be other ci= rcumstances when Suppression is useful, for example, to eliminate inessenti= al Reporting traffic (even if there is no Measurement Traffic). > >=20 > > From RFC 7594 section 5.2.2: "However, Suppression information always r= eplaces (rather than adds to) any previous Suppression information." > >=20 > > The idea in both documents was to provide a mechanism that was flexible= in how tasks could be configured to react to it, but simple in how the "pa= nic button" would be pushed in the case of a network event.=20 > >=20 > > From the archive link Juergen provided, it looks like the purpose of su= ppression in the information model has changed fairly dramatically, and tha= t it is now a more generic capability to disable tasks according to any of = multiple schedules. I'm concerned that it may no longer provide the simple = "panic button" that was intended. Do we really want to deviate in this way = from something that was defined specifically in the framework documents, wh= ich after all are intended to provide guidance for more detailed documentat= ion? > >=20 > > Ken > >=20 > > -----Original Message----- > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Tuesday, March 29, 2016 12:58 PM > > To: Juergen Schoenwaelder; KEN KO > > Cc: lmap@ietf.org; bs7652@att.com > > Subject: RE: [lmap] Question on multiple outstanding suppressions > >=20 > > Juergen, > >=20 > > I suspect it was with good reason that the BBF wanted this as a single = instance active at a time.=20 > >=20 > > Possibly Ken or Barbara could provide the reasoning. > >=20 > > Minimally I would think we would need to be able administratively enabl= e/disable a suppression object; that at least lets me shut them down tempor= arily. > >=20 > > BR, > > Tim > >=20 > > -----Original Message----- > > From: EXT Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, March 29, 2016 3:48 AM > > To: KEN KO > > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > > Subject: Re: [lmap] Question on multiple outstanding suppressions > >=20 > > The original reasoning can be found here: > >=20 > > https://mailarchive.ietf.org/arch/msg/lmap/ptg-TcdfMuVHM93PWisj4u-tb > > FI > >=20 > > Not being able to provision multiple suppressions seems a major limitat= ion to me. > >=20 > > /js > >=20 > > On Thu, Mar 24, 2016 at 03:00:27PM +0000, KEN KO wrote: > > > Tim, thanks for catching this. I'd also like to understand why lmap h= as changed it. > > > Ken > > >=20 > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > > Sent: Thursday, March 24, 2016 9:57 AM > > > To: lmap@ietf.org > > > Cc: KEN KO; bs7652@att.com > > > Subject: Question on multiple outstanding suppressions > > >=20 > > > Team, > > >=20 > > > I noticed that the information model has support for multiple suppres= sions. > > > With the current definition in the information model, it looks like t= here isn't any constraints on multiple suppression requests that can be act= ive at the same time. > > >=20 > > > I just wanted to a confirmation on this. We used to have just 1 suppr= ession object in an instruction. It looks like this changed in draft-07. > > >=20 > > > This actually conflicts with BBF TR-304 Section 5.2 where the text sa= ys: > > > Suppression is the temporary cessation of all or a subset of measurem= ent-related tasks. A Measurement Controller can send a suppress message to = the MA that instructs the MA to temporarily suspend some or all of its sche= duled measurement-related tasks. Suppression ends either in response to an = explicit unsuppress message or at the time indicated in the suppress messag= e. Suppression might be used when the measurement system wants to minimize = inessential traffic, for example after a major network incident. Only one s= uppression message can exist at a time in a given MA. A new suppression mes= sage completely replaces the previous one. > > >=20 > > > So TR-304 would expect 1 suppression with an enable; this is quite di= fferent from the behavior that changed last November. > > >=20 > > >=20 > > > Looking for guidance. > > >=20 > > > BR, > > > Tim > >=20 > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > >=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 >=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 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 From nobody Fri Apr 1 17:11:59 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D47112D101 for ; Fri, 1 Apr 2016 17:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 aGxU9T6OtLRA for ; Fri, 1 Apr 2016 17:11:54 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4131F12D093 for ; Fri, 1 Apr 2016 17:11:54 -0700 (PDT) Received: from E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 2 Apr 2016 01:11:53 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) with Microsoft SMTP Server (TLS) id 8.3.342.0; Sat, 2 Apr 2016 01:11:52 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 2 Apr 2016 01:11:51 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1104.000; Sat, 2 Apr 2016 01:11:51 +0100 From: To: , , Thread-Topic: First take on the Definition of Cycle_ID Thread-Index: AdFtpaQ4sad9WcjaTKOX8iqNJBtJzAAvQFpwAAAlMeAHg/2DQA== Date: Sat, 2 Apr 2016 00:11:51 +0000 Message-ID: <5da26e4cd2d442ad8dcc627b0b1c0a4c@rew09926dag03b.domain1.systemhost.net> 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-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.187.101.44] 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.17 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: Sat, 02 Apr 2016 00:11:57 -0000 Al, Not sure if this got resolved, sorry if this email is now redundant. In your example, I'd have thought that cycle-id would be something like "te= sts-during-lmap-meeting". Then it would be easy for someone to extract all= the relevant results from all the relevant Mas. I think if you want to dis= tinguish between tests during the first 15 minutes and the last 15 minutes,= then you have two options - during data analysis, look at the timestamp in= the results - or create two cycle-ids "tests-during-first-part-of-lmap-mee= ting" and "tests-during-last-part-of-lmap-meeting" phil -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: 23 February 2016 16:02 To: Romascanu, Dan (Dan) ; lmap@ietf.org Subject: Re: [lmap] First take on the Definition of Cycle_ID Hi Dan, 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 s= how its potential value): The Cycle_ID could include the date, YYYY-MM-DD, time, HH:MM:SS (and perhaps the time zone, too) code, decimal number to dis= tinguish 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 s= cheduled LMAP interim meeting: I can easily construct the first and last Cy= cle_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 sam= e 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 th= e 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 time= s with the table of results instead. (As I described yesterday, "Blue" time= stamps refer to the schedule times for a task, and "Red" refer to the actua= l 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 ex= act minute, second, and possibly sub-second when the measurement interval s= tarted. You have to compose your query with ranges just to find a single set of res= ults.=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,=20 > > 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=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. > > >=20 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Apr 1 17:21:46 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E93512D11A for ; Fri, 1 Apr 2016 17:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=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 VcJVatCoskYu for ; Fri, 1 Apr 2016 17:21:43 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45EF412D0FD for ; Fri, 1 Apr 2016 17:14:29 -0700 (PDT) Received: from EVCAS16-UKBR.domain1.systemhost.net (193.113.108.107) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 2 Apr 2016 01:14:28 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVCAS16-UKBR.domain1.systemhost.net (193.113.108.107) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 2 Apr 2016 01:14:26 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 2 Apr 2016 01:14:25 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1104.000; Sat, 2 Apr 2016 01:14:25 +0100 From: To: , Thread-Topic: [lmap] Question on multiple outstanding suppressions Thread-Index: AdGF3V4xmgrf/a4tTNWOZo/M3lKnUgAAFPfwAOxpyAAAER67AAAA2uaAAABZtIAABjjJAAAXtT4AAIkGUiA= Date: Sat, 2 Apr 2016 00:14:25 +0000 Message-ID: <40550b3f2c764fc8bff4918c65c68158@rew09926dag03b.domain1.systemhost.net> References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329084814.GA38204@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329173257.GB40617@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A619A6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160330074956.GC41707@elstar.local> In-Reply-To: <20160330074956.GC41707@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.187.101.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: bs7652@att.com, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 02 Apr 2016 00:21:45 -0000 Different question about suppression. Ma-status-schedule-state can have the values: enabled, active and disabled.= Can you explain the difference between enabled and active, please Thanks phil -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: 30 March 2016 04:50 To: Carey, Timothy (Nokia - US) Cc: bs7652@att.com; KEN KO ; lmap@ietf.org Subject: Re: [lmap] Question on multiple outstanding suppressions On Tue, Mar 29, 2016 at 08:31:06PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > Looking at the text of section 3.3 > The new multi-instance model doesn't seem to support this text. I disagree. =20 > For example - can't just turn-on/turn-off suppression by setting enabled = to false and the unsuppression. This question is orthogonal to the question whether there are multiple supp= ressions or just effectively two. > Honestly it worked better when it was a single object with an enable and/= or endtime... > Why? There were two mechanisms, the traditional suppression and the reactio= n to loss of the controller. We now have a single mechanism that covers bot= h cases and at the same time is more flexible and supports provisioned supp= ressions. The question whether we add enable/disable leafs in random places or everyw= here is a separate question. When it comes to YANG, I am not a big fan, I r= ather would like to see a generic solution for this problem. /js > BR, > Tim >=20 > -----Original Message----- > From: EXT Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, March 29, 2016 12:33 PM > To: KEN KO > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > Subject: Re: [lmap] Question on multiple outstanding suppressions >=20 > You can still use suppressions as a panic button. You can have multiple p= anic buttons if you want to (but you do not have to use it in that way). Yo= u can have automatic pre-configured panic buttons (the new years evening ex= ample) but you do not have to use it that way. >=20 > If you read the emails, you will note that we had not only panic buttons = but also a second mechanism to handle the loss of the controller. Instead o= f having multiple hardwired mechanisms to disable 'things', the proposal ba= ck then was to generalize _one_ mechanism so that it can do it all. The sup= pressions we have now makes code simpler, extensible and more powerful at t= he same time. I do not see a good reason to go back. >=20 > /js >=20 > On Tue, Mar 29, 2016 at 05:22:55PM +0000, KEN KO wrote: > > TR-304 (from BBF) and RFC 7594 both document suppression as a single in= stance. It is intended to be used as a fairly blunt instrument, for instanc= e to prevent measurement traffic from exacerbating network congestion durin= g an unusual event. > >=20 > > From TR-304 section 5.2: "Suppression might be used when the measuremen= t system wants to minimize inessential traffic, for example after a major n= etwork incident. Only one suppression message can exist at a time in a give= n MA. A new suppression message completely replaces the previous one." > >=20 > > From RFC 7594 section 5.2.2.1: "The main motivation for Suppression is = to enable the Measurement System to eliminate Measurement Traffic, because = there is some unexpected network issue, for example. There may be other ci= rcumstances when Suppression is useful, for example, to eliminate inessenti= al Reporting traffic (even if there is no Measurement Traffic). > >=20 > > From RFC 7594 section 5.2.2: "However, Suppression information always r= eplaces (rather than adds to) any previous Suppression information." > >=20 > > The idea in both documents was to provide a mechanism that was flexible= in how tasks could be configured to react to it, but simple in how the "pa= nic button" would be pushed in the case of a network event.=20 > >=20 > > From the archive link Juergen provided, it looks like the purpose of su= ppression in the information model has changed fairly dramatically, and tha= t it is now a more generic capability to disable tasks according to any of = multiple schedules. I'm concerned that it may no longer provide the simple = "panic button" that was intended. Do we really want to deviate in this way = from something that was defined specifically in the framework documents, wh= ich after all are intended to provide guidance for more detailed documentat= ion? > >=20 > > Ken > >=20 > > -----Original Message----- > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Tuesday, March 29, 2016 12:58 PM > > To: Juergen Schoenwaelder; KEN KO > > Cc: lmap@ietf.org; bs7652@att.com > > Subject: RE: [lmap] Question on multiple outstanding suppressions > >=20 > > Juergen, > >=20 > > I suspect it was with good reason that the BBF wanted this as a single = instance active at a time.=20 > >=20 > > Possibly Ken or Barbara could provide the reasoning. > >=20 > > Minimally I would think we would need to be able administratively enabl= e/disable a suppression object; that at least lets me shut them down tempor= arily. > >=20 > > BR, > > Tim > >=20 > > -----Original Message----- > > From: EXT Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, March 29, 2016 3:48 AM > > To: KEN KO > > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > > Subject: Re: [lmap] Question on multiple outstanding suppressions > >=20 > > The original reasoning can be found here: > >=20 > > https://mailarchive.ietf.org/arch/msg/lmap/ptg-TcdfMuVHM93PWisj4u-tb > > FI > >=20 > > Not being able to provision multiple suppressions seems a major limitat= ion to me. > >=20 > > /js > >=20 > > On Thu, Mar 24, 2016 at 03:00:27PM +0000, KEN KO wrote: > > > Tim, thanks for catching this. I'd also like to understand why lmap h= as changed it. > > > Ken > > >=20 > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > > Sent: Thursday, March 24, 2016 9:57 AM > > > To: lmap@ietf.org > > > Cc: KEN KO; bs7652@att.com > > > Subject: Question on multiple outstanding suppressions > > >=20 > > > Team, > > >=20 > > > I noticed that the information model has support for multiple suppres= sions. > > > With the current definition in the information model, it looks like t= here isn't any constraints on multiple suppression requests that can be act= ive at the same time. > > >=20 > > > I just wanted to a confirmation on this. We used to have just 1 suppr= ession object in an instruction. It looks like this changed in draft-07. > > >=20 > > > This actually conflicts with BBF TR-304 Section 5.2 where the text sa= ys: > > > Suppression is the temporary cessation of all or a subset of measurem= ent-related tasks. A Measurement Controller can send a suppress message to = the MA that instructs the MA to temporarily suspend some or all of its sche= duled measurement-related tasks. Suppression ends either in response to an = explicit unsuppress message or at the time indicated in the suppress messag= e. Suppression might be used when the measurement system wants to minimize = inessential traffic, for example after a major network incident. Only one s= uppression message can exist at a time in a given MA. A new suppression mes= sage completely replaces the previous one. > > >=20 > > > So TR-304 would expect 1 suppression with an enable; this is quite di= fferent from the behavior that changed last November. > > >=20 > > >=20 > > > Looking for guidance. > > >=20 > > > BR, > > > Tim > >=20 > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > >=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 >=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 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 From nobody Sat Apr 2 06:30:42 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6156B12D126 for ; Sat, 2 Apr 2016 06:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 k2-rSYhwH_0g for ; Sat, 2 Apr 2016 06:30:38 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E7112D0FA for ; Sat, 2 Apr 2016 06:30:37 -0700 (PDT) Received: from EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 2 Apr 2016 14:30:33 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 2 Apr 2016 14:30:35 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 2 Apr 2016 14:30:35 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1104.000; Sat, 2 Apr 2016 14:30:34 +0100 From: To: , Thread-Topic: [lmap] some lmap result report model changes Thread-Index: AQHRgQSR6F/044lnsE6HtqyKwVze3J92vqQQ Date: Sat, 2 Apr 2016 13:30:34 +0000 Message-ID: References: <20160318105405.GA55018@elstar.local> In-Reply-To: <20160318105405.GA55018@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.187.101.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] some lmap result report model changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 02 Apr 2016 13:30:40 -0000 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: 18 March 2016 07:54 To: lmap@ietf.org Subject: [lmap] some lmap result report model changes 2) It is almost impossible to implement 'conflict' on a per row level. The lmap scheduler can likely track which actions were running during the execution of an action but it surely does not know the internals of the action and hence it can't know how to determine conflicts on a per row level. Likewise, the measurement action does not know how to determine what else is going on on the system and related to the lmap framework. Hence, the conflict should be reported as part of ma-report-action-obj and not as a result row property. [phil] Let me see if I understand.=20 A conflict means that something may have interfered /impacted the measureme= nt results being reported, for example "cross traffic" is detected. I agree= this isn't something that the scheduler knows about - it's detected by the= MA at the time of the measurement.=20 Ma-report-action-obj doesn't seem to exist? I guess ma-report-result-obj.=20 This reports the meta-data for a single executed action.=20 However, if I get it right an action can in fact consist of a series of mea= surements. Assuming these measurements are close in time then I think it's = ok to report conflicts at the action rather than row level. For example, su= ppose the action was "measure the RTT to test server X by sending 10 test p= ackets in quick succession", then I'd be interested in knowing there was cr= oss-traffic sometime during the 10 pkts - knowing that test pkts 1, 2 and 8= suffered cross-traffic is probably too detailed=20 Incidentally I think the draft could do with some example of the difference= between action with several measurements (as in the RTT example) and a ser= ies of actions (measure the RTT every 10 minutes). Or at least the differen= ce that we expect between these - I guess someone is free to treat my examp= le as 10 actions, each of which sends 1 test packet.=20 Thanks phil From nobody Sat Apr 2 06:35:08 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80C012D138 for ; Sat, 2 Apr 2016 06:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 xDkHpVLnJVtW for ; Sat, 2 Apr 2016 06:35:05 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537F512D127 for ; Sat, 2 Apr 2016 06:35:05 -0700 (PDT) Received: from EVHUB05-UKBR.domain1.systemhost.net (193.113.108.173) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 2 Apr 2016 14:35:01 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EVHUB05-UKBR.domain1.systemhost.net (193.113.108.173) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 2 Apr 2016 14:35:03 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 2 Apr 2016 14:35:02 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1104.000; Sat, 2 Apr 2016 14:35:02 +0100 From: To: , Thread-Topic: [lmap] some lmap result report model changes Thread-Index: AQHRgQSR6F/044lnsE6HtqyKwVze3J92xbcA Date: Sat, 2 Apr 2016 13:35:02 +0000 Message-ID: <7df9f95aca974b28bf711f11055bdf64@rew09926dag03b.domain1.systemhost.net> References: <20160318105405.GA55018@elstar.local> In-Reply-To: <20160318105405.GA55018@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.187.101.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] some lmap result report model changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 02 Apr 2016 13:35:07 -0000 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: 18 March 2016 07:54 To: lmap@ietf.org Subject: [lmap] some lmap result report model changes 3) A measurement action may produce different result 'tables'. The assumption that there is a single header followed by a set of rows is too limited. We need to allow for a set of result 'tables' instead of a single one. [phil] If I get it right, this concerns where we want to report different subset o= f the results to different collectors.=20 It would then be nice to have a table tailored for each collector.=20 The alternative is one table, which has all the possible fields in the tabl= e columns but leaves some of the columns empty (for the results that a part= icular collector doesn't need). Both will work, but I agree it seems more e= legant to have several tables, tailored for each collector. If results are reported to only one collector, then I don't think you'd nee= d more than one table.=20 Thanks phil From nobody Sat Apr 2 06:38:50 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CF312D13B for ; Sat, 2 Apr 2016 06:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 C2sb8iI7ObuG for ; Sat, 2 Apr 2016 06:38:48 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1F212D138 for ; Sat, 2 Apr 2016 06:38:48 -0700 (PDT) Received: from E07HT04-UKBR.domain1.systemhost.net (193.113.197.162) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 2 Apr 2016 14:38:44 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by E07HT04-UKBR.domain1.systemhost.net (193.113.197.162) with Microsoft SMTP Server (TLS) id 8.3.342.0; Sat, 2 Apr 2016 14:38:46 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 2 Apr 2016 14:38:45 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1104.000; Sat, 2 Apr 2016 14:38:45 +0100 From: To: , Thread-Topic: [lmap] some lmap result report model changes Thread-Index: AQHRgQSR6F/044lnsE6HtqyKwVze3J92xuHg Date: Sat, 2 Apr 2016 13:38:44 +0000 Message-ID: <6172425c6ce242b1bcd7f033ec6b3226@rew09926dag03b.domain1.systemhost.net> References: <20160318105405.GA55018@elstar.local> In-Reply-To: <20160318105405.GA55018@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.187.101.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] some lmap result report model changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 02 Apr 2016 13:38:49 -0000 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: 18 March 2016 07:54 To: lmap@ietf.org Subject: [lmap] some lmap result report model changes 4) The description of ma-report-row-start-time and ma-report-row-end-time says that this timestamp is the start and the end of the action. If so, they should be reported as part of the ma-report-action-obj and not as part of the ma-report-row-obj. [phil] For an action that is a series of measurements (say 10 measurements of RTT = to test server X, in rapid succession), then I think it makes sense to reco= rd the time of those individual measurements.=20 From nobody Sat Apr 2 08:31:17 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C5612D1A7 for ; Sat, 2 Apr 2016 08:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 IpJsZuybbyqq for ; Sat, 2 Apr 2016 08:31:10 -0700 (PDT) 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 7A24412D11E for ; Sat, 2 Apr 2016 08:31:08 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id D9A27B6824C99; Sat, 2 Apr 2016 15:31:03 +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 u32FV5H0026213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 2 Apr 2016 15:31:05 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 u32FV5L6002305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Apr 2016 15:31:05 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Sat, 2 Apr 2016 11:31:05 -0400 From: "Carey, Timothy (Nokia - US)" To: "EXT philip.eardley@bt.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [lmap] Question on multiple outstanding suppressions Thread-Index: AdGF3V4xmgrf/a4tTNWOZo/M3lKnUgAAFPfwAOxpyAAAER67AAAA2uaAAABZtIAABjjJAAAXtT4AAIfjPSAAIPARUA== Date: Sat, 2 Apr 2016 15:31:04 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A62126E@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329084814.GA38204@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329173257.GB40617@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A619A6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160330074956.GC41707@elstar.local> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "bs7652@att.com" , "KEN.KO@adtran.com" , "lmap@ietf.org" Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 02 Apr 2016 15:31:13 -0000 Phil, Inline -----Original Message----- From: EXT philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Friday, April 01, 2016 9:00 PM To: j.schoenwaelder@jacobs-university.de; Carey, Timothy (Nokia - US) Cc: bs7652@att.com; KEN.KO@adtran.com; lmap@ietf.org Subject: RE: [lmap] Question on multiple outstanding suppressions Let me check if I understand how suppression would now work, or my likely t= o reveal my misunderstanding.=20 For each schedule there's a tag ma-schedule-suppression-tags<0..*> Example of this tag would be "suppress-by-default" When ma-suppression-obj is sent, then the ma-suppression-match string can b= e set to "suppress-by-default". Then all schedules with this tag are suppre= ssed. Did I get that right? Yes but the tag can be anything (e.g., tag0) Similarly, each action can have a tag ma-action-suppression-tags<0..*.> Sim= ilarly, another example of the tag is "suppress-if-controller-seems-dead" Correct However, Tasks have a Boolean ma-task-suppress-by-default ...? Yes when a suppression match object doesn't exist - these take effect= . The reason I needed the enable parameter for suppression is that in TR-069 = we don't have the concept of option parameters for runtime so I use an empt= y suppression match to invoke these Booleans. Thanks, phil -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: 30 March 2016 04:50 To: Carey, Timothy (Nokia - US) Cc: bs7652@att.com; KEN KO ; lmap@ietf.org Subject: Re: [lmap] Question on multiple outstanding suppressions On Tue, Mar 29, 2016 at 08:31:06PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > Looking at the text of section 3.3 > The new multi-instance model doesn't seem to support this text. I disagree. =20 > For example - can't just turn-on/turn-off suppression by setting enabled = to false and the unsuppression. This question is orthogonal to the question whether there are multiple supp= ressions or just effectively two. > Honestly it worked better when it was a single object with an enable and/= or endtime... > Why? There were two mechanisms, the traditional suppression and the reactio= n to loss of the controller. We now have a single mechanism that covers bot= h cases and at the same time is more flexible and supports provisioned supp= ressions. The question whether we add enable/disable leafs in random places or everyw= here is a separate question. When it comes to YANG, I am not a big fan, I r= ather would like to see a generic solution for this problem. /js > BR, > Tim >=20 > -----Original Message----- > From: EXT Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, March 29, 2016 12:33 PM > To: KEN KO > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > Subject: Re: [lmap] Question on multiple outstanding suppressions >=20 > You can still use suppressions as a panic button. You can have multiple p= anic buttons if you want to (but you do not have to use it in that way). Yo= u can have automatic pre-configured panic buttons (the new years evening ex= ample) but you do not have to use it that way. >=20 > If you read the emails, you will note that we had not only panic buttons = but also a second mechanism to handle the loss of the controller. Instead o= f having multiple hardwired mechanisms to disable 'things', the proposal ba= ck then was to generalize _one_ mechanism so that it can do it all. The sup= pressions we have now makes code simpler, extensible and more powerful at t= he same time. I do not see a good reason to go back. >=20 > /js >=20 > On Tue, Mar 29, 2016 at 05:22:55PM +0000, KEN KO wrote: > > TR-304 (from BBF) and RFC 7594 both document suppression as a single in= stance. It is intended to be used as a fairly blunt instrument, for instanc= e to prevent measurement traffic from exacerbating network congestion durin= g an unusual event. > >=20 > > From TR-304 section 5.2: "Suppression might be used when the measuremen= t system wants to minimize inessential traffic, for example after a major n= etwork incident. Only one suppression message can exist at a time in a give= n MA. A new suppression message completely replaces the previous one." > >=20 > > From RFC 7594 section 5.2.2.1: "The main motivation for Suppression is = to enable the Measurement System to eliminate Measurement Traffic, because = there is some unexpected network issue, for example. There may be other ci= rcumstances when Suppression is useful, for example, to eliminate inessenti= al Reporting traffic (even if there is no Measurement Traffic). > >=20 > > From RFC 7594 section 5.2.2: "However, Suppression information always r= eplaces (rather than adds to) any previous Suppression information." > >=20 > > The idea in both documents was to provide a mechanism that was flexible= in how tasks could be configured to react to it, but simple in how the "pa= nic button" would be pushed in the case of a network event.=20 > >=20 > > From the archive link Juergen provided, it looks like the purpose of su= ppression in the information model has changed fairly dramatically, and tha= t it is now a more generic capability to disable tasks according to any of = multiple schedules. I'm concerned that it may no longer provide the simple = "panic button" that was intended. Do we really want to deviate in this way = from something that was defined specifically in the framework documents, wh= ich after all are intended to provide guidance for more detailed documentat= ion? > >=20 > > Ken > >=20 > > -----Original Message----- > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Tuesday, March 29, 2016 12:58 PM > > To: Juergen Schoenwaelder; KEN KO > > Cc: lmap@ietf.org; bs7652@att.com > > Subject: RE: [lmap] Question on multiple outstanding suppressions > >=20 > > Juergen, > >=20 > > I suspect it was with good reason that the BBF wanted this as a single = instance active at a time.=20 > >=20 > > Possibly Ken or Barbara could provide the reasoning. > >=20 > > Minimally I would think we would need to be able administratively enabl= e/disable a suppression object; that at least lets me shut them down tempor= arily. > >=20 > > BR, > > Tim > >=20 > > -----Original Message----- > > From: EXT Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, March 29, 2016 3:48 AM > > To: KEN KO > > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > > Subject: Re: [lmap] Question on multiple outstanding suppressions > >=20 > > The original reasoning can be found here: > >=20 > > https://mailarchive.ietf.org/arch/msg/lmap/ptg-TcdfMuVHM93PWisj4u-tb > > FI > >=20 > > Not being able to provision multiple suppressions seems a major limitat= ion to me. > >=20 > > /js > >=20 > > On Thu, Mar 24, 2016 at 03:00:27PM +0000, KEN KO wrote: > > > Tim, thanks for catching this. I'd also like to understand why lmap h= as changed it. > > > Ken > > >=20 > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > > Sent: Thursday, March 24, 2016 9:57 AM > > > To: lmap@ietf.org > > > Cc: KEN KO; bs7652@att.com > > > Subject: Question on multiple outstanding suppressions > > >=20 > > > Team, > > >=20 > > > I noticed that the information model has support for multiple suppres= sions. > > > With the current definition in the information model, it looks like t= here isn't any constraints on multiple suppression requests that can be act= ive at the same time. > > >=20 > > > I just wanted to a confirmation on this. We used to have just 1 suppr= ession object in an instruction. It looks like this changed in draft-07. > > >=20 > > > This actually conflicts with BBF TR-304 Section 5.2 where the text sa= ys: > > > Suppression is the temporary cessation of all or a subset of measurem= ent-related tasks. A Measurement Controller can send a suppress message to = the MA that instructs the MA to temporarily suspend some or all of its sche= duled measurement-related tasks. Suppression ends either in response to an = explicit unsuppress message or at the time indicated in the suppress messag= e. Suppression might be used when the measurement system wants to minimize = inessential traffic, for example after a major network incident. Only one s= uppression message can exist at a time in a given MA. A new suppression mes= sage completely replaces the previous one. > > >=20 > > > So TR-304 would expect 1 suppression with an enable; this is quite di= fferent from the behavior that changed last November. > > >=20 > > >=20 > > > Looking for guidance. > > >=20 > > > BR, > > > Tim > >=20 > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > >=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 >=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 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 From nobody Sat Apr 2 08:38:36 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E8B12D13E for ; Sat, 2 Apr 2016 08:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1Ylet2r50MgX for ; Sat, 2 Apr 2016 08:38:31 -0700 (PDT) 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 5938C12D102 for ; Sat, 2 Apr 2016 08:38:31 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 3E3EFC05BAD65; Sat, 2 Apr 2016 15:38:25 +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 u32FcSsN026012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 2 Apr 2016 15:38:28 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u32FcSB9022278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Apr 2016 15:38:28 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Sat, 2 Apr 2016 11:38:28 -0400 From: "Carey, Timothy (Nokia - US)" To: "EXT philip.eardley@bt.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [lmap] Question on multiple outstanding suppressions Thread-Index: AdGF3V4xmgrf/a4tTNWOZo/M3lKnUgAAFPfwAOxpyAAAER67AAAA2uaAAABZtIAABjjJAAAXtT4AAIkGUiAAIA9b0A== Date: Sat, 2 Apr 2016 15:38:26 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A62129A@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329084814.GA38204@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329173257.GB40617@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A619A6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160330074956.GC41707@elstar.local> <40550b3f2c764fc8bff4918c65c68158@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <40550b3f2c764fc8bff4918c65c68158@rew09926dag03b.domain1.systemhost.net> 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: "bs7652@att.com" , "KEN.KO@adtran.com" , "lmap@ietf.org" Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 02 Apr 2016 15:38:35 -0000 A schedule may be enabled - but it hasn't hit its timer - e.g., calendar st= art May 1, 2016 end May 10, 2016=20 In TR-069 we have a enable parameter (part of the convention that all r/w m= ulti-instance objects have administrative enable capabilities so Enabled fo= r me means - the administrative state is enabled. BR, Tim -----Original Message----- From: EXT philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Friday, April 01, 2016 9:14 PM To: j.schoenwaelder@jacobs-university.de; Carey, Timothy (Nokia - US) Cc: bs7652@att.com; KEN.KO@adtran.com; lmap@ietf.org Subject: RE: [lmap] Question on multiple outstanding suppressions Different question about suppression. Ma-status-schedule-state can have the values: enabled, active and disabled.= Can you explain the difference between enabled and active, please Thanks p= hil -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: 30 March 2016 04:50 To: Carey, Timothy (Nokia - US) Cc: bs7652@att.com; KEN KO ; lmap@ietf.org Subject: Re: [lmap] Question on multiple outstanding suppressions On Tue, Mar 29, 2016 at 08:31:06PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > Looking at the text of section 3.3 > The new multi-instance model doesn't seem to support this text. I disagree. =20 > For example - can't just turn-on/turn-off suppression by setting enabled = to false and the unsuppression. This question is orthogonal to the question whether there are multiple supp= ressions or just effectively two. > Honestly it worked better when it was a single object with an enable and/= or endtime... > Why? There were two mechanisms, the traditional suppression and the reactio= n to loss of the controller. We now have a single mechanism that covers bot= h cases and at the same time is more flexible and supports provisioned supp= ressions. The question whether we add enable/disable leafs in random places or everyw= here is a separate question. When it comes to YANG, I am not a big fan, I r= ather would like to see a generic solution for this problem. /js > BR, > Tim >=20 > -----Original Message----- > From: EXT Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, March 29, 2016 12:33 PM > To: KEN KO > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > Subject: Re: [lmap] Question on multiple outstanding suppressions >=20 > You can still use suppressions as a panic button. You can have multiple p= anic buttons if you want to (but you do not have to use it in that way). Yo= u can have automatic pre-configured panic buttons (the new years evening ex= ample) but you do not have to use it that way. >=20 > If you read the emails, you will note that we had not only panic buttons = but also a second mechanism to handle the loss of the controller. Instead o= f having multiple hardwired mechanisms to disable 'things', the proposal ba= ck then was to generalize _one_ mechanism so that it can do it all. The sup= pressions we have now makes code simpler, extensible and more powerful at t= he same time. I do not see a good reason to go back. >=20 > /js >=20 > On Tue, Mar 29, 2016 at 05:22:55PM +0000, KEN KO wrote: > > TR-304 (from BBF) and RFC 7594 both document suppression as a single in= stance. It is intended to be used as a fairly blunt instrument, for instanc= e to prevent measurement traffic from exacerbating network congestion durin= g an unusual event. > >=20 > > From TR-304 section 5.2: "Suppression might be used when the measuremen= t system wants to minimize inessential traffic, for example after a major n= etwork incident. Only one suppression message can exist at a time in a give= n MA. A new suppression message completely replaces the previous one." > >=20 > > From RFC 7594 section 5.2.2.1: "The main motivation for Suppression is = to enable the Measurement System to eliminate Measurement Traffic, because = there is some unexpected network issue, for example. There may be other ci= rcumstances when Suppression is useful, for example, to eliminate inessenti= al Reporting traffic (even if there is no Measurement Traffic). > >=20 > > From RFC 7594 section 5.2.2: "However, Suppression information always r= eplaces (rather than adds to) any previous Suppression information." > >=20 > > The idea in both documents was to provide a mechanism that was flexible= in how tasks could be configured to react to it, but simple in how the "pa= nic button" would be pushed in the case of a network event.=20 > >=20 > > From the archive link Juergen provided, it looks like the purpose of su= ppression in the information model has changed fairly dramatically, and tha= t it is now a more generic capability to disable tasks according to any of = multiple schedules. I'm concerned that it may no longer provide the simple = "panic button" that was intended. Do we really want to deviate in this way = from something that was defined specifically in the framework documents, wh= ich after all are intended to provide guidance for more detailed documentat= ion? > >=20 > > Ken > >=20 > > -----Original Message----- > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Tuesday, March 29, 2016 12:58 PM > > To: Juergen Schoenwaelder; KEN KO > > Cc: lmap@ietf.org; bs7652@att.com > > Subject: RE: [lmap] Question on multiple outstanding suppressions > >=20 > > Juergen, > >=20 > > I suspect it was with good reason that the BBF wanted this as a single = instance active at a time.=20 > >=20 > > Possibly Ken or Barbara could provide the reasoning. > >=20 > > Minimally I would think we would need to be able administratively enabl= e/disable a suppression object; that at least lets me shut them down tempor= arily. > >=20 > > BR, > > Tim > >=20 > > -----Original Message----- > > From: EXT Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, March 29, 2016 3:48 AM > > To: KEN KO > > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > > Subject: Re: [lmap] Question on multiple outstanding suppressions > >=20 > > The original reasoning can be found here: > >=20 > > https://mailarchive.ietf.org/arch/msg/lmap/ptg-TcdfMuVHM93PWisj4u-tb > > FI > >=20 > > Not being able to provision multiple suppressions seems a major limitat= ion to me. > >=20 > > /js > >=20 > > On Thu, Mar 24, 2016 at 03:00:27PM +0000, KEN KO wrote: > > > Tim, thanks for catching this. I'd also like to understand why lmap h= as changed it. > > > Ken > > >=20 > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > > Sent: Thursday, March 24, 2016 9:57 AM > > > To: lmap@ietf.org > > > Cc: KEN KO; bs7652@att.com > > > Subject: Question on multiple outstanding suppressions > > >=20 > > > Team, > > >=20 > > > I noticed that the information model has support for multiple suppres= sions. > > > With the current definition in the information model, it looks like t= here isn't any constraints on multiple suppression requests that can be act= ive at the same time. > > >=20 > > > I just wanted to a confirmation on this. We used to have just 1 suppr= ession object in an instruction. It looks like this changed in draft-07. > > >=20 > > > This actually conflicts with BBF TR-304 Section 5.2 where the text sa= ys: > > > Suppression is the temporary cessation of all or a subset of measurem= ent-related tasks. A Measurement Controller can send a suppress message to = the MA that instructs the MA to temporarily suspend some or all of its sche= duled measurement-related tasks. Suppression ends either in response to an = explicit unsuppress message or at the time indicated in the suppress messag= e. Suppression might be used when the measurement system wants to minimize = inessential traffic, for example after a major network incident. Only one s= uppression message can exist at a time in a given MA. A new suppression mes= sage completely replaces the previous one. > > >=20 > > > So TR-304 would expect 1 suppression with an enable; this is quite di= fferent from the behavior that changed last November. > > >=20 > > >=20 > > > Looking for guidance. > > >=20 > > > BR, > > > Tim > >=20 > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > >=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 >=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 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 From nobody Sat Apr 2 10:45:37 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF05912D1E2 for ; Sat, 2 Apr 2016 10:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 DJ66YBytslIM for ; Sat, 2 Apr 2016 10:45:33 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 078D912D0D8 for ; Sat, 2 Apr 2016 10:45:33 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 1D50A123268; Sat, 2 Apr 2016 13:51:14 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id B43C2F23F0; Sat, 2 Apr 2016 13:45:32 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Sat, 2 Apr 2016 13:45:32 -0400 From: "MORTON, ALFRED C (AL)" To: "philip.eardley@bt.com" , "j.schoenwaelder@jacobs-university.de" , "lmap@ietf.org" Date: Sat, 2 Apr 2016 13:45:31 -0400 Thread-Topic: [lmap] some lmap result report model changes Thread-Index: AQHRgQSR6F/044lnsE6HtqyKwVze3J92xuHggABEC6A= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D445AE1C6BE@NJFPSRVEXG0.research.att.com> References: <20160318105405.GA55018@elstar.local> <6172425c6ce242b1bcd7f033ec6b3226@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <6172425c6ce242b1bcd7f033ec6b3226@rew09926dag03b.domain1.systemhost.net> 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] some lmap result report model changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 02 Apr 2016 17:45:34 -0000 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: Saturday, April 02, 2016 9:39 AM > To: j.schoenwaelder@jacobs-university.de; lmap@ietf.org > Subject: Re: [lmap] some lmap result report model changes >=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: 18 March 2016 07:54 > To: lmap@ietf.org > Subject: [lmap] some lmap result report model changes >=20 > 4) The description of ma-report-row-start-time and > ma-report-row-end-time says that this timestamp is the start and > the end of the action. If so, they should be reported as part of > the ma-report-action-obj and not as part of the ma-report-row-obj. >=20 > [phil] > For an action that is a series of measurements (say 10 measurements of > RTT to test server X, in rapid succession), then I think it makes sense > to record the time of those individual measurements. >=20 Right. One of the benefits of using IPPM metrics in general, and in this case in particular, is that the set of info to report has already been considered. Individual results like this are reported as=20 the Time when the packet is sent from source to the server, and the RTT metric from RFC2681 (and the Registry). Al From nobody Tue Apr 5 04:54:41 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B3112D1B1 for ; Tue, 5 Apr 2016 04:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 5bFsKDnvHrq5 for ; Tue, 5 Apr 2016 04:54:37 -0700 (PDT) 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 6A3A612D100 for ; Tue, 5 Apr 2016 04:54:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BB7CA2252; Tue, 5 Apr 2016 13:54:35 +0200 (CEST) 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 dPv7zm_lz3Gc; Tue, 5 Apr 2016 13:54:27 +0200 (CEST) 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, 5 Apr 2016 13:54:35 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA58520043; Tue, 5 Apr 2016 13:54:34 +0200 (CEST) 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 bzYetYgItSXN; Tue, 5 Apr 2016 13:54:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF8C620058; Tue, 5 Apr 2016 13:54:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 84BFA3A712FB; Tue, 5 Apr 2016 13:54:31 +0200 (CEST) Date: Tue, 5 Apr 2016 13:54:30 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160405115428.GA58350@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A60FF07@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329171809.GC40459@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614595@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160330074136.GB41707@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A61A2D2@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A61A2D2@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information model question on Events in the schedule X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 11:54:40 -0000 On Wed, Mar 30, 2016 at 11:49:24AM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > > I think again there is overload in the event. > In -05 there were timing objects. > These timing objects were assigned to a schedule. The Calendar and periodic timing object has a start and end date. The one-off and Immediate were one time. > > At that revision everything was cored in terms of scheduling a task. > > Then things got conflated with an event concept in -06 but the timing objects still have a start and end time. I do not think things got 'conflated'. > In the case of the schedule with a calendar/periodic "event" this would be the start and stop time of the schedule. > No, it always has been the start / end of the interval in which calendar/periodic events are created. If a schedule has a stop time, this must be a property of the schedule, not of the event triggering the execution of the schedule. > On the single schedule object: That is incorrect the calendar object has a start and end date. I do not understand why you say it doesn't have a end date. > > Is it that you expect different/numerous event instances for a single schedule (each time the schedule timer fires). If so I think that is what was conflated? If so the original intent was to simply have a timer object that described when a schedule was active not the actual event that it did fire. > It never did this or at least I never understood it that way. /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 Apr 5 04:58:18 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266AA12D1E4 for ; Tue, 5 Apr 2016 04:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 8Zu8XWOrYCrp for ; Tue, 5 Apr 2016 04:58:16 -0700 (PDT) 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 7222012D100 for ; Tue, 5 Apr 2016 04:58:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 377EC2252; Tue, 5 Apr 2016 13:58:15 +0200 (CEST) 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 5SNwEDC2be4h; Tue, 5 Apr 2016 13:58:07 +0200 (CEST) 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, 5 Apr 2016 13:58:14 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8065C20058; Tue, 5 Apr 2016 13:58:14 +0200 (CEST) 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 b3TFCrmxUpaO; Tue, 5 Apr 2016 13:58:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5492220056; Tue, 5 Apr 2016 13:58:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5AA4A3A7134A; Tue, 5 Apr 2016 13:58:02 +0200 (CEST) Date: Tue, 5 Apr 2016 13:58:02 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20160405115802.GB58350@elstar.local> Mail-Followup-To: philip.eardley@bt.com, timothy.carey@nokia.com, bs7652@att.com, KEN.KO@adtran.com, lmap@ietf.org References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329084814.GA38204@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329173257.GB40617@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A619A6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160330074956.GC41707@elstar.local> 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: timothy.carey@nokia.com, bs7652@att.com, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 11:58:18 -0000 On Sat, Apr 02, 2016 at 12:00:03AM +0000, philip.eardley@bt.com wrote: > Let me check if I understand how suppression would now work, or my likely to reveal my misunderstanding. > > For each schedule there's a tag ma-schedule-suppression-tags<0..*> > Example of this tag would be "suppress-by-default" > > When ma-suppression-obj is sent, then the ma-suppression-match string can be set to "suppress-by-default". Then all schedules with this tag are suppressed. > > Did I get that right? Yes. Note that tags can have other user-defined values. > Similarly, each action can have a tag ma-action-suppression-tags<0..*.> > Similarly, another example of the tag is "suppress-if-controller-seems-dead" > However, Tasks have a Boolean ma-task-suppress-by-default ...? This kicks in if there are no tags to match. I personally would remove ma-task-suppress-by-default since we have a more flexible mechanism that can emulate it as you described above. /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 Apr 5 05:00:19 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C957512D505 for ; Tue, 5 Apr 2016 05:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 3FAE0r2-tnCb for ; Tue, 5 Apr 2016 05:00:15 -0700 (PDT) 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 E0E5812D1D6 for ; Tue, 5 Apr 2016 05:00:14 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A6B99762; Tue, 5 Apr 2016 14:00:13 +0200 (CEST) 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 xOUS1OWV9PrZ; Tue, 5 Apr 2016 14:00:06 +0200 (CEST) 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, 5 Apr 2016 14:00:13 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 065CE20047; Tue, 5 Apr 2016 14:00:13 +0200 (CEST) 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 BmpZOVEkbaEH; Tue, 5 Apr 2016 14:00:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 003B720054; Tue, 5 Apr 2016 14:00:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E0A523A7137A; Tue, 5 Apr 2016 14:00:10 +0200 (CEST) Date: Tue, 5 Apr 2016 14:00:10 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20160405120010.GC58350@elstar.local> Mail-Followup-To: philip.eardley@bt.com, timothy.carey@nokia.com, bs7652@att.com, KEN.KO@adtran.com, lmap@ietf.org References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329084814.GA38204@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329173257.GB40617@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A619A6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160330074956.GC41707@elstar.local> <40550b3f2c764fc8bff4918c65c68158@rew09926dag03b.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40550b3f2c764fc8bff4918c65c68158@rew09926dag03b.domain1.systemhost.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: timothy.carey@nokia.com, bs7652@att.com, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 12:00:18 -0000 On Sat, Apr 02, 2016 at 12:14:25AM +0000, philip.eardley@bt.com wrote: > Different question about suppression. > Ma-status-schedule-state can have the values: enabled, active and disabled. Can you explain the difference between enabled and active, please Enables means when the event happens, the suppression becomes active (and when suppression is over it returns to enabled). In my implementation, a suppression becomes disabled if it can't every trigger anymore (e.g., a suppression bound to a startup event will get active at startup and then transition into disabled afterwards). /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 Apr 5 05:35:30 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841EC12D1AF for ; Tue, 5 Apr 2016 05:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 QHrapt3FizDM for ; Tue, 5 Apr 2016 05:35:27 -0700 (PDT) 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 9C10B12D5C8 for ; Tue, 5 Apr 2016 05:35:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6157A764; Tue, 5 Apr 2016 14:35:21 +0200 (CEST) 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 lVwZz115kY8n; Tue, 5 Apr 2016 14:35:13 +0200 (CEST) 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, 5 Apr 2016 14:35:20 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A756020045; Tue, 5 Apr 2016 14:35:20 +0200 (CEST) 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 e9X9FFRugF8t; Tue, 5 Apr 2016 14:35:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40CA320043; Tue, 5 Apr 2016 14:35:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 46FA13A714F2; Tue, 5 Apr 2016 14:35:17 +0200 (CEST) Date: Tue, 5 Apr 2016 14:35:17 +0200 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20160405123516.GA58588@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> <20160222085611.GA12467@elstar.local> 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] Support for multiple report table formats from one task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 12:35:29 -0000 On Thu, Mar 31, 2016 at 09:19:07PM -0400, Ron Stana wrote: > Juergen, > > The changes to version 4 of the LMAP YANG model ( > https://tools.ietf.org/html/draft-ietf-lmap-yang-04) allow for multiple > tables to be sent for one task, so thank you. However the client > application will need to be able to determine what data is in each of the > different tables. There were two suggestions made in this thread: > > 1) use different registry references for each table via the metric object > 2) use different values in the 'tag' object for each table > > The problem I see is neither the 'metric' or 'tag' objects are within the > new 'table' object so each table cannot define its own value for these. > There are two options I think: - Either assume that there is a 1:1 relationship between metrics listed and the result tables; or - Introduce an additional structure that binds 0..n metrics to a result table. /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 Apr 5 05:39:58 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1076212D59D for ; Tue, 5 Apr 2016 05:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 7e6uY25D9P5I for ; Tue, 5 Apr 2016 05:39:55 -0700 (PDT) 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 CD79912D5B4 for ; Tue, 5 Apr 2016 05:39:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 94704AB6; Tue, 5 Apr 2016 14:39:53 +0200 (CEST) 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 0Xbyh9p1oqTt; Tue, 5 Apr 2016 14:39:45 +0200 (CEST) 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, 5 Apr 2016 14:39:52 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC29920045; Tue, 5 Apr 2016 14:39:52 +0200 (CEST) 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 c9AkmxFMx3yF; Tue, 5 Apr 2016 14:39:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C76AC20043; Tue, 5 Apr 2016 14:39:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 75CE63A7152D; Tue, 5 Apr 2016 14:39:50 +0200 (CEST) Date: Tue, 5 Apr 2016 14:39:50 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20160405123950.GB58588@elstar.local> Mail-Followup-To: philip.eardley@bt.com, lmap@ietf.org References: <20160318105405.GA55018@elstar.local> <7df9f95aca974b28bf711f11055bdf64@rew09926dag03b.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7df9f95aca974b28bf711f11055bdf64@rew09926dag03b.domain1.systemhost.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] some lmap result report model changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 12:39:57 -0000 On Sat, Apr 02, 2016 at 01:35:02PM +0000, philip.eardley@bt.com wrote: > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: 18 March 2016 07:54 > To: lmap@ietf.org > Subject: [lmap] some lmap result report model changes > > 3) A measurement action may produce different result 'tables'. The > assumption that there is a single header followed by a set of rows > is too limited. We need to allow for a set of result 'tables' > instead of a single one. > > [phil] > If I get it right, this concerns where we want to report different subset of the results to different collectors. > It would then be nice to have a table tailored for each collector. > The alternative is one table, which has all the possible fields in the table columns but leaves some of the columns empty (for the results that a particular collector doesn't need). Both will work, but I agree it seems more elegant to have several tables, tailored for each collector. > If results are reported to only one collector, then I don't think you'd need more than one table. > This is a question of how the results are structured. You either have a flexible table layout that allows tools to send results of different measurements in one table or you have a more fixed table layout where it is more natural to send multiple differently structured tables. Since we do not any specific assumptions or recommendations, I think it makes sense to support both. /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 Apr 5 05:42:58 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB3B12D69B for ; Tue, 5 Apr 2016 05:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 tWTAuaHRjrZ2 for ; Tue, 5 Apr 2016 05:42:48 -0700 (PDT) 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 7797D12D676 for ; Tue, 5 Apr 2016 05:42:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3D9BE229D; Tue, 5 Apr 2016 14:42:41 +0200 (CEST) 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 abpwKDwYPl-x; Tue, 5 Apr 2016 14:42:33 +0200 (CEST) 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, 5 Apr 2016 14:42:40 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D88D20047; Tue, 5 Apr 2016 14:42:40 +0200 (CEST) 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 9e8uosxD0Div; Tue, 5 Apr 2016 14:42:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 874A420045; Tue, 5 Apr 2016 14:42:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7A8C43A7155D; Tue, 5 Apr 2016 14:42:39 +0200 (CEST) Date: Tue, 5 Apr 2016 14:42:39 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20160405124239.GC58588@elstar.local> Mail-Followup-To: philip.eardley@bt.com, lmap@ietf.org References: <20160318105405.GA55018@elstar.local> <6172425c6ce242b1bcd7f033ec6b3226@rew09926dag03b.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6172425c6ce242b1bcd7f033ec6b3226@rew09926dag03b.domain1.systemhost.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] some lmap result report model changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 12:42:50 -0000 On Sat, Apr 02, 2016 at 01:38:44PM +0000, philip.eardley@bt.com wrote: > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: 18 March 2016 07:54 > To: lmap@ietf.org > Subject: [lmap] some lmap result report model changes > > 4) The description of ma-report-row-start-time and > ma-report-row-end-time says that this timestamp is the start and > the end of the action. If so, they should be reported as part of > the ma-report-action-obj and not as part of the ma-report-row-obj. > > [phil] > For an action that is a series of measurements (say 10 measurements of RTT to test server X, in rapid succession), then I think it makes sense to record the time of those individual measurements. I think stuff that happens "inside" of a measurement task (timing details, observed cross traffic for certain packet trains, ...) should go into the result tables and not into the meta data of the result record. /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 Apr 5 05:48:45 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5881E12D5D0 for ; Tue, 5 Apr 2016 05:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 SAF3o3fj1Ko9 for ; Tue, 5 Apr 2016 05:48:42 -0700 (PDT) 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 89D0D12D5C7 for ; Tue, 5 Apr 2016 05:48:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 51A3D22A3; Tue, 5 Apr 2016 14:48:41 +0200 (CEST) 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 vGBnLLTLm8x6; Tue, 5 Apr 2016 14:48:33 +0200 (CEST) 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, 5 Apr 2016 14:48:40 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7393D20045; Tue, 5 Apr 2016 14:48:40 +0200 (CEST) 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 gfK3ufdetwRs; Tue, 5 Apr 2016 14:48:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5A8E20043; Tue, 5 Apr 2016 14:48:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 535043A715A2; Tue, 5 Apr 2016 14:48:38 +0200 (CEST) Date: Tue, 5 Apr 2016 14:48:38 +0200 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20160405124838.GD58588@elstar.local> Mail-Followup-To: Ron Stana , lmap@ietf.org, alissa@cooperw.in References: 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: alissa@cooperw.in, lmap@ietf.org Subject: Re: [lmap] Learning MA Capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 12:48:44 -0000 On Thu, Mar 31, 2016 at 08:53:17PM -0400, Ron Stana wrote: > LMAP Team, > > We want the MA to provide information to the Controller that will be used > to characterize/limit the Measurement Tasks that are later executed. > > Examples include: > > - licenses for optional features > - max test bandwidth > - total number of simultaneous tests and data streams (based on VM > resources for virtual devices) > > This appears to be information that LMAP suggests can be provided as part > of getting the capabilities from the MA. I have two questions based on > version 9 of the LMAP Information Model. This is not modelled in the information model. > 1) Which API should be used to pass this information from the MA to the > Controller? > > - ietf-lmap-control:lmap-state seems logical however there doesn't > appear to be a place for this type of information in it > - One possibility is to define a 'capability task' whose > ietf-lmap-control:lmap/tasks/task/option contains the data. The controller > could then GET the ietf-lmap-control:lmap object to the values. However, I > am not sure if tasks were envisioned to return data in this manner. The results go to the collector and not to the controller. > 2) While looking into how to solve this issue we found > https://tools.ietf.org/html/rfc7223. Has any consideration been given to > adding the 'interfaces' or 'interfaces-state' objects defined in that > document to ietf-lmap-control/lmap-state? This would partially address the > issue above but more importantly being able to get general RX and TX > statistics on the test interface would be useful for general MA > troubleshooting. The YANG data model says: o Capability and Status Information: Some of the status information is modeled in the /lmap-state/agent subtree and the /lmap-state/ schedules subtree. Information about network interfaces can be obtained from the interfaces YANG data model [RFC7223]. In other words, to expose interface details and statistics one should implement RFC7223. /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 Apr 5 06:47:31 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC8F12D127 for ; Tue, 5 Apr 2016 06:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viavisolutions-com.20150623.gappssmtp.com 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 NGSRi5k-ryaE for ; Tue, 5 Apr 2016 06:47:27 -0700 (PDT) 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 1CA3A12D16D for ; Tue, 5 Apr 2016 06:47:27 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id 127so25211051wmu.1 for ; Tue, 05 Apr 2016 06:47:27 -0700 (PDT) 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; bh=YwmZDDiZ47+ZxpuD2UOtKSEH7QaiQ0DV10lPu3fUFtU=; b=nz5FehpqBZByjC2lUobD+5Z4uYQzpFAHQbC+DcWcZuFxdC8N0Uqec73GOciuIFmGgj kg37xrs5Z6mJHgNlGLTRz/OB+GRzwGTOwmuRBJ4zTvktmYI90NFeib04EVxtYeSO5Waf 4q579wWnlzELFrNxY5TaFksUiEg1EvRpEYJYtGGgd2yLRhkdAl3i68EJ0zgGg11qTMM/ zpM51xiY/NUuIiBxLH9Ya9rt481KlFDilndPfg/tTBCASAre+eHZ2M9AS4R+nKf+1OZO FwCRci87E8Nnw0GIkWh+FlewtnkSlRDVzq+uPesHASpcHBHZ12F9fQ/BmJUMTCEJnFYm 9A8Q== 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; bh=YwmZDDiZ47+ZxpuD2UOtKSEH7QaiQ0DV10lPu3fUFtU=; b=O8UWiix1jiGG1O14hjMentnTte4zLCBEg9CK9ph3AvHx+yxn25fR7fIYPzxeV1J0Ce b6ufMVli939JrT8q7sJxi1Q6vF64wxwSfgx1gcej4LuTqLnRlPI7woxKs8tMAqRVWMn/ SUBL59NVGpZdSXm0ubRKIBcGrKOcJy30QrXfSs2gyvYVy22ZMjeke+dehCnc1duYVGg3 RElohuReyIZCi7xMc0AaPlQssGnaJ1IsGhQznk83zbv/P/oGsMn8aJsn54ULi0cEAj7p xF+wj/Q64EBxmr7GRe08WP/GeE0A+bpaXkDOpWDJhs/vpuQbG8ZFj1JEOg+HR64YBMRf j0kA== X-Gm-Message-State: AD7BkJJh+glXFv2gzk4DYvTWsO8zLa8JDoZCOQ0PbeWvgq4zigBsOJY27K8zTD7c467Dql6XgzsV6+nRMvyd8bw1 MIME-Version: 1.0 X-Received: by 10.194.185.179 with SMTP id fd19mr20304796wjc.107.1459864044501; Tue, 05 Apr 2016 06:47:24 -0700 (PDT) Received: by 10.28.155.21 with HTTP; Tue, 5 Apr 2016 06:47:24 -0700 (PDT) In-Reply-To: <20160405124838.GD58588@elstar.local> References: <20160405124838.GD58588@elstar.local> Date: Tue, 5 Apr 2016 09:47:24 -0400 Message-ID: From: Ron Stana To: Juergen Schoenwaelder , Ron Stana , lmap@ietf.org, alissa@cooperw.in Content-Type: multipart/alternative; boundary=047d7bb0402acb235a052fbd15f9 Archived-At: Subject: Re: [lmap] Learning MA Capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 13:47:30 -0000 --047d7bb0402acb235a052fbd15f9 Content-Type: text/plain; charset=UTF-8 Juergen, For #1, learning the MA's capabilities, please confirm this is the expected use case: 1) MA is provisioned with predefined channel information for Controller 2) MA registers with Controller 3) Controller wants to dynamically learn the MA's capabilities so it reads either ietf-lmap-control:lmap or ietf-lmap-control:lmap-state to learn the device type and a list of tasks 4) Based on predefined information (i.e. hard coded), the controller uses the device type to know which task or tasks will tell it the capabilities. 5) Controller automatically submits the necessary schedules for the capability task(s) and result task (task that defines collector channel). It uses predefined channel information for the collector and presumably an immediate event for all the schedules. Most likely the capability tasks don't take any inputs. 6) Controller then requests data from Collector until it arrives from these tasks. I just want to confirm this is correct, since I expected the capability learning to just be a simple data exchange between the Controller and MA. For #2, To add support for RFC7223, please confirm the expectation is that a vendor would extend the ietf-lmap-control:lmap-state model so the extra information could be included. I didn't think the LMAP data models were expected to be extended, but if this is acceptable then it seems like the capability information could also be added to ietf-lmap-control:lmap-state, which would simplify the capability learning process by limiting it to just a read of ietf-lmap-control:lmap-state. Ron On Tue, Apr 5, 2016 at 8:48 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Mar 31, 2016 at 08:53:17PM -0400, Ron Stana wrote: > > LMAP Team, > > > > We want the MA to provide information to the Controller that will be used > > to characterize/limit the Measurement Tasks that are later executed. > > > > Examples include: > > > > - licenses for optional features > > - max test bandwidth > > - total number of simultaneous tests and data streams (based on VM > > resources for virtual devices) > > > > This appears to be information that LMAP suggests can be provided as part > > of getting the capabilities from the MA. I have two questions based on > > version 9 of the LMAP Information Model. > > This is not modelled in the information model. > > > 1) Which API should be used to pass this information from the MA to the > > Controller? > > > > - ietf-lmap-control:lmap-state seems logical however there doesn't > > appear to be a place for this type of information in it > > - One possibility is to define a 'capability task' whose > > ietf-lmap-control:lmap/tasks/task/option contains the data. The > controller > > could then GET the ietf-lmap-control:lmap object to the values. > However, I > > am not sure if tasks were envisioned to return data in this manner. > > The results go to the collector and not to the controller. > > > 2) While looking into how to solve this issue we found > > https://tools.ietf.org/html/rfc7223. Has any consideration been given > to > > adding the 'interfaces' or 'interfaces-state' objects defined in that > > document to ietf-lmap-control/lmap-state? This would partially address > the > > issue above but more importantly being able to get general RX and TX > > statistics on the test interface would be useful for general MA > > troubleshooting. > > The YANG data model says: > > o Capability and Status Information: Some of the status information > is modeled in the /lmap-state/agent subtree and the /lmap-state/ > schedules subtree. Information about network interfaces can be > obtained from the interfaces YANG data model [RFC7223]. > > In other words, to expose interface details and statistics one should > implement RFC7223. > > /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 > --047d7bb0402acb235a052fbd15f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Juergen,

For #1, learning the MA's = capabilities, please confirm this is the expected use case:

<= /div>
1) MA is provisioned with predefined channel information for Cont= roller
2) MA registers with Controller
3) Controller wa= nts to dynamically learn the MA's capabilities so it reads either=C2=A0= ietf-lmap-control:lmap=C2=A0or=C2=A0ietf-lmap-control:lmap-state to learn the device type and a list of tasks<= /span>
4) Based on predefined in= formation (i.e. hard coded), the controller uses the device type to know wh= ich task or tasks will tell it the capabilities.=C2=A0
5) Controller automatically submits the neces= sary schedules for the capability task(s) and result task (task that define= s collector channel). It uses predefined channel information for the collec= tor and presumably an immediate event for all the schedules. Most likely=C2=A0the capability tasks don't t= ake any inputs.
6) Contro= ller then requests data from Collector until it arrives from these tasks.

I ju= st want to confirm this is correct, since I expected the capability learnin= g to just be a simple data exchange between the Controller and MA.

For #2,
To add support for=C2= =A0RFC7223, please confirm=C2=A0the expectation is that a vendor would= extend the=C2=A0ietf-lmap-control:lmap-state model so the extra infor= mation could be included.=C2=A0 I didn't think the LMAP data models wer= e expected to be extended, but if this is acceptable then it seems like the= capability information could also be added to=C2=A0ietf-lmap-control:lmap-state, which would simplify the cap= ability learning process by limiting it to just a read of=C2=A0ietf-lmap-control:lmap-state.
<= br>
Ron
<= div>

=

On Tue, Apr 5, 20= 16 at 8:48 AM, Juergen Schoenwaelder <j.schoenwaelder@j= acobs-university.de> wrote:
On Thu, Mar 31, 2016 at 08:53:17PM -0400, Ron Stana wrote:
> LMAP Team,
>
> We want the MA to provide information to the Controller that will be u= sed
> to characterize/limit the Measurement Tasks that are later executed. >
> Examples include:
>
>=C2=A0 =C2=A0 - licenses for optional features
>=C2=A0 =C2=A0 - max test bandwidth
>=C2=A0 =C2=A0 - total number of simultaneous tests and data streams (ba= sed on VM
>=C2=A0 =C2=A0 resources for virtual devices)
>
> This appears to be information that LMAP suggests can be provided as p= art
> of getting the capabilities from the MA.=C2=A0 I have two questions ba= sed on
> version 9 of the LMAP Information Model.

This is not modelled in the information model.

> 1) Which API should be used to pass this information from the MA to th= e
> Controller?
>
>=C2=A0 =C2=A0 - ietf-lmap-control:lmap-state seems logical however ther= e doesn't
>=C2=A0 =C2=A0 appear to be a place for this type of information in it >=C2=A0 =C2=A0 - One possibility is to define a 'capability task'= ; whose
>=C2=A0 =C2=A0 ietf-lmap-control:lmap/tasks/task/option contains the dat= a.=C2=A0 The controller
>=C2=A0 =C2=A0 could then GET the ietf-lmap-control:lmap object to the v= alues.=C2=A0 However, I
>=C2=A0 =C2=A0 am not sure if tasks were envisioned to return data in th= is manner.

The results go to the collector and not to the controller.

> 2) While looking into how to solve this issue we found
> https://tools.ietf.org/html/rfc7223.=C2=A0 Has any consi= deration been given to
> adding the 'interfaces' or 'interfaces-state' objects = defined in that
> document to ietf-lmap-control/lmap-state?=C2=A0 This would partially a= ddress the
> issue above but more importantly being able to get general RX and TX > statistics on the test interface would be useful for general MA
> troubleshooting.

The YANG data model says:

=C2=A0 =C2=A0o=C2=A0 Capability and Status Information: Some of the status = information
=C2=A0 =C2=A0 =C2=A0 is modeled in the /lmap-state/agent subtree and the /l= map-state/
=C2=A0 =C2=A0 =C2=A0 schedules subtree.=C2=A0 Information about network int= erfaces can be
=C2=A0 =C2=A0 =C2=A0 obtained from the interfaces YANG data model [RFC7223]= .

In other words, to expose interface details and statistics one should
implement RFC7223.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<htt= p://www.jacobs-university.de/>

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

--047d7bb0402acb235a052fbd15f9-- From nobody Tue Apr 5 06:53:37 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3EE12D11B for ; Tue, 5 Apr 2016 06:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 J-X_gtkMCt79 for ; Tue, 5 Apr 2016 06:53:35 -0700 (PDT) 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 9564A12D1EB for ; Tue, 5 Apr 2016 06:53:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6206914D3; Tue, 5 Apr 2016 15:53:32 +0200 (CEST) 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 9_q000U0g1ee; Tue, 5 Apr 2016 15:53:24 +0200 (CEST) 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, 5 Apr 2016 15:53:31 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 638A820045; Tue, 5 Apr 2016 15:53:31 +0200 (CEST) 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 B1Tyasu341tY; Tue, 5 Apr 2016 15:53:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D267B20043; Tue, 5 Apr 2016 15:53:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6734E3A71BC5; Tue, 5 Apr 2016 15:53:28 +0200 (CEST) Date: Tue, 5 Apr 2016 15:53:27 +0200 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20160405135327.GA58974@elstar.local> Mail-Followup-To: Ron Stana , lmap@ietf.org, alissa@cooperw.in References: <20160405124838.GD58588@elstar.local> 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: alissa@cooperw.in, lmap@ietf.org Subject: Re: [lmap] Learning MA Capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 13:53:37 -0000 On Tue, Apr 05, 2016 at 09:47:24AM -0400, Ron Stana wrote: > Juergen, > > For #1, learning the MA's capabilities, please confirm this is the expected > use case: > > 1) MA is provisioned with predefined channel information for Controller > 2) MA registers with Controller > 3) Controller wants to dynamically learn the MA's capabilities so it reads > either ietf-lmap-control:lmap or ietf-lmap-control:lmap-state to learn the > device type and a list of tasks > 4) Based on predefined information (i.e. hard coded), the controller uses > the device type to know which task or tasks will tell it the capabilities. > 5) Controller automatically submits the necessary schedules for the > capability task(s) and result task (task that defines collector channel). > It uses predefined channel information for the collector and presumably an > immediate event for all the schedules. Most likely the capability tasks > don't take any inputs. > 6) Controller then requests data from Collector until it arrives from these > tasks. > > I just want to confirm this is correct, since I expected the capability > learning to just be a simple data exchange between the Controller and MA. I do not understand what steps 4), 5), 6) would do. I guess I am not sure what you consider 'MA capabilities' that are not covered in the information or data model. > For #2, > > To add support for RFC7223, please confirm the expectation is that a vendor > would extend the ietf-lmap-control:lmap-state model so the extra > information could be included. I didn't think the LMAP data models were > expected to be extended, but if this is acceptable then it seems like the > capability information could also be added to ietf-lmap-control:lmap-state, > which would simplify the capability learning process by limiting it to just > a read of ietf-lmap-control:lmap-state. No, the expectation is that a controller can pick relevant information out network interfaces from the data model described in RFC7223. There is no point in replicating this information. /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 Apr 5 20:36:53 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED3412D704 for ; Tue, 5 Apr 2016 20:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viavisolutions-com.20150623.gappssmtp.com 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 8gWZMN4BVdfx for ; Tue, 5 Apr 2016 20:36:49 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 4D4CB12D707 for ; Tue, 5 Apr 2016 20:36:49 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id l6so47036484wml.1 for ; Tue, 05 Apr 2016 20:36:49 -0700 (PDT) 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; bh=g2/AgXOcmLFJn2zfv+syk4HZImXCTsxoooFj2pDfxh8=; b=ZHGx25poWLNBQn29eQSlkFdWQzhPEZ4MNQB3yCKPGodCQuWuOYO/70VnU/DC8KvUJA KQ5pCC0fV6JWQsxdzAaGOUCLJOqWVJRfqbc3bE2dfAFLg82AgrPfeRc3ktyYV3kBq1vV v4FIVggDE7nONnK1uvH7e2rOZmE00vld3rJU5GwN+Y7IAEffKoMEWQ1XerikLezEpop3 nFufvsAoVkr9CZrg8qrreWDM+0KTrP/nm2cp8eW06fmb9//nABLCw/MvlPxb2f7AU6Cq 2xjEq53BPi7kpcfz3P6LSpGmVHxw5I0Ydhm4TCyyqrXsxlVih88R5JA1K0ix9Tmf5MBq qGPw== 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; bh=g2/AgXOcmLFJn2zfv+syk4HZImXCTsxoooFj2pDfxh8=; b=YzK2CFJ0vEPaE2heJcRLyvR1g7uykmLqaEgn/uv3VtaYb8Pq/CWglqxN+1JNf16PLB bxK/7EScBoc7zMe6hTqMXkztpAFj/jtIyER3wGIJzV/U73DQq49lk5uOo6J863oStkxr f5srE+iUjJKUV+jV8ICHK8jXU5DZ2AJDSB/mAe4Rc6eyiVws/EhJIetqeZR+3CALsYl8 68oXlWV52/EedcMAg3poZlkQioDogn7DDhfPTp7e8RsXiJCrpGmHZBlgk7f4WYSofX5u jfS/ZjgJ20rHDhAipSZSg7MNSzt6Dcmwj42NwL/4sfuvpawW3+bahEKab9IjdCkjINf1 ifcA== X-Gm-Message-State: AD7BkJJ69gMwIB8Yoq+Lm6LrO7oDxOSo9Jbg2i0iy4jQLGO/twFxPV7Y4QUAYc9wWS0+wDRxeeGdxqDoenLAwP0g MIME-Version: 1.0 X-Received: by 10.28.64.197 with SMTP id n188mr16487884wma.96.1459913807810; Tue, 05 Apr 2016 20:36:47 -0700 (PDT) Received: by 10.28.155.21 with HTTP; Tue, 5 Apr 2016 20:36:47 -0700 (PDT) In-Reply-To: <20160405135327.GA58974@elstar.local> References: <20160405124838.GD58588@elstar.local> <20160405135327.GA58974@elstar.local> Date: Tue, 5 Apr 2016 23:36:47 -0400 Message-ID: From: Ron Stana To: Juergen Schoenwaelder , Ron Stana , lmap@ietf.org, alissa@cooperw.in Content-Type: multipart/alternative; boundary=001a114b2e02eaf8ab052fc8ab65 Archived-At: Subject: Re: [lmap] Learning MA Capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 06 Apr 2016 03:36:52 -0000 --001a114b2e02eaf8ab052fc8ab65 Content-Type: text/plain; charset=UTF-8 Juergen, Steps 4,5 & 6 are performed to learn the dynamic capabilities of the MA. For example, when the MA is a software-only implementation, the capabilities will vary depending on what hardware it is installed on. Depending on the number of CPUs, type of NIC, etc the number of tests, test options and test parameter ranges may vary. This is the type of information that is not expected to change after the MA has been installed but it still needs to be read at least once by the Controller. For support of RFC7223, are you suggesting the MA should implement an API outside of the LMAP models to return that information? Ron On Tue, Apr 5, 2016 at 9:53 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Apr 05, 2016 at 09:47:24AM -0400, Ron Stana wrote: > > Juergen, > > > > For #1, learning the MA's capabilities, please confirm this is the > expected > > use case: > > > > 1) MA is provisioned with predefined channel information for Controller > > 2) MA registers with Controller > > 3) Controller wants to dynamically learn the MA's capabilities so it > reads > > either ietf-lmap-control:lmap or ietf-lmap-control:lmap-state to learn > the > > device type and a list of tasks > > 4) Based on predefined information (i.e. hard coded), the controller uses > > the device type to know which task or tasks will tell it the > capabilities. > > 5) Controller automatically submits the necessary schedules for the > > capability task(s) and result task (task that defines collector channel). > > It uses predefined channel information for the collector and presumably > an > > immediate event for all the schedules. Most likely the capability tasks > > don't take any inputs. > > 6) Controller then requests data from Collector until it arrives from > these > > tasks. > > > > I just want to confirm this is correct, since I expected the capability > > learning to just be a simple data exchange between the Controller and MA. > > I do not understand what steps 4), 5), 6) would do. I guess I am not > sure what you consider 'MA capabilities' that are not covered in the > information or data model. > > > For #2, > > > > To add support for RFC7223, please confirm the expectation is that a > vendor > > would extend the ietf-lmap-control:lmap-state model so the extra > > information could be included. I didn't think the LMAP data models were > > expected to be extended, but if this is acceptable then it seems like the > > capability information could also be added to > ietf-lmap-control:lmap-state, > > which would simplify the capability learning process by limiting it to > just > > a read of ietf-lmap-control:lmap-state. > > No, the expectation is that a controller can pick relevant information > out network interfaces from the data model described in RFC7223. There > is no point in replicating this information. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a114b2e02eaf8ab052fc8ab65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Juergen,

Steps 4,5 & 6 are performe= d to learn the dynamic capabilities of the MA. For example, when the MA is = a software-only implementation, the capabilities will vary depending on wha= t hardware it is installed on.=C2=A0 Depending on the number of CPUs, type = of NIC, etc the number of tests, test options and test parameter ranges may= vary.=C2=A0 This is the type of information that is not expected to change= after the MA has been installed but it still needs to be read at least onc= e by the Controller.

For support of=C2=A0RFC7223, are you suggesting the MA should implement= an API outside of the LMAP models to return that information?=C2=A0=

Ron


On Tue, Apr 5, 2016 at 9:53 AM, = Juergen Schoenwaelder <j.schoenwaelder@jacobs-universit= y.de> wrote:
On Tue, Apr 05= , 2016 at 09:47:24AM -0400, Ron Stana wrote:
> Juergen,
>
> For #1, learning the MA's capabilities, please confirm this is the= expected
> use case:
>
> 1) MA is provisioned with predefined channel information for Controlle= r
> 2) MA registers with Controller
> 3) Controller wants to dynamically learn the MA's capabilities so = it reads
> either ietf-lmap-control:lmap or ietf-lmap-control:lmap-state to learn= the
> device type and a list of tasks
> 4) Based on predefined information (i.e. hard coded), the controller u= ses
> the device type to know which task or tasks will tell it the capabilit= ies.
> 5) Controller automatically submits the necessary schedules for the > capability task(s) and result task (task that defines collector channe= l).
> It uses predefined channel information for the collector and presumabl= y an
> immediate event for all the schedules. Most likely the capability task= s
> don't take any inputs.
> 6) Controller then requests data from Collector until it arrives from = these
> tasks.
>
> I just want to confirm this is correct, since I expected the capabilit= y
> learning to just be a simple data exchange between the Controller and = MA.

I do not understand what steps 4), 5), 6) would do. I guess I am not
sure what you consider 'MA capabilities' that are not covered in th= e
information or data model.

> For #2,
>
> To add support for RFC7223, please confirm the expectation is that a v= endor
> would extend the ietf-lmap-control:lmap-state model so the extra
> information could be included.=C2=A0 I didn't think the LMAP data = models were
> expected to be extended, but if this is acceptable then it seems like = the
> capability information could also be added to ietf-lmap-control:lmap-s= tate,
> which would simplify the capability learning process by limiting it to= just
> a read of ietf-lmap-control:lmap-state.

No, the expectation is that a controller can pick relevant information
out network interfaces from the data model described in RFC7223. There
is no point in replicating this information.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<htt= p://www.jacobs-university.de/>

--001a114b2e02eaf8ab052fc8ab65-- From nobody Fri Apr 8 05:52:07 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACB112D63C for ; Fri, 8 Apr 2016 05:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kCPsenC2LbGM for ; Fri, 8 Apr 2016 05:52:04 -0700 (PDT) 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 3DB7912D56A for ; Fri, 8 Apr 2016 05:52:03 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 817ECA451688F for ; Fri, 8 Apr 2016 12:51:59 +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 u38Cq2rt009868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 8 Apr 2016 12:52:02 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 u38Cq1N4024128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Apr 2016 12:52:02 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Fri, 8 Apr 2016 08:52:01 -0400 From: "Carey, Timothy (Nokia - US)" To: "lmap@ietf.org" Thread-Topic: LMAP: Defining the Schedule's events Thread-Index: AdGRlXE/Uq+NXwwZQ1S5HMAXfJJ26g== Date: Fri, 8 Apr 2016 12:52:00 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A627E42@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.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A627E42US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP: Defining the Schedule's events X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 12:52:06 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A627E42US70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Team, In the IETF#95 LMAP session we had a discussion on the need for the new par= ameters for the ma-schedule-end and ma-schedule-duration parameters, given = that the ma-schedule-start (which is typed as an event) We said we would show that these parameters were not needed using an exampl= e - so here goes. Lets assume we have a schedule made up of 2 actions (A1, A2) in pipeline mo= de. The ma-schedule-start would has a periodic event: Start April 1, 2016 at 02:00:00 End May 1, 2016 at 02:00:00 Interval 86,400 (daily) Randomness 3600 (within the hour) So the schedule will reoccur every day starting on April 1 beginning at 2:0= 0pm. (T0) The starting period will be random between 2:00am and 3:00am. (T1= ) This definition is sufficient for invoking A1 (T1) and is what Al conside= rs as Blue times. As A1 performs a test A1 places bits on the wire (T2) and collects results = (T3). When A1 completes (T4), A2 is invoked (T5) which places bits on a wire for = A2 (T2) and collects results (T3)). Finally the results from the schedule a= re reported (T6). T2&T3: Al considers this time to be part of the definition of the metric an= d are reported as part of the result content (not as an actual parameter). = This was his Red time T4&T5: Are the ma-report-[start|end]-time T6: Is the ma-report-date As such - As long as an Event has a defined occurrence (T1=3DT0 + randomnes= s) all that is necessary is a single parameter to define the occurrence. Questions? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A627E42US70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Team,

 

In the IETF#95 LMAP session we had a discussion on t= he need for the new parameters for the ma-schedule-end and ma-schedule-dura= tion parameters, given that the ma-schedule-start (which is typed as an eve= nt)

 

We said we would show that these parameters were not= needed using an example – so here goes.

 

Lets assume we have a schedule made up of 2 actions = (A1, A2) in pipeline mode. The ma-schedule-start would has a periodic event= :

Start April 1, = 2016 at 02:00:00

End May 1, 2016= at 02:00:00

Interval 86,400= (daily)

Randomness 3600= (within the hour)

 

So the schedule will reoccur every day starting on A= pril 1 beginning at 2:00pm. (T0) The starting period will be random between= 2:00am and 3:00am. (T1) This definition is sufficient for invoking A1 (T1)= and is what Al considers as Blue times.

 

As A1 performs a test A1 places bits on the wire (T2= ) and collects results (T3).

When A1 completes (T4), A2 is invoked (T5) which pla= ces bits on a wire for A2 (T2) and collects results (T3)). Finally the resu= lts from the schedule are reported (T6).

 

T2&T3: Al considers this time to be part of the = definition of the metric and are reported as part of the result content (no= t as an actual parameter). This was his Red time

 

T4&T5: Are the ma-report-[start|end]-time

T6: Is the ma-report-date

 

As such – As long as an Event has a defined oc= currence (T1=3DT0 + randomness) all that is necessary is a single param= eter to define the occurrence.

 

Questions?

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77012A627E42US70UWXCHMBA0_-- From nobody Sun Apr 17 09:34:36 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C992B12B00D for ; Sun, 17 Apr 2016 09:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viavisolutions-com.20150623.gappssmtp.com 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 LbdMmrTzEi50 for ; Sun, 17 Apr 2016 09:34:33 -0700 (PDT) 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 EC4D012D0C2 for ; Sun, 17 Apr 2016 09:34:32 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id a140so90160250wma.0 for ; Sun, 17 Apr 2016 09:34:32 -0700 (PDT) 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; bh=HiCSa6et3a8rkX9kAz6ibCV8RpJlXkZkeGbrXeXCsaw=; b=PTQarP7UoMCQDkV3DRkMRE/yotyyVpFbRqgEaxHeUZ9WfYr7JQjd0bV+FEr86WJwkx T4+OYOhCp+qEdZEVSekBL3ehVeA6XJDJDdANIds49hGJVJI3eSq0zgi7FyQniDoK35Me J5qewLP4VuF1DglBvP6xJa+nfUnsXZU7s4jXHCZOJGhy46INR8kPyRo9xznZBiFwcpAd cfknMXwDDmrqU26PxkMX8hc7PkGKGNyj/gMQUrzQrJE0wQAsh/oQYt8+rEq0cU1vUsfP VZEJjiNJujkIlng82OLYg637dvjAZ41aX8C7rqbWOGYE7JtlDJBGSQQibmtAawwrwdxP 2QJA== 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; bh=HiCSa6et3a8rkX9kAz6ibCV8RpJlXkZkeGbrXeXCsaw=; b=eKPmkYQu0R6WOoZbr955SJN7tVGAi9NGVVoEusEaBxT37sAdJm3AZuAZv4Oa4981Yl 2liqxrikn0zwY2smhsOwRcmn9RW6E9NSKvlKjBDXgBBN/6m+VDup6qLSlZjfZ6sY/kAr TzpEIzBz65tWHWYVddj954LwBl+QWuQVCxUN1IoAjmN6nMhdyBFI2wMsgHV73fIkNChw GnqsdWNvSC1F5FlNuqJEfUDKoie+rGx7JwXCS7AU7UA+4fcxSq/61AFFXRh8uT3Vak5E h2GoUa4qeUUiGedF5FAmJQ88U1hNIEz8Jf0YApsyWuZCe8OzqGnpWv4M2Uy8G+15MO8Y hbrA== X-Gm-Message-State: AOPr4FX4k55h2ZaKGnI7ncx4esePfZghqpJdJecam2pis5aHx34OanNFKla/lkh/I5SBMnsLDL1D4gIkkAprIqZv MIME-Version: 1.0 X-Received: by 10.28.234.151 with SMTP id g23mr14095229wmi.40.1460910871318; Sun, 17 Apr 2016 09:34:31 -0700 (PDT) Received: by 10.28.155.21 with HTTP; Sun, 17 Apr 2016 09:34:31 -0700 (PDT) In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A627E42@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A627E42@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Sun, 17 Apr 2016 12:34:31 -0400 Message-ID: From: Ron Stana To: "Carey, Timothy (Nokia - US)" Content-Type: multipart/alternative; boundary=001a1147689488c2330530b0d161 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: Defining the Schedule's events X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 17 Apr 2016 16:34:36 -0000 --001a1147689488c2330530b0d161 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tim, It appears you are making an assumption that each action will end on its own (T4). While that is true for turn-up tests like RFC-2544 and Y.1564, long term performance monitoring tests like TWAMP and Y.1731 are expected to produce results 24/7 and so do not have a defined end time. They are configured with a rate to send packets, the MA measures FD, FDV and FLR and then the MA periodically aggregates these stats and sends them to the collector. The aggregation rate is typically 1, 5 or 15 minutes so reports contain rolling start/end times as the test executes. While what I describe above is the typical use case, there are other scenarios where these same tests can be configured to emulate short random bursts. In this scenario the tests need to be configured with an initial start time, an interval to restart the test, a random start offset and a duration. For example, start at 1:00 today, restart every 5 minutes thereafter, each run should be offset by a random value within 4 minutes and each run should send the data flows for 1 minute. I think the only part of this LMAP did not define was the last parameter - the test duration. While each test could offer test-specific parameters to define its duration, I thought the proposal to add the 'end' object was to provide a common approach for this. Ron On Fri, Apr 8, 2016 at 8:52 AM, Carey, Timothy (Nokia - US) < timothy.carey@nokia.com> wrote: > Team, > > > > In the IETF#95 LMAP session we had a discussion on the need for the new > parameters for the ma-schedule-end and ma-schedule-duration parameters, > given that the ma-schedule-start (which is typed as an event) > > > > We said we would show that these parameters were not needed using an > example =E2=80=93 so here goes. > > > > Lets assume we have a schedule made up of 2 actions (A1, A2) in pipeline > mode. The ma-schedule-start would has a periodic event: > > Start April 1, 2016 at 02:00:00 > > End May 1, 2016 at 02:00:00 > > Interval 86,400 (daily) > > Randomness 3600 (within the hour) > > > > So the schedule will reoccur every day starting on April 1 beginning at > 2:00pm. (T0) The starting period will be random between 2:00am and 3:00am= . > (T1) This definition is sufficient for invoking A1 (T1) and is what Al > considers as Blue times. > > > > As A1 performs a test A1 places bits on the wire (T2) and collects result= s > (T3). > > When A1 completes (T4), A2 is invoked (T5) which places bits on a wire fo= r > A2 (T2) and collects results (T3)). Finally the results from the schedule > are reported (T6). > > > > T2&T3: Al considers this time to be part of the definition of the metric > and are reported as part of the result content (not as an actual > parameter). This was his Red time > > > > T4&T5: Are the ma-report-[start|end]-time > > T6: Is the ma-report-date > > > > As such =E2=80=93 As long as an Event has a defined occurrence (T1=3DT0 + > randomness) all that is necessary is a single parameter to define the > occurrence. > > > > Questions? > > > > BR, > > Tim > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > --001a1147689488c2330530b0d161 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tim,

It appears you are making an assum= ption that each action will end on its own (T4).=C2=A0 While that is true f= or turn-up tests like RFC-2544 and Y.1564, long term performance monitoring= tests like TWAMP and Y.1731 are expected to produce results 24/7 and so do= not have a defined end time.=C2=A0 They are configured with a rate to send= packets, the MA measures FD, FDV and FLR and then the MA periodically aggr= egates these stats and sends them to the collector.=C2=A0 The aggregation r= ate is typically 1, 5 or 15 minutes so reports contain rolling start/end ti= mes as the test executes.

While what I describe ab= ove is the typical use case, there are other scenarios where these same tes= ts can be configured to emulate short random bursts. In this scenario the t= ests need to be configured with an initial start time, an interval to resta= rt the test, a random start offset and a duration.=C2=A0 For example, start= at 1:00 today, restart every 5 minutes thereafter, each run should be offs= et by a random value within 4 minutes and each run should send the data flo= ws for 1 minute.=C2=A0 I think the only part of this LMAP did not define wa= s the last parameter - the test duration. While each test could offer test-= specific parameters to define its duration, I thought the proposal to add t= he 'end' object was to provide a common approach for this.

Ron

On Fri, Apr 8, 2016 at 8:52 AM, Carey, Timothy (Nokia - US= ) <timothy.carey@nokia.com> wrote:

Team,

=C2=A0

In the IETF#95 LMAP session we had a discussion on t= he need for the new parameters for the ma-schedule-end and ma-schedule-dura= tion parameters, given that the ma-schedule-start (which is typed as an eve= nt)

=C2=A0

We said we would show that these parameters were not= needed using an example =E2=80=93 so here goes.

=C2=A0

Lets assume we have a schedule made up of 2 actions = (A1, A2) in pipeline mode. The ma-schedule-start would has a periodic event= :

Start April 1, 2016 at 02:00:00<= /u>

End May 1, 2016 at 02:00:00<= /p>

Interval 86,400 (daily)

Randomness 3600 (within the hour)

=C2=A0

So the schedule will reoccur every day starting on A= pril 1 beginning at 2:00pm. (T0) The starting period will be random between= 2:00am and 3:00am. (T1) This definition is sufficient for invoking A1 (T1)= and is what Al considers as Blue times.

=C2=A0

As A1 performs a test A1 places bits on the wire (T2= ) and collects results (T3).

When A1 completes (T4), A2 is invoked (T5) which pla= ces bits on a wire for A2 (T2) and collects results (T3)). Finally the resu= lts from the schedule are reported (T6).

=C2=A0

T2&T3: Al considers this time to be part of the = definition of the metric and are reported as part of the result content (no= t as an actual parameter). This was his Red time

=C2=A0

T4&T5: Are the ma-report-[start|end]-time=

T6: Is the ma-report-date

=C2=A0

As such =E2=80=93 As long as an Event has a defined = occurrence (T1=3DT0 + randomness) all that is necessary is a single paramet= er to define the occurrence.

=C2=A0

Questions?

=C2=A0

BR,

Tim


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


--001a1147689488c2330530b0d161-- From nobody Sun Apr 17 18:19:31 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8056012D96F for ; Sun, 17 Apr 2016 18:19:30 -0700 (PDT) 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 autolearn_force=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 M_9YwD8b5uGr for ; Sun, 17 Apr 2016 18:19:28 -0700 (PDT) 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 79A6212D693 for ; Sun, 17 Apr 2016 18:19:24 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 7385181779208; Mon, 18 Apr 2016 01:19:22 +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 u3I1JMxp010508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Apr 2016 01:19:23 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 u3I1JM1X008109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Apr 2016 01:19:22 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Sun, 17 Apr 2016 21:19:22 -0400 From: "Carey, Timothy (Nokia - US)" To: EXT Ron Stana Thread-Topic: [lmap] LMAP: Defining the Schedule's events Thread-Index: AQHRmMcIsS7v7zskLkW09Igh4D3XRZ+O62+Q Date: Mon, 18 Apr 2016 01:19:20 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A631C28@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A627E42@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_9966516C6EB5FC4381E05BF80AA55F77012A631C28US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: Defining the Schedule's events X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 18 Apr 2016 01:19:30 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A631C28US70UWXCHMBA0_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9uLA0KDQpUaGFua3MgZm9yIGxvb2tpbmcgYXQgdGhpcy4NCldoZW4gSSBkaXNjdXNzZWQgdGhp cyB3aXRoIEFsIGluZGljYXRlZCB0aGF0IHRoZXNlIHdvdWxkIGJlIHBhcnQgb2YgdGhlIG1ldHJp Yy9hY3Rpb24gZGVmaW5pdGlvbi4NCg0KQnV0IGlmIHdlIHdvdWxkIHdhbnQgdG8gZGVmaW5lIGEg bm9uLW1ldHJpYyBzcGVjaWZpYyBkdXJhdGlvbiBhdHRyaWJ1dGUgb2YgYW4gaW5kaXZpZHVhbCBh Y3Rpb24gd2l0aGluIHRoZSBjb250ZXh0IG9mIHRoZSBvdmVyYWxsIHNjaGVkdWxlIChJIGJlbGll dmUgdGhpcyBpcyB3aGF0IHlvdSBhcmUgcmVxdWVzdGluZz8pIHRoZW4gd2Ugc2hvdWxkIGFzc2ln biB0aGF0IGR1cmF0aW9uIHRoYXQgcmVzdWx0cyBpbiAoVDQpIHRvIHRoZSBhY3Rpb24uIEFjdHVh bGx5IHlvdSBoYXZlIHRoZSBzYW1lIHByb2JsZW0gd2l0aCBUMiDigJMgd2l0aGluIHRoZSBjb250 ZXh0IGFjdGlvbiDigJMgdGhpcyBvZmZzZXQgaWYgbmVjZXNzYXJ5IGlzIGRpZmZlcmVudCBmcm9t IHRoZSBzY2hlZHVsZSBzdGFydCByYW5kb21uZXNzIChvbmNlIHRoZSBwcm9jZXNzIHN0YXJ0cyBo b3cgbG9uZyB0byB3YWl0IGJlZm9yZSB0aGUgYml0cyBoaXQgdGhlIHdpcmUpLiAgTWF5YmUgdGhh dCBpcyB3aGF0IHdlIGFyZSBtaXNzaW5nIOKAkyBBIHRpbWVyIGZvciBhbiBhY3Rpb24gd2l0aGlu IHRoZSBjb250ZXh0IG9mIHRoZSBzY2hlZHVsZeKApg0KDQpDb21tZW50cz8NCg0KRnJvbTogRVhU IFJvbiBTdGFuYSBbbWFpbHRvOnJvbi5zdGFuYUB2aWF2aXNvbHV0aW9ucy5jb21dDQpTZW50OiBT dW5kYXksIEFwcmlsIDE3LCAyMDE2IDY6MzUgUE0NClRvOiBDYXJleSwgVGltb3RoeSAoTm9raWEg LSBVUykNCkNjOiBsbWFwQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2xtYXBdIExNQVA6IERlZmlu aW5nIHRoZSBTY2hlZHVsZSdzIGV2ZW50cw0KDQpUaW0sDQoNCkl0IGFwcGVhcnMgeW91IGFyZSBt YWtpbmcgYW4gYXNzdW1wdGlvbiB0aGF0IGVhY2ggYWN0aW9uIHdpbGwgZW5kIG9uIGl0cyBvd24g KFQ0KS4gIFdoaWxlIHRoYXQgaXMgdHJ1ZSBmb3IgdHVybi11cCB0ZXN0cyBsaWtlIFJGQy0yNTQ0 IGFuZCBZLjE1NjQsIGxvbmcgdGVybSBwZXJmb3JtYW5jZSBtb25pdG9yaW5nIHRlc3RzIGxpa2Ug VFdBTVAgYW5kIFkuMTczMSBhcmUgZXhwZWN0ZWQgdG8gcHJvZHVjZSByZXN1bHRzIDI0LzcgYW5k IHNvIGRvIG5vdCBoYXZlIGEgZGVmaW5lZCBlbmQgdGltZS4gIFRoZXkgYXJlIGNvbmZpZ3VyZWQg d2l0aCBhIHJhdGUgdG8gc2VuZCBwYWNrZXRzLCB0aGUgTUEgbWVhc3VyZXMgRkQsIEZEViBhbmQg RkxSIGFuZCB0aGVuIHRoZSBNQSBwZXJpb2RpY2FsbHkgYWdncmVnYXRlcyB0aGVzZSBzdGF0cyBh bmQgc2VuZHMgdGhlbSB0byB0aGUgY29sbGVjdG9yLiAgVGhlIGFnZ3JlZ2F0aW9uIHJhdGUgaXMg dHlwaWNhbGx5IDEsIDUgb3IgMTUgbWludXRlcyBzbyByZXBvcnRzIGNvbnRhaW4gcm9sbGluZyBz dGFydC9lbmQgdGltZXMgYXMgdGhlIHRlc3QgZXhlY3V0ZXMuDQoNCldoaWxlIHdoYXQgSSBkZXNj cmliZSBhYm92ZSBpcyB0aGUgdHlwaWNhbCB1c2UgY2FzZSwgdGhlcmUgYXJlIG90aGVyIHNjZW5h cmlvcyB3aGVyZSB0aGVzZSBzYW1lIHRlc3RzIGNhbiBiZSBjb25maWd1cmVkIHRvIGVtdWxhdGUg c2hvcnQgcmFuZG9tIGJ1cnN0cy4gSW4gdGhpcyBzY2VuYXJpbyB0aGUgdGVzdHMgbmVlZCB0byBi ZSBjb25maWd1cmVkIHdpdGggYW4gaW5pdGlhbCBzdGFydCB0aW1lLCBhbiBpbnRlcnZhbCB0byBy ZXN0YXJ0IHRoZSB0ZXN0LCBhIHJhbmRvbSBzdGFydCBvZmZzZXQgYW5kIGEgZHVyYXRpb24uICBG b3IgZXhhbXBsZSwgc3RhcnQgYXQgMTowMCB0b2RheSwgcmVzdGFydCBldmVyeSA1IG1pbnV0ZXMg dGhlcmVhZnRlciwgZWFjaCBydW4gc2hvdWxkIGJlIG9mZnNldCBieSBhIHJhbmRvbSB2YWx1ZSB3 aXRoaW4gNCBtaW51dGVzIGFuZCBlYWNoIHJ1biBzaG91bGQgc2VuZCB0aGUgZGF0YSBmbG93cyBm b3IgMSBtaW51dGUuICBJIHRoaW5rIHRoZSBvbmx5IHBhcnQgb2YgdGhpcyBMTUFQIGRpZCBub3Qg ZGVmaW5lIHdhcyB0aGUgbGFzdCBwYXJhbWV0ZXIgLSB0aGUgdGVzdCBkdXJhdGlvbi4gV2hpbGUg ZWFjaCB0ZXN0IGNvdWxkIG9mZmVyIHRlc3Qtc3BlY2lmaWMgcGFyYW1ldGVycyB0byBkZWZpbmUg aXRzIGR1cmF0aW9uLCBJIHRob3VnaHQgdGhlIHByb3Bvc2FsIHRvIGFkZCB0aGUgJ2VuZCcgb2Jq ZWN0IHdhcyB0byBwcm92aWRlIGEgY29tbW9uIGFwcHJvYWNoIGZvciB0aGlzLg0KDQpSb24NCg0K T24gRnJpLCBBcHIgOCwgMjAxNiBhdCA4OjUyIEFNLCBDYXJleSwgVGltb3RoeSAoTm9raWEgLSBV UykgPHRpbW90aHkuY2FyZXlAbm9raWEuY29tPG1haWx0bzp0aW1vdGh5LmNhcmV5QG5va2lhLmNv bT4+IHdyb3RlOg0KVGVhbSwNCg0KSW4gdGhlIElFVEYjOTUgTE1BUCBzZXNzaW9uIHdlIGhhZCBh IGRpc2N1c3Npb24gb24gdGhlIG5lZWQgZm9yIHRoZSBuZXcgcGFyYW1ldGVycyBmb3IgdGhlIG1h LXNjaGVkdWxlLWVuZCBhbmQgbWEtc2NoZWR1bGUtZHVyYXRpb24gcGFyYW1ldGVycywgZ2l2ZW4g dGhhdCB0aGUgbWEtc2NoZWR1bGUtc3RhcnQgKHdoaWNoIGlzIHR5cGVkIGFzIGFuIGV2ZW50KQ0K DQpXZSBzYWlkIHdlIHdvdWxkIHNob3cgdGhhdCB0aGVzZSBwYXJhbWV0ZXJzIHdlcmUgbm90IG5l ZWRlZCB1c2luZyBhbiBleGFtcGxlIOKAkyBzbyBoZXJlIGdvZXMuDQoNCkxldHMgYXNzdW1lIHdl IGhhdmUgYSBzY2hlZHVsZSBtYWRlIHVwIG9mIDIgYWN0aW9ucyAoQTEsIEEyKSBpbiBwaXBlbGlu ZSBtb2RlLiBUaGUgbWEtc2NoZWR1bGUtc3RhcnQgd291bGQgaGFzIGEgcGVyaW9kaWMgZXZlbnQ6 DQoNClN0YXJ0IEFwcmlsIDEsIDIwMTYgYXQgMDI6MDA6MDANCg0KRW5kIE1heSAxLCAyMDE2IGF0 IDAyOjAwOjAwDQoNCkludGVydmFsIDg2LDQwMCAoZGFpbHkpDQoNClJhbmRvbW5lc3MgMzYwMCAo d2l0aGluIHRoZSBob3VyKQ0KDQpTbyB0aGUgc2NoZWR1bGUgd2lsbCByZW9jY3VyIGV2ZXJ5IGRh eSBzdGFydGluZyBvbiBBcHJpbCAxIGJlZ2lubmluZyBhdCAyOjAwcG0uIChUMCkgVGhlIHN0YXJ0 aW5nIHBlcmlvZCB3aWxsIGJlIHJhbmRvbSBiZXR3ZWVuIDI6MDBhbSBhbmQgMzowMGFtLiAoVDEp IFRoaXMgZGVmaW5pdGlvbiBpcyBzdWZmaWNpZW50IGZvciBpbnZva2luZyBBMSAoVDEpIGFuZCBp cyB3aGF0IEFsIGNvbnNpZGVycyBhcyBCbHVlIHRpbWVzLg0KDQpBcyBBMSBwZXJmb3JtcyBhIHRl c3QgQTEgcGxhY2VzIGJpdHMgb24gdGhlIHdpcmUgKFQyKSBhbmQgY29sbGVjdHMgcmVzdWx0cyAo VDMpLg0KV2hlbiBBMSBjb21wbGV0ZXMgKFQ0KSwgQTIgaXMgaW52b2tlZCAoVDUpIHdoaWNoIHBs YWNlcyBiaXRzIG9uIGEgd2lyZSBmb3IgQTIgKFQyKSBhbmQgY29sbGVjdHMgcmVzdWx0cyAoVDMp KS4gRmluYWxseSB0aGUgcmVzdWx0cyBmcm9tIHRoZSBzY2hlZHVsZSBhcmUgcmVwb3J0ZWQgKFQ2 KS4NCg0KVDImVDM6IEFsIGNvbnNpZGVycyB0aGlzIHRpbWUgdG8gYmUgcGFydCBvZiB0aGUgZGVm aW5pdGlvbiBvZiB0aGUgbWV0cmljIGFuZCBhcmUgcmVwb3J0ZWQgYXMgcGFydCBvZiB0aGUgcmVz dWx0IGNvbnRlbnQgKG5vdCBhcyBhbiBhY3R1YWwgcGFyYW1ldGVyKS4gVGhpcyB3YXMgaGlzIFJl ZCB0aW1lDQoNClQ0JlQ1OiBBcmUgdGhlIG1hLXJlcG9ydC1bc3RhcnR8ZW5kXS10aW1lDQpUNjog SXMgdGhlIG1hLXJlcG9ydC1kYXRlDQoNCkFzIHN1Y2gg4oCTIEFzIGxvbmcgYXMgYW4gRXZlbnQg aGFzIGEgZGVmaW5lZCBvY2N1cnJlbmNlIChUMT1UMCArIHJhbmRvbW5lc3MpIGFsbCB0aGF0IGlz IG5lY2Vzc2FyeSBpcyBhIHNpbmdsZSBwYXJhbWV0ZXIgdG8gZGVmaW5lIHRoZSBvY2N1cnJlbmNl Lg0KDQpRdWVzdGlvbnM/DQoNCkJSLA0KVGltDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpsbWFwIG1haWxpbmcgbGlzdA0KbG1hcEBpZXRmLm9yZzxt YWlsdG86bG1hcEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbG1hcA0KDQo= --_000_9966516C6EB5FC4381E05BF80AA55F77012A631C28US70UWXCHMBA0_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9uLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhh bmtzIGZvciBsb29raW5nIGF0IHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldo ZW4gSSBkaXNjdXNzZWQgdGhpcyB3aXRoIEFsIGluZGljYXRlZCB0aGF0IHRoZXNlIHdvdWxkIGJl IHBhcnQgb2YgdGhlIG1ldHJpYy9hY3Rpb24gZGVmaW5pdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBpZiB3 ZSB3b3VsZCB3YW50IHRvIGRlZmluZSBhIG5vbi1tZXRyaWMgc3BlY2lmaWMgZHVyYXRpb24gYXR0 cmlidXRlIG9mIGFuIGluZGl2aWR1YWwgYWN0aW9uIHdpdGhpbiB0aGUgY29udGV4dCBvZiB0aGUg b3ZlcmFsbCBzY2hlZHVsZSAoSSBiZWxpZXZlIHRoaXMgaXMNCiB3aGF0IHlvdSBhcmUgcmVxdWVz dGluZz8pIHRoZW4gd2Ugc2hvdWxkIGFzc2lnbiB0aGF0IGR1cmF0aW9uIHRoYXQgcmVzdWx0cyBp biAoVDQpIHRvIHRoZSBhY3Rpb24uIEFjdHVhbGx5IHlvdSBoYXZlIHRoZSBzYW1lIHByb2JsZW0g d2l0aCBUMiDigJMgd2l0aGluIHRoZSBjb250ZXh0IGFjdGlvbiDigJMgdGhpcyBvZmZzZXQgaWYg bmVjZXNzYXJ5IGlzIGRpZmZlcmVudCBmcm9tIHRoZSBzY2hlZHVsZSBzdGFydCByYW5kb21uZXNz IChvbmNlIHRoZSBwcm9jZXNzDQogc3RhcnRzIGhvdyBsb25nIHRvIHdhaXQgYmVmb3JlIHRoZSBi aXRzIGhpdCB0aGUgd2lyZSkuJm5ic3A7IE1heWJlIHRoYXQgaXMgd2hhdCB3ZSBhcmUgbWlzc2lu ZyDigJMgQSB0aW1lciBmb3IgYW4gYWN0aW9uIHdpdGhpbiB0aGUgY29udGV4dCBvZiB0aGUgc2No ZWR1bGXigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvbW1lbnRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRVhUIFJvbiBTdGFuYSBb bWFpbHRvOnJvbi5zdGFuYUB2aWF2aXNvbHV0aW9ucy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g U3VuZGF5LCBBcHJpbCAxNywgMjAxNiA2OjM1IFBNPGJyPg0KPGI+VG86PC9iPiBDYXJleSwgVGlt b3RoeSAoTm9raWEgLSBVUyk8YnI+DQo8Yj5DYzo8L2I+IGxtYXBAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtsbWFwXSBMTUFQOiBEZWZpbmluZyB0aGUgU2NoZWR1bGUncyBldmVu dHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRpbSw8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGFwcGVhcnMgeW91 IGFyZSBtYWtpbmcgYW4gYXNzdW1wdGlvbiB0aGF0IGVhY2ggYWN0aW9uIHdpbGwgZW5kIG9uIGl0 cyBvd24gKFQ0KS4mbmJzcDsgV2hpbGUgdGhhdCBpcyB0cnVlIGZvciB0dXJuLXVwIHRlc3RzIGxp a2UgUkZDLTI1NDQgYW5kIFkuMTU2NCwgbG9uZyB0ZXJtIHBlcmZvcm1hbmNlIG1vbml0b3Jpbmcg dGVzdHMgbGlrZSBUV0FNUCBhbmQgWS4xNzMxIGFyZSBleHBlY3RlZCB0byBwcm9kdWNlIHJlc3Vs dHMNCiAyNC83IGFuZCBzbyBkbyBub3QgaGF2ZSBhIGRlZmluZWQgZW5kIHRpbWUuJm5ic3A7IFRo ZXkgYXJlIGNvbmZpZ3VyZWQgd2l0aCBhIHJhdGUgdG8gc2VuZCBwYWNrZXRzLCB0aGUgTUEgbWVh c3VyZXMgRkQsIEZEViBhbmQgRkxSIGFuZCB0aGVuIHRoZSBNQSBwZXJpb2RpY2FsbHkgYWdncmVn YXRlcyB0aGVzZSBzdGF0cyBhbmQgc2VuZHMgdGhlbSB0byB0aGUgY29sbGVjdG9yLiZuYnNwOyBU aGUgYWdncmVnYXRpb24gcmF0ZSBpcyB0eXBpY2FsbHkgMSwgNSBvciAxNQ0KIG1pbnV0ZXMgc28g cmVwb3J0cyBjb250YWluIHJvbGxpbmcgc3RhcnQvZW5kIHRpbWVzIGFzIHRoZSB0ZXN0IGV4ZWN1 dGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XaGlsZSB3aGF0IEkgZGVzY3JpYmUgYWJvdmUgaXMgdGhlIHR5cGljYWwgdXNlIGNhc2UsIHRo ZXJlIGFyZSBvdGhlciBzY2VuYXJpb3Mgd2hlcmUgdGhlc2Ugc2FtZSB0ZXN0cyBjYW4gYmUgY29u ZmlndXJlZCB0byBlbXVsYXRlIHNob3J0IHJhbmRvbSBidXJzdHMuIEluIHRoaXMgc2NlbmFyaW8g dGhlIHRlc3RzIG5lZWQgdG8gYmUgY29uZmlndXJlZCB3aXRoIGFuIGluaXRpYWwgc3RhcnQgdGlt ZSwgYW4gaW50ZXJ2YWwNCiB0byByZXN0YXJ0IHRoZSB0ZXN0LCBhIHJhbmRvbSBzdGFydCBvZmZz ZXQgYW5kIGEgZHVyYXRpb24uJm5ic3A7IEZvciBleGFtcGxlLCBzdGFydCBhdCAxOjAwIHRvZGF5 LCByZXN0YXJ0IGV2ZXJ5IDUgbWludXRlcyB0aGVyZWFmdGVyLCBlYWNoIHJ1biBzaG91bGQgYmUg b2Zmc2V0IGJ5IGEgcmFuZG9tIHZhbHVlIHdpdGhpbiA0IG1pbnV0ZXMgYW5kIGVhY2ggcnVuIHNo b3VsZCBzZW5kIHRoZSBkYXRhIGZsb3dzIGZvciAxIG1pbnV0ZS4mbmJzcDsgSSB0aGluayB0aGUN CiBvbmx5IHBhcnQgb2YgdGhpcyBMTUFQIGRpZCBub3QgZGVmaW5lIHdhcyB0aGUgbGFzdCBwYXJh bWV0ZXIgLSB0aGUgdGVzdCBkdXJhdGlvbi4gV2hpbGUgZWFjaCB0ZXN0IGNvdWxkIG9mZmVyIHRl c3Qtc3BlY2lmaWMgcGFyYW1ldGVycyB0byBkZWZpbmUgaXRzIGR1cmF0aW9uLCBJIHRob3VnaHQg dGhlIHByb3Bvc2FsIHRvIGFkZCB0aGUgJ2VuZCcgb2JqZWN0IHdhcyB0byBwcm92aWRlIGEgY29t bW9uIGFwcHJvYWNoIGZvciB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBcHIgOCwgMjAxNiBhdCA4OjUyIEFNLCBDYXJl eSwgVGltb3RoeSAoTm9raWEgLSBVUykgJmx0OzxhIGhyZWY9Im1haWx0bzp0aW1vdGh5LmNhcmV5 QG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpbW90aHkuY2FyZXlAbm9raWEuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGVhbSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIHRoZSBJRVRGIzk1IExN QVAgc2Vzc2lvbiB3ZSBoYWQgYSBkaXNjdXNzaW9uIG9uIHRoZSBuZWVkIGZvciB0aGUgbmV3IHBh cmFtZXRlcnMgZm9yIHRoZSBtYS1zY2hlZHVsZS1lbmQgYW5kIG1hLXNjaGVkdWxlLWR1cmF0aW9u IHBhcmFtZXRlcnMsIGdpdmVuIHRoYXQgdGhlIG1hLXNjaGVkdWxlLXN0YXJ0DQogKHdoaWNoIGlz IHR5cGVkIGFzIGFuIGV2ZW50KSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIHNhaWQg d2Ugd291bGQgc2hvdyB0aGF0IHRoZXNlIHBhcmFtZXRlcnMgd2VyZSBub3QgbmVlZGVkIHVzaW5n IGFuIGV4YW1wbGUg4oCTIHNvIGhlcmUgZ29lcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkxldHMgYXNzdW1lIHdlIGhhdmUgYSBzY2hlZHVsZSBtYWRlIHVwIG9mIDIgYWN0aW9ucyAoQTEs IEEyKSBpbiBwaXBlbGluZSBtb2RlLiBUaGUgbWEtc2NoZWR1bGUtc3RhcnQgd291bGQgaGFzIGEg cGVyaW9kaWMgZXZlbnQ6DQo8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDoy MC4yNXB0Ij5TdGFydCBBcHJpbCAxLCAyMDE2IGF0IDAyOjAwOjAwPG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MjAuMjVwdCI+RW5kIE1heSAxLCAyMDE2IGF0IDAyOjAwOjAw PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MjAuMjVwdCI+SW50ZXJ2YWwg ODYsNDAwIChkYWlseSk8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDoyMC4y NXB0Ij5SYW5kb21uZXNzIDM2MDAgKHdpdGhpbiB0aGUgaG91cik8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlNvIHRoZSBzY2hlZHVsZSB3aWxsIHJlb2NjdXIgZXZlcnkgZGF5IHN0YXJ0aW5n IG9uIEFwcmlsIDEgYmVnaW5uaW5nIGF0IDI6MDBwbS4gKFQwKSBUaGUgc3RhcnRpbmcgcGVyaW9k IHdpbGwgYmUgcmFuZG9tIGJldHdlZW4gMjowMGFtIGFuZCAzOjAwYW0uIChUMSkgVGhpcyBkZWZp bml0aW9uIGlzIHN1ZmZpY2llbnQNCiBmb3IgaW52b2tpbmcgQTEgKFQxKSBhbmQgaXMgd2hhdCBB bCBjb25zaWRlcnMgYXMgQmx1ZSB0aW1lcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFz IEExIHBlcmZvcm1zIGEgdGVzdCBBMSBwbGFjZXMgYml0cyBvbiB0aGUgd2lyZSAoVDIpIGFuZCBj b2xsZWN0cyByZXN1bHRzIChUMykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPldoZW4gQTEgY29tcGxldGVzIChUNCksIEEyIGlzIGludm9rZWQgKFQ1KSB3aGljaCBwbGFj ZXMgYml0cyBvbiBhIHdpcmUgZm9yIEEyIChUMikgYW5kIGNvbGxlY3RzIHJlc3VsdHMgKFQzKSku IEZpbmFsbHkgdGhlIHJlc3VsdHMgZnJvbSB0aGUgc2NoZWR1bGUgYXJlIHJlcG9ydGVkIChUNiku PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UMiZhbXA7VDM6IEFsIGNvbnNpZGVycyB0aGlz IHRpbWUgdG8gYmUgcGFydCBvZiB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgbWV0cmljIGFuZCBhcmUg cmVwb3J0ZWQgYXMgcGFydCBvZiB0aGUgcmVzdWx0IGNvbnRlbnQgKG5vdCBhcyBhbiBhY3R1YWwg cGFyYW1ldGVyKS4gVGhpcyB3YXMgaGlzIFJlZCB0aW1lPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UNCZhbXA7VDU6IEFyZSB0aGUgbWEtcmVwb3J0LVtzdGFydHxlbmRdLXRpbWU8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VDY6IElzIHRoZSBtYS1yZXBvcnQtZGF0 ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgc3VjaCDigJMgQXMgbG9uZyBhcyBhbiBF dmVudCBoYXMgYSBkZWZpbmVkIG9jY3VycmVuY2UgKFQxPVQwICYjNDM7IHJhbmRvbW5lc3MpIGFs bCB0aGF0IGlzIG5lY2Vzc2FyeSBpcyBhIHNpbmdsZSBwYXJhbWV0ZXIgdG8gZGVmaW5lIHRoZSBv Y2N1cnJlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UXVlc3Rpb25zPzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+QlIsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlRpbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpsbWFwIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpsbWFwQGlldGYub3JnIj5sbWFwQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1hcCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1hcDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9966516C6EB5FC4381E05BF80AA55F77012A631C28US70UWXCHMBA0_-- From nobody Mon Apr 18 06:40:25 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AB412D940 for ; Mon, 18 Apr 2016 06:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viavisolutions-com.20150623.gappssmtp.com 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 JRHBjNNXVEi4 for ; Mon, 18 Apr 2016 06:40:20 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 455D712D8B9 for ; Mon, 18 Apr 2016 06:40:20 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id u206so124706803wme.1 for ; Mon, 18 Apr 2016 06:40:20 -0700 (PDT) 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; bh=OgMgOoT2UxrktHUlGbs+6WeVlcasrAQbN2bS/IfD8Uk=; b=i0I39SKpmLscfFesRZOQh7FGqPR5qoHg9CxCAOSAWslhzKnxs981sSaAXYr61KsoAg PAgkPT4FwCDVf7piH/W5nYwIhB/7BWUaoB97fca0p7+LDDq2KDxx3/KOq31xJPhml2aP D8Mp5qW7d8/W57ViAXXyYQA918KtOp5WPKP8BOCt1Z+sy3vwVvw6a9YGgdKebKS2DG17 Qw8FIETxd8ySAV61cgwxpdkPOield4uI/qRrX1fng9iAP0hH/GijSQtErFC1BZ9vxQQV UA37p+0U7F0H51UHQqzZaiNJYOTpY/vzd0XAiTG9N2KnlKonriVmp/ZgcsJyQsVeB4ml myjA== 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; bh=OgMgOoT2UxrktHUlGbs+6WeVlcasrAQbN2bS/IfD8Uk=; b=kuoWNTip2+cVCkuwg1+1THmSjtpt55++zvhk8uhqiyXwx83hXNANhi/JJuitF6G4/Q 3nqZZCGjgxQkxx/LXUeEPMz0CgkD/vk8Q14aeUs2+I8aIVBLHSqH0yMxsGPLfrikTuTn b9Xb+wdX35qKe2hVjVkeDx/B1AOxyz4rL88swmhmNiBUKvej1l7++YG4T92jbEgM3YCr zgtRw1+pWo9txjrbCE0l/o0MF/Mzk+dhBkxCJlNGOY/xZ3t71KMjIWG0MhgbePWhQ++V DBYvy+WsRsv1hyYy8GBMOUfEgr2NPO92cJy8LPzcc+2+6Ha/oSU3ukIvpaV9otTHqdbp xC6w== X-Gm-Message-State: AOPr4FVm1tEwDB00eA9ObWyB2lT75VN0l4UN7kZLks2mBU+ShKMbQ70kXv1QLqqS6qKzfZEXBkUQWxJZXoZiDXRP MIME-Version: 1.0 X-Received: by 10.28.1.85 with SMTP id 82mr19455054wmb.58.1460986818476; Mon, 18 Apr 2016 06:40:18 -0700 (PDT) Received: by 10.28.155.21 with HTTP; Mon, 18 Apr 2016 06:40:18 -0700 (PDT) In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A631C28@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A627E42@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77012A631C28@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Mon, 18 Apr 2016 09:40:18 -0400 Message-ID: From: Ron Stana To: "Carey, Timothy (Nokia - US)" Content-Type: multipart/alternative; boundary=001a113ca8565676330530c280d2 Archived-At: Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: Defining the Schedule's events X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 18 Apr 2016 13:40:23 -0000 --001a113ca8565676330530c280d2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tim, The exact definition of the metric is still unclear to me since I have not seen an example of a test with average complexity using metrics with LMAP from beginning to end. By average complexity I mean a test that allows independent configuration of multiple simultaneous data flows and produces multiple report formats during the test duration. The tests I mentioned previously (RFC-2544, Y.1564, Y.1731 and TWAMP) minimally require this type of support and are the main tests used in Ethernet service testing today. None-the-less, my understanding of the metric is that it defines the format of the packet stream and the methodology of the transmit frequency. These are two examples from https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-00 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Std_Dev Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Mean It does not appear to define the time period over which the measurement was taken. This is good because for most tests the measurement period is a user defined input parameter. Performance monitoring tests will report the metric repeatedly during the test execution. Referring to the example in my prior email, a TWAMP test would produce a group of metrics for each data stream every 1, 5 or 15 minutes depending on the test configuration. It is possible the test could be configured to produce multiple reports - for example at a short interval for troubleshooting in addition to one of the intervals previously mentioned for general service monitoring. Thus, the TWAMP test produces instances of metrics for an unspecified amount of time - typically until a user manually stops the test. In summary, from my perspective, the duration of the test is outside the scope of the metric definition....but maybe I just don't understand the metric definition well enough. Ron On Sun, Apr 17, 2016 at 9:19 PM, Carey, Timothy (Nokia - US) < timothy.carey@nokia.com> wrote: > Ron, > > > > Thanks for looking at this. > > When I discussed this with Al indicated that these would be part of the > metric/action definition. > > > > But if we would want to define a non-metric specific duration attribute o= f > an individual action within the context of the overall schedule (I believ= e > this is what you are requesting?) then we should assign that duration tha= t > results in (T4) to the action. Actually you have the same problem with T2= =E2=80=93 > within the context action =E2=80=93 this offset if necessary is different= from the > schedule start randomness (once the process starts how long to wait befor= e > the bits hit the wire). Maybe that is what we are missing =E2=80=93 A ti= mer for an > action within the context of the schedule=E2=80=A6 > > > > Comments? > > > > *From:* EXT Ron Stana [mailto:ron.stana@viavisolutions.com] > *Sent:* Sunday, April 17, 2016 6:35 PM > *To:* Carey, Timothy (Nokia - US) > *Cc:* lmap@ietf.org > *Subject:* Re: [lmap] LMAP: Defining the Schedule's events > > > > Tim, > > > > It appears you are making an assumption that each action will end on its > own (T4). While that is true for turn-up tests like RFC-2544 and Y.1564, > long term performance monitoring tests like TWAMP and Y.1731 are expected > to produce results 24/7 and so do not have a defined end time. They are > configured with a rate to send packets, the MA measures FD, FDV and FLR a= nd > then the MA periodically aggregates these stats and sends them to the > collector. The aggregation rate is typically 1, 5 or 15 minutes so repor= ts > contain rolling start/end times as the test executes. > > > > While what I describe above is the typical use case, there are other > scenarios where these same tests can be configured to emulate short rando= m > bursts. In this scenario the tests need to be configured with an initial > start time, an interval to restart the test, a random start offset and a > duration. For example, start at 1:00 today, restart every 5 minutes > thereafter, each run should be offset by a random value within 4 minutes > and each run should send the data flows for 1 minute. I think the only > part of this LMAP did not define was the last parameter - the test > duration. While each test could offer test-specific parameters to define > its duration, I thought the proposal to add the 'end' object was to provi= de > a common approach for this. > > > > Ron > > > > On Fri, Apr 8, 2016 at 8:52 AM, Carey, Timothy (Nokia - US) < > timothy.carey@nokia.com> wrote: > > Team, > > > > In the IETF#95 LMAP session we had a discussion on the need for the new > parameters for the ma-schedule-end and ma-schedule-duration parameters, > given that the ma-schedule-start (which is typed as an event) > > > > We said we would show that these parameters were not needed using an > example =E2=80=93 so here goes. > > > > Lets assume we have a schedule made up of 2 actions (A1, A2) in pipeline > mode. The ma-schedule-start would has a periodic event: > > Start April 1, 2016 at 02:00:00 > > End May 1, 2016 at 02:00:00 > > Interval 86,400 (daily) > > Randomness 3600 (within the hour) > > > > So the schedule will reoccur every day starting on April 1 beginning at > 2:00pm. (T0) The starting period will be random between 2:00am and 3:00am= . > (T1) This definition is sufficient for invoking A1 (T1) and is what Al > considers as Blue times. > > > > As A1 performs a test A1 places bits on the wire (T2) and collects result= s > (T3). > > When A1 completes (T4), A2 is invoked (T5) which places bits on a wire fo= r > A2 (T2) and collects results (T3)). Finally the results from the schedule > are reported (T6). > > > > T2&T3: Al considers this time to be part of the definition of the metric > and are reported as part of the result content (not as an actual > parameter). This was his Red time > > > > T4&T5: Are the ma-report-[start|end]-time > > T6: Is the ma-report-date > > > > As such =E2=80=93 As long as an Event has a defined occurrence (T1=3DT0 + > randomness) all that is necessary is a single parameter to define the > occurrence. > > > > Questions? > > > > BR, > > Tim > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > > --001a113ca8565676330530c280d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tim,

The exact definition of the metric= is still unclear to me since I have not seen an example of a test with ave= rage complexity using metrics with LMAP from beginning to end.=C2=A0 By ave= rage complexity I mean a test that allows independent configuration of mult= iple simultaneous data flows and produces multiple report formats during th= e test duration. The tests I mentioned previously (RFC-2544, Y.1564, Y.1731= and TWAMP) minimally require this type of support and are the main tests u= sed in Ethernet service testing today.=C2=A0 None-the-less, my understandin= g of the metric is that it defines the format of the packet stream and the = methodology of the transmit frequency. These are two examples from=C2=A0ht= tps://tools.ietf.org/html/draft-ietf-ippm-initial-registry-00=C2=A0

Act_IP_UDP_Poisson_UDP-Paylo=
ad-250_One-way_Delay_Std_Dev
Act_IP_UDP_Per=
iodic-var_UDP-Payload-142_One-way_Delay_Mean

=

It does not appear to define the time period over wh=
ich the measurement was taken.  This is good because for most tests the mea=
surement period is a user defined input parameter.  Performance monitoring =
tests will report the metric repeatedly during the test execution.  Referri=
ng to the example in my prior email, a TWAMP test would produce a group of =
metrics for each data stream every 1, 5 or 15 minutes depending on the test=
 configuration. It is possible the test could be configured to produce mult=
iple reports - for example at a short interval for troubleshooting in addit=
ion to one of the intervals previously mentioned for general service monito=
ring. Thus, the TWAMP test produces instances of metrics for an unspecified=
 amount of time - typically until a user manually stops the test. =C2=A0

In summary, fr=
om my perspective, the duration of the test is outside the scope of the met=
ric definition....but maybe I just don't understand the metric definiti=
on well enough.

Ron


 


<=
pre class=3D"" style=3D"margin-top:0px;margin-bottom:0px">
<= /div>

On Sun, Apr = 17, 2016 at 9:19 PM, Carey, Timothy (Nokia - US) <timothy.carey@noki= a.com> wrote:

Ron,=

=C2=A0

Thanks for looking at thi= s.

When I discussed this wit= h Al indicated that these would be part of the metric/action definition.=

=C2=A0

But if we would want to d= efine a non-metric specific duration attribute of an individual action with= in the context of the overall schedule (I believe this is what you are requesting?) then we should assign that duration that results= in (T4) to the action. Actually you have the same problem with T2 =E2=80= =93 within the context action =E2=80=93 this offset if necessary is differe= nt from the schedule start randomness (once the process starts how long to wait before the bits hit the wire).=C2=A0 Maybe that is= what we are missing =E2=80=93 A timer for an action within the context of = the schedule=E2=80=A6

=C2=A0

Comments?

=C2=A0

From: EXT Ron = Stana [mailto:ron.stana@viavisolutions.com]
Sent: Sunday, April 17, 2016 6:35 PM
To: Carey, Timothy (Nokia - US)
Cc: lmap@ietf.org=
Subject: Re: [lmap] LMAP: Defining the Schedule's events<= u>

=C2=A0

Tim,

=C2=A0

It appears you are making an assumption that each ac= tion will end on its own (T4).=C2=A0 While that is true for turn-up tests l= ike RFC-2544 and Y.1564, long term performance monitoring tests like TWAMP = and Y.1731 are expected to produce results 24/7 and so do not have a defined end time.=C2=A0 They are configured with= a rate to send packets, the MA measures FD, FDV and FLR and then the MA pe= riodically aggregates these stats and sends them to the collector.=C2=A0 Th= e aggregation rate is typically 1, 5 or 15 minutes so reports contain rolling start/end times as the test executes.

=C2=A0

While what I describe above is the typical use case,= there are other scenarios where these same tests can be configured to emul= ate short random bursts. In this scenario the tests need to be configured w= ith an initial start time, an interval to restart the test, a random start offset and a duration.=C2=A0 For examp= le, start at 1:00 today, restart every 5 minutes thereafter, each run shoul= d be offset by a random value within 4 minutes and each run should send the= data flows for 1 minute.=C2=A0 I think the only part of this LMAP did not define was the last parameter - the test du= ration. While each test could offer test-specific parameters to define its = duration, I thought the proposal to add the 'end' object was to pro= vide a common approach for this.

=C2=A0

Ron

=C2=A0

On Fri, Apr 8, 2016 at 8:52 AM, Carey, Timothy (Noki= a - US) <ti= mothy.carey@nokia.com> wrote:

Team,

=C2=A0

In the IETF#95 LMAP session we had a discussion on t= he need for the new parameters for the ma-schedule-end and ma-schedule-dura= tion parameters, given that the ma-schedule-start (which is typed as an event)

=C2=A0

We said we would show that these parameters were not= needed using an example =E2=80=93 so here goes.

=C2=A0

Lets assume we have a schedule made up of 2 actions = (A1, A2) in pipeline mode. The ma-schedule-start would has a periodic event= :

Start April 1, 2016 at 02:00:00<= /u>

End May 1, 2016 at 02:00:00<= /p>

Interval 86,400 (daily)

Randomness 3600 (within the hour)

=C2=A0

So the schedule will reoccur every day starting on A= pril 1 beginning at 2:00pm. (T0) The starting period will be random between= 2:00am and 3:00am. (T1) This definition is sufficient for invoking A1 (T1) and is what Al considers as Blue times.=

=C2=A0

As A1 performs a test A1 places bits on the wire (T2= ) and collects results (T3).

When A1 completes (T4), A2 is invoked (T5) which pla= ces bits on a wire for A2 (T2) and collects results (T3)). Finally the resu= lts from the schedule are reported (T6).

=C2=A0

T2&T3: Al considers this time to be part of the = definition of the metric and are reported as part of the result content (no= t as an actual parameter). This was his Red time

=C2=A0

T4&T5: Are the ma-report-[start|end]-time=

T6: Is the ma-report-date

=C2=A0

As such =E2=80=93 As long as an Event has a defined = occurrence (T1=3DT0 + randomness) all that is necessary is a single paramet= er to define the occurrence.

=C2=A0

Questions?

=C2=A0

BR,

Tim


_______________________________________________
lmap mailing list
lmap@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lmap

=C2=A0


--001a113ca8565676330530c280d2-- From nobody Mon Apr 18 08:19:37 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A273512D583 for ; Mon, 18 Apr 2016 08:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 xijNRVO2WDZu for ; Mon, 18 Apr 2016 08:19:33 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDA712D0CF for ; Mon, 18 Apr 2016 08:19:33 -0700 (PDT) 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 2DC4B120D0F; Mon, 18 Apr 2016 11:26:03 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 65BBAE135D; Mon, 18 Apr 2016 11:18:55 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Mon, 18 Apr 2016 11:19:29 -0400 From: "MORTON, ALFRED C (AL)" To: Ron Stana , "Carey, Timothy (Nokia - US)" Date: Mon, 18 Apr 2016 11:19:28 -0400 Thread-Topic: [lmap] LMAP: Defining the Schedule's events Thread-Index: AdGZd9rQJTkpf774ROKeFrGZd8cc6QACpZBg Message-ID: <4AF73AA205019A4C8A1DDD32C034631D4587DEFEC7@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A627E42@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77012A631C28@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D4587DEFEC7NJFPSRVEXG0re_" MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: Defining the Schedule's events X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 18 Apr 2016 15:19:36 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D4587DEFEC7NJFPSRVEXG0re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9uIGFuZCBUaW0sDQoNCnRyeWluZyB0byBtYWtlIGEgZmV3IG1pbnV0ZXMgZm9yIHRoaXMu Li4NCg0KVGhlIFJlZ2lzdHJ5IEVudHJpZXMqIGZvciB0aGUgTWV0cmljcyBpbmNsdWRlIFJ1bi10 aW1lIFBhcmFtZXRlcnMNCmZvciB0aGUgU3RhcnQgdGltZSBhbmQgRW5kIFRpbWUsIGJ1dCBvbmUg b2YgdGhlbSBjb3VsZCBiZSBpbnRlcnByZXRlZA0KYXMgYSBEdXJhdGlvbiBpZiBzcGVjaWZpZWQg Y29ycmVjdGx5ICh0aGUgU3RhcnQgdGltZSBtdXN0IGJlIGFsbCB6ZXJvcywNCnRoZW4gdGhlIFN0 b3AgdGltZSBpcyBpbnRlcnByZXRlZCBhcyBhIGR1cmF0aW9uLCBBTkQgdGhlIGFjdHVhbCBzdGFy dA0KYW5kIHN0b3AgdGltZSBhcmUgY29udHJvbGxlZCB0aHJvdWdoIOKAnG90aGVyIG1lYW5z4oCd KS4gU2VlDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0taW5p dGlhbC1yZWdpc3RyeS0wMCNzZWN0aW9uLTQuMy41DQoNCuKAnE90aGVyIG1lYW5z4oCdIHdvdWxk IGJlIHRoZSBTY2hlZHVsZSBvYmplY3QgYW5kIHRoZSBFdmVudCBvYmplY3QuDQpBcyBJIHVuZGVy c3RhbmQgaXQgYm90aCBzY2hlZHVsZSBhbmQgZXZlbnQgb2JqZWN0cyBoYXZlIHN0YXJ0IHRpbWUN CmFuZCBzdG9wIHRpbWUgc3BlY2lmaWNhdGlvbnMgYXZhaWxhYmxlLCBhbmQgRXZlbnQgaGFzIER1 cmF0aW9uIHNwZWNpZmljYXRpb24NCmF2YWlsYWJsZSB3aGljaCB3b3VsZCBiZSB1c2VmdWwgZm9y IHJlY3VycmluZyBldmVudHMgKHBlcmlvZGljIG9yIGNhbGVuZGFyKS4NCg0KRXZlbnR1YWxseSwg dGhlIE1BIGhhcyB0byByZXBvcnQgdGhlIHJlc3VsdHMgb2YgdGhlIG1ldHJpYy9tZWFzdXJlbWVu dC4NClRoYXTigJlzIHdoZW4gdGhlIGFjdHVhbCAoUkVEKSBzdGFydCBhbmQgZW5kIHRpbWVzIHdo ZW4gcGFja2V0cyB3ZXJlIGFjdHVhbGx5DQpmbG93aW5nIGJldHdlZW4gbWVhc3VyZW1lbnQgcG9p bnRzIGFyZSByZXBvcnRlZCwgYWNjb3JkaW5nIHRvIHRoZSBSZWdpc3RyeSBFbnRyeS4NClNlZToN Cg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1pbml0aWFsLXJl Z2lzdHJ5LTAwI3NlY3Rpb24tNC40LjINCg0KQXMgSSBzYWlkIGF0IHRoZSBtZWV0aW5nLCBpdCB3 b3VsZCBiZSBnb29kIHRvIGxvb2sgYXQgc29tZSBleGFtcGxlcw0KDQp3aGljaCBhdHRlbXB0IHRv IHNjaGVkdWxlIHRoZSDigJxBY3RfSVBfVURQX1JvdW5kLXRyaXBfRGVsYXlfUG9pc3Nvbl85NXRo LXBlcmNlbnRpbGXigJ0NCg0KcmVnaXN0cnkgZW50cnksIGFzIGEgUGVyaW9kaWMgZXZlbnQsIGEg b25lLXRpbWUgZXZlbnQsIGFuZCBhIGNvbnRpbnVvdXMNCg0KZXZlbnQgYXMgUm9uIGlzIHN1Z2dl c3RpbmcuDQoNCg0KDQpyZWdhcmRzLA0KDQpBbA0KDQoqIE5vdGUgdGhhdCB0aGUgUmVnaXN0cnkg RW50cnkgZm9yIGEgTWV0cmljIGluY2x1ZGVzIHRoZSBNZXRyaWMgRGVmaW5pdGlvbiwNCnRoZSBt ZXRob2Qgb2YgbWVhc3VyZW1lbnQsIGFuZCBSdW4tdGltZSBwYXJhbWV0ZXJzLg0KDQoNCkZyb206 IFJvbiBTdGFuYSBbbWFpbHRvOnJvbi5zdGFuYUB2aWF2aXNvbHV0aW9ucy5jb21dDQpTZW50OiBN b25kYXksIEFwcmlsIDE4LCAyMDE2IDk6NDAgQU0NClRvOiBDYXJleSwgVGltb3RoeSAoTm9raWEg LSBVUykNCkNjOiBsbWFwQGlldGYub3JnOyBNT1JUT04sIEFMRlJFRCBDIChBTCkNClN1YmplY3Q6 IFJlOiBbbG1hcF0gTE1BUDogRGVmaW5pbmcgdGhlIFNjaGVkdWxlJ3MgZXZlbnRzDQoNClRpbSwN Cg0KVGhlIGV4YWN0IGRlZmluaXRpb24gb2YgdGhlIG1ldHJpYyBpcyBzdGlsbCB1bmNsZWFyIHRv IG1lIHNpbmNlIEkgaGF2ZSBub3Qgc2VlbiBhbiBleGFtcGxlIG9mIGEgdGVzdCB3aXRoIGF2ZXJh Z2UgY29tcGxleGl0eSB1c2luZyBtZXRyaWNzIHdpdGggTE1BUCBmcm9tIGJlZ2lubmluZyB0byBl bmQuICBCeSBhdmVyYWdlIGNvbXBsZXhpdHkgSSBtZWFuIGEgdGVzdCB0aGF0IGFsbG93cyBpbmRl cGVuZGVudCBjb25maWd1cmF0aW9uIG9mIG11bHRpcGxlIHNpbXVsdGFuZW91cyBkYXRhIGZsb3dz IGFuZCBwcm9kdWNlcyBtdWx0aXBsZSByZXBvcnQgZm9ybWF0cyBkdXJpbmcgdGhlIHRlc3QgZHVy YXRpb24uIFRoZSB0ZXN0cyBJIG1lbnRpb25lZCBwcmV2aW91c2x5IChSRkMtMjU0NCwgWS4xNTY0 LCBZLjE3MzEgYW5kIFRXQU1QKSBtaW5pbWFsbHkgcmVxdWlyZSB0aGlzIHR5cGUgb2Ygc3VwcG9y dCBhbmQgYXJlIHRoZSBtYWluIHRlc3RzIHVzZWQgaW4gRXRoZXJuZXQgc2VydmljZSB0ZXN0aW5n IHRvZGF5LiAgTm9uZS10aGUtbGVzcywgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgbWV0cmljIGlz IHRoYXQgaXQgZGVmaW5lcyB0aGUgZm9ybWF0IG9mIHRoZSBwYWNrZXQgc3RyZWFtIGFuZCB0aGUg bWV0aG9kb2xvZ3kgb2YgdGhlIHRyYW5zbWl0IGZyZXF1ZW5jeS4gVGhlc2UgYXJlIHR3byBleGFt cGxlcyBmcm9tIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0taW5p dGlhbC1yZWdpc3RyeS0wMA0KDQoNCkFjdF9JUF9VRFBfUG9pc3Nvbl9VRFAtUGF5bG9hZC0yNTBf T25lLXdheV9EZWxheV9TdGRfRGV2DQoNCkFjdF9JUF9VRFBfUGVyaW9kaWMtdmFyX1VEUC1QYXls b2FkLTE0Ml9PbmUtd2F5X0RlbGF5X01lYW4NCg0KDQoNCkl0IGRvZXMgbm90IGFwcGVhciB0byBk ZWZpbmUgdGhlIHRpbWUgcGVyaW9kIG92ZXIgd2hpY2ggdGhlIG1lYXN1cmVtZW50IHdhcyB0YWtl bi4gIFRoaXMgaXMgZ29vZCBiZWNhdXNlIGZvciBtb3N0IHRlc3RzIHRoZSBtZWFzdXJlbWVudCBw ZXJpb2QgaXMgYSB1c2VyIGRlZmluZWQgaW5wdXQgcGFyYW1ldGVyLiAgUGVyZm9ybWFuY2UgbW9u aXRvcmluZyB0ZXN0cyB3aWxsIHJlcG9ydCB0aGUgbWV0cmljIHJlcGVhdGVkbHkgZHVyaW5nIHRo ZSB0ZXN0IGV4ZWN1dGlvbi4gIFJlZmVycmluZyB0byB0aGUgZXhhbXBsZSBpbiBteSBwcmlvciBl bWFpbCwgYSBUV0FNUCB0ZXN0IHdvdWxkIHByb2R1Y2UgYSBncm91cCBvZiBtZXRyaWNzIGZvciBl YWNoIGRhdGEgc3RyZWFtIGV2ZXJ5IDEsIDUgb3IgMTUgbWludXRlcyBkZXBlbmRpbmcgb24gdGhl IHRlc3QgY29uZmlndXJhdGlvbi4gSXQgaXMgcG9zc2libGUgdGhlIHRlc3QgY291bGQgYmUgY29u ZmlndXJlZCB0byBwcm9kdWNlIG11bHRpcGxlIHJlcG9ydHMgLSBmb3IgZXhhbXBsZSBhdCBhIHNo b3J0IGludGVydmFsIGZvciB0cm91Ymxlc2hvb3RpbmcgaW4gYWRkaXRpb24gdG8gb25lIG9mIHRo ZSBpbnRlcnZhbHMgcHJldmlvdXNseSBtZW50aW9uZWQgZm9yIGdlbmVyYWwgc2VydmljZSBtb25p dG9yaW5nLiBUaHVzLCB0aGUgVFdBTVAgdGVzdCBwcm9kdWNlcyBpbnN0YW5jZXMgb2YgbWV0cmlj cyBmb3IgYW4gdW5zcGVjaWZpZWQgYW1vdW50IG9mIHRpbWUgLSB0eXBpY2FsbHkgdW50aWwgYSB1 c2VyIG1hbnVhbGx5IHN0b3BzIHRoZSB0ZXN0Lg0KDQoNCg0KSW4gc3VtbWFyeSwgZnJvbSBteSBw ZXJzcGVjdGl2ZSwgdGhlIGR1cmF0aW9uIG9mIHRoZSB0ZXN0IGlzIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoZSBtZXRyaWMgZGVmaW5pdGlvbi4uLi5idXQgbWF5YmUgSSBqdXN0IGRvbid0IHVuZGVy c3RhbmQgdGhlIG1ldHJpYyBkZWZpbml0aW9uIHdlbGwgZW5vdWdoLg0KDQoNCg0KUm9uDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCk9uIFN1biwgQXByIDE3LCAyMDE2IGF0IDk6MTkgUE0sIENh cmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKSA8dGltb3RoeS5jYXJleUBub2tpYS5jb208bWFpbHRv OnRpbW90aHkuY2FyZXlAbm9raWEuY29tPj4gd3JvdGU6DQpSb24sDQoNClRoYW5rcyBmb3IgbG9v a2luZyBhdCB0aGlzLg0KV2hlbiBJIGRpc2N1c3NlZCB0aGlzIHdpdGggQWwgaW5kaWNhdGVkIHRo YXQgdGhlc2Ugd291bGQgYmUgcGFydCBvZiB0aGUgbWV0cmljL2FjdGlvbiBkZWZpbml0aW9uLg0K DQpCdXQgaWYgd2Ugd291bGQgd2FudCB0byBkZWZpbmUgYSBub24tbWV0cmljIHNwZWNpZmljIGR1 cmF0aW9uIGF0dHJpYnV0ZSBvZiBhbiBpbmRpdmlkdWFsIGFjdGlvbiB3aXRoaW4gdGhlIGNvbnRl eHQgb2YgdGhlIG92ZXJhbGwgc2NoZWR1bGUgKEkgYmVsaWV2ZSB0aGlzIGlzIHdoYXQgeW91IGFy ZSByZXF1ZXN0aW5nPykgdGhlbiB3ZSBzaG91bGQgYXNzaWduIHRoYXQgZHVyYXRpb24gdGhhdCBy ZXN1bHRzIGluIChUNCkgdG8gdGhlIGFjdGlvbi4gQWN0dWFsbHkgeW91IGhhdmUgdGhlIHNhbWUg cHJvYmxlbSB3aXRoIFQyIOKAkyB3aXRoaW4gdGhlIGNvbnRleHQgYWN0aW9uIOKAkyB0aGlzIG9m ZnNldCBpZiBuZWNlc3NhcnkgaXMgZGlmZmVyZW50IGZyb20gdGhlIHNjaGVkdWxlIHN0YXJ0IHJh bmRvbW5lc3MgKG9uY2UgdGhlIHByb2Nlc3Mgc3RhcnRzIGhvdyBsb25nIHRvIHdhaXQgYmVmb3Jl IHRoZSBiaXRzIGhpdCB0aGUgd2lyZSkuICBNYXliZSB0aGF0IGlzIHdoYXQgd2UgYXJlIG1pc3Np bmcg4oCTIEEgdGltZXIgZm9yIGFuIGFjdGlvbiB3aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhlIHNj aGVkdWxl4oCmDQoNCkNvbW1lbnRzPw0KDQpGcm9tOiBFWFQgUm9uIFN0YW5hIFttYWlsdG86cm9u LnN0YW5hQHZpYXZpc29sdXRpb25zLmNvbTxtYWlsdG86cm9uLnN0YW5hQHZpYXZpc29sdXRpb25z LmNvbT5dDQpTZW50OiBTdW5kYXksIEFwcmlsIDE3LCAyMDE2IDY6MzUgUE0NClRvOiBDYXJleSwg VGltb3RoeSAoTm9raWEgLSBVUykNCkNjOiBsbWFwQGlldGYub3JnPG1haWx0bzpsbWFwQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtsbWFwXSBMTUFQOiBEZWZpbmluZyB0aGUgU2NoZWR1bGUncyBl dmVudHMNCg0KVGltLA0KDQpJdCBhcHBlYXJzIHlvdSBhcmUgbWFraW5nIGFuIGFzc3VtcHRpb24g dGhhdCBlYWNoIGFjdGlvbiB3aWxsIGVuZCBvbiBpdHMgb3duIChUNCkuICBXaGlsZSB0aGF0IGlz IHRydWUgZm9yIHR1cm4tdXAgdGVzdHMgbGlrZSBSRkMtMjU0NCBhbmQgWS4xNTY0LCBsb25nIHRl cm0gcGVyZm9ybWFuY2UgbW9uaXRvcmluZyB0ZXN0cyBsaWtlIFRXQU1QIGFuZCBZLjE3MzEgYXJl IGV4cGVjdGVkIHRvIHByb2R1Y2UgcmVzdWx0cyAyNC83IGFuZCBzbyBkbyBub3QgaGF2ZSBhIGRl ZmluZWQgZW5kIHRpbWUuICBUaGV5IGFyZSBjb25maWd1cmVkIHdpdGggYSByYXRlIHRvIHNlbmQg cGFja2V0cywgdGhlIE1BIG1lYXN1cmVzIEZELCBGRFYgYW5kIEZMUiBhbmQgdGhlbiB0aGUgTUEg cGVyaW9kaWNhbGx5IGFnZ3JlZ2F0ZXMgdGhlc2Ugc3RhdHMgYW5kIHNlbmRzIHRoZW0gdG8gdGhl IGNvbGxlY3Rvci4gIFRoZSBhZ2dyZWdhdGlvbiByYXRlIGlzIHR5cGljYWxseSAxLCA1IG9yIDE1 IG1pbnV0ZXMgc28gcmVwb3J0cyBjb250YWluIHJvbGxpbmcgc3RhcnQvZW5kIHRpbWVzIGFzIHRo ZSB0ZXN0IGV4ZWN1dGVzLg0KDQpXaGlsZSB3aGF0IEkgZGVzY3JpYmUgYWJvdmUgaXMgdGhlIHR5 cGljYWwgdXNlIGNhc2UsIHRoZXJlIGFyZSBvdGhlciBzY2VuYXJpb3Mgd2hlcmUgdGhlc2Ugc2Ft ZSB0ZXN0cyBjYW4gYmUgY29uZmlndXJlZCB0byBlbXVsYXRlIHNob3J0IHJhbmRvbSBidXJzdHMu IEluIHRoaXMgc2NlbmFyaW8gdGhlIHRlc3RzIG5lZWQgdG8gYmUgY29uZmlndXJlZCB3aXRoIGFu IGluaXRpYWwgc3RhcnQgdGltZSwgYW4gaW50ZXJ2YWwgdG8gcmVzdGFydCB0aGUgdGVzdCwgYSBy YW5kb20gc3RhcnQgb2Zmc2V0IGFuZCBhIGR1cmF0aW9uLiAgRm9yIGV4YW1wbGUsIHN0YXJ0IGF0 IDE6MDAgdG9kYXksIHJlc3RhcnQgZXZlcnkgNSBtaW51dGVzIHRoZXJlYWZ0ZXIsIGVhY2ggcnVu IHNob3VsZCBiZSBvZmZzZXQgYnkgYSByYW5kb20gdmFsdWUgd2l0aGluIDQgbWludXRlcyBhbmQg ZWFjaCBydW4gc2hvdWxkIHNlbmQgdGhlIGRhdGEgZmxvd3MgZm9yIDEgbWludXRlLiAgSSB0aGlu ayB0aGUgb25seSBwYXJ0IG9mIHRoaXMgTE1BUCBkaWQgbm90IGRlZmluZSB3YXMgdGhlIGxhc3Qg cGFyYW1ldGVyIC0gdGhlIHRlc3QgZHVyYXRpb24uIFdoaWxlIGVhY2ggdGVzdCBjb3VsZCBvZmZl ciB0ZXN0LXNwZWNpZmljIHBhcmFtZXRlcnMgdG8gZGVmaW5lIGl0cyBkdXJhdGlvbiwgSSB0aG91 Z2h0IHRoZSBwcm9wb3NhbCB0byBhZGQgdGhlICdlbmQnIG9iamVjdCB3YXMgdG8gcHJvdmlkZSBh IGNvbW1vbiBhcHByb2FjaCBmb3IgdGhpcy4NCg0KUm9uDQoNCk9uIEZyaSwgQXByIDgsIDIwMTYg YXQgODo1MiBBTSwgQ2FyZXksIFRpbW90aHkgKE5va2lhIC0gVVMpIDx0aW1vdGh5LmNhcmV5QG5v a2lhLmNvbTxtYWlsdG86dGltb3RoeS5jYXJleUBub2tpYS5jb20+PiB3cm90ZToNClRlYW0sDQoN CkluIHRoZSBJRVRGIzk1IExNQVAgc2Vzc2lvbiB3ZSBoYWQgYSBkaXNjdXNzaW9uIG9uIHRoZSBu ZWVkIGZvciB0aGUgbmV3IHBhcmFtZXRlcnMgZm9yIHRoZSBtYS1zY2hlZHVsZS1lbmQgYW5kIG1h LXNjaGVkdWxlLWR1cmF0aW9uIHBhcmFtZXRlcnMsIGdpdmVuIHRoYXQgdGhlIG1hLXNjaGVkdWxl LXN0YXJ0ICh3aGljaCBpcyB0eXBlZCBhcyBhbiBldmVudCkNCg0KV2Ugc2FpZCB3ZSB3b3VsZCBz aG93IHRoYXQgdGhlc2UgcGFyYW1ldGVycyB3ZXJlIG5vdCBuZWVkZWQgdXNpbmcgYW4gZXhhbXBs ZSDigJMgc28gaGVyZSBnb2VzLg0KDQpMZXRzIGFzc3VtZSB3ZSBoYXZlIGEgc2NoZWR1bGUgbWFk ZSB1cCBvZiAyIGFjdGlvbnMgKEExLCBBMikgaW4gcGlwZWxpbmUgbW9kZS4gVGhlIG1hLXNjaGVk dWxlLXN0YXJ0IHdvdWxkIGhhcyBhIHBlcmlvZGljIGV2ZW50Og0KDQpTdGFydCBBcHJpbCAxLCAy MDE2IGF0IDAyOjAwOjAwDQoNCkVuZCBNYXkgMSwgMjAxNiBhdCAwMjowMDowMA0KDQpJbnRlcnZh bCA4Niw0MDAgKGRhaWx5KQ0KDQpSYW5kb21uZXNzIDM2MDAgKHdpdGhpbiB0aGUgaG91cikNCg0K U28gdGhlIHNjaGVkdWxlIHdpbGwgcmVvY2N1ciBldmVyeSBkYXkgc3RhcnRpbmcgb24gQXByaWwg MSBiZWdpbm5pbmcgYXQgMjowMHBtLiAoVDApIFRoZSBzdGFydGluZyBwZXJpb2Qgd2lsbCBiZSBy YW5kb20gYmV0d2VlbiAyOjAwYW0gYW5kIDM6MDBhbS4gKFQxKSBUaGlzIGRlZmluaXRpb24gaXMg c3VmZmljaWVudCBmb3IgaW52b2tpbmcgQTEgKFQxKSBhbmQgaXMgd2hhdCBBbCBjb25zaWRlcnMg YXMgQmx1ZSB0aW1lcy4NCg0KQXMgQTEgcGVyZm9ybXMgYSB0ZXN0IEExIHBsYWNlcyBiaXRzIG9u IHRoZSB3aXJlIChUMikgYW5kIGNvbGxlY3RzIHJlc3VsdHMgKFQzKS4NCldoZW4gQTEgY29tcGxl dGVzIChUNCksIEEyIGlzIGludm9rZWQgKFQ1KSB3aGljaCBwbGFjZXMgYml0cyBvbiBhIHdpcmUg Zm9yIEEyIChUMikgYW5kIGNvbGxlY3RzIHJlc3VsdHMgKFQzKSkuIEZpbmFsbHkgdGhlIHJlc3Vs dHMgZnJvbSB0aGUgc2NoZWR1bGUgYXJlIHJlcG9ydGVkIChUNikuDQoNClQyJlQzOiBBbCBjb25z aWRlcnMgdGhpcyB0aW1lIHRvIGJlIHBhcnQgb2YgdGhlIGRlZmluaXRpb24gb2YgdGhlIG1ldHJp YyBhbmQgYXJlIHJlcG9ydGVkIGFzIHBhcnQgb2YgdGhlIHJlc3VsdCBjb250ZW50IChub3QgYXMg YW4gYWN0dWFsIHBhcmFtZXRlcikuIFRoaXMgd2FzIGhpcyBSZWQgdGltZQ0KDQpUNCZUNTogQXJl IHRoZSBtYS1yZXBvcnQtW3N0YXJ0fGVuZF0tdGltZQ0KVDY6IElzIHRoZSBtYS1yZXBvcnQtZGF0 ZQ0KDQpBcyBzdWNoIOKAkyBBcyBsb25nIGFzIGFuIEV2ZW50IGhhcyBhIGRlZmluZWQgb2NjdXJy ZW5jZSAoVDE9VDAgKyByYW5kb21uZXNzKSBhbGwgdGhhdCBpcyBuZWNlc3NhcnkgaXMgYSBzaW5n bGUgcGFyYW1ldGVyIHRvIGRlZmluZSB0aGUgb2NjdXJyZW5jZS4NCg0KUXVlc3Rpb25zPw0KDQpC UiwNClRpbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbG1hcCBtYWlsaW5nIGxpc3QNCmxtYXBAaWV0Zi5vcmc8bWFpbHRvOmxtYXBAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXANCg0KDQo= --_000_4AF73AA205019A4C8A1DDD32C034631D4587DEFEC7NJFPSRVEXG0re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwg bGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25z b2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBs ZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+ SGkgUm9uIGFuZCBUaW0sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2Nv bG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6YmxhY2snPnRyeWluZyB0byBtYWtlIGEgZmV3IG1pbnV0ZXMgZm9yIHRoaXMuLi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+VGhlIFJl Z2lzdHJ5IEVudHJpZXMqIGZvciB0aGUgTWV0cmljcyBpbmNsdWRlIFJ1bi10aW1lIFBhcmFtZXRl cnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPmZv ciB0aGUgU3RhcnQgdGltZSBhbmQgRW5kIFRpbWUsIGJ1dCBvbmUgb2YgdGhlbSBjb3VsZCBiZSBp bnRlcnByZXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpi bGFjayc+YXMgYSBEdXJhdGlvbiBpZiBzcGVjaWZpZWQgY29ycmVjdGx5ICh0aGUgU3RhcnQgdGlt ZSBtdXN0IGJlIGFsbCB6ZXJvcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7Y29sb3I6YmxhY2snPnRoZW4gdGhlIFN0b3AgdGltZSBpcyBpbnRlcnByZXRlZCBhcyBhIGR1 cmF0aW9uLCBBTkQgdGhlIGFjdHVhbCBzdGFydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+YW5kIHN0b3AgdGltZSBhcmUgY29udHJvbGxlZCB0aHJv dWdoIOKAnG90aGVyIG1lYW5z4oCdKS4gU2VlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWlwcG0taW5pdGlhbC1yZWdpc3RyeS0wMCNzZWN0aW9uLTQuMy41PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPuKAnE90aGVyIG1lYW5z 4oCdIHdvdWxkIGJlIHRoZSBTY2hlZHVsZSBvYmplY3QgYW5kIHRoZSBFdmVudCBvYmplY3QuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz5BcyBJIHVu ZGVyc3RhbmQgaXQgYm90aCBzY2hlZHVsZSBhbmQgZXZlbnQgb2JqZWN0cyBoYXZlIHN0YXJ0IHRp bWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPmFu ZCBzdG9wIHRpbWUgc3BlY2lmaWNhdGlvbnMgYXZhaWxhYmxlLCBhbmQgRXZlbnQgaGFzIER1cmF0 aW9uIHNwZWNpZmljYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6YmxhY2snPmF2YWlsYWJsZSB3aGljaCB3b3VsZCBiZSB1c2VmdWwgZm9yIHJlY3Vycmlu ZyBldmVudHMgKHBlcmlvZGljIG9yIGNhbGVuZGFyKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+RXZlbnR1YWxseSwgdGhlIE1BIGhhcyB0byBy ZXBvcnQgdGhlIHJlc3VsdHMgb2YgdGhlIG1ldHJpYy9tZWFzdXJlbWVudC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPlRoYXTigJlzIHdoZW4gdGhl IGFjdHVhbCAoUkVEKSBzdGFydCBhbmQgZW5kIHRpbWVzIHdoZW4gcGFja2V0cyB3ZXJlIGFjdHVh bGx5PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz5m bG93aW5nIGJldHdlZW4gbWVhc3VyZW1lbnQgcG9pbnRzIGFyZSByZXBvcnRlZCwgYWNjb3JkaW5n IHRvIHRoZSBSZWdpc3RyeSBFbnRyeS4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciO2NvbG9yOmJsYWNrJz5TZWU6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7Y29sb3I6YmxhY2snPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWlwcG0taW5pdGlhbC1yZWdpc3RyeS0wMCNzZWN0aW9uLTQuNC4yIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLWluaXRpYWwtcmVnaXN0cnkt MDAjc2VjdGlvbi00LjQuMjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijtjb2xvcjpibGFjayc+QXMgSSBzYWlkIGF0IHRoZSBtZWV0aW5nLCBpdCB3b3VsZCBiZSBn b29kIHRvIGxvb2sgYXQgc29tZSBleGFtcGxlcyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHByZT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayc+d2hpY2ggYXR0ZW1wdCB0 byBzY2hlZHVsZSB0aGUg4oCcQWN0X0lQX1VEUF9Sb3VuZC10cmlwX0RlbGF5X1BvaXNzb25fOTV0 aC1wZXJjZW50aWxl4oCdPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayc+cmVnaXN0cnkgZW50cnksIGFzIGEgUGVyaW9k aWMgZXZlbnQsIGEgb25lLXRpbWUgZXZlbnQsIGFuZCBhIGNvbnRpbnVvdXMgPG86cD48L286cD48 L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFj ayc+ZXZlbnQgYXMgUm9uIGlzIHN1Z2dlc3RpbmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+PHBy ZT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xv cjpibGFjayc+cmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrJz5BbDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPiogTm90ZSB0aGF0IHRoZSBSZWdpc3Ry eSBFbnRyeSBmb3IgYSBNZXRyaWMgaW5jbHVkZXMgdGhlIE1ldHJpYyBEZWZpbml0aW9uLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+dGhlIG1ldGhv ZCBvZiBtZWFzdXJlbWVudCwgYW5kIFJ1bi10aW1lIHBhcmFtZXRlcnMuPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPiBSb24gU3RhbmEgW21haWx0bzpyb24uc3RhbmFAdmlhdmlzb2x1dGlvbnMuY29tXSA8YnI+ PGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMTgsIDIwMTYgOTo0MCBBTTxicj48Yj5Ubzo8L2I+ IENhcmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKTxicj48Yj5DYzo8L2I+IGxtYXBAaWV0Zi5vcmc7 IE1PUlRPTiwgQUxGUkVEIEMgKEFMKTxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtsbWFwXSBMTUFQ OiBEZWZpbmluZyB0aGUgU2NoZWR1bGUncyBldmVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPlRpbSw8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGUg ZXhhY3QgZGVmaW5pdGlvbiBvZiB0aGUgbWV0cmljIGlzIHN0aWxsIHVuY2xlYXIgdG8gbWUgc2lu Y2UgSSBoYXZlIG5vdCBzZWVuIGFuIGV4YW1wbGUgb2YgYSB0ZXN0IHdpdGggYXZlcmFnZSBjb21w bGV4aXR5IHVzaW5nIG1ldHJpY3Mgd2l0aCBMTUFQIGZyb20gYmVnaW5uaW5nIHRvIGVuZC4mbmJz cDsgQnkgYXZlcmFnZSBjb21wbGV4aXR5IEkgbWVhbiBhIHRlc3QgdGhhdCBhbGxvd3MgaW5kZXBl bmRlbnQgY29uZmlndXJhdGlvbiBvZiBtdWx0aXBsZSBzaW11bHRhbmVvdXMgZGF0YSBmbG93cyBh bmQgcHJvZHVjZXMgbXVsdGlwbGUgcmVwb3J0IGZvcm1hdHMgZHVyaW5nIHRoZSB0ZXN0IGR1cmF0 aW9uLiBUaGUgdGVzdHMgSSBtZW50aW9uZWQgcHJldmlvdXNseSAoUkZDLTI1NDQsIFkuMTU2NCwg WS4xNzMxIGFuZCBUV0FNUCkgbWluaW1hbGx5IHJlcXVpcmUgdGhpcyB0eXBlIG9mIHN1cHBvcnQg YW5kIGFyZSB0aGUgbWFpbiB0ZXN0cyB1c2VkIGluIEV0aGVybmV0IHNlcnZpY2UgdGVzdGluZyB0 b2RheS4mbmJzcDsgTm9uZS10aGUtbGVzcywgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgbWV0cmlj IGlzIHRoYXQgaXQgZGVmaW5lcyB0aGUgZm9ybWF0IG9mIHRoZSBwYWNrZXQgc3RyZWFtIGFuZCB0 aGUgbWV0aG9kb2xvZ3kgb2YgdGhlIHRyYW5zbWl0IGZyZXF1ZW5jeS4gVGhlc2UgYXJlIHR3byBl eGFtcGxlcyBmcm9tJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtaXBwbS1pbml0aWFsLXJlZ2lzdHJ5LTAwIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1pcHBtLWluaXRpYWwtcmVnaXN0cnktMDA8L2E+Jm5ic3A7PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGRpdj48cHJlPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+QWN0X0lQX1VEUF9Q b2lzc29uX1VEUC1QYXlsb2FkLTI1MF9PbmUtd2F5X0RlbGF5X1N0ZF9EZXY8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+QWN0X0lQX1VEUF9QZXJp b2RpYy12YXJfVURQLVBheWxvYWQtMTQyX09uZS13YXlfRGVsYXlfTWVhbjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIic+SXQgZG9lcyBub3QgYXBwZWFyIHRvIGRlZmluZSB0aGUgdGltZSBwZXJpb2Qgb3Zl ciB3aGljaCB0aGUgbWVhc3VyZW1lbnQgd2FzIHRha2VuLsKgIFRoaXMgaXMgZ29vZCBiZWNhdXNl IGZvciBtb3N0IHRlc3RzIHRoZSBtZWFzdXJlbWVudCBwZXJpb2QgaXMgYSB1c2VyIGRlZmluZWQg aW5wdXQgcGFyYW1ldGVyLsKgIFBlcmZvcm1hbmNlIG1vbml0b3JpbmcgdGVzdHMgd2lsbCByZXBv cnQgdGhlIG1ldHJpYyByZXBlYXRlZGx5IGR1cmluZyB0aGUgdGVzdCBleGVjdXRpb24uwqAgUmVm ZXJyaW5nIHRvIHRoZSBleGFtcGxlIGluIG15IHByaW9yIGVtYWlsLCBhIFRXQU1QIHRlc3Qgd291 bGQgcHJvZHVjZSBhIGdyb3VwIG9mIG1ldHJpY3MgZm9yIGVhY2ggZGF0YSBzdHJlYW0gZXZlcnkg MSwgNSBvciAxNSBtaW51dGVzIGRlcGVuZGluZyBvbiB0aGUgdGVzdCBjb25maWd1cmF0aW9uLiBJ dCBpcyBwb3NzaWJsZSB0aGUgdGVzdCBjb3VsZCBiZSBjb25maWd1cmVkIHRvIHByb2R1Y2UgbXVs dGlwbGUgcmVwb3J0cyAtIGZvciBleGFtcGxlIGF0IGEgc2hvcnQgaW50ZXJ2YWwgZm9yIHRyb3Vi bGVzaG9vdGluZyBpbiBhZGRpdGlvbiB0byBvbmUgb2YgdGhlIGludGVydmFscyBwcmV2aW91c2x5 IG1lbnRpb25lZCBmb3IgZ2VuZXJhbCBzZXJ2aWNlIG1vbml0b3JpbmcuIFRodXMsIHRoZSBUV0FN UCB0ZXN0IHByb2R1Y2VzIGluc3RhbmNlcyBvZiBtZXRyaWNzIGZvciBhbiB1bnNwZWNpZmllZCBh bW91bnQgb2YgdGltZSAtIHR5cGljYWxseSB1bnRpbCBhIHVzZXIgbWFudWFsbHkgc3RvcHMgdGhl IHRlc3QuICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+SW4gc3VtbWFyeSwgZnJvbSBteSBwZXJzcGVjdGl2ZSwgdGhlIGR1cmF0aW9uIG9mIHRoZSB0 ZXN0IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBtZXRyaWMgZGVmaW5pdGlvbi4uLi5idXQg bWF5YmUgSSBqdXN0IGRvbid0IHVuZGVyc3RhbmQgdGhlIG1ldHJpYyBkZWZpbml0aW9uIHdlbGwg ZW5vdWdoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT48cHJlPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Um9u PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+IDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIFN1biwgQXByIDE3LCAyMDE2 IGF0IDk6MTkgUE0sIENhcmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKSAmbHQ7PGEgaHJlZj0ibWFp bHRvOnRpbW90aHkuY2FyZXlAbm9raWEuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGltb3RoeS5jYXJl eUBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Sb24sPC9zcGFuPjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+VGhhbmtzIGZvciBsb29raW5nIGF0IHRoaXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2hlbiBJIGRpc2N1 c3NlZCB0aGlzIHdpdGggQWwgaW5kaWNhdGVkIHRoYXQgdGhlc2Ugd291bGQgYmUgcGFydCBvZiB0 aGUgbWV0cmljL2FjdGlvbiBkZWZpbml0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkJ1dCBp ZiB3ZSB3b3VsZCB3YW50IHRvIGRlZmluZSBhIG5vbi1tZXRyaWMgc3BlY2lmaWMgZHVyYXRpb24g YXR0cmlidXRlIG9mIGFuIGluZGl2aWR1YWwgYWN0aW9uIHdpdGhpbiB0aGUgY29udGV4dCBvZiB0 aGUgb3ZlcmFsbCBzY2hlZHVsZSAoSSBiZWxpZXZlIHRoaXMgaXMgd2hhdCB5b3UgYXJlIHJlcXVl c3Rpbmc/KSB0aGVuIHdlIHNob3VsZCBhc3NpZ24gdGhhdCBkdXJhdGlvbiB0aGF0IHJlc3VsdHMg aW4gKFQ0KSB0byB0aGUgYWN0aW9uLiBBY3R1YWxseSB5b3UgaGF2ZSB0aGUgc2FtZSBwcm9ibGVt IHdpdGggVDIg4oCTIHdpdGhpbiB0aGUgY29udGV4dCBhY3Rpb24g4oCTIHRoaXMgb2Zmc2V0IGlm IG5lY2Vzc2FyeSBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgc2NoZWR1bGUgc3RhcnQgcmFuZG9tbmVz cyAob25jZSB0aGUgcHJvY2VzcyBzdGFydHMgaG93IGxvbmcgdG8gd2FpdCBiZWZvcmUgdGhlIGJp dHMgaGl0IHRoZSB3aXJlKS4mbmJzcDsgTWF5YmUgdGhhdCBpcyB3aGF0IHdlIGFyZSBtaXNzaW5n IOKAkyBBIHRpbWVyIGZvciBhbiBhY3Rpb24gd2l0aGluIHRoZSBjb250ZXh0IG9mIHRoZSBzY2hl ZHVsZeKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNvbW1lbnRzPzwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gRVhUIFJvbiBTdGFu YSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpyb24uc3RhbmFAdmlhdmlzb2x1dGlvbnMuY29tIiB0 YXJnZXQ9Il9ibGFuayI+cm9uLnN0YW5hQHZpYXZpc29sdXRpb25zLmNvbTwvYT5dIDxicj48Yj5T ZW50OjwvYj4gU3VuZGF5LCBBcHJpbCAxNywgMjAxNiA2OjM1IFBNPGJyPjxiPlRvOjwvYj4gQ2Fy ZXksIFRpbW90aHkgKE5va2lhIC0gVVMpPGJyPjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmxt YXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sbWFwQGlldGYub3JnPC9hPjxicj48Yj5TdWJq ZWN0OjwvYj4gUmU6IFtsbWFwXSBMTUFQOiBEZWZpbmluZyB0aGUgU2NoZWR1bGUncyBldmVudHM8 L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86 cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5UaW0sPG86cD48L286cD48L3A+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPkl0IGFwcGVhcnMgeW91IGFyZSBtYWtpbmcgYW4gYXNzdW1w dGlvbiB0aGF0IGVhY2ggYWN0aW9uIHdpbGwgZW5kIG9uIGl0cyBvd24gKFQ0KS4mbmJzcDsgV2hp bGUgdGhhdCBpcyB0cnVlIGZvciB0dXJuLXVwIHRlc3RzIGxpa2UgUkZDLTI1NDQgYW5kIFkuMTU2 NCwgbG9uZyB0ZXJtIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcgdGVzdHMgbGlrZSBUV0FNUCBhbmQg WS4xNzMxIGFyZSBleHBlY3RlZCB0byBwcm9kdWNlIHJlc3VsdHMgMjQvNyBhbmQgc28gZG8gbm90 IGhhdmUgYSBkZWZpbmVkIGVuZCB0aW1lLiZuYnNwOyBUaGV5IGFyZSBjb25maWd1cmVkIHdpdGgg YSByYXRlIHRvIHNlbmQgcGFja2V0cywgdGhlIE1BIG1lYXN1cmVzIEZELCBGRFYgYW5kIEZMUiBh bmQgdGhlbiB0aGUgTUEgcGVyaW9kaWNhbGx5IGFnZ3JlZ2F0ZXMgdGhlc2Ugc3RhdHMgYW5kIHNl bmRzIHRoZW0gdG8gdGhlIGNvbGxlY3Rvci4mbmJzcDsgVGhlIGFnZ3JlZ2F0aW9uIHJhdGUgaXMg dHlwaWNhbGx5IDEsIDUgb3IgMTUgbWludXRlcyBzbyByZXBvcnRzIGNvbnRhaW4gcm9sbGluZyBz dGFydC9lbmQgdGltZXMgYXMgdGhlIHRlc3QgZXhlY3V0ZXMuPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPldoaWxlIHdoYXQgSSBkZXNjcmliZSBhYm92ZSBpcyB0aGUg dHlwaWNhbCB1c2UgY2FzZSwgdGhlcmUgYXJlIG90aGVyIHNjZW5hcmlvcyB3aGVyZSB0aGVzZSBz YW1lIHRlc3RzIGNhbiBiZSBjb25maWd1cmVkIHRvIGVtdWxhdGUgc2hvcnQgcmFuZG9tIGJ1cnN0 cy4gSW4gdGhpcyBzY2VuYXJpbyB0aGUgdGVzdHMgbmVlZCB0byBiZSBjb25maWd1cmVkIHdpdGgg YW4gaW5pdGlhbCBzdGFydCB0aW1lLCBhbiBpbnRlcnZhbCB0byByZXN0YXJ0IHRoZSB0ZXN0LCBh IHJhbmRvbSBzdGFydCBvZmZzZXQgYW5kIGEgZHVyYXRpb24uJm5ic3A7IEZvciBleGFtcGxlLCBz dGFydCBhdCAxOjAwIHRvZGF5LCByZXN0YXJ0IGV2ZXJ5IDUgbWludXRlcyB0aGVyZWFmdGVyLCBl YWNoIHJ1biBzaG91bGQgYmUgb2Zmc2V0IGJ5IGEgcmFuZG9tIHZhbHVlIHdpdGhpbiA0IG1pbnV0 ZXMgYW5kIGVhY2ggcnVuIHNob3VsZCBzZW5kIHRoZSBkYXRhIGZsb3dzIGZvciAxIG1pbnV0ZS4m bmJzcDsgSSB0aGluayB0aGUgb25seSBwYXJ0IG9mIHRoaXMgTE1BUCBkaWQgbm90IGRlZmluZSB3 YXMgdGhlIGxhc3QgcGFyYW1ldGVyIC0gdGhlIHRlc3QgZHVyYXRpb24uIFdoaWxlIGVhY2ggdGVz dCBjb3VsZCBvZmZlciB0ZXN0LXNwZWNpZmljIHBhcmFtZXRlcnMgdG8gZGVmaW5lIGl0cyBkdXJh dGlvbiwgSSB0aG91Z2h0IHRoZSBwcm9wb3NhbCB0byBhZGQgdGhlICdlbmQnIG9iamVjdCB3YXMg dG8gcHJvdmlkZSBhIGNvbW1vbiBhcHByb2FjaCBmb3IgdGhpcy48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Um9uPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPk9uIEZyaSwgQXByIDgsIDIwMTYgYXQgODo1MiBBTSwgQ2FyZXksIFRpbW90 aHkgKE5va2lhIC0gVVMpICZsdDs8YSBocmVmPSJtYWlsdG86dGltb3RoeS5jYXJleUBub2tpYS5j b20iIHRhcmdldD0iX2JsYW5rIj50aW1vdGh5LmNhcmV5QG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5UZWFtLDxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPkluIHRoZSBJRVRGIzk1IExNQVAgc2Vzc2lvbiB3ZSBoYWQgYSBkaXNj dXNzaW9uIG9uIHRoZSBuZWVkIGZvciB0aGUgbmV3IHBhcmFtZXRlcnMgZm9yIHRoZSBtYS1zY2hl ZHVsZS1lbmQgYW5kIG1hLXNjaGVkdWxlLWR1cmF0aW9uIHBhcmFtZXRlcnMsIGdpdmVuIHRoYXQg dGhlIG1hLXNjaGVkdWxlLXN0YXJ0ICh3aGljaCBpcyB0eXBlZCBhcyBhbiBldmVudCkgPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+V2Ugc2FpZCB3ZSB3b3VsZCBzaG93IHRoYXQgdGhlc2UgcGFyYW1ldGVy cyB3ZXJlIG5vdCBuZWVkZWQgdXNpbmcgYW4gZXhhbXBsZSDigJMgc28gaGVyZSBnb2VzLjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPkxldHMgYXNzdW1lIHdlIGhhdmUgYSBzY2hlZHVsZSBtYWRlIHVwIG9m IDIgYWN0aW9ucyAoQTEsIEEyKSBpbiBwaXBlbGluZSBtb2RlLiBUaGUgbWEtc2NoZWR1bGUtc3Rh cnQgd291bGQgaGFzIGEgcGVyaW9kaWMgZXZlbnQ6IDxvOnA+PC9vOnA+PC9wPjxwIHN0eWxlPSdt YXJnaW4tbGVmdDoyMC4yNXB0Jz5TdGFydCBBcHJpbCAxLCAyMDE2IGF0IDAyOjAwOjAwPG86cD48 L286cD48L3A+PHAgc3R5bGU9J21hcmdpbi1sZWZ0OjIwLjI1cHQnPkVuZCBNYXkgMSwgMjAxNiBh dCAwMjowMDowMDxvOnA+PC9vOnA+PC9wPjxwIHN0eWxlPSdtYXJnaW4tbGVmdDoyMC4yNXB0Jz5J bnRlcnZhbCA4Niw0MDAgKGRhaWx5KTxvOnA+PC9vOnA+PC9wPjxwIHN0eWxlPSdtYXJnaW4tbGVm dDoyMC4yNXB0Jz5SYW5kb21uZXNzIDM2MDAgKHdpdGhpbiB0aGUgaG91cik8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz5TbyB0aGUgc2NoZWR1bGUgd2lsbCByZW9jY3VyIGV2ZXJ5IGRheSBzdGFydGluZyBv biBBcHJpbCAxIGJlZ2lubmluZyBhdCAyOjAwcG0uIChUMCkgVGhlIHN0YXJ0aW5nIHBlcmlvZCB3 aWxsIGJlIHJhbmRvbSBiZXR3ZWVuIDI6MDBhbSBhbmQgMzowMGFtLiAoVDEpIFRoaXMgZGVmaW5p dGlvbiBpcyBzdWZmaWNpZW50IGZvciBpbnZva2luZyBBMSAoVDEpIGFuZCBpcyB3aGF0IEFsIGNv bnNpZGVycyBhcyBCbHVlIHRpbWVzLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8n PiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPkFzIEExIHBlcmZvcm1z IGEgdGVzdCBBMSBwbGFjZXMgYml0cyBvbiB0aGUgd2lyZSAoVDIpIGFuZCBjb2xsZWN0cyByZXN1 bHRzIChUMykuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+V2hlbiBBMSBjb21w bGV0ZXMgKFQ0KSwgQTIgaXMgaW52b2tlZCAoVDUpIHdoaWNoIHBsYWNlcyBiaXRzIG9uIGEgd2ly ZSBmb3IgQTIgKFQyKSBhbmQgY29sbGVjdHMgcmVzdWx0cyAoVDMpKS4gRmluYWxseSB0aGUgcmVz dWx0cyBmcm9tIHRoZSBzY2hlZHVsZSBhcmUgcmVwb3J0ZWQgKFQ2KS48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz5UMiZhbXA7VDM6IEFsIGNvbnNpZGVycyB0aGlzIHRpbWUgdG8gYmUgcGFydCBvZiB0aGUg ZGVmaW5pdGlvbiBvZiB0aGUgbWV0cmljIGFuZCBhcmUgcmVwb3J0ZWQgYXMgcGFydCBvZiB0aGUg cmVzdWx0IGNvbnRlbnQgKG5vdCBhcyBhbiBhY3R1YWwgcGFyYW1ldGVyKS4gVGhpcyB3YXMgaGlz IFJlZCB0aW1lPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+VDQmYW1wO1Q1OiBBcmUgdGhlIG1hLXJlcG9y dC1bc3RhcnR8ZW5kXS10aW1lPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+VDY6 IElzIHRoZSBtYS1yZXBvcnQtZGF0ZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8n PiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPkFzIHN1Y2gg4oCTIEFz IGxvbmcgYXMgYW4gRXZlbnQgaGFzIGEgZGVmaW5lZCBvY2N1cnJlbmNlIChUMT1UMCArIHJhbmRv bW5lc3MpIGFsbCB0aGF0IGlzIG5lY2Vzc2FyeSBpcyBhIHNpbmdsZSBwYXJhbWV0ZXIgdG8gZGVm aW5lIHRoZSBvY2N1cnJlbmNlLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZu YnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPlF1ZXN0aW9ucz88bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz5CUiw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5UaW08 bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+bG1hcCBtYWlsaW5nIGxpc3Q8 YnI+PGEgaHJlZj0ibWFpbHRvOmxtYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sbWFwQGll dGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2xtYXAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2xtYXA8L2E+PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0 bWw+ --_000_4AF73AA205019A4C8A1DDD32C034631D4587DEFEC7NJFPSRVEXG0re_-- From nobody Tue Apr 19 02:14:39 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF81812D5D0 for ; Tue, 19 Apr 2016 02:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 QTx7UT-A8pY9 for ; Tue, 19 Apr 2016 02:14:36 -0700 (PDT) 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 5B1A012D9C0 for ; Tue, 19 Apr 2016 02:14:36 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2A1818A5; Tue, 19 Apr 2016 11:14:35 +0200 (CEST) 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 2mMC33N6TgpC; Tue, 19 Apr 2016 11:14:28 +0200 (CEST) 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, 19 Apr 2016 11:14:34 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7511820046; Tue, 19 Apr 2016 11:14:34 +0200 (CEST) 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 698nfL7uRzo5; Tue, 19 Apr 2016 11:14:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02B5120047; Tue, 19 Apr 2016 11:14:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A77A43AA733C; Tue, 19 Apr 2016 11:14:32 +0200 (CEST) Date: Tue, 19 Apr 2016 11:14:32 +0200 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20160419091432.GA2698@elstar.local> Mail-Followup-To: Ron Stana , lmap@ietf.org, alissa@cooperw.in References: <20160405124838.GD58588@elstar.local> <20160405135327.GA58974@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: alissa@cooperw.in, lmap@ietf.org Subject: Re: [lmap] Learning MA Capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 09:14:38 -0000 On Tue, Apr 05, 2016 at 11:36:47PM -0400, Ron Stana wrote: > Juergen, > > Steps 4,5 & 6 are performed to learn the dynamic capabilities of the MA. > For example, when the MA is a software-only implementation, the > capabilities will vary depending on what hardware it is installed on. > Depending on the number of CPUs, type of NIC, etc the number of tests, test > options and test parameter ranges may vary. This is the type of > information that is not expected to change after the MA has been installed > but it still needs to be read at least once by the Controller. > > For support of RFC7223, are you suggesting the MA should implement an API > outside of the LMAP models to return that information? > For a YANG-based solution, RFC 7223 (and any other relevant YANG data model) leads to a well-defined way to obtain this information. There is no point in duplicating this work. /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 Apr 19 02:19:24 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9204312D10B for ; Tue, 19 Apr 2016 02:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 MCmV6ttAa1-H for ; Tue, 19 Apr 2016 02:19:20 -0700 (PDT) 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 6EFBD12B014 for ; Tue, 19 Apr 2016 02:19:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3187BE89; Tue, 19 Apr 2016 11:19:19 +0200 (CEST) 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 OIaVr8YLp63s; Tue, 19 Apr 2016 11:19:11 +0200 (CEST) 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, 19 Apr 2016 11:19:18 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0AAC920047; Tue, 19 Apr 2016 11:19:18 +0200 (CEST) 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 9NEEpgFyoYuQ; Tue, 19 Apr 2016 11:19:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1FE320046; Tue, 19 Apr 2016 11:19:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C6DE73AA740A; Tue, 19 Apr 2016 11:19:15 +0200 (CEST) Date: Tue, 19 Apr 2016 11:19:15 +0200 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20160419091915.GB2698@elstar.local> Mail-Followup-To: Ron Stana , "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A627E42@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.6.0 (2016-04-01) Archived-At: Cc: "Carey, Timothy \(Nokia - US\)" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: Defining the Schedule's events X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 09:19:23 -0000 Yes, this is the reason I added this. /js On Sun, Apr 17, 2016 at 12:34:31PM -0400, Ron Stana wrote: > Tim, > > It appears you are making an assumption that each action will end on its > own (T4). While that is true for turn-up tests like RFC-2544 and Y.1564, > long term performance monitoring tests like TWAMP and Y.1731 are expected > to produce results 24/7 and so do not have a defined end time. They are > configured with a rate to send packets, the MA measures FD, FDV and FLR and > then the MA periodically aggregates these stats and sends them to the > collector. The aggregation rate is typically 1, 5 or 15 minutes so reports > contain rolling start/end times as the test executes. > > While what I describe above is the typical use case, there are other > scenarios where these same tests can be configured to emulate short random > bursts. In this scenario the tests need to be configured with an initial > start time, an interval to restart the test, a random start offset and a > duration. For example, start at 1:00 today, restart every 5 minutes > thereafter, each run should be offset by a random value within 4 minutes > and each run should send the data flows for 1 minute. I think the only > part of this LMAP did not define was the last parameter - the test > duration. While each test could offer test-specific parameters to define > its duration, I thought the proposal to add the 'end' object was to provide > a common approach for this. > > Ron > > On Fri, Apr 8, 2016 at 8:52 AM, Carey, Timothy (Nokia - US) < > timothy.carey@nokia.com> wrote: > > > Team, > > > > > > > > In the IETF#95 LMAP session we had a discussion on the need for the new > > parameters for the ma-schedule-end and ma-schedule-duration parameters, > > given that the ma-schedule-start (which is typed as an event) > > > > > > > > We said we would show that these parameters were not needed using an > > example – so here goes. > > > > > > > > Lets assume we have a schedule made up of 2 actions (A1, A2) in pipeline > > mode. The ma-schedule-start would has a periodic event: > > > > Start April 1, 2016 at 02:00:00 > > > > End May 1, 2016 at 02:00:00 > > > > Interval 86,400 (daily) > > > > Randomness 3600 (within the hour) > > > > > > > > So the schedule will reoccur every day starting on April 1 beginning at > > 2:00pm. (T0) The starting period will be random between 2:00am and 3:00am. > > (T1) This definition is sufficient for invoking A1 (T1) and is what Al > > considers as Blue times. > > > > > > > > As A1 performs a test A1 places bits on the wire (T2) and collects results > > (T3). > > > > When A1 completes (T4), A2 is invoked (T5) which places bits on a wire for > > A2 (T2) and collects results (T3)). Finally the results from the schedule > > are reported (T6). > > > > > > > > T2&T3: Al considers this time to be part of the definition of the metric > > and are reported as part of the result content (not as an actual > > parameter). This was his Red time > > > > > > > > T4&T5: Are the ma-report-[start|end]-time > > > > T6: Is the ma-report-date > > > > > > > > As such – As long as an Event has a defined occurrence (T1=T0 + > > randomness) all that is necessary is a single parameter to define the > > occurrence. > > > > > > > > Questions? > > > > > > > > BR, > > > > Tim > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > > > > _______________________________________________ > 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 Apr 19 05:01:31 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99EC612EDC3 for ; Tue, 19 Apr 2016 05:01:28 -0700 (PDT) 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 autolearn_force=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 oLrS9JYaUXHg for ; Tue, 19 Apr 2016 05:01:26 -0700 (PDT) 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 B421A12ED4A for ; Tue, 19 Apr 2016 05:01:25 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 460ECEAED2E6C; Tue, 19 Apr 2016 12:01:22 +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 u3JC1Npo001289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Apr 2016 12:01:24 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u3JC1NnA015127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Apr 2016 12:01:23 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 19 Apr 2016 08:01:23 -0400 From: "Carey, Timothy (Nokia - US)" To: "EXT MORTON, ALFRED C (AL)" , Ron Stana Thread-Topic: [lmap] LMAP: Defining the Schedule's events Thread-Index: AQHRmMcIsS7v7zskLkW09Igh4D3XRZ+O62+QgAEVwQCAABu1AIABEw7w Date: Tue, 19 Apr 2016 12:01:25 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6347A3@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A627E42@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77012A631C28@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4587DEFEC7@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D4587DEFEC7@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.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A6347A3US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: Defining the Schedule's events X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 12:01:28 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A6347A3US70UWXCHMBA0_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWwsDQpJbmxpbmUgPFRBQz4NCg0KRnJvbTogRVhUIE1PUlRPTiwgQUxGUkVEIEMgKEFMKSBbbWFp bHRvOmFjbW9ydG9uQGF0dC5jb21dDQpTZW50OiBNb25kYXksIEFwcmlsIDE4LCAyMDE2IDU6MTkg UE0NClRvOiBSb24gU3RhbmE7IENhcmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKQ0KQ2M6IGxtYXBA aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbbG1hcF0gTE1BUDogRGVmaW5pbmcgdGhlIFNjaGVkdWxl J3MgZXZlbnRzDQoNCkhpIFJvbiBhbmQgVGltLA0KDQp0cnlpbmcgdG8gbWFrZSBhIGZldyBtaW51 dGVzIGZvciB0aGlzLi4uDQoNClRoZSBSZWdpc3RyeSBFbnRyaWVzKiBmb3IgdGhlIE1ldHJpY3Mg aW5jbHVkZSBSdW4tdGltZSBQYXJhbWV0ZXJzDQpmb3IgdGhlIFN0YXJ0IHRpbWUgYW5kIEVuZCBU aW1lLCBidXQgb25lIG9mIHRoZW0gY291bGQgYmUgaW50ZXJwcmV0ZWQNCmFzIGEgRHVyYXRpb24g aWYgc3BlY2lmaWVkIGNvcnJlY3RseSAodGhlIFN0YXJ0IHRpbWUgbXVzdCBiZSBhbGwgemVyb3Ms DQp0aGVuIHRoZSBTdG9wIHRpbWUgaXMgaW50ZXJwcmV0ZWQgYXMgYSBkdXJhdGlvbiwgQU5EIHRo ZSBhY3R1YWwgc3RhcnQNCmFuZCBzdG9wIHRpbWUgYXJlIGNvbnRyb2xsZWQgdGhyb3VnaCDigJxv dGhlciBtZWFuc+KAnSkuIFNlZQ0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1pcHBtLWluaXRpYWwtcmVnaXN0cnktMDAjc2VjdGlvbi00LjMuNQ0KDQrigJxPdGhlciBt ZWFuc+KAnSB3b3VsZCBiZSB0aGUgU2NoZWR1bGUgb2JqZWN0IGFuZCB0aGUgRXZlbnQgb2JqZWN0 Lg0KQXMgSSB1bmRlcnN0YW5kIGl0IGJvdGggc2NoZWR1bGUgYW5kIGV2ZW50IG9iamVjdHMgaGF2 ZSBzdGFydCB0aW1lDQphbmQgc3RvcCB0aW1lIHNwZWNpZmljYXRpb25zIGF2YWlsYWJsZSwgYW5k IEV2ZW50IGhhcyBEdXJhdGlvbiBzcGVjaWZpY2F0aW9uDQphdmFpbGFibGUgd2hpY2ggd291bGQg YmUgdXNlZnVsIGZvciByZWN1cnJpbmcgZXZlbnRzIChwZXJpb2RpYyBvciBjYWxlbmRhcikuDQoN CjxUQUM+IFRoZSBzY2hlZHVsZeKAmXMgdGltZXIgaXMgc3VmZmljaWVudCB0byBzdGF0ZSB3aGVu IHRoZSBpbml0aWFsIGFjdGlvbihzKSBhcmUgaW52b2tlZC4gSSBzYXkgYWN0aW9ucyBiZWNhdXNl IHRoZSBleGVjdXRpb24gbW9kZSBmb3IgdGhlIHNjaGVkdWxl4oCZcyBhY3Rpb27igJlzIGNvdWxk IGJlIHBhcmFsbGVsLiBJbiB0aGUgY2FzZSB3aGVuIHRoZSBzY2hlZHVsZeKAmXMgZXhlY3V0aW9u IG1vZGUgaXMgc2VxdWVudGlhbCB0aGVuIGl0IHdvdWxkIGJlIHN1ZmZpY2llbnQgdG8gc3RhdGUg d2hlbiB0aGUgZmlyc3QgYWN0aW9uIGlzIGludm9rZWQuDQpXaGF0IHRoZSBzY2hlZHVsZeKAmXMg dGltZXIgZG9lc27igJl0IGRvIGlzIHNwZWNpZnkgdGhlIGR1cmF0aW9uIG9mIHRoZSBpbmRpdmlk dWFsIGFjdGlvbihzKSBvciB3aGVuIHRoZSBzZWNvbmQgYWN0aW9uIGlzIGV4ZWN1dGVkIGluIHJl bGF0aW9uIHRvIHRoZSBjb21wbGV0aW9uIG9mIHRoZSBmaXJzdCBhY3Rpb24uIFdoYXQgd2Ugd291 bGQgbmVlZCB0byBkbyBpcyBlaXRoZXI6IFBhc3MgdGhlIGR1cmF0aW9uIG9mIGFjdGlvbiBiYXNl ZCBvbiB0aGUgb3B0aW9ucyAoVDAgPSB6ZXJvLCBUZj1zb21lIGR1cmF0aW9uKSBvciB3ZSBjb3Vs ZCBwdXQgYSB0aW1lciBvbiB0aGUgYWN0aW9uIOKAkyB3aGljaCB3b3VsZCBwcm92aWRlIHRoZSBl eHRlcm5hbCBjb250cm9sIHRoYXQgd291bGQgYWxsb3cgdGhlIHN0YXJ0IHRvIGJlIGJldHRlciBj b250cm9sbGVkIGluIHRoZSBjb250ZXh0IG9mIHRoZSBvdmVyYWxsIHNjaGVkdWxlLg0KDQpFdmVu dHVhbGx5LCB0aGUgTUEgaGFzIHRvIHJlcG9ydCB0aGUgcmVzdWx0cyBvZiB0aGUgbWV0cmljL21l YXN1cmVtZW50Lg0KVGhhdOKAmXMgd2hlbiB0aGUgYWN0dWFsIChSRUQpIHN0YXJ0IGFuZCBlbmQg dGltZXMgd2hlbiBwYWNrZXRzIHdlcmUgYWN0dWFsbHkNCmZsb3dpbmcgYmV0d2VlbiBtZWFzdXJl bWVudCBwb2ludHMgYXJlIHJlcG9ydGVkLCBhY2NvcmRpbmcgdG8gdGhlIFJlZ2lzdHJ5IEVudHJ5 Lg0KU2VlOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLWlu aXRpYWwtcmVnaXN0cnktMDAjc2VjdGlvbi00LjQuMg0KDQo8VEFDPiBUaGVzZSBzZWVtIHRvIGJl IHRoZSBhY3R1YWwg4oCTIG5vdCBjb25maWd1cmVkIHN0YXJ0IGFuZCBlbmQgdGltZXMNCkludGVy ZXN0aW5nIEkgdGhpbmsgdGhlcmUgbWlnaHQgYmUgYSBwcm9ibGVtIGluIHRoZSBkcmFmdCB3aXRo IFRmIGFzIGl0IHdvdWxkIGJlIOKAnGVuZOKAnSBvZiB0aGUgaW50ZXJ2YWwgbm90IHRoZSDigJxz dGFydOKAnSBvZiB0aGUgaW50ZXJ2YWw/DQogICBUMCB0aGUgc3RhcnQgb2YgYSBtZWFzdXJlbWVu dCBpbnRlcnZhbCwgKGZvcm1hdCAiZGF0ZS1hbmQtdGltZSIgYXMNCiAgICAgIHNwZWNpZmllZCBp biBTZWN0aW9uIDUuNiBvZiBbUkZDMzMzOV08aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzMzMzkjc2VjdGlvbi01LjY+LCBzZWUgYWxzbyBTZWN0aW9uIDMgb2Y8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzY5OTEjc2VjdGlvbi0zPg0KICAgICAgW1JGQzY5OTFdPGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTkxI3NlY3Rpb24tMz4pLiAgVGhlIFVUQyBUaW1lIFpv bmUgaXMgcmVxdWlyZWQgYnkgU2VjdGlvbiA2LjEgb2Y8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzIzMzAjc2VjdGlvbi02LjE+DQogICAgICBbUkZDMjMzMF08aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzIzMzAjc2VjdGlvbi02LjE+Lg0KDQogICBUZiB0aGUgc3RhcnQgb2Yg YSBtZWFzdXJlbWVudCBpbnRlcnZhbCwgKGZvcm1hdCAiZGF0ZS1hbmQtdGltZSIgYXMNCiAgICAg IHNwZWNpZmllZCBpbiBTZWN0aW9uIDUuNiBvZiBbUkZDMzMzOV08aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzMzMzkjc2VjdGlvbi01LjY+LCBzZWUgYWxzbyBTZWN0aW9uIDMgb2Y8aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5OTEjc2VjdGlvbi0zPg0KICAgICAgW1JGQzY5 OTFdPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTkxI3NlY3Rpb24tMz4pLiAgVGhl IFVUQyBUaW1lIFpvbmUgaXMgcmVxdWlyZWQgYnkgU2VjdGlvbiA2LjEgb2Y8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzIzMzAjc2VjdGlvbi02LjE+DQogICAgICBbUkZDMjMzMF08aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIzMzAjc2VjdGlvbi02LjE+Lg0KDQoNCkFzIEkg c2FpZCBhdCB0aGUgbWVldGluZywgaXQgd291bGQgYmUgZ29vZCB0byBsb29rIGF0IHNvbWUgZXhh bXBsZXMNCg0Kd2hpY2ggYXR0ZW1wdCB0byBzY2hlZHVsZSB0aGUg4oCcQWN0X0lQX1VEUF9Sb3Vu ZC10cmlwX0RlbGF5X1BvaXNzb25fOTV0aC1wZXJjZW50aWxl4oCdDQoNCnJlZ2lzdHJ5IGVudHJ5 LCBhcyBhIFBlcmlvZGljIGV2ZW50LCBhIG9uZS10aW1lIGV2ZW50LCBhbmQgYSBjb250aW51b3Vz DQoNCmV2ZW50IGFzIFJvbiBpcyBzdWdnZXN0aW5nLg0KDQoNCg0KcmVnYXJkcywNCg0KQWwNCg0K KiBOb3RlIHRoYXQgdGhlIFJlZ2lzdHJ5IEVudHJ5IGZvciBhIE1ldHJpYyBpbmNsdWRlcyB0aGUg TWV0cmljIERlZmluaXRpb24sDQp0aGUgbWV0aG9kIG9mIG1lYXN1cmVtZW50LCBhbmQgUnVuLXRp bWUgcGFyYW1ldGVycy4NCg0KDQpGcm9tOiBSb24gU3RhbmEgW21haWx0bzpyb24uc3RhbmFAdmlh dmlzb2x1dGlvbnMuY29tXQ0KU2VudDogTW9uZGF5LCBBcHJpbCAxOCwgMjAxNiA5OjQwIEFNDQpU bzogQ2FyZXksIFRpbW90aHkgKE5va2lhIC0gVVMpDQpDYzogbG1hcEBpZXRmLm9yZzxtYWlsdG86 bG1hcEBpZXRmLm9yZz47IE1PUlRPTiwgQUxGUkVEIEMgKEFMKQ0KU3ViamVjdDogUmU6IFtsbWFw XSBMTUFQOiBEZWZpbmluZyB0aGUgU2NoZWR1bGUncyBldmVudHMNCg0KVGltLA0KDQpUaGUgZXhh Y3QgZGVmaW5pdGlvbiBvZiB0aGUgbWV0cmljIGlzIHN0aWxsIHVuY2xlYXIgdG8gbWUgc2luY2Ug SSBoYXZlIG5vdCBzZWVuIGFuIGV4YW1wbGUgb2YgYSB0ZXN0IHdpdGggYXZlcmFnZSBjb21wbGV4 aXR5IHVzaW5nIG1ldHJpY3Mgd2l0aCBMTUFQIGZyb20gYmVnaW5uaW5nIHRvIGVuZC4gIEJ5IGF2 ZXJhZ2UgY29tcGxleGl0eSBJIG1lYW4gYSB0ZXN0IHRoYXQgYWxsb3dzIGluZGVwZW5kZW50IGNv bmZpZ3VyYXRpb24gb2YgbXVsdGlwbGUgc2ltdWx0YW5lb3VzIGRhdGEgZmxvd3MgYW5kIHByb2R1 Y2VzIG11bHRpcGxlIHJlcG9ydCBmb3JtYXRzIGR1cmluZyB0aGUgdGVzdCBkdXJhdGlvbi4gVGhl IHRlc3RzIEkgbWVudGlvbmVkIHByZXZpb3VzbHkgKFJGQy0yNTQ0LCBZLjE1NjQsIFkuMTczMSBh bmQgVFdBTVApIG1pbmltYWxseSByZXF1aXJlIHRoaXMgdHlwZSBvZiBzdXBwb3J0IGFuZCBhcmUg dGhlIG1haW4gdGVzdHMgdXNlZCBpbiBFdGhlcm5ldCBzZXJ2aWNlIHRlc3RpbmcgdG9kYXkuICBO b25lLXRoZS1sZXNzLCBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBtZXRyaWMgaXMgdGhhdCBpdCBk ZWZpbmVzIHRoZSBmb3JtYXQgb2YgdGhlIHBhY2tldCBzdHJlYW0gYW5kIHRoZSBtZXRob2RvbG9n eSBvZiB0aGUgdHJhbnNtaXQgZnJlcXVlbmN5LiBUaGVzZSBhcmUgdHdvIGV4YW1wbGVzIGZyb20g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1pbml0aWFsLXJlZ2lz dHJ5LTAwDQoNCg0KQWN0X0lQX1VEUF9Qb2lzc29uX1VEUC1QYXlsb2FkLTI1MF9PbmUtd2F5X0Rl bGF5X1N0ZF9EZXYNCg0KQWN0X0lQX1VEUF9QZXJpb2RpYy12YXJfVURQLVBheWxvYWQtMTQyX09u ZS13YXlfRGVsYXlfTWVhbg0KDQoNCg0KSXQgZG9lcyBub3QgYXBwZWFyIHRvIGRlZmluZSB0aGUg dGltZSBwZXJpb2Qgb3ZlciB3aGljaCB0aGUgbWVhc3VyZW1lbnQgd2FzIHRha2VuLiAgVGhpcyBp cyBnb29kIGJlY2F1c2UgZm9yIG1vc3QgdGVzdHMgdGhlIG1lYXN1cmVtZW50IHBlcmlvZCBpcyBh IHVzZXIgZGVmaW5lZCBpbnB1dCBwYXJhbWV0ZXIuICBQZXJmb3JtYW5jZSBtb25pdG9yaW5nIHRl c3RzIHdpbGwgcmVwb3J0IHRoZSBtZXRyaWMgcmVwZWF0ZWRseSBkdXJpbmcgdGhlIHRlc3QgZXhl Y3V0aW9uLiAgUmVmZXJyaW5nIHRvIHRoZSBleGFtcGxlIGluIG15IHByaW9yIGVtYWlsLCBhIFRX QU1QIHRlc3Qgd291bGQgcHJvZHVjZSBhIGdyb3VwIG9mIG1ldHJpY3MgZm9yIGVhY2ggZGF0YSBz dHJlYW0gZXZlcnkgMSwgNSBvciAxNSBtaW51dGVzIGRlcGVuZGluZyBvbiB0aGUgdGVzdCBjb25m aWd1cmF0aW9uLiBJdCBpcyBwb3NzaWJsZSB0aGUgdGVzdCBjb3VsZCBiZSBjb25maWd1cmVkIHRv IHByb2R1Y2UgbXVsdGlwbGUgcmVwb3J0cyAtIGZvciBleGFtcGxlIGF0IGEgc2hvcnQgaW50ZXJ2 YWwgZm9yIHRyb3VibGVzaG9vdGluZyBpbiBhZGRpdGlvbiB0byBvbmUgb2YgdGhlIGludGVydmFs cyBwcmV2aW91c2x5IG1lbnRpb25lZCBmb3IgZ2VuZXJhbCBzZXJ2aWNlIG1vbml0b3JpbmcuIFRo dXMsIHRoZSBUV0FNUCB0ZXN0IHByb2R1Y2VzIGluc3RhbmNlcyBvZiBtZXRyaWNzIGZvciBhbiB1 bnNwZWNpZmllZCBhbW91bnQgb2YgdGltZSAtIHR5cGljYWxseSB1bnRpbCBhIHVzZXIgbWFudWFs bHkgc3RvcHMgdGhlIHRlc3QuDQoNCg0KDQpJbiBzdW1tYXJ5LCBmcm9tIG15IHBlcnNwZWN0aXZl LCB0aGUgZHVyYXRpb24gb2YgdGhlIHRlc3QgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIG1l dHJpYyBkZWZpbml0aW9uLi4uLmJ1dCBtYXliZSBJIGp1c3QgZG9uJ3QgdW5kZXJzdGFuZCB0aGUg bWV0cmljIGRlZmluaXRpb24gd2VsbCBlbm91Z2guDQoNCg0KDQpSb24NCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KT24gU3VuLCBBcHIgMTcsIDIwMTYgYXQgOToxOSBQTSwgQ2FyZXksIFRpbW90 aHkgKE5va2lhIC0gVVMpIDx0aW1vdGh5LmNhcmV5QG5va2lhLmNvbTxtYWlsdG86dGltb3RoeS5j YXJleUBub2tpYS5jb20+PiB3cm90ZToNClJvbiwNCg0KVGhhbmtzIGZvciBsb29raW5nIGF0IHRo aXMuDQpXaGVuIEkgZGlzY3Vzc2VkIHRoaXMgd2l0aCBBbCBpbmRpY2F0ZWQgdGhhdCB0aGVzZSB3 b3VsZCBiZSBwYXJ0IG9mIHRoZSBtZXRyaWMvYWN0aW9uIGRlZmluaXRpb24uDQoNCkJ1dCBpZiB3 ZSB3b3VsZCB3YW50IHRvIGRlZmluZSBhIG5vbi1tZXRyaWMgc3BlY2lmaWMgZHVyYXRpb24gYXR0 cmlidXRlIG9mIGFuIGluZGl2aWR1YWwgYWN0aW9uIHdpdGhpbiB0aGUgY29udGV4dCBvZiB0aGUg b3ZlcmFsbCBzY2hlZHVsZSAoSSBiZWxpZXZlIHRoaXMgaXMgd2hhdCB5b3UgYXJlIHJlcXVlc3Rp bmc/KSB0aGVuIHdlIHNob3VsZCBhc3NpZ24gdGhhdCBkdXJhdGlvbiB0aGF0IHJlc3VsdHMgaW4g KFQ0KSB0byB0aGUgYWN0aW9uLiBBY3R1YWxseSB5b3UgaGF2ZSB0aGUgc2FtZSBwcm9ibGVtIHdp dGggVDIg4oCTIHdpdGhpbiB0aGUgY29udGV4dCBhY3Rpb24g4oCTIHRoaXMgb2Zmc2V0IGlmIG5l Y2Vzc2FyeSBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgc2NoZWR1bGUgc3RhcnQgcmFuZG9tbmVzcyAo b25jZSB0aGUgcHJvY2VzcyBzdGFydHMgaG93IGxvbmcgdG8gd2FpdCBiZWZvcmUgdGhlIGJpdHMg aGl0IHRoZSB3aXJlKS4gIE1heWJlIHRoYXQgaXMgd2hhdCB3ZSBhcmUgbWlzc2luZyDigJMgQSB0 aW1lciBmb3IgYW4gYWN0aW9uIHdpdGhpbiB0aGUgY29udGV4dCBvZiB0aGUgc2NoZWR1bGXigKYN Cg0KQ29tbWVudHM/DQoNCkZyb206IEVYVCBSb24gU3RhbmEgW21haWx0bzpyb24uc3RhbmFAdmlh dmlzb2x1dGlvbnMuY29tPG1haWx0bzpyb24uc3RhbmFAdmlhdmlzb2x1dGlvbnMuY29tPl0NClNl bnQ6IFN1bmRheSwgQXByaWwgMTcsIDIwMTYgNjozNSBQTQ0KVG86IENhcmV5LCBUaW1vdGh5IChO b2tpYSAtIFVTKQ0KQ2M6IGxtYXBAaWV0Zi5vcmc8bWFpbHRvOmxtYXBAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW2xtYXBdIExNQVA6IERlZmluaW5nIHRoZSBTY2hlZHVsZSdzIGV2ZW50cw0KDQpU aW0sDQoNCkl0IGFwcGVhcnMgeW91IGFyZSBtYWtpbmcgYW4gYXNzdW1wdGlvbiB0aGF0IGVhY2gg YWN0aW9uIHdpbGwgZW5kIG9uIGl0cyBvd24gKFQ0KS4gIFdoaWxlIHRoYXQgaXMgdHJ1ZSBmb3Ig dHVybi11cCB0ZXN0cyBsaWtlIFJGQy0yNTQ0IGFuZCBZLjE1NjQsIGxvbmcgdGVybSBwZXJmb3Jt YW5jZSBtb25pdG9yaW5nIHRlc3RzIGxpa2UgVFdBTVAgYW5kIFkuMTczMSBhcmUgZXhwZWN0ZWQg dG8gcHJvZHVjZSByZXN1bHRzIDI0LzcgYW5kIHNvIGRvIG5vdCBoYXZlIGEgZGVmaW5lZCBlbmQg dGltZS4gIFRoZXkgYXJlIGNvbmZpZ3VyZWQgd2l0aCBhIHJhdGUgdG8gc2VuZCBwYWNrZXRzLCB0 aGUgTUEgbWVhc3VyZXMgRkQsIEZEViBhbmQgRkxSIGFuZCB0aGVuIHRoZSBNQSBwZXJpb2RpY2Fs bHkgYWdncmVnYXRlcyB0aGVzZSBzdGF0cyBhbmQgc2VuZHMgdGhlbSB0byB0aGUgY29sbGVjdG9y LiAgVGhlIGFnZ3JlZ2F0aW9uIHJhdGUgaXMgdHlwaWNhbGx5IDEsIDUgb3IgMTUgbWludXRlcyBz byByZXBvcnRzIGNvbnRhaW4gcm9sbGluZyBzdGFydC9lbmQgdGltZXMgYXMgdGhlIHRlc3QgZXhl Y3V0ZXMuDQoNCldoaWxlIHdoYXQgSSBkZXNjcmliZSBhYm92ZSBpcyB0aGUgdHlwaWNhbCB1c2Ug Y2FzZSwgdGhlcmUgYXJlIG90aGVyIHNjZW5hcmlvcyB3aGVyZSB0aGVzZSBzYW1lIHRlc3RzIGNh biBiZSBjb25maWd1cmVkIHRvIGVtdWxhdGUgc2hvcnQgcmFuZG9tIGJ1cnN0cy4gSW4gdGhpcyBz Y2VuYXJpbyB0aGUgdGVzdHMgbmVlZCB0byBiZSBjb25maWd1cmVkIHdpdGggYW4gaW5pdGlhbCBz dGFydCB0aW1lLCBhbiBpbnRlcnZhbCB0byByZXN0YXJ0IHRoZSB0ZXN0LCBhIHJhbmRvbSBzdGFy dCBvZmZzZXQgYW5kIGEgZHVyYXRpb24uICBGb3IgZXhhbXBsZSwgc3RhcnQgYXQgMTowMCB0b2Rh eSwgcmVzdGFydCBldmVyeSA1IG1pbnV0ZXMgdGhlcmVhZnRlciwgZWFjaCBydW4gc2hvdWxkIGJl IG9mZnNldCBieSBhIHJhbmRvbSB2YWx1ZSB3aXRoaW4gNCBtaW51dGVzIGFuZCBlYWNoIHJ1biBz aG91bGQgc2VuZCB0aGUgZGF0YSBmbG93cyBmb3IgMSBtaW51dGUuICBJIHRoaW5rIHRoZSBvbmx5 IHBhcnQgb2YgdGhpcyBMTUFQIGRpZCBub3QgZGVmaW5lIHdhcyB0aGUgbGFzdCBwYXJhbWV0ZXIg LSB0aGUgdGVzdCBkdXJhdGlvbi4gV2hpbGUgZWFjaCB0ZXN0IGNvdWxkIG9mZmVyIHRlc3Qtc3Bl Y2lmaWMgcGFyYW1ldGVycyB0byBkZWZpbmUgaXRzIGR1cmF0aW9uLCBJIHRob3VnaHQgdGhlIHBy b3Bvc2FsIHRvIGFkZCB0aGUgJ2VuZCcgb2JqZWN0IHdhcyB0byBwcm92aWRlIGEgY29tbW9uIGFw cHJvYWNoIGZvciB0aGlzLg0KDQpSb24NCg0KT24gRnJpLCBBcHIgOCwgMjAxNiBhdCA4OjUyIEFN LCBDYXJleSwgVGltb3RoeSAoTm9raWEgLSBVUykgPHRpbW90aHkuY2FyZXlAbm9raWEuY29tPG1h aWx0bzp0aW1vdGh5LmNhcmV5QG5va2lhLmNvbT4+IHdyb3RlOg0KVGVhbSwNCg0KSW4gdGhlIElF VEYjOTUgTE1BUCBzZXNzaW9uIHdlIGhhZCBhIGRpc2N1c3Npb24gb24gdGhlIG5lZWQgZm9yIHRo ZSBuZXcgcGFyYW1ldGVycyBmb3IgdGhlIG1hLXNjaGVkdWxlLWVuZCBhbmQgbWEtc2NoZWR1bGUt ZHVyYXRpb24gcGFyYW1ldGVycywgZ2l2ZW4gdGhhdCB0aGUgbWEtc2NoZWR1bGUtc3RhcnQgKHdo aWNoIGlzIHR5cGVkIGFzIGFuIGV2ZW50KQ0KDQpXZSBzYWlkIHdlIHdvdWxkIHNob3cgdGhhdCB0 aGVzZSBwYXJhbWV0ZXJzIHdlcmUgbm90IG5lZWRlZCB1c2luZyBhbiBleGFtcGxlIOKAkyBzbyBo ZXJlIGdvZXMuDQoNCkxldHMgYXNzdW1lIHdlIGhhdmUgYSBzY2hlZHVsZSBtYWRlIHVwIG9mIDIg YWN0aW9ucyAoQTEsIEEyKSBpbiBwaXBlbGluZSBtb2RlLiBUaGUgbWEtc2NoZWR1bGUtc3RhcnQg d291bGQgaGFzIGEgcGVyaW9kaWMgZXZlbnQ6DQoNClN0YXJ0IEFwcmlsIDEsIDIwMTYgYXQgMDI6 MDA6MDANCg0KRW5kIE1heSAxLCAyMDE2IGF0IDAyOjAwOjAwDQoNCkludGVydmFsIDg2LDQwMCAo ZGFpbHkpDQoNClJhbmRvbW5lc3MgMzYwMCAod2l0aGluIHRoZSBob3VyKQ0KDQpTbyB0aGUgc2No ZWR1bGUgd2lsbCByZW9jY3VyIGV2ZXJ5IGRheSBzdGFydGluZyBvbiBBcHJpbCAxIGJlZ2lubmlu ZyBhdCAyOjAwcG0uIChUMCkgVGhlIHN0YXJ0aW5nIHBlcmlvZCB3aWxsIGJlIHJhbmRvbSBiZXR3 ZWVuIDI6MDBhbSBhbmQgMzowMGFtLiAoVDEpIFRoaXMgZGVmaW5pdGlvbiBpcyBzdWZmaWNpZW50 IGZvciBpbnZva2luZyBBMSAoVDEpIGFuZCBpcyB3aGF0IEFsIGNvbnNpZGVycyBhcyBCbHVlIHRp bWVzLg0KDQpBcyBBMSBwZXJmb3JtcyBhIHRlc3QgQTEgcGxhY2VzIGJpdHMgb24gdGhlIHdpcmUg KFQyKSBhbmQgY29sbGVjdHMgcmVzdWx0cyAoVDMpLg0KV2hlbiBBMSBjb21wbGV0ZXMgKFQ0KSwg QTIgaXMgaW52b2tlZCAoVDUpIHdoaWNoIHBsYWNlcyBiaXRzIG9uIGEgd2lyZSBmb3IgQTIgKFQy KSBhbmQgY29sbGVjdHMgcmVzdWx0cyAoVDMpKS4gRmluYWxseSB0aGUgcmVzdWx0cyBmcm9tIHRo ZSBzY2hlZHVsZSBhcmUgcmVwb3J0ZWQgKFQ2KS4NCg0KVDImVDM6IEFsIGNvbnNpZGVycyB0aGlz IHRpbWUgdG8gYmUgcGFydCBvZiB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgbWV0cmljIGFuZCBhcmUg cmVwb3J0ZWQgYXMgcGFydCBvZiB0aGUgcmVzdWx0IGNvbnRlbnQgKG5vdCBhcyBhbiBhY3R1YWwg cGFyYW1ldGVyKS4gVGhpcyB3YXMgaGlzIFJlZCB0aW1lDQoNClQ0JlQ1OiBBcmUgdGhlIG1hLXJl cG9ydC1bc3RhcnR8ZW5kXS10aW1lDQpUNjogSXMgdGhlIG1hLXJlcG9ydC1kYXRlDQoNCkFzIHN1 Y2gg4oCTIEFzIGxvbmcgYXMgYW4gRXZlbnQgaGFzIGEgZGVmaW5lZCBvY2N1cnJlbmNlIChUMT1U MCArIHJhbmRvbW5lc3MpIGFsbCB0aGF0IGlzIG5lY2Vzc2FyeSBpcyBhIHNpbmdsZSBwYXJhbWV0 ZXIgdG8gZGVmaW5lIHRoZSBvY2N1cnJlbmNlLg0KDQpRdWVzdGlvbnM/DQoNCkJSLA0KVGltDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpsbWFwIG1h aWxpbmcgbGlzdA0KbG1hcEBpZXRmLm9yZzxtYWlsdG86bG1hcEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1hcA0KDQoNCg== --_000_9966516C6EB5FC4381E05BF80AA55F77012A6347A3US70UWXCHMBA0_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWwsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklubGluZSAmbHQ7VEFDJmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IEVYVCBNT1JUT04sIEFMRlJFRCBDIChBTCkgW21haWx0bzphY21vcnRvbkBhdHQu Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMTgsIDIwMTYgNToxOSBQTTxi cj4NCjxiPlRvOjwvYj4gUm9uIFN0YW5hOyBDYXJleSwgVGltb3RoeSAoTm9raWEgLSBVUyk8YnI+ DQo8Yj5DYzo8L2I+IGxtYXBAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtsbWFw XSBMTUFQOiBEZWZpbmluZyB0aGUgU2NoZWR1bGUncyBldmVudHM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgUm9u IGFuZCBUaW0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj50cnlpbmcgdG8gbWFrZSBhIGZldyBt aW51dGVzIGZvciB0aGlzLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgUmVnaXN0cnkg RW50cmllcyogZm9yIHRoZSBNZXRyaWNzIGluY2x1ZGUgUnVuLXRpbWUgUGFyYW1ldGVyczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5mb3IgdGhlIFN0YXJ0IHRpbWUgYW5kIEVuZCBUaW1lLCBidXQgb25lIG9mIHRoZW0gY291 bGQgYmUgaW50ZXJwcmV0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+YXMgYSBEdXJhdGlvbiBpZiBzcGVjaWZpZWQgY29y cmVjdGx5ICh0aGUgU3RhcnQgdGltZSBtdXN0IGJlIGFsbCB6ZXJvcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+dGhlbiB0 aGUgU3RvcCB0aW1lIGlzIGludGVycHJldGVkIGFzIGEgZHVyYXRpb24sIEFORCB0aGUgYWN0dWFs IHN0YXJ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPmFuZCBzdG9wIHRpbWUgYXJlIGNvbnRyb2xsZWQgdGhyb3VnaCDigJxv dGhlciBtZWFuc+KAnSkuIFNlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1pbml0aWFsLXJlZ2lzdHJ5 LTAwI3NlY3Rpb24tNC4zLjUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWlwcG0taW5pdGlhbC1yZWdpc3RyeS0wMCNzZWN0aW9uLTQuMy41PC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+4oCcT3RoZXIgbWVhbnPigJ0gd291bGQgYmUgdGhlIFNjaGVkdWxlIG9iamVj dCBhbmQgdGhlIEV2ZW50IG9iamVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QXMgSSB1bmRlcnN0YW5kIGl0IGJvdGgg c2NoZWR1bGUgYW5kIGV2ZW50IG9iamVjdHMgaGF2ZSBzdGFydCB0aW1lPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPmFuZCBz dG9wIHRpbWUgc3BlY2lmaWNhdGlvbnMgYXZhaWxhYmxlLCBhbmQgRXZlbnQgaGFzIER1cmF0aW9u IHNwZWNpZmljYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+YXZhaWxhYmxlIHdoaWNoIHdvdWxkIGJlIHVzZWZ1bCBm b3IgcmVjdXJyaW5nIGV2ZW50cyAocGVyaW9kaWMgb3IgY2FsZW5kYXIpLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0 O1RBQyZndDsgVGhlIHNjaGVkdWxl4oCZcyB0aW1lciBpcyBzdWZmaWNpZW50IHRvIHN0YXRlIHdo ZW4gdGhlIGluaXRpYWwgYWN0aW9uKHMpIGFyZSBpbnZva2VkLiBJIHNheSBhY3Rpb25zIGJlY2F1 c2UgdGhlIGV4ZWN1dGlvbiBtb2RlIGZvciB0aGUgc2NoZWR1bGXigJlzIGFjdGlvbuKAmXMNCiBj b3VsZCBiZSBwYXJhbGxlbC4gSW4gdGhlIGNhc2Ugd2hlbiB0aGUgc2NoZWR1bGXigJlzIGV4ZWN1 dGlvbiBtb2RlIGlzIHNlcXVlbnRpYWwgdGhlbiBpdCB3b3VsZCBiZSBzdWZmaWNpZW50IHRvIHN0 YXRlIHdoZW4gdGhlIGZpcnN0IGFjdGlvbiBpcyBpbnZva2VkLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPldoYXQgdGhlIHNjaGVkdWxl4oCZcyB0aW1lciBkb2VzbuKAmXQgZG8gaXMg c3BlY2lmeSB0aGUgZHVyYXRpb24gb2YgdGhlIGluZGl2aWR1YWwgYWN0aW9uKHMpIG9yIHdoZW4g dGhlIHNlY29uZCBhY3Rpb24gaXMgZXhlY3V0ZWQgaW4gcmVsYXRpb24gdG8gdGhlIGNvbXBsZXRp b24NCiBvZiB0aGUgZmlyc3QgYWN0aW9uLiBXaGF0IHdlIHdvdWxkIG5lZWQgdG8gZG8gaXMgZWl0 aGVyOiBQYXNzIHRoZSBkdXJhdGlvbiBvZiBhY3Rpb24gYmFzZWQgb24gdGhlIG9wdGlvbnMgKFQw ID0gemVybywgVGY9c29tZSBkdXJhdGlvbikgb3Igd2UgY291bGQgcHV0IGEgdGltZXIgb24gdGhl IGFjdGlvbiDigJMgd2hpY2ggd291bGQgcHJvdmlkZSB0aGUgZXh0ZXJuYWwgY29udHJvbCB0aGF0 IHdvdWxkIGFsbG93IHRoZSBzdGFydCB0byBiZSBiZXR0ZXINCiBjb250cm9sbGVkIGluIHRoZSBj b250ZXh0IG9mIHRoZSBvdmVyYWxsIHNjaGVkdWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ RXZlbnR1YWxseSwgdGhlIE1BIGhhcyB0byByZXBvcnQgdGhlIHJlc3VsdHMgb2YgdGhlIG1ldHJp Yy9tZWFzdXJlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhdOKAmXMgd2hlbiB0aGUgYWN0dWFsIChSRUQpIHN0 YXJ0IGFuZCBlbmQgdGltZXMgd2hlbiBwYWNrZXRzIHdlcmUgYWN0dWFsbHk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Zmxv d2luZyBiZXR3ZWVuIG1lYXN1cmVtZW50IHBvaW50cyBhcmUgcmVwb3J0ZWQsIGFjY29yZGluZyB0 byB0aGUgUmVnaXN0cnkgRW50cnkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+U2VlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBw bS1pbml0aWFsLXJlZ2lzdHJ5LTAwI3NlY3Rpb24tNC40LjIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0taW5pdGlhbC1yZWdpc3RyeS0wMCNzZWN0aW9uLTQuNC4y PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jmx0O1RBQyZndDsgVGhlc2Ugc2VlbSB0byBiZSB0aGUgYWN0dWFsIOKA kyBub3QgY29uZmlndXJlZCBzdGFydCBhbmQgZW5kIHRpbWVzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkludGVyZXN0aW5nIEkgdGhpbmsgdGhlcmUgbWlnaHQgYmUgYSBwcm9ibGVtIGlu IHRoZSBkcmFmdCB3aXRoIFRmIGFzIGl0IHdvdWxkIGJlIOKAnGVuZOKAnSBvZiB0aGUgaW50ZXJ2 YWwgbm90IHRoZSDigJxzdGFydOKAnSBvZiB0aGUgaW50ZXJ2YWw/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUMCB0aGUg c3RhcnQgb2YgYSBtZWFzdXJlbWVudCBpbnRlcnZhbCwgKGZvcm1hdCAmcXVvdDtkYXRlLWFuZC10 aW1lJnF1b3Q7IGFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZpZWQgaW4NCjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMzM5I3NlY3Rpb24tNS42Ij5T ZWN0aW9uJm5ic3A7NS42IG9mIFtSRkMzMzM5XTwvYT4sIHNlZSBhbHNvDQo8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjk5MSNzZWN0aW9uLTMiPlNlY3Rpb24mbmJzcDsz IG9mPG86cD48L286cD48L2E+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1Pjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsdWUiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM2OTkxI3NlY3Rpb24tMyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtSRkM2OTkx XTwvYT48L3NwYW4+PC91PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4pLiZuYnNwOyBUaGUgVVRDIFRpbWUgWm9uZQ0KIGlz IHJlcXVpcmVkIGJ5IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyMzMw I3NlY3Rpb24tNi4xIj5TZWN0aW9uJm5ic3A7Ni4xIG9mPG86cD48L286cD48L2E+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsdWUiPjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyMzMwI3NlY3Rpb24tNi4xIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1JGQzIzMzBdPC9hPjwvc3Bhbj48L3U+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyA8Yj4NClRmIHRoZSBzdGFydCBvZiBhIG1lYXN1cmVtZW50IGludGVy dmFsLCAoZm9ybWF0ICZxdW90O2RhdGUtYW5kLXRpbWU8L2I+JnF1b3Q7IGFzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZpZWQgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmMzMzM5I3NlY3Rpb24tNS42Ij5TZWN0aW9uJm5ic3A7NS42IG9mIFtSRkMz MzM5XTwvYT4sIHNlZSBhbHNvDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNjk5MSNzZWN0aW9uLTMiPlNlY3Rpb24mbmJzcDszIG9mPG86cD48L286cD48L2E+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsdWUiPjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTkxI3NlY3Rpb24tMyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtSRkM2OTkxXTwvYT48L3NwYW4+PC91PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4pLiZuYnNwOyBUaGUgVVRDIFRpbWUgWm9uZQ0KIGlzIHJlcXVpcmVkIGJ5IDxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyMzMwI3NlY3Rpb24tNi4xIj5TZWN0aW9uJm5i c3A7Ni4xIG9mPG86cD48L286cD48L2E+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsdWUiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmMyMzMwI3NlY3Rpb24tNi4xIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg W1JGQzIzMzBdPC9hPjwvc3Bhbj48L3U+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5BcyBJIHNhaWQgYXQgdGhl IG1lZXRpbmcsIGl0IHdvdWxkIGJlIGdvb2QgdG8gbG9vayBhdCBzb21lIGV4YW1wbGVzDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOmJsYWNrIj53aGljaCBhdHRlbXB0IHRvIHNjaGVkdWxlIHRoZSDigJxBY3RfSVBfVURQX1Jv dW5kLXRyaXBfRGVsYXlfUG9pc3Nvbl85NXRoLXBlcmNlbnRpbGXigJ08bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2si PnJlZ2lzdHJ5IGVudHJ5LCBhcyBhIFBlcmlvZGljIGV2ZW50LCBhIG9uZS10aW1lIGV2ZW50LCBh bmQgYSBjb250aW51b3VzIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+ZXZlbnQgYXMgUm9uIGlzIHN1Z2dlc3Rp bmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPnJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOmJsYWNrIj5BbDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4qIE5vdGUgdGhhdCB0aGUg UmVnaXN0cnkgRW50cnkgZm9yIGEgTWV0cmljIGluY2x1ZGVzIHRoZSBNZXRyaWMgRGVmaW5pdGlv biw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+dGhlIG1ldGhvZCBvZiBtZWFzdXJlbWVudCwgYW5kIFJ1bi10aW1lIHBhcmFt ZXRlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSb24gU3RhbmEg WzxhIGhyZWY9Im1haWx0bzpyb24uc3RhbmFAdmlhdmlzb2x1dGlvbnMuY29tIj5tYWlsdG86cm9u LnN0YW5hQHZpYXZpc29sdXRpb25zLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBBcHJpbCAxOCwgMjAxNiA5OjQwIEFNPGJyPg0KPGI+VG86PC9iPiBDYXJleSwgVGltb3RoeSAo Tm9raWEgLSBVUyk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpsbWFwQGlldGYub3Jn Ij5sbWFwQGlldGYub3JnPC9hPjsgTU9SVE9OLCBBTEZSRUQgQyAoQUwpPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbbG1hcF0gTE1BUDogRGVmaW5pbmcgdGhlIFNjaGVkdWxlJ3MgZXZlbnRzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRpbSw8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBleGFjdCBk ZWZpbml0aW9uIG9mIHRoZSBtZXRyaWMgaXMgc3RpbGwgdW5jbGVhciB0byBtZSBzaW5jZSBJIGhh dmUgbm90IHNlZW4gYW4gZXhhbXBsZSBvZiBhIHRlc3Qgd2l0aCBhdmVyYWdlIGNvbXBsZXhpdHkg dXNpbmcgbWV0cmljcyB3aXRoIExNQVAgZnJvbSBiZWdpbm5pbmcgdG8gZW5kLiZuYnNwOyBCeSBh dmVyYWdlIGNvbXBsZXhpdHkgSSBtZWFuIGEgdGVzdCB0aGF0IGFsbG93cyBpbmRlcGVuZGVudCBj b25maWd1cmF0aW9uDQogb2YgbXVsdGlwbGUgc2ltdWx0YW5lb3VzIGRhdGEgZmxvd3MgYW5kIHBy b2R1Y2VzIG11bHRpcGxlIHJlcG9ydCBmb3JtYXRzIGR1cmluZyB0aGUgdGVzdCBkdXJhdGlvbi4g VGhlIHRlc3RzIEkgbWVudGlvbmVkIHByZXZpb3VzbHkgKFJGQy0yNTQ0LCBZLjE1NjQsIFkuMTcz MSBhbmQgVFdBTVApIG1pbmltYWxseSByZXF1aXJlIHRoaXMgdHlwZSBvZiBzdXBwb3J0IGFuZCBh cmUgdGhlIG1haW4gdGVzdHMgdXNlZCBpbiBFdGhlcm5ldCBzZXJ2aWNlDQogdGVzdGluZyB0b2Rh eS4mbmJzcDsgTm9uZS10aGUtbGVzcywgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgbWV0cmljIGlz IHRoYXQgaXQgZGVmaW5lcyB0aGUgZm9ybWF0IG9mIHRoZSBwYWNrZXQgc3RyZWFtIGFuZCB0aGUg bWV0aG9kb2xvZ3kgb2YgdGhlIHRyYW5zbWl0IGZyZXF1ZW5jeS4gVGhlc2UgYXJlIHR3byBleGFt cGxlcyBmcm9tJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtaXBwbS1pbml0aWFsLXJlZ2lzdHJ5LTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1pcHBtLWluaXRpYWwtcmVnaXN0cnktMDA8L2E+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5B Y3RfSVBfVURQX1BvaXNzb25fVURQLVBheWxvYWQtMjUwX09uZS13YXlfRGVsYXlfU3RkX0Rldjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFj dF9JUF9VRFBfUGVyaW9kaWMtdmFyX1VEUC1QYXlsb2FkLTE0Ml9PbmUtd2F5X0RlbGF5X01lYW48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkl0IGRvZXMgbm90 IGFwcGVhciB0byBkZWZpbmUgdGhlIHRpbWUgcGVyaW9kIG92ZXIgd2hpY2ggdGhlIG1lYXN1cmVt ZW50IHdhcyB0YWtlbi4mbmJzcDsgVGhpcyBpcyBnb29kIGJlY2F1c2UgZm9yIG1vc3QgdGVzdHMg dGhlIG1lYXN1cmVtZW50IHBlcmlvZCBpcyBhIHVzZXIgZGVmaW5lZCBpbnB1dCBwYXJhbWV0ZXIu Jm5ic3A7IFBlcmZvcm1hbmNlIG1vbml0b3JpbmcgdGVzdHMgd2lsbCByZXBvcnQgdGhlIG1ldHJp YyByZXBlYXRlZGx5IGR1cmluZyB0aGUgdGVzdCBleGVjdXRpb24uJm5ic3A7IFJlZmVycmluZyB0 byB0aGUgZXhhbXBsZSBpbiBteSBwcmlvciBlbWFpbCwgYSBUV0FNUCB0ZXN0IHdvdWxkIHByb2R1 Y2UgYSBncm91cCBvZiBtZXRyaWNzIGZvciBlYWNoIGRhdGEgc3RyZWFtIGV2ZXJ5IDEsIDUgb3Ig MTUgbWludXRlcyBkZXBlbmRpbmcgb24gdGhlIHRlc3QgY29uZmlndXJhdGlvbi4gSXQgaXMgcG9z c2libGUgdGhlIHRlc3QgY291bGQgYmUgY29uZmlndXJlZCB0byBwcm9kdWNlIG11bHRpcGxlIHJl cG9ydHMgLSBmb3IgZXhhbXBsZSBhdCBhIHNob3J0IGludGVydmFsIGZvciB0cm91Ymxlc2hvb3Rp bmcgaW4gYWRkaXRpb24gdG8gb25lIG9mIHRoZSBpbnRlcnZhbHMgcHJldmlvdXNseSBtZW50aW9u ZWQgZm9yIGdlbmVyYWwgc2VydmljZSBtb25pdG9yaW5nLiBUaHVzLCB0aGUgVFdBTVAgdGVzdCBw cm9kdWNlcyBpbnN0YW5jZXMgb2YgbWV0cmljcyBmb3IgYW4gdW5zcGVjaWZpZWQgYW1vdW50IG9m IHRpbWUgLSB0eXBpY2FsbHkgdW50aWwgYSB1c2VyIG1hbnVhbGx5IHN0b3BzIHRoZSB0ZXN0LiAm bmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkluIHN1bW1hcnksIGZyb20gbXkgcGVyc3BlY3RpdmUsIHRoZSBk dXJhdGlvbiBvZiB0aGUgdGVzdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgbWV0cmljIGRl ZmluaXRpb24uLi4uYnV0IG1heWJlIEkganVzdCBkb24ndCB1bmRlcnN0YW5kIHRoZSBtZXRyaWMg ZGVmaW5pdGlvbiB3ZWxsIGVub3VnaC48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJvbjwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBTdW4sIEFwciAxNywgMjAxNiBhdCA5OjE5IFBNLCBDYXJleSwgVGltb3Ro eSAoTm9raWEgLSBVUykgJmx0OzxhIGhyZWY9Im1haWx0bzp0aW1vdGh5LmNhcmV5QG5va2lhLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnRpbW90aHkuY2FyZXlAbm9raWEuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvbiw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGFua3MgZm9yIGxvb2tpbmcgYXQgdGhpcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5XaGVuIEkgZGlzY3Vzc2VkIHRoaXMgd2l0aCBBbCBpbmRpY2F0ZWQgdGhhdCB0aGVzZSB3 b3VsZCBiZSBwYXJ0IG9mIHRoZSBtZXRyaWMvYWN0aW9uIGRlZmluaXRpb24uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QnV0IGlmIHdlIHdvdWxkIHdhbnQgdG8gZGVmaW5lIGEgbm9uLW1ldHJpYyBzcGVjaWZpYyBk dXJhdGlvbiBhdHRyaWJ1dGUgb2YgYW4gaW5kaXZpZHVhbCBhY3Rpb24gd2l0aGluDQogdGhlIGNv bnRleHQgb2YgdGhlIG92ZXJhbGwgc2NoZWR1bGUgKEkgYmVsaWV2ZSB0aGlzIGlzIHdoYXQgeW91 IGFyZSByZXF1ZXN0aW5nPykgdGhlbiB3ZSBzaG91bGQgYXNzaWduIHRoYXQgZHVyYXRpb24gdGhh dCByZXN1bHRzIGluIChUNCkgdG8gdGhlIGFjdGlvbi4gQWN0dWFsbHkgeW91IGhhdmUgdGhlIHNh bWUgcHJvYmxlbSB3aXRoIFQyIOKAkyB3aXRoaW4gdGhlIGNvbnRleHQgYWN0aW9uIOKAkyB0aGlz IG9mZnNldCBpZiBuZWNlc3NhcnkgaXMgZGlmZmVyZW50DQogZnJvbSB0aGUgc2NoZWR1bGUgc3Rh cnQgcmFuZG9tbmVzcyAob25jZSB0aGUgcHJvY2VzcyBzdGFydHMgaG93IGxvbmcgdG8gd2FpdCBi ZWZvcmUgdGhlIGJpdHMgaGl0IHRoZSB3aXJlKS4mbmJzcDsgTWF5YmUgdGhhdCBpcyB3aGF0IHdl IGFyZSBtaXNzaW5nIOKAkyBBIHRpbWVyIGZvciBhbiBhY3Rpb24gd2l0aGluIHRoZSBjb250ZXh0 IG9mIHRoZSBzY2hlZHVsZeKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvbW1lbnRzPzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IEVYVCBSb24gU3RhbmEgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cm9uLnN0YW5hQHZpYXZp c29sdXRpb25zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbi5zdGFuYUB2aWF2aXNvbHV0aW9ucy5j b208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgQXByaWwgMTcsIDIwMTYgNjozNSBQ TTxicj4NCjxiPlRvOjwvYj4gQ2FyZXksIFRpbW90aHkgKE5va2lhIC0gVVMpPGJyPg0KPGI+Q2M6 PC9iPiA8YSBocmVmPSJtYWlsdG86bG1hcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmxtYXBA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbG1hcF0gTE1BUDogRGVmaW5p bmcgdGhlIFNjaGVkdWxlJ3MgZXZlbnRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VGltLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkl0IGFwcGVhcnMgeW91IGFyZSBtYWtpbmcgYW4gYXNzdW1wdGlvbiB0 aGF0IGVhY2ggYWN0aW9uIHdpbGwgZW5kIG9uIGl0cyBvd24gKFQ0KS4mbmJzcDsgV2hpbGUgdGhh dCBpcyB0cnVlIGZvciB0dXJuLXVwIHRlc3RzIGxpa2UgUkZDLTI1NDQgYW5kIFkuMTU2NCwgbG9u ZyB0ZXJtIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcNCiB0ZXN0cyBsaWtlIFRXQU1QIGFuZCBZLjE3 MzEgYXJlIGV4cGVjdGVkIHRvIHByb2R1Y2UgcmVzdWx0cyAyNC83IGFuZCBzbyBkbyBub3QgaGF2 ZSBhIGRlZmluZWQgZW5kIHRpbWUuJm5ic3A7IFRoZXkgYXJlIGNvbmZpZ3VyZWQgd2l0aCBhIHJh dGUgdG8gc2VuZCBwYWNrZXRzLCB0aGUgTUEgbWVhc3VyZXMgRkQsIEZEViBhbmQgRkxSIGFuZCB0 aGVuIHRoZSBNQSBwZXJpb2RpY2FsbHkgYWdncmVnYXRlcyB0aGVzZSBzdGF0cyBhbmQgc2VuZHMg dGhlbSB0bw0KIHRoZSBjb2xsZWN0b3IuJm5ic3A7IFRoZSBhZ2dyZWdhdGlvbiByYXRlIGlzIHR5 cGljYWxseSAxLCA1IG9yIDE1IG1pbnV0ZXMgc28gcmVwb3J0cyBjb250YWluIHJvbGxpbmcgc3Rh cnQvZW5kIHRpbWVzIGFzIHRoZSB0ZXN0IGV4ZWN1dGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hpbGUgd2hhdCBJIGRlc2NyaWJl IGFib3ZlIGlzIHRoZSB0eXBpY2FsIHVzZSBjYXNlLCB0aGVyZSBhcmUgb3RoZXIgc2NlbmFyaW9z IHdoZXJlIHRoZXNlIHNhbWUgdGVzdHMgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gZW11bGF0ZSBzaG9y dCByYW5kb20gYnVyc3RzLiBJbiB0aGlzIHNjZW5hcmlvIHRoZSB0ZXN0cw0KIG5lZWQgdG8gYmUg Y29uZmlndXJlZCB3aXRoIGFuIGluaXRpYWwgc3RhcnQgdGltZSwgYW4gaW50ZXJ2YWwgdG8gcmVz dGFydCB0aGUgdGVzdCwgYSByYW5kb20gc3RhcnQgb2Zmc2V0IGFuZCBhIGR1cmF0aW9uLiZuYnNw OyBGb3IgZXhhbXBsZSwgc3RhcnQgYXQgMTowMCB0b2RheSwgcmVzdGFydCBldmVyeSA1IG1pbnV0 ZXMgdGhlcmVhZnRlciwgZWFjaCBydW4gc2hvdWxkIGJlIG9mZnNldCBieSBhIHJhbmRvbSB2YWx1 ZSB3aXRoaW4gNCBtaW51dGVzIGFuZA0KIGVhY2ggcnVuIHNob3VsZCBzZW5kIHRoZSBkYXRhIGZs b3dzIGZvciAxIG1pbnV0ZS4mbmJzcDsgSSB0aGluayB0aGUgb25seSBwYXJ0IG9mIHRoaXMgTE1B UCBkaWQgbm90IGRlZmluZSB3YXMgdGhlIGxhc3QgcGFyYW1ldGVyIC0gdGhlIHRlc3QgZHVyYXRp b24uIFdoaWxlIGVhY2ggdGVzdCBjb3VsZCBvZmZlciB0ZXN0LXNwZWNpZmljIHBhcmFtZXRlcnMg dG8gZGVmaW5lIGl0cyBkdXJhdGlvbiwgSSB0aG91Z2h0IHRoZSBwcm9wb3NhbCB0byBhZGQgdGhl DQogJ2VuZCcgb2JqZWN0IHdhcyB0byBwcm92aWRlIGEgY29tbW9uIGFwcHJvYWNoIGZvciB0aGlz LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Um9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBGcmksIEFwciA4LCAyMDE2IGF0IDg6NTIgQU0sIENhcmV5LCBUaW1vdGh5IChO b2tpYSAtIFVTKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpbW90aHkuY2FyZXlAbm9raWEuY29tIiB0 YXJnZXQ9Il9ibGFuayI+dGltb3RoeS5jYXJleUBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UZWFtLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gdGhlIElFVEYjOTUgTE1BUCBzZXNzaW9uIHdl IGhhZCBhIGRpc2N1c3Npb24gb24gdGhlIG5lZWQgZm9yIHRoZSBuZXcgcGFyYW1ldGVycyBmb3Ig dGhlIG1hLXNjaGVkdWxlLWVuZCBhbmQgbWEtc2NoZWR1bGUtZHVyYXRpb24gcGFyYW1ldGVycywg Z2l2ZW4gdGhhdCB0aGUgbWEtc2NoZWR1bGUtc3RhcnQNCiAod2hpY2ggaXMgdHlwZWQgYXMgYW4g ZXZlbnQpIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2Ugc2FpZCB3ZSB3b3VsZCBzaG93 IHRoYXQgdGhlc2UgcGFyYW1ldGVycyB3ZXJlIG5vdCBuZWVkZWQgdXNpbmcgYW4gZXhhbXBsZSDi gJMgc28gaGVyZSBnb2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TGV0cyBhc3N1bWUg d2UgaGF2ZSBhIHNjaGVkdWxlIG1hZGUgdXAgb2YgMiBhY3Rpb25zIChBMSwgQTIpIGluIHBpcGVs aW5lIG1vZGUuIFRoZSBtYS1zY2hlZHVsZS1zdGFydCB3b3VsZCBoYXMgYSBwZXJpb2RpYyBldmVu dDoNCjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjIwLjI1cHQiPlN0YXJ0 IEFwcmlsIDEsIDIwMTYgYXQgMDI6MDA6MDA8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW4tbGVmdDoyMC4yNXB0Ij5FbmQgTWF5IDEsIDIwMTYgYXQgMDI6MDA6MDA8bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDoyMC4yNXB0Ij5JbnRlcnZhbCA4Niw0MDAgKGRhaWx5 KTxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjIwLjI1cHQiPlJhbmRvbW5l c3MgMzYwMCAod2l0aGluIHRoZSBob3VyKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U28g dGhlIHNjaGVkdWxlIHdpbGwgcmVvY2N1ciBldmVyeSBkYXkgc3RhcnRpbmcgb24gQXByaWwgMSBi ZWdpbm5pbmcgYXQgMjowMHBtLiAoVDApIFRoZSBzdGFydGluZyBwZXJpb2Qgd2lsbCBiZSByYW5k b20gYmV0d2VlbiAyOjAwYW0gYW5kIDM6MDBhbS4gKFQxKSBUaGlzIGRlZmluaXRpb24gaXMgc3Vm ZmljaWVudA0KIGZvciBpbnZva2luZyBBMSAoVDEpIGFuZCBpcyB3aGF0IEFsIGNvbnNpZGVycyBh cyBCbHVlIHRpbWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgQTEgcGVyZm9ybXMg YSB0ZXN0IEExIHBsYWNlcyBiaXRzIG9uIHRoZSB3aXJlIChUMikgYW5kIGNvbGxlY3RzIHJlc3Vs dHMgKFQzKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hlbiBBMSBj b21wbGV0ZXMgKFQ0KSwgQTIgaXMgaW52b2tlZCAoVDUpIHdoaWNoIHBsYWNlcyBiaXRzIG9uIGEg d2lyZSBmb3IgQTIgKFQyKSBhbmQgY29sbGVjdHMgcmVzdWx0cyAoVDMpKS4gRmluYWxseSB0aGUg cmVzdWx0cyBmcm9tIHRoZSBzY2hlZHVsZSBhcmUgcmVwb3J0ZWQgKFQ2KS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlQyJmFtcDtUMzogQWwgY29uc2lkZXJzIHRoaXMgdGltZSB0byBiZSBw YXJ0IG9mIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBtZXRyaWMgYW5kIGFyZSByZXBvcnRlZCBhcyBw YXJ0IG9mIHRoZSByZXN1bHQgY29udGVudCAobm90IGFzIGFuIGFjdHVhbCBwYXJhbWV0ZXIpLiBU aGlzIHdhcyBoaXMgUmVkIHRpbWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlQ0JmFtcDtU NTogQXJlIHRoZSBtYS1yZXBvcnQtW3N0YXJ0fGVuZF0tdGltZTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UNjogSXMgdGhlIG1hLXJlcG9ydC1kYXRlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5BcyBzdWNoIOKAkyBBcyBsb25nIGFzIGFuIEV2ZW50IGhhcyBhIGRl ZmluZWQgb2NjdXJyZW5jZSAoVDE9VDAgJiM0MzsgcmFuZG9tbmVzcykgYWxsIHRoYXQgaXMgbmVj ZXNzYXJ5IGlzIGEgc2luZ2xlIHBhcmFtZXRlciB0byBkZWZpbmUgdGhlIG9jY3VycmVuY2UuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5RdWVzdGlvbnM/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5CUiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGltPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmxtYXAgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmxtYXBAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5sbWFwQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbG1hcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbG1hcDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9966516C6EB5FC4381E05BF80AA55F77012A6347A3US70UWXCHMBA0_-- From nobody Tue Apr 19 05:27:06 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECC612E3A4 for ; Tue, 19 Apr 2016 05:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 vWupinKP3Qbi for ; Tue, 19 Apr 2016 05:27:02 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2A92812E1D9 for ; Tue, 19 Apr 2016 05:27:02 -0700 (PDT) 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 BF0791212C0; Tue, 19 Apr 2016 08:33:34 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 12C4FE1350; Tue, 19 Apr 2016 08:26:25 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Tue, 19 Apr 2016 08:27:00 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Nokia - US)" , Ron Stana Date: Tue, 19 Apr 2016 08:24:45 -0400 Thread-Topic: [lmap] LMAP: Defining the Schedule's events Thread-Index: AQHRmMcIsS7v7zskLkW09Igh4D3XRZ+O62+QgAEVwQCAABu1AIABEw7wgAALafE= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D4587F74FA0@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A627E42@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77012A631C28@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4587DEFEC7@NJFPSRVEXG0.research.att.com>, <9966516C6EB5FC4381E05BF80AA55F77012A6347A3@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A6347A3@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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: Defining the Schedule's events X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 12:27:04 -0000 Yes, in Tf, s/start/end/.=20 Thanks for the catch, Al ________________________________________ From: Carey, Timothy (Nokia - US) [timothy.carey@nokia.com] Sent: Tuesday, April 19, 2016 8:01 AM To: MORTON, ALFRED C (AL); Ron Stana Cc: lmap@ietf.org Subject: RE: [lmap] LMAP: Defining the Schedule's events Al, Inline From: EXT MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Monday, April 18, 2016 5:19 PM To: Ron Stana; Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: RE: [lmap] LMAP: Defining the Schedule's events Hi Ron and Tim, trying to make a few minutes for this... The Registry Entries* for the Metrics include Run-time Parameters for the Start time and End Time, but one of them could be interpreted as a Duration if specified correctly (the Start time must be all zeros, then the Stop time is interpreted as a duration, AND the actual start and stop time are controlled through =93other means=94). See https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-00#section-4.3= .5 =93Other means=94 would be the Schedule object and the Event object. As I understand it both schedule and event objects have start time and stop time specifications available, and Event has Duration specificatio= n available which would be useful for recurring events (periodic or calendar)= . The schedule=92s timer is sufficient to state when the initial action= (s) are invoked. I say actions because the execution mode for the schedule= =92s action=92s could be parallel. In the case when the schedule=92s execut= ion mode is sequential then it would be sufficient to state when the first = action is invoked. What the schedule=92s timer doesn=92t do is specify the duration of the ind= ividual action(s) or when the second action is executed in relation to the = completion of the first action. What we would need to do is either: Pass th= e duration of action based on the options (T0 =3D zero, Tf=3Dsome duration)= or we could put a timer on the action =96 which would provide the external= control that would allow the start to be better controlled in the context = of the overall schedule. Eventually, the MA has to report the results of the metric/measurement. That=92s when the actual (RED) start and end times when packets were actual= ly flowing between measurement points are reported, according to the Registry = Entry. See: https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-00#section-4.4= .2 These seem to be the actual =96 not configured start and end times Interesting I think there might be a problem in the draft with Tf as it wou= ld be =93end=94 of the interval not the =93start=94 of the interval? T0 the start of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC T= ime Zone is required by Section 6.1 of [RFC2330]. Tf the start of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC T= ime Zone is required by Section 6.1 of [RFC2330]. As I said at the meeting, it would be good to look at some examples which attempt to schedule the =93Act_IP_UDP_Round-trip_Delay_Poisson_95th-p= ercentile=94 registry entry, as a Periodic event, a one-time event, and a continuous event as Ron is suggesting. regards, Al * Note that the Registry Entry for a Metric includes the Metric Definition, the method of measurement, and Run-time parameters. From: Ron Stana [mailto:ron.stana@viavisolutions.com] Sent: Monday, April 18, 2016 9:40 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org; MORTON, ALFRED C (AL) Subject: Re: [lmap] LMAP: Defining the Schedule's events Tim, The exact definition of the metric is still unclear to me since I have not = seen an example of a test with average complexity using metrics with LMAP f= rom beginning to end. By average complexity I mean a test that allows inde= pendent configuration of multiple simultaneous data flows and produces mult= iple report formats during the test duration. The tests I mentioned previou= sly (RFC-2544, Y.1564, Y.1731 and TWAMP) minimally require this type of sup= port and are the main tests used in Ethernet service testing today. None-t= he-less, my understanding of the metric is that it defines the format of th= e packet stream and the methodology of the transmit frequency. These are tw= o examples from https://tools.ietf.org/html/draft-ietf-ippm-initial-registr= y-00 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Std_Dev Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Mean It does not appear to define the time period over which the measurement was= taken. This is good because for most tests the measurement period is a us= er defined input parameter. Performance monitoring tests will report the m= etric repeatedly during the test execution. Referring to the example in my= prior email, a TWAMP test would produce a group of metrics for each data s= tream every 1, 5 or 15 minutes depending on the test configuration. It is p= ossible the test could be configured to produce multiple reports - for exam= ple at a short interval for troubleshooting in addition to one of the inter= vals previously mentioned for general service monitoring. Thus, the TWAMP t= est produces instances of metrics for an unspecified amount of time - typic= ally until a user manually stops the test. In summary, from my perspective, the duration of the test is outside the sc= ope of the metric definition....but maybe I just don't understand the metri= c definition well enough. Ron On Sun, Apr 17, 2016 at 9:19 PM, Carey, Timothy (Nokia - US) > wrote: Ron, Thanks for looking at this. When I discussed this with Al indicated that these would be part of the met= ric/action definition. But if we would want to define a non-metric specific duration attribute of = an individual action within the context of the overall schedule (I believe = this is what you are requesting?) then we should assign that duration that = results in (T4) to the action. Actually you have the same problem with T2 = =96 within the context action =96 this offset if necessary is different fro= m the schedule start randomness (once the process starts how long to wait b= efore the bits hit the wire). Maybe that is what we are missing =96 A time= r for an action within the context of the schedule=85 Comments? From: EXT Ron Stana [mailto:ron.stana@viavisolutions.com] Sent: Sunday, April 17, 2016 6:35 PM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] LMAP: Defining the Schedule's events Tim, It appears you are making an assumption that each action will end on its ow= n (T4). While that is true for turn-up tests like RFC-2544 and Y.1564, lon= g term performance monitoring tests like TWAMP and Y.1731 are expected to p= roduce results 24/7 and so do not have a defined end time. They are config= ured with a rate to send packets, the MA measures FD, FDV and FLR and then = the MA periodically aggregates these stats and sends them to the collector.= The aggregation rate is typically 1, 5 or 15 minutes so reports contain r= olling start/end times as the test executes. While what I describe above is the typical use case, there are other scenar= ios where these same tests can be configured to emulate short random bursts= . In this scenario the tests need to be configured with an initial start ti= me, an interval to restart the test, a random start offset and a duration. = For example, start at 1:00 today, restart every 5 minutes thereafter, each= run should be offset by a random value within 4 minutes and each run shoul= d send the data flows for 1 minute. I think the only part of this LMAP did= not define was the last parameter - the test duration. While each test cou= ld offer test-specific parameters to define its duration, I thought the pro= posal to add the 'end' object was to provide a common approach for this. Ron On Fri, Apr 8, 2016 at 8:52 AM, Carey, Timothy (Nokia - US) > wrote: Team, In the IETF#95 LMAP session we had a discussion on the need for the new par= ameters for the ma-schedule-end and ma-schedule-duration parameters, given = that the ma-schedule-start (which is typed as an event) We said we would show that these parameters were not needed using an exampl= e =96 so here goes. Lets assume we have a schedule made up of 2 actions (A1, A2) in pipeline mo= de. The ma-schedule-start would has a periodic event: Start April 1, 2016 at 02:00:00 End May 1, 2016 at 02:00:00 Interval 86,400 (daily) Randomness 3600 (within the hour) So the schedule will reoccur every day starting on April 1 beginning at 2:0= 0pm. (T0) The starting period will be random between 2:00am and 3:00am. (T1= ) This definition is sufficient for invoking A1 (T1) and is what Al conside= rs as Blue times. As A1 performs a test A1 places bits on the wire (T2) and collects results = (T3). When A1 completes (T4), A2 is invoked (T5) which places bits on a wire for = A2 (T2) and collects results (T3)). Finally the results from the schedule a= re reported (T6). T2&T3: Al considers this time to be part of the definition of the metric an= d are reported as part of the result content (not as an actual parameter). = This was his Red time T4&T5: Are the ma-report-[start|end]-time T6: Is the ma-report-date As such =96 As long as an Event has a defined occurrence (T1=3DT0 + randomn= ess) all that is necessary is a single parameter to define the occurrence. Questions? BR, Tim _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Apr 22 12:15:04 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD3312E1F1 for ; Fri, 22 Apr 2016 12:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 b9AHkNGs4OGN for ; Fri, 22 Apr 2016 12:15:00 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id A113812E110 for ; Fri, 22 Apr 2016 12:15:00 -0700 (PDT) X-SENDER-IP: 10.64.163.159 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.24,518,1454994000"; d="scan'208,217";a="566182591" Received: from unknown (HELO exchpapp18.corp.twcable.com) ([10.64.163.159]) by cdcipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 22 Apr 2016 15:10:59 -0400 Received: from EXCHPAPP11.corp.twcable.com (10.64.163.152) by exchpapp18.corp.twcable.com (10.64.163.159) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 22 Apr 2016 15:14:15 -0400 Received: from EXCHPAPP11.corp.twcable.com ([10.245.162.16]) by exchpapp11.corp.twcable.com ([10.245.162.16]) with mapi id 15.00.1156.000; Fri, 22 Apr 2016 15:14:15 -0400 From: "Weil, Jason" To: "lmap@ietf.org" Thread-Topic: IETF95 - LMAP Minutes Posted Thread-Index: AQHRnMsoAPRyuVPOgk22+ieRXGLwRg== Date: Fri, 22 Apr 2016 19:14:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22276.005 x-tm-as-result: No--37.119300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_D33FF04551BD1jasonweiltwcablecom_" MIME-Version: 1.0 Archived-At: Subject: [lmap] IETF95 - LMAP Minutes Posted X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 22 Apr 2016 19:15:03 -0000 --_000_D33FF04551BD1jasonweiltwcablecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, I have just uploaded the minutes from the LMAP meeting at IETF95 in Buenos = Aires. I'd like to once again thank our notetakers, Tim Carey and Holger Wi= ehen! As always, let me Dan or me know if if you have any questions or edits on t= he notes from the meeting. The notes can be found at the following link: https://www.ietf.org/proceedi= ngs/95/minutes/minutes-95-lmap Thanks, Jason ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_D33FF04551BD1jasonweiltwcablecom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3167ECF8B460B741A336CFC9BDBE59CE@twcable.com> Content-Transfer-Encoding: quoted-printable
All,

I have just uploaded the minutes from the LMAP meeting at IETF95 in Bu= enos Aires. I’d like to once again thank our notetakers, Tim Carey an= d Holger Wiehen!

As always, let me Dan or me know if if you have any questions or edits= on the notes from the meeting. 

The notes can be found at the following link: https://www.ietf.org/p= roceedings/95/minutes/minutes-95-lmap

Thanks,

Jason


This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mai= l, you are hereby notified that any dissemination, distribution, copying, o= r action taken in relation to the contents of and attachments to this E-mai= l 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.
 --_000_D33FF04551BD1jasonweiltwcablecom_-- From nobody Sun Apr 24 10:36:29 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B06C12B00F for ; Sun, 24 Apr 2016 10:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viavisolutions-com.20150623.gappssmtp.com 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 7xP64aBqQwnH for ; Sun, 24 Apr 2016 10:36:26 -0700 (PDT) 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 91F4412D0AE for ; Sun, 24 Apr 2016 10:36:25 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id e201so63983271wme.0 for ; Sun, 24 Apr 2016 10:36:25 -0700 (PDT) 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; bh=9klSw9w5cRDJGZdidVnsWnAnH0bBsNoKOwRO00K85NA=; b=uDzY2SxOMKnzmeZlRd8C5/v5tESFiYYkUNRY+muOKJJySgbU2nVgl6My9ga6nHwxbk yW230sXdUR5uPxQGS5LSf8xc+aMadzvZM0VSs2EEcNKG4HWzKoIEFzRwixQxwbYZj3zo uBNVYzaZQsPgz75gOlDkV8GsiiAQ9TJVS4LImIDv3VX9dIZWY6iL14Tyn00wtubOI9GN Mxvc6D+YD8IdfvYDJBR8DYVhOVJEvLFUj0+9dy4cvB95iUgjNlj5CxFLFHU0FIb7ck6z 4hbNcwTN6K7aH+BVGW04GD6yuRrgNSacWD4Co8t9sASv3u3eYF9DaAoSm0M8O/JSh+mw JL+A== 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; bh=9klSw9w5cRDJGZdidVnsWnAnH0bBsNoKOwRO00K85NA=; b=MYDEkwh9dWqyKV0MjgXvQG8U3q0mBlFu3bF01Xz+WH86GAS6pmckglLbFuzS8fQNWv mlqcpXCr/JXJI/YhoxRfeaq+rxSieZI9zU4CbhhjMGytTSU9SiJG0Hr8DJVj/N0RS2oC PDrWTXMjY0dUsAwxq1qlgw3B2iPLIBezVvnUQQK+p5mkAXCCFgwRjdtwkM38U3KAv1CY k/iNK6qPWSl9jpHOYP8THV0WgIcmFD8H304I0i2h2Qb99lSXsITaE+Gwf6x0DiYQv/LS X8lXIqmzX4yJOijA4Vl6B7Hke4iQZoS64yOUetgtRTNHrKgPPc0eKRQ/PwnUf/sRFgJa giRw== X-Gm-Message-State: AOPr4FUR+Q5keYDQpsHqaFGRLMcy6vr/CHFxpUuJOgZf4OuTcaLuyMsuqGC4CQyBJK2FvgEt46gBqeSok6Blv9st MIME-Version: 1.0 X-Received: by 10.194.186.242 with SMTP id fn18mr32461986wjc.65.1461519383847; Sun, 24 Apr 2016 10:36:23 -0700 (PDT) Received: by 10.28.155.21 with HTTP; Sun, 24 Apr 2016 10:36:23 -0700 (PDT) In-Reply-To: <20160419091432.GA2698@elstar.local> References: <20160405124838.GD58588@elstar.local> <20160405135327.GA58974@elstar.local> <20160419091432.GA2698@elstar.local> Date: Sun, 24 Apr 2016 13:36:23 -0400 Message-ID: From: Ron Stana To: Juergen Schoenwaelder , Ron Stana , lmap@ietf.org, alissa@cooperw.in Content-Type: multipart/alternative; boundary=047d7bb04deab50fba05313e7f83 Archived-At: Subject: Re: [lmap] Learning MA Capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 24 Apr 2016 17:36:28 -0000 --047d7bb04deab50fba05313e7f83 Content-Type: text/plain; charset=UTF-8 Juergen, Can you explain how we can implement RFC-7233 without modifying the LMAP YANG model? I don't see fields in the LMAP YANG model for returning the specific fields defined in RFC-7233 and I don't see a generic set of fields in the LMAP YANG model that could be used to return it either. I think the LMAP ietf-lmap-control model should be updated to include a generic set of read-only attributes within the agent object. This generic set of read-only attributes could be defined the same way was the option object that exists within schedule/action and task objects. This means each read-only attribute would consist of an id and value and the value could contain structured data. This way, the device specific capabilities I am asking about such as software licenses, number of simultaneous tests, etc can be learned by the controller and the RFC-7233 data can be returned: +--rw interfaces | +--rw interface* [name] | +--rw name string | +--rw description? string | +--rw type identityref | +--rw enabled? boolean | +--rw link-up-down-trap-enable? enumeration | +--ro last-started yang:date-and-time +--ro interfaces-state +--ro interface* [name] +--ro name string +--ro type identityref +--ro admin-status enumeration +--ro oper-status enumeration +--ro last-change? yang:date-and-time +--ro if-index int32 +--ro phys-address? yang:phys-address +--ro higher-layer-if* interface-state-ref +--ro lower-layer-if* interface-state-ref +--ro speed? yang:gauge64 +--ro statistics +--ro discontinuity-time yang:date-and-time +--ro in-octets? yang:counter64 +--ro in-unicast-pkts? yang:counter64 +--ro in-broadcast-pkts? yang:counter64 +--ro in-multicast-pkts? yang:counter64 +--ro in-discards? yang:counter32 +--ro in-errors? yang:counter32 +--ro in-unknown-protos? yang:counter32 +--ro out-octets? yang:counter64 +--ro out-unicast-pkts? yang:counter64 +--ro out-broadcast-pkts? yang:counter64 +--ro out-multicast-pkts? yang:counter64 +--ro out-discards? yang:counter32 +--ro out-errors? yang:counter32 Ron On Tue, Apr 19, 2016 at 5:14 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Apr 05, 2016 at 11:36:47PM -0400, Ron Stana wrote: > > Juergen, > > > > Steps 4,5 & 6 are performed to learn the dynamic capabilities of the MA. > > For example, when the MA is a software-only implementation, the > > capabilities will vary depending on what hardware it is installed on. > > Depending on the number of CPUs, type of NIC, etc the number of tests, > test > > options and test parameter ranges may vary. This is the type of > > information that is not expected to change after the MA has been > installed > > but it still needs to be read at least once by the Controller. > > > > For support of RFC7223, are you suggesting the MA should implement an API > > outside of the LMAP models to return that information? > > > > For a YANG-based solution, RFC 7223 (and any other relevant YANG data > model) leads to a well-defined way to obtain this information. There > is no point in duplicating this work. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --047d7bb04deab50fba05313e7f83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+SnVlcmdlbiw8ZGl2Pjxicj48L2Rpdj48ZGl2PkNhbiB5b3UgZXhwbGFp biBob3cgd2UgY2FuIGltcGxlbWVudCBSRkMtNzIzMyB3aXRob3V0IG1vZGlmeWluZyB0aGUgTE1B UCBZQU5HIG1vZGVsP8KgIEkgZG9uJiMzOTt0IHNlZSBmaWVsZHMgaW4gdGhlIExNQVAgWUFORyBt b2RlbCBmb3IgcmV0dXJuaW5nIHRoZSBzcGVjaWZpYyBmaWVsZHMgZGVmaW5lZCBpbiBSRkMtNzIz MyBhbmQgSSBkb24mIzM5O3Qgc2VlIGEgZ2VuZXJpYyBzZXQgb2YgZmllbGRzIGluIHRoZSBMTUFQ IFlBTkcgbW9kZWwgdGhhdCBjb3VsZCBiZSB1c2VkIHRvIHJldHVybiBpdCBlaXRoZXIuPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5JIHRoaW5rIHRoZSBMTUFQIGlldGYtbG1hcC1jb250cm9sIG1v ZGVsIHNob3VsZCBiZSB1cGRhdGVkIHRvIGluY2x1ZGUgYSBnZW5lcmljIHNldCBvZiByZWFkLW9u bHkgYXR0cmlidXRlcyB3aXRoaW4gdGhlIGFnZW50IG9iamVjdC7CoCBUaGlzIGdlbmVyaWMgc2V0 IG9mIHJlYWQtb25seSBhdHRyaWJ1dGVzIGNvdWxkIGJlIGRlZmluZWQgdGhlIHNhbWUgd2F5IHdh cyB0aGUgb3B0aW9uIG9iamVjdCB0aGF0IGV4aXN0cyB3aXRoaW4gc2NoZWR1bGUvYWN0aW9uIGFu ZCB0YXNrIG9iamVjdHMuwqAgVGhpcyBtZWFucyBlYWNoIHJlYWQtb25seSBhdHRyaWJ1dGUgd291 bGQgY29uc2lzdCBvZiBhbiBpZCBhbmQgdmFsdWUgYW5kIHRoZSB2YWx1ZSBjb3VsZCBjb250YWlu IHN0cnVjdHVyZWQgZGF0YS7CoCBUaGlzIHdheSwgdGhlIGRldmljZSBzcGVjaWZpYyBjYXBhYmls aXRpZXMgSSBhbSBhc2tpbmcgYWJvdXQgc3VjaCBhcyBzb2Z0d2FyZSBsaWNlbnNlcywgbnVtYmVy IG9mIHNpbXVsdGFuZW91cyB0ZXN0cywgZXRjIGNhbiBiZSBsZWFybmVkIGJ5IHRoZSBjb250cm9s bGVyIGFuZCB0aGUgUkZDLTcyMzMgZGF0YSBjYW4gYmUgcmV0dXJuZWQ6PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj48ZGl2IGNsYXNzPSIiPjxjb2RlIGNsYXNzPSIiPsKgIMKgIMKgIMKgwqA8L2Nv ZGU+PGNvZGUgY2xhc3M9IiI+Ky0tcncgaW50ZXJmYWNlczwvY29kZT48L2Rpdj48ZGl2IGNsYXNz PSIiPjxjb2RlIGNsYXNzPSIiPsKgwqDCoMKgwqDCoMKgwqA8L2NvZGU+PGNvZGUgY2xhc3M9IiI+ fMKgICstLXJ3IDwvY29kZT48Y29kZSBjbGFzcz0iIj5pbnRlcmZhY2U8L2NvZGU+PGNvZGUgY2xh c3M9IiI+KiBbbmFtZV08L2NvZGU+PC9kaXY+PGRpdiBjbGFzcz0iIj48Y29kZSBjbGFzcz0iIj7C oMKgwqDCoMKgwqDCoMKgPC9jb2RlPjxjb2RlIGNsYXNzPSIiPnzCoMKgwqDCoCArLS1ydyBuYW1l wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzdHJpbmc8L2Nv ZGU+PC9kaXY+PGRpdiBjbGFzcz0iIj48Y29kZSBjbGFzcz0iIj7CoMKgwqDCoMKgwqDCoMKgPC9j b2RlPjxjb2RlIGNsYXNzPSIiPnzCoMKgwqDCoCArLS1ydyBkZXNjcmlwdGlvbj/CoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgc3RyaW5nPC9jb2RlPjwvZGl2PjxkaXYgY2xhc3M9IiI+PGNv ZGUgY2xhc3M9IiI+wqDCoMKgwqDCoMKgwqDCoDwvY29kZT48Y29kZSBjbGFzcz0iIj58wqDCoMKg wqAgKy0tcncgdHlwZcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgaWRlbnRpdHlyZWY8L2NvZGU+PC9kaXY+PGRpdiBjbGFzcz0iIj48Y29kZSBjbGFzcz0iIj7C oMKgwqDCoMKgwqDCoMKgPC9jb2RlPjxjb2RlIGNsYXNzPSIiPnzCoMKgwqDCoCArLS1ydyBlbmFi bGVkP8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDwvY29kZT48Y29kZSBj bGFzcz0iIj5ib29sZWFuPC9jb2RlPjwvZGl2PjxkaXYgY2xhc3M9IiI+PGNvZGUgY2xhc3M9IiI+ wqDCoMKgwqDCoMKgwqDCoDwvY29kZT48Y29kZSBjbGFzcz0iIj58wqDCoMKgwqAgKy0tcncgbGlu ay11cC1kb3duLXRyYXAtZW5hYmxlP8KgwqAgZW51bWVyYXRpb248L2NvZGU+PC9kaXY+PGRpdiBj bGFzcz0iIj48Y29kZSBjbGFzcz0iIj7CoMKgwqDCoMKgwqDCoMKgPC9jb2RlPjxjb2RlIGNsYXNz PSIiPnzCoCArLS1ybyBsYXN0LXN0YXJ0ZWTCoMKgwqAgeWFuZzpkYXRlLWFuZC10aW1lPC9jb2Rl PjwvZGl2PjxkaXYgY2xhc3M9IiI+PGNvZGUgY2xhc3M9IiI+wqDCoMKgwqDCoMKgwqDCoDwvY29k ZT48Y29kZSBjbGFzcz0iIj4rLS1ybyBpbnRlcmZhY2VzLXN0YXRlPC9jb2RlPjwvZGl2PjxkaXYg Y2xhc3M9IiI+PGNvZGUgY2xhc3M9IiI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoDwvY29kZT48Y29k ZSBjbGFzcz0iIj4rLS1ybyA8L2NvZGU+PGNvZGUgY2xhc3M9IiI+aW50ZXJmYWNlPC9jb2RlPjxj b2RlIGNsYXNzPSIiPiogW25hbWVdPC9jb2RlPjwvZGl2PjxkaXYgY2xhc3M9IiI+PGNvZGUgY2xh c3M9IiI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDwvY29kZT48Y29kZSBjbGFzcz0iIj4r LS1ybyBuYW1lwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzdHJpbmc8L2NvZGU+PC9kaXY+ PGRpdiBjbGFzcz0iIj48Y29kZSBjbGFzcz0iIj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg PC9jb2RlPjxjb2RlIGNsYXNzPSIiPistLXJvIHR5cGXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIGlkZW50aXR5cmVmPC9jb2RlPjwvZGl2PjxkaXYgY2xhc3M9IiI+PGNvZGUgY2xhc3M9IiI+ wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDwvY29kZT48Y29kZSBjbGFzcz0iIj4rLS1ybyBh ZG1pbi1zdGF0dXPCoMKgwqDCoMKgwqAgZW51bWVyYXRpb248L2NvZGU+PC9kaXY+PGRpdiBjbGFz cz0iIj48Y29kZSBjbGFzcz0iIj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPC9jb2RlPjxj b2RlIGNsYXNzPSIiPistLXJvIG9wZXItc3RhdHVzwqDCoMKgwqDCoMKgwqAgZW51bWVyYXRpb248 L2NvZGU+PC9kaXY+PGRpdiBjbGFzcz0iIj48Y29kZSBjbGFzcz0iIj7CoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgPC9jb2RlPjxjb2RlIGNsYXNzPSIiPistLXJvIGxhc3QtY2hhbmdlP8KgwqDC oMKgwqDCoCB5YW5nOmRhdGUtYW5kLXRpbWU8L2NvZGU+PC9kaXY+PGRpdiBjbGFzcz0iIj48Y29k ZSBjbGFzcz0iIj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPC9jb2RlPjxjb2RlIGNsYXNz PSIiPistLXJvIDwvY29kZT48Y29kZSBjbGFzcz0iIj5pZjwvY29kZT48Y29kZSBjbGFzcz0iIj4t aW5kZXjCoMKgwqDCoMKgwqDCoMKgwqDCoCBpbnQzMjwvY29kZT48L2Rpdj48ZGl2IGNsYXNzPSIi Pjxjb2RlIGNsYXNzPSIiPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8L2NvZGU+PGNvZGUg Y2xhc3M9IiI+Ky0tcm8gcGh5cy1hZGRyZXNzP8KgwqDCoMKgwqAgeWFuZzpwaHlzLWFkZHJlc3M8 L2NvZGU+PC9kaXY+PGRpdiBjbGFzcz0iIj48Y29kZSBjbGFzcz0iIj7CoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgPC9jb2RlPjxjb2RlIGNsYXNzPSIiPistLXJvIGhpZ2hlci1sYXllci08L2Nv ZGU+PGNvZGUgY2xhc3M9IiI+aWY8L2NvZGU+PGNvZGUgY2xhc3M9IiI+KsKgwqAgPC9jb2RlPjxj b2RlIGNsYXNzPSIiPmludGVyZmFjZTwvY29kZT48Y29kZSBjbGFzcz0iIj4tc3RhdGUtcmVmPC9j b2RlPjwvZGl2PjxkaXYgY2xhc3M9IiI+PGNvZGUgY2xhc3M9IiI+wqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoDwvY29kZT48Y29kZSBjbGFzcz0iIj4rLS1ybyBsb3dlci1sYXllci08L2NvZGU+ PGNvZGUgY2xhc3M9IiI+aWY8L2NvZGU+PGNvZGUgY2xhc3M9IiI+KsKgwqDCoCA8L2NvZGU+PGNv ZGUgY2xhc3M9IiI+aW50ZXJmYWNlPC9jb2RlPjxjb2RlIGNsYXNzPSIiPi1zdGF0ZS1yZWY8L2Nv ZGU+PC9kaXY+PGRpdiBjbGFzcz0iIj48Y29kZSBjbGFzcz0iIj7CoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgPC9jb2RlPjxjb2RlIGNsYXNzPSIiPistLXJvIHNwZWVkP8KgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCB5YW5nOmdhdWdlNjQ8L2NvZGU+PC9kaXY+PGRpdiBjbGFzcz0iIj48Y29kZSBj bGFzcz0iIj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPC9jb2RlPjxjb2RlIGNsYXNzPSIi PistLXJvIHN0YXRpc3RpY3M8L2NvZGU+PC9kaXY+PGRpdiBjbGFzcz0iIj48Y29kZSBjbGFzcz0i Ij7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPC9jb2RlPjxjb2RlIGNsYXNzPSIiPistLXJv IGRpc2NvbnRpbnVpdHktdGltZcKgwqDCoCB5YW5nOmRhdGUtYW5kLXRpbWU8L2NvZGU+PC9kaXY+ PGRpdiBjbGFzcz0iIj48Y29kZSBjbGFzcz0iIj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg PC9jb2RlPjxjb2RlIGNsYXNzPSIiPistLXJvIGluLW9jdGV0cz/CoMKgwqDCoMKgwqDCoMKgwqDC oMKgIHlhbmc6Y291bnRlcjY0PC9jb2RlPjwvZGl2PjxkaXYgY2xhc3M9IiI+PGNvZGUgY2xhc3M9 IiI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDwvY29kZT48Y29kZSBjbGFzcz0iIj4rLS1y byBpbi11bmljYXN0LXBrdHM/wqDCoMKgwqDCoCB5YW5nOmNvdW50ZXI2NDwvY29kZT48L2Rpdj48 ZGl2IGNsYXNzPSIiPjxjb2RlIGNsYXNzPSIiPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8 L2NvZGU+PGNvZGUgY2xhc3M9IiI+Ky0tcm8gaW4tYnJvYWRjYXN0LXBrdHM/wqDCoMKgIHlhbmc6 Y291bnRlcjY0PC9jb2RlPjwvZGl2PjxkaXYgY2xhc3M9IiI+PGNvZGUgY2xhc3M9IiI+wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoDwvY29kZT48Y29kZSBjbGFzcz0iIj4rLS1ybyBpbi1tdWx0 aWNhc3QtcGt0cz/CoMKgwqAgeWFuZzpjb3VudGVyNjQ8L2NvZGU+PC9kaXY+PGRpdiBjbGFzcz0i Ij48Y29kZSBjbGFzcz0iIj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPC9jb2RlPjxjb2Rl IGNsYXNzPSIiPistLXJvIGluLWRpc2NhcmRzP8KgwqDCoMKgwqDCoMKgwqDCoCB5YW5nOmNvdW50 ZXIzMjwvY29kZT48L2Rpdj48ZGl2IGNsYXNzPSIiPjxjb2RlIGNsYXNzPSIiPsKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqA8L2NvZGU+PGNvZGUgY2xhc3M9IiI+Ky0tcm8gaW4tZXJyb3JzP8Kg wqDCoMKgwqDCoMKgwqDCoMKgwqAgeWFuZzpjb3VudGVyMzI8L2NvZGU+PC9kaXY+PGRpdiBjbGFz cz0iIj48Y29kZSBjbGFzcz0iIj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPC9jb2RlPjxj b2RlIGNsYXNzPSIiPistLXJvIGluLXVua25vd24tcHJvdG9zP8KgwqDCoCB5YW5nOmNvdW50ZXIz MjwvY29kZT48L2Rpdj48ZGl2IGNsYXNzPSIiPjxjb2RlIGNsYXNzPSIiPsKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqA8L2NvZGU+PGNvZGUgY2xhc3M9IiI+Ky0tcm8gb3V0LW9jdGV0cz/CoMKg wqDCoMKgwqDCoMKgwqDCoCB5YW5nOmNvdW50ZXI2NDwvY29kZT48L2Rpdj48ZGl2IGNsYXNzPSIi Pjxjb2RlIGNsYXNzPSIiPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8L2NvZGU+PGNvZGUg Y2xhc3M9IiI+Ky0tcm8gb3V0LXVuaWNhc3QtcGt0cz/CoMKgwqDCoCB5YW5nOmNvdW50ZXI2NDwv Y29kZT48L2Rpdj48ZGl2IGNsYXNzPSIiPjxjb2RlIGNsYXNzPSIiPsKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqA8L2NvZGU+PGNvZGUgY2xhc3M9IiI+Ky0tcm8gb3V0LWJyb2FkY2FzdC1wa3Rz P8KgwqAgeWFuZzpjb3VudGVyNjQ8L2NvZGU+PC9kaXY+PGRpdiBjbGFzcz0iIj48Y29kZSBjbGFz cz0iIj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPC9jb2RlPjxjb2RlIGNsYXNzPSIiPist LXJvIG91dC1tdWx0aWNhc3QtcGt0cz/CoMKgIHlhbmc6Y291bnRlcjY0PC9jb2RlPjwvZGl2Pjxk aXYgY2xhc3M9IiI+PGNvZGUgY2xhc3M9IiI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDwv Y29kZT48Y29kZSBjbGFzcz0iIj4rLS1ybyBvdXQtZGlzY2FyZHM/wqDCoMKgwqDCoMKgwqDCoCB5 YW5nOmNvdW50ZXIzMjwvY29kZT48L2Rpdj48ZGl2IGNsYXNzPSIiPjxjb2RlIGNsYXNzPSIiPsKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8L2NvZGU+PGNvZGUgY2xhc3M9IiI+Ky0tcm8gb3V0 LWVycm9ycz/CoMKgwqDCoMKgwqDCoMKgwqDCoCB5YW5nOmNvdW50ZXIzMjwvY29kZT48L2Rpdj48 L2Rpdj48ZGl2IGNsYXNzPSIiPjxjb2RlIGNsYXNzPSIiPjxicj48L2NvZGU+PC9kaXY+PGRpdiBj bGFzcz0iIj48Zm9udCBmYWNlPSJtb25vc3BhY2UiPlJvbjwvZm9udD48L2Rpdj48L2Rpdj48ZGl2 IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUdWUs IEFwciAxOSwgMjAxNiBhdCA1OjE0IEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPHNwYW4gZGly PSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJz aXR5LmRlIiB0YXJnZXQ9Il9ibGFuayI+ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5 LmRlPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij5PbiBUdWUsIEFwciAwNSwgMjAxNiBhdCAxMTozNjo0N1BNIC0wNDAw LCBSb24gU3RhbmEgd3JvdGU6PGJyPg0KJmd0OyBKdWVyZ2VuLDxicj4NCiZndDs8YnI+DQomZ3Q7 IFN0ZXBzIDQsNSAmYW1wOyA2IGFyZSBwZXJmb3JtZWQgdG8gbGVhcm4gdGhlIGR5bmFtaWMgY2Fw YWJpbGl0aWVzIG9mIHRoZSBNQS48YnI+DQomZ3Q7IEZvciBleGFtcGxlLCB3aGVuIHRoZSBNQSBp cyBhIHNvZnR3YXJlLW9ubHkgaW1wbGVtZW50YXRpb24sIHRoZTxicj4NCiZndDsgY2FwYWJpbGl0 aWVzIHdpbGwgdmFyeSBkZXBlbmRpbmcgb24gd2hhdCBoYXJkd2FyZSBpdCBpcyBpbnN0YWxsZWQg b24uPGJyPg0KJmd0OyBEZXBlbmRpbmcgb24gdGhlIG51bWJlciBvZiBDUFVzLCB0eXBlIG9mIE5J QywgZXRjIHRoZSBudW1iZXIgb2YgdGVzdHMsIHRlc3Q8YnI+DQomZ3Q7IG9wdGlvbnMgYW5kIHRl c3QgcGFyYW1ldGVyIHJhbmdlcyBtYXkgdmFyeS7CoCBUaGlzIGlzIHRoZSB0eXBlIG9mPGJyPg0K Jmd0OyBpbmZvcm1hdGlvbiB0aGF0IGlzIG5vdCBleHBlY3RlZCB0byBjaGFuZ2UgYWZ0ZXIgdGhl IE1BIGhhcyBiZWVuIGluc3RhbGxlZDxicj4NCiZndDsgYnV0IGl0IHN0aWxsIG5lZWRzIHRvIGJl IHJlYWQgYXQgbGVhc3Qgb25jZSBieSB0aGUgQ29udHJvbGxlci48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBGb3Igc3VwcG9ydCBvZiBSRkM3MjIzLCBhcmUgeW91IHN1Z2dlc3RpbmcgdGhlIE1BIHNob3Vs ZCBpbXBsZW1lbnQgYW4gQVBJPGJyPg0KJmd0OyBvdXRzaWRlIG9mIHRoZSBMTUFQIG1vZGVscyB0 byByZXR1cm4gdGhhdCBpbmZvcm1hdGlvbj88YnI+DQomZ3Q7PGJyPg0KPGJyPg0KRm9yIGEgWUFO Ry1iYXNlZCBzb2x1dGlvbiwgUkZDIDcyMjMgKGFuZCBhbnkgb3RoZXIgcmVsZXZhbnQgWUFORyBk YXRhPGJyPg0KbW9kZWwpIGxlYWRzIHRvIGEgd2VsbC1kZWZpbmVkIHdheSB0byBvYnRhaW4gdGhp cyBpbmZvcm1hdGlvbi4gVGhlcmU8YnI+DQppcyBubyBwb2ludCBpbiBkdXBsaWNhdGluZyB0aGlz IHdvcmsuPGJyPg0KPHNwYW4gY2xhc3M9IkhPRW5aYiI+PGZvbnQgY29sb3I9IiM4ODg4ODgiPjxi cj4NCi9qczxicj4NCjxicj4NCi0tPGJyPg0KSnVlcmdlbiBTY2hvZW53YWVsZGVywqAgwqAgwqAg wqAgwqAgwqBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8YnI+DQpQaG9uZTogPGEgaHJl Zj0idGVsOiUyQjQ5JTIwNDIxJTIwMjAwJTIwMzU4NyIgdmFsdWU9Iis0OTQyMTIwMDM1ODciPis0 OSA0MjEgMjAwIDM1ODc8L2E+wqAgwqAgwqAgwqAgwqBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJl bWVuIHwgR2VybWFueTxicj4NCkZheDrCoCDCoDxhIGhyZWY9InRlbDolMkI0OSUyMDQyMSUyMDIw MCUyMDMxMDMiIHZhbHVlPSIrNDk0MjEyMDAzMTAzIj4rNDkgNDIxIDIwMCAzMTAzPC9hPsKgIMKg IMKgIMKgIMKgJmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIiBy ZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmphY29icy11bml2ZXJz aXR5LmRlLzwvYT4mZ3Q7PGJyPg0KPC9mb250Pjwvc3Bhbj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJy PjwvZGl2Pg0K --047d7bb04deab50fba05313e7f83-- From nobody Mon Apr 25 01:43:05 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E3112D4FB for ; Mon, 25 Apr 2016 01:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 s8FDQVpgfW3C for ; Mon, 25 Apr 2016 01:43:02 -0700 (PDT) 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 8383612D099 for ; Mon, 25 Apr 2016 01:43:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3BCE2740; Mon, 25 Apr 2016 10:43:01 +0200 (CEST) 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 xpauRJVrG0O3; Mon, 25 Apr 2016 10:42:58 +0200 (CEST) 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, 25 Apr 2016 10:43:00 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27CF520046; Mon, 25 Apr 2016 10:43:00 +0200 (CEST) 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 G5pWSuxgAYVP; Mon, 25 Apr 2016 10:42:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D05EC2004A; Mon, 25 Apr 2016 10:42:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9E3B53AB48FA; Mon, 25 Apr 2016 10:42:58 +0200 (CEST) Date: Mon, 25 Apr 2016 10:42:58 +0200 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20160425084258.GA16977@elstar.local> Mail-Followup-To: Ron Stana , lmap@ietf.org, alissa@cooperw.in References: <20160405124838.GD58588@elstar.local> <20160405135327.GA58974@elstar.local> <20160419091432.GA2698@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: alissa@cooperw.in, lmap@ietf.org Subject: Re: [lmap] Learning MA Capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 25 Apr 2016 08:43:04 -0000 On Sun, Apr 24, 2016 at 01:36:23PM -0400, Ron Stana wrote: > Juergen, > > Can you explain how we can implement RFC-7233 without modifying the LMAP > YANG model? I don't see fields in the LMAP YANG model for returning the > specific fields defined in RFC-7233 and I don't see a generic set of fields > in the LMAP YANG model that could be used to return it either. He? You can implement RFC 7233 standalone. Why would there be special fields required in LMAP? > I think the LMAP ietf-lmap-control model should be updated to include a > generic set of read-only attributes within the agent object. This generic > set of read-only attributes could be defined the same way was the option > object that exists within schedule/action and task objects. This means > each read-only attribute would consist of an id and value and the value > could contain structured data. This way, the device specific capabilities > I am asking about such as software licenses, number of simultaneous tests, > etc can be learned by the controller and the RFC-7233 data can be returned: > > +--rw interfaces > | +--rw interface* [name] > | +--rw name string > | +--rw description? string > | +--rw type identityref > | +--rw enabled? boolean > | +--rw link-up-down-trap-enable? enumeration > | +--ro last-started yang:date-and-time > +--ro interfaces-state > +--ro interface* [name] > +--ro name string > +--ro type identityref > +--ro admin-status enumeration > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* interface-state-ref > +--ro lower-layer-if* interface-state-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 This does not make sense to me. Why solve a problem that has already been solved? There is really nothing that says a controller is only allowed to look at LMAP objects. It is a feature to not repeat what has already been specified elsewhere. /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 Apr 25 05:57:34 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A945A12D1E3 for ; Mon, 25 Apr 2016 05:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viavisolutions-com.20150623.gappssmtp.com 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 bQk1YEdXOepz for ; Mon, 25 Apr 2016 05:57:30 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 43C0412D5C6 for ; Mon, 25 Apr 2016 05:57:30 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id v200so14738142wmv.1 for ; Mon, 25 Apr 2016 05:57:30 -0700 (PDT) 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; bh=Jri76+0kCitl/Z9I79qjk49j8ZM4TaeBtpDOpKu8U9o=; b=hFypxnpXZI5cjI2hZiLZNMQsEIlNBirZBEysyvjMKGaf57RzLfT+L+JS7Za9amBW25 FeAR9TGXZ6FRlZVtWMet5E1MneSUlMNBbzLx6BnkuAA3aE4hxDvEPxMC/SR2Ha7VeC+7 r6h4vdDMRZ7lRv8d3ZWPLL6w+dDucVm+CqFzW4MRAAuRgyGb3+i0DecME3NyU1ZafkO0 QdKOl+GhDkkgscfgda/lt2AzxadLiJvRsrm740+Sj8Km7ch0seiZoGRkADrpAaKGsaB/ 2PVtgz+BX8IcEQyluORRV6NfpkGOvrspZ0v2Cv96BWxNRUXGWEaDzEpRGejgSoWYSm50 mxvA== 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; bh=Jri76+0kCitl/Z9I79qjk49j8ZM4TaeBtpDOpKu8U9o=; b=h9cdLEMktF5zPHBDbYOcEkzQwtIMMQ/sTHx7/fqJH2vzequAEApDk6Xp2TPLEv0xCZ hQox2LxYVK4KJLVKH6mrujBf2kXWNzwSvBcDbJNAuER48gyLBJMgsI8AurZ5SsA6p4+E gVxEXhlBMLhNjBQFey8v0KJrZMbuCoIRZn4cTCmKBpLS9XkKFN85Xg8pbCwbV7I+QyDi VhVwSKEN0xDVjF+xuTzoisAXzsvWy1hRAapKdDOB6WoJJS08Hsu9T6czf6PWmg4WEycB 5wlCglWvV/JvntRgR4vX6mt0PdJfihPIdto5M2Y207z8Xb+DEss7xG7S6uBWkZk1wxXF Fc/g== X-Gm-Message-State: AOPr4FX4/fIAHE88xKbq6S0Fkuqzc75iEJ2/N6jwdeRW5N3sIYy9HTrOk5d3bsYCNogpOdGx6bD3747x/Qzr6rE7 MIME-Version: 1.0 X-Received: by 10.28.45.216 with SMTP id t207mr11859695wmt.40.1461589048649; Mon, 25 Apr 2016 05:57:28 -0700 (PDT) Received: by 10.28.155.21 with HTTP; Mon, 25 Apr 2016 05:57:28 -0700 (PDT) In-Reply-To: <20160425084258.GA16977@elstar.local> References: <20160405124838.GD58588@elstar.local> <20160405135327.GA58974@elstar.local> <20160419091432.GA2698@elstar.local> <20160425084258.GA16977@elstar.local> Date: Mon, 25 Apr 2016 08:57:28 -0400 Message-ID: From: Ron Stana To: Juergen Schoenwaelder , Ron Stana , lmap@ietf.org, alissa@cooperw.in Content-Type: multipart/alternative; boundary=001a114231200d9bd505314eb851 Archived-At: Subject: Re: [lmap] Learning MA Capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 25 Apr 2016 12:57:32 -0000 --001a114231200d9bd505314eb851 Content-Type: text/plain; charset=UTF-8 Juergen, I thought the goal of LMAP was to provide a common API for managing test devices; providing a specific implementation for common operations and a pass-thru mechanism for device-specific data. Since it does that for tests, I thought it was trying to do that for capabilities and status as well. From your response it seems like it is expecting proprietary APIs to be used for obtaining status and capability information not defined by LMAP. Please confirm and if this is correct I would propose that this be stated in the LMAP documentation. Note that I am not arguing for one way or the other, I am just trying to understand what is expected. Ron On Mon, Apr 25, 2016 at 4:42 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sun, Apr 24, 2016 at 01:36:23PM -0400, Ron Stana wrote: > > Juergen, > > > > Can you explain how we can implement RFC-7233 without modifying the LMAP > > YANG model? I don't see fields in the LMAP YANG model for returning the > > specific fields defined in RFC-7233 and I don't see a generic set of > fields > > in the LMAP YANG model that could be used to return it either. > > He? You can implement RFC 7233 standalone. Why would there be special > fields required in LMAP? > > > I think the LMAP ietf-lmap-control model should be updated to include a > > generic set of read-only attributes within the agent object. This > generic > > set of read-only attributes could be defined the same way was the option > > object that exists within schedule/action and task objects. This means > > each read-only attribute would consist of an id and value and the value > > could contain structured data. This way, the device specific > capabilities > > I am asking about such as software licenses, number of simultaneous > tests, > > etc can be learned by the controller and the RFC-7233 data can be > returned: > > > > +--rw interfaces > > | +--rw interface* [name] > > | +--rw name string > > | +--rw description? string > > | +--rw type identityref > > | +--rw enabled? boolean > > | +--rw link-up-down-trap-enable? enumeration > > | +--ro last-started yang:date-and-time > > +--ro interfaces-state > > +--ro interface* [name] > > +--ro name string > > +--ro type identityref > > +--ro admin-status enumeration > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* interface-state-ref > > +--ro lower-layer-if* interface-state-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > This does not make sense to me. Why solve a problem that has already > been solved? There is really nothing that says a controller is only > allowed to look at LMAP objects. It is a feature to not repeat what > has already been specified elsewhere. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a114231200d9bd505314eb851 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Juergen,

I thought the goal of LMAP was= to provide a common API for managing test devices; providing a specific im= plementation for common operations and a pass-thru mechanism for device-spe= cific data.=C2=A0 Since it does that for tests, I thought it was trying to = do that for capabilities and status as well.=C2=A0 From your response it se= ems like it is expecting proprietary APIs to be used for obtaining status a= nd capability information not defined by LMAP.=C2=A0 Please confirm and if = this is correct I would propose that this be stated in the LMAP documentati= on. Note that I am not arguing for one way or the other, I am just trying t= o understand what is expected.

Ron

On Mon, Apr 25, 2016 = at 4:42 AM, Juergen Schoenwaelder <j.schoenwaelder@jaco= bs-university.de> wrote:
On= Sun, Apr 24, 2016 at 01:36:23PM -0400, Ron Stana wrote:
> Juergen,
>
> Can you explain how we can implement RFC-7233 without modifying the LM= AP
> YANG model?=C2=A0 I don't see fields in the LMAP YANG model for re= turning the
> specific fields defined in RFC-7233 and I don't see a generic set = of fields
> in the LMAP YANG model that could be used to return it either.

He? You can implement RFC 7233 standalone. Why would there be special
fields required in LMAP?

> I think the LMAP ietf-lmap-control model should be updated to include = a
> generic set of read-only attributes within the agent object.=C2=A0 Thi= s generic
> set of read-only attributes could be defined the same way was the opti= on
> object that exists within schedule/action and task objects.=C2=A0 This= means
> each read-only attribute would consist of an id and value and the valu= e
> could contain structured data.=C2=A0 This way, the device specific cap= abilities
> I am asking about such as software licenses, number of simultaneous te= sts,
> etc can be learned by the controller and the RFC-7233 data can be retu= rned:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw interfaces
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw interface* [name]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw name=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw descriptio= n?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw type=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 identityref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw enabled?= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boole= an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw link-up-do= wn-trap-enable?=C2=A0 =C2=A0enumeration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro last-started=C2=A0 =C2= =A0 yang:date-and-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro interfaces-state
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro interface* [name]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro name=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro type=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identityref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro admin-stat= us=C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro oper-statu= s=C2=A0 =C2=A0 =C2=A0 =C2=A0 enumeration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro last-chang= e?=C2=A0 =C2=A0 =C2=A0 =C2=A0yang:date-and-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro if-index= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro phys-addre= ss?=C2=A0 =C2=A0 =C2=A0 yang:phys-address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro higher-lay= er-if*=C2=A0 =C2=A0interface-state-ref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro lower-laye= r-if*=C2=A0 =C2=A0 interface-state-ref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro speed?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:gauge64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro statistics=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro discontinu= ity-time=C2=A0 =C2=A0 yang:date-and-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-octets?= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-unicast= -pkts?=C2=A0 =C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-broadca= st-pkts?=C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-multica= st-pkts?=C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-discard= s?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-errors?= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-unknown= -protos?=C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-octets= ?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-unicas= t-pkts?=C2=A0 =C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-broadc= ast-pkts?=C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-multic= ast-pkts?=C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-discar= ds?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-errors= ?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32

This does not make sense to me. Why solve a problem that has already
been solved? There is really nothing that says a controller is only
allowed to look at LMAP objects. It is a feature to not repeat what
has already been specified elsewhere.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<htt= p://www.jacobs-university.de/>

--001a114231200d9bd505314eb851-- From nobody Mon Apr 25 06:14:18 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9935612D5C0 for ; Mon, 25 Apr 2016 06:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 dXKrgSSZdbeM for ; Mon, 25 Apr 2016 06:14:14 -0700 (PDT) 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 4ADD212D5BF for ; Mon, 25 Apr 2016 06:14:14 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 12E728DF; Mon, 25 Apr 2016 15:14:13 +0200 (CEST) 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 WZhsC2FXQ0MD; Mon, 25 Apr 2016 15:14:09 +0200 (CEST) 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, 25 Apr 2016 15:14:12 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47ECA20047; Mon, 25 Apr 2016 15:14:12 +0200 (CEST) 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 U9iZBL2Gj9kS; Mon, 25 Apr 2016 15:14:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A13A20046; Mon, 25 Apr 2016 15:14:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 711803AB505D; Mon, 25 Apr 2016 15:14:09 +0200 (CEST) Date: Mon, 25 Apr 2016 15:14:08 +0200 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20160425131408.GA17402@elstar.local> Mail-Followup-To: Ron Stana , lmap@ietf.org, alissa@cooperw.in References: <20160405124838.GD58588@elstar.local> <20160405135327.GA58974@elstar.local> <20160419091432.GA2698@elstar.local> <20160425084258.GA16977@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: alissa@cooperw.in, lmap@ietf.org Subject: Re: [lmap] Learning MA Capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 25 Apr 2016 13:14:16 -0000 On Mon, Apr 25, 2016 at 08:57:28AM -0400, Ron Stana wrote: > Juergen, > > I thought the goal of LMAP was to provide a common API for managing test > devices; providing a specific implementation for common operations and a > pass-thru mechanism for device-specific data. Since it does that for > tests, I thought it was trying to do that for capabilities and status as > well. From your response it seems like it is expecting proprietary APIs to > be used for obtaining status and capability information not defined by > LMAP. Please confirm and if this is correct I would propose that this be > stated in the LMAP documentation. Note that I am not arguing for one way or > the other, I am just trying to understand what is expected. > There is no need to use proprietary APIs. You can use NETCONF or RESTCONF to access the ietf-interfaces YANG data model in the same way you use NETCONF or RESTCONF to access the ietf-lmap-control 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 Mon Apr 25 10:08:54 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234C312D0DA for ; Mon, 25 Apr 2016 10:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viavisolutions-com.20150623.gappssmtp.com 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 WcwN53Wt7ZAx for ; Mon, 25 Apr 2016 10:08:51 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 C2E4A12D630 for ; Mon, 25 Apr 2016 10:08:50 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id n3so138442172wmn.0 for ; Mon, 25 Apr 2016 10:08:50 -0700 (PDT) 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; bh=9vKJI5Da2eZYOT4bCAbf+QMqKA3LKqenEsTBnBOcYI4=; b=qYUgFhO1OEUTSt7uwReVuBdWmDWZVNdWEqlrUmQMrCpVPg44fLBygtdihj6M+za2Vz CasKUHCgIFfQfTMli/9S71rw2X65un+s4oN3OrZqXskCYNMFd/lXvLFHUPPTqoMaJmo0 aCKxNT/lVVLCcg7fLgnqO2iwyjoafap3uOYGJ7pqllW6f/j2yKwHZOlG97Q0zzJ2vyPy 7tVEnN3nd4oZx8oentxwqYyD+W3Idz2+Sj7IeNvMKZDFf4dnB1EarCXoB6cjhBs9K7fn e1uDbf2cdDMUcRPNfyWW/8JhB7dhtL1N+8KhGtBOqe6FUaiERgogRtHJnm7gl1iX2l3V 6E8g== 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; bh=9vKJI5Da2eZYOT4bCAbf+QMqKA3LKqenEsTBnBOcYI4=; b=N1biiKojpM0ocNRfRX4gSAPV3gNvX6No8o4QDtj5mXaUaUjQHDCzg9zM3qn1BEWc1j txE7vQ3hGkhVja71KBZaafntOWCUd9fCoPR6Ozm1E+m/5IaePmNrfAlQUXxFHc1uh+9B zehXVCYSmaFP0hMUirjnW4dW5Bbzp3PwG6f0lfv1r9ON/kkdF3yM+MEtYPus3fNh49pw 3eH83Bntft54JsmmfNv1umdONq5n4BNR9t0cUfvHXxWkJ9xUha4SmD7JvXfTsf/4Q+qY LKxGScuIr7YHbyIyPgiFixPyr7Wrp3CwQd6m2MLbeaDrIK5Ouogn6ryrvV1KNWdvPfrv klVA== X-Gm-Message-State: AOPr4FWbEpZfpgOm+Z/SrMaOXU9Tc/uX4ZFMKZ4vVtgt3dBGUzlSmU1wE8AUaxnURwqOz0qb45HmP7aHziPWP4hr MIME-Version: 1.0 X-Received: by 10.194.186.242 with SMTP id fn18mr38433674wjc.65.1461604129119; Mon, 25 Apr 2016 10:08:49 -0700 (PDT) Received: by 10.28.155.21 with HTTP; Mon, 25 Apr 2016 10:08:48 -0700 (PDT) In-Reply-To: <20160425131408.GA17402@elstar.local> References: <20160405124838.GD58588@elstar.local> <20160405135327.GA58974@elstar.local> <20160419091432.GA2698@elstar.local> <20160425084258.GA16977@elstar.local> <20160425131408.GA17402@elstar.local> Date: Mon, 25 Apr 2016 13:08:48 -0400 Message-ID: From: Ron Stana To: Juergen Schoenwaelder , Ron Stana , lmap@ietf.org, alissa@cooperw.in Content-Type: multipart/alternative; boundary=047d7bb04deaeb52ba0531523a68 Archived-At: Subject: Re: [lmap] Learning MA Capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 25 Apr 2016 17:08:53 -0000 --047d7bb04deaeb52ba0531523a68 Content-Type: text/plain; charset=UTF-8 Juergen, I was using the term 'proprietary' incorrectly. I was intending it to mean 'device-specific' but it really means 'vendor-specific'. I can see now that having additional standards-based implementations is in agreement with LMAP and so implementing RFC-7223 outside of LMAP is acceptable for extending the interface state information. While this results in device-specific implementations, they are not vendor-specific. Concerning how an LMAP client learns the vendor specific capabilities of an MA, are you in agreement that this would require a vendor-specific API? Since test configurations consist of vendor-specific information and LMAP addresses this, I thought LMAP might also provide an approach for vendor-specific capabilities. I can understand if this is outside the scope of LMAP and so left for vendors to provide. Ron On Mon, Apr 25, 2016 at 9:14 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Apr 25, 2016 at 08:57:28AM -0400, Ron Stana wrote: > > Juergen, > > > > I thought the goal of LMAP was to provide a common API for managing test > > devices; providing a specific implementation for common operations and a > > pass-thru mechanism for device-specific data. Since it does that for > > tests, I thought it was trying to do that for capabilities and status as > > well. From your response it seems like it is expecting proprietary APIs > to > > be used for obtaining status and capability information not defined by > > LMAP. Please confirm and if this is correct I would propose that this be > > stated in the LMAP documentation. Note that I am not arguing for one way > or > > the other, I am just trying to understand what is expected. > > > > There is no need to use proprietary APIs. > > You can use NETCONF or RESTCONF to access the ietf-interfaces YANG > data model in the same way you use NETCONF or RESTCONF to access the > ietf-lmap-control 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 > --047d7bb04deaeb52ba0531523a68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Juergen,

I was using the term 'prop= rietary' incorrectly.=C2=A0 I was intending it to mean 'device-spec= ific' but it really means 'vendor-specific'.

I can see now that having additional standards-based implementations= is in agreement with LMAP and so implementing RFC-7223 outside of LMAP is = acceptable for extending the interface state information.=C2=A0 While this = results in device-specific implementations, they are not vendor-specific.

Concerning how an LMAP client learns the vendor spe= cific capabilities of an MA, are you in agreement that this would require a= vendor-specific API? Since test configurations consist of vendor-specific = information and LMAP addresses this, I thought LMAP might also provide an a= pproach for vendor-specific capabilities.=C2=A0 I can understand if this is= outside the scope of LMAP and so left for vendors to provide.
Ron=C2=A0

On Mon, Apr 25, 2016 at 9:14 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote= :
On Mon, Apr 25, 2016 at 08:57:28AM -040= 0, Ron Stana wrote:
> Juergen,
>
> I thought the goal of LMAP was to provide a common API for managing te= st
> devices; providing a specific implementation for common operations and= a
> pass-thru mechanism for device-specific data.=C2=A0 Since it does that= for
> tests, I thought it was trying to do that for capabilities and status = as
> well.=C2=A0 From your response it seems like it is expecting proprieta= ry APIs to
> be used for obtaining status and capability information not defined by=
> LMAP.=C2=A0 Please confirm and if this is correct I would propose that= this be
> stated in the LMAP documentation. Note that I am not arguing for one w= ay or
> the other, I am just trying to understand what is expected.
>

There is no need to use proprietary APIs.

You can use NETCONF or RESTCONF to access the ietf-interfaces YANG
data model in the same way you use NETCONF or RESTCONF to access the
ietf-lmap-control YANG data model.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<htt= p://www.jacobs-university.de/>

--047d7bb04deaeb52ba0531523a68-- From nobody Mon Apr 25 10:21:58 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786E612D655 for ; Mon, 25 Apr 2016 10:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 Hq4ByHFiyEvi for ; Mon, 25 Apr 2016 10:21:46 -0700 (PDT) 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 0CE6B12D64F for ; Mon, 25 Apr 2016 10:21:46 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5A765903; Mon, 25 Apr 2016 19:21:44 +0200 (CEST) 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 mX66l8jzqCvQ; Mon, 25 Apr 2016 19:21:40 +0200 (CEST) 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, 25 Apr 2016 19:21:43 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93A2E20047; Mon, 25 Apr 2016 19:21:43 +0200 (CEST) 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 9uCrx8PvdwQI; Mon, 25 Apr 2016 19:21:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89D5020046; Mon, 25 Apr 2016 19:21:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2B59E3AB597A; Mon, 25 Apr 2016 19:21:39 +0200 (CEST) Date: Mon, 25 Apr 2016 19:21:38 +0200 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20160425172135.GA18095@elstar.local> Mail-Followup-To: Ron Stana , lmap@ietf.org, alissa@cooperw.in References: <20160405124838.GD58588@elstar.local> <20160405135327.GA58974@elstar.local> <20160419091432.GA2698@elstar.local> <20160425084258.GA16977@elstar.local> <20160425131408.GA17402@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: alissa@cooperw.in, lmap@ietf.org Subject: Re: [lmap] Learning MA Capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 25 Apr 2016 17:21:49 -0000 On Mon, Apr 25, 2016 at 01:08:48PM -0400, Ron Stana wrote: > Juergen, > > I was using the term 'proprietary' incorrectly. I was intending it to mean > 'device-specific' but it really means 'vendor-specific'. > > I can see now that having additional standards-based implementations is in > agreement with LMAP and so implementing RFC-7223 outside of LMAP is > acceptable for extending the interface state information. While this > results in device-specific implementations, they are not vendor-specific. > > Concerning how an LMAP client learns the vendor specific capabilities of an > MA, are you in agreement that this would require a vendor-specific API? No. > Since test configurations consist of vendor-specific information and LMAP > addresses this, I thought LMAP might also provide an approach for > vendor-specific capabilities. I can understand if this is outside the > scope of LMAP and so left for vendors to provide. RFC 7223 is as interoperable as the LMAP YANG data model. There is a standard mechanism to discover the data models supported, the details depend on the protocol. I do not understand why you see a requirement for vendor-specific APIs from the use of RFC 7223. /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 Apr 25 11:56:10 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383CF12B041 for ; Mon, 25 Apr 2016 11:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viavisolutions-com.20150623.gappssmtp.com 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 nqdtH4wqDyg2 for ; Mon, 25 Apr 2016 11:56:07 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 9B5C112D601 for ; Mon, 25 Apr 2016 11:56:07 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id u206so142331235wme.1 for ; Mon, 25 Apr 2016 11:56:07 -0700 (PDT) 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; bh=3Q1Qk+TFbWspEtl+Z/InNa7vCw0I/TaGhzQmG1MNy9g=; b=nIy3w3snQDfDv81H6Ju7unqsS4hV9gVQJ8BccjznV4KVIxC5+ElOnQx9PAXpBEVdCS 4JY5drwXbaggkdPnpr3YaBDINAq5PglJTxcGlGWfsrplkoARtBS7w8PZRsvFatT5zm5+ KLk8Ir9Nuh/n5DJy/Y/AWTRnnT6XqPyCtpERvSdbN+D0bhqflf2UhBNZ0YCnJFQBcOwi 4OODzGtBLCJ633pzJm52qyONQCosmMmA+xxdoi97uODFWRKa5niZ84f1hjcH5RCaiCho P8I+M+43/Qq+9vdpWKovSe+X/UTx3emO5c00Oppse0cYdjyT3jdhagtS2TkgC6tY7I35 kMWA== 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; bh=3Q1Qk+TFbWspEtl+Z/InNa7vCw0I/TaGhzQmG1MNy9g=; b=kHUZt2RIi4lffg3erGQWxRv8nvt4hiSs9qillQdAeK3ch/LgGaLcgR7j6ZWxSMq8P1 3ZDq2aqrYiMSA+5DCkMkEaAqAIqPSoa5EX6kVvVxMpjtSFj+H8lRwVfG9HoXvlhLb+EQ IxB+mm9hC0BdE0LebG2qD55qehJJZnhCfBrCg6427dH35AciiaP0XzZO/Bi6hh8a0DG2 NOQYhzCcLaG9R/ZR7NfcwE/oE5VmJF0zDCQOR2AnfMC6mD9Axe3/9xBVwQpiQ0VNxUHc XOeyE5I/upQlBYJCz4j2fpP2FK+HIq4ROWOAp9IZA3CvG3JPRCTLFrHba928x5FSzHhO zUZQ== X-Gm-Message-State: AOPr4FUl5SDGrj1swVFYeovW5uT/hJs5gknU4fNImZ6lSndTZC92WZFx5yKrjMyRfi+QizAtxGslpVFvWVtpgY22 MIME-Version: 1.0 X-Received: by 10.194.185.179 with SMTP id fd19mr35950770wjc.107.1461610565937; Mon, 25 Apr 2016 11:56:05 -0700 (PDT) Received: by 10.28.155.21 with HTTP; Mon, 25 Apr 2016 11:56:05 -0700 (PDT) In-Reply-To: <20160425172135.GA18095@elstar.local> References: <20160405124838.GD58588@elstar.local> <20160405135327.GA58974@elstar.local> <20160419091432.GA2698@elstar.local> <20160425084258.GA16977@elstar.local> <20160425131408.GA17402@elstar.local> <20160425172135.GA18095@elstar.local> Date: Mon, 25 Apr 2016 14:56:05 -0400 Message-ID: From: Ron Stana To: Juergen Schoenwaelder , Ron Stana , lmap@ietf.org, alissa@cooperw.in Content-Type: multipart/alternative; boundary=047d7bb0402a955c95053153ba9c Archived-At: Subject: Re: [lmap] Learning MA Capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 25 Apr 2016 18:56:09 -0000 --047d7bb0402a955c95053153ba9c Content-Type: text/plain; charset=UTF-8 Juergen, RFC-7223 just offers extra information about the network interfaces. My original question was two-fold: how does an MA let a client know about vendor-specific capabilities during the Controller & MA registration/capabilities process and would the approach taken for this be similar for extending the status to include something like RFC-7223 during the Controller & MA status retrieval process. I now understand if a device wants to support RFC-7223 it just implements it outside of LMAP - thank you for clarifying this. The registration and capabilities exchange is a separate part of the LMAP architecture and that is the part I am still asking about. There will be vendor-specific capabilities that clients of the MAs will need to obtain so they understand the limitations of a given device and adjust test configurations accordingly. For example, when dealing with test devices that are installed as virtual machines on various hardware platforms, the number of simultaneous tests and data streams generated supported can vary based on the amount of memory, hard drive space and NIC. These same capabilities could also be limited by licenses/software options. I am trying to determine if this type of information is expected to be obtained by the controller during the capabilities exchange or if it is done outside of LMAP. Ron On Mon, Apr 25, 2016 at 1:21 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Apr 25, 2016 at 01:08:48PM -0400, Ron Stana wrote: > > Juergen, > > > > I was using the term 'proprietary' incorrectly. I was intending it to > mean > > 'device-specific' but it really means 'vendor-specific'. > > > > I can see now that having additional standards-based implementations is > in > > agreement with LMAP and so implementing RFC-7223 outside of LMAP is > > acceptable for extending the interface state information. While this > > results in device-specific implementations, they are not vendor-specific. > > > > Concerning how an LMAP client learns the vendor specific capabilities of > an > > MA, are you in agreement that this would require a vendor-specific API? > > No. > > > Since test configurations consist of vendor-specific information and LMAP > > addresses this, I thought LMAP might also provide an approach for > > vendor-specific capabilities. I can understand if this is outside the > > scope of LMAP and so left for vendors to provide. > > RFC 7223 is as interoperable as the LMAP YANG data model. There is a > standard mechanism to discover the data models supported, the details > depend on the protocol. I do not understand why you see a requirement > for vendor-specific APIs from the use of RFC 7223. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --047d7bb0402a955c95053153ba9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Juergen,

RFC-7223 just offers extra inf= ormation about the network interfaces.=C2=A0 My original question was two-f= old: how does an MA let a client know about vendor-specific capabilities du= ring the Controller & MA registration/capabilities process and would th= e approach taken for this be similar for extending the status to include so= mething like RFC-7223 during the Controller & MA status retrieval proce= ss.=C2=A0 I now understand if a device wants to support RFC-7223 it just im= plements it outside of LMAP - thank you for clarifying this. =C2=A0

The registration and capabilities exchange is a separate = part of the LMAP architecture and that is the part I am still asking about.= =C2=A0 There will be vendor-specific capabilities that clients of the MAs w= ill need to obtain so they understand the limitations of a given device and= adjust test configurations accordingly.=C2=A0 For example, when dealing wi= th test devices that are installed as virtual machines on various hardware = platforms, the number of simultaneous tests and data streams generated supp= orted can vary based on the amount of memory, hard drive space and NIC.=C2= =A0 These same capabilities could also be limited by licenses/software opti= ons.=C2=A0 I am trying to determine if this type of information is expected= to be obtained by the controller during the capabilities exchange or if it= is done outside of LMAP. =C2=A0

Ron



On Mon, Apr 25, 2016 at 1:21 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote= :
On Mon, Apr 25, 2016 at 01:08:48PM -040= 0, Ron Stana wrote:
> Juergen,
>
> I was using the term 'proprietary' incorrectly.=C2=A0 I was in= tending it to mean
> 'device-specific' but it really means 'vendor-specific'= ;.
>
> I can see now that having additional standards-based implementations i= s in
> agreement with LMAP and so implementing RFC-7223 outside of LMAP is > acceptable for extending the interface state information.=C2=A0 While = this
> results in device-specific implementations, they are not vendor-specif= ic.
>
> Concerning how an LMAP client learns the vendor specific capabilities = of an
> MA, are you in agreement that this would require a vendor-specific API= ?

No.

> Since test configurations consist of vendor-specific information and L= MAP
> addresses this, I thought LMAP might also provide an approach for
> vendor-specific capabilities.=C2=A0 I can understand if this is outsid= e the
> scope of LMAP and so left for vendors to provide.

RFC 7223 is as interoperable as the LMAP YANG data model. There is a
standard mechanism to discover the data models supported, the details
depend on the protocol. I do not understand why you see a requirement
for vendor-specific APIs from the use of RFC 7223.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<htt= p://www.jacobs-university.de/>

--047d7bb0402a955c95053153ba9c-- From nobody Mon Apr 25 12:24:44 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDCA12D692 for ; Mon, 25 Apr 2016 12:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 yNpSsIX-FVme for ; Mon, 25 Apr 2016 12:24:41 -0700 (PDT) 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 7DFA012D6B5 for ; Mon, 25 Apr 2016 12:24:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 48751116C; Mon, 25 Apr 2016 21:24:40 +0200 (CEST) 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 UP4zfY7c9Vl6; Mon, 25 Apr 2016 21:24:35 +0200 (CEST) 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, 25 Apr 2016 21:24:39 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33BE520047; Mon, 25 Apr 2016 21:24:39 +0200 (CEST) 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 kb6MdjiL45VJ; Mon, 25 Apr 2016 21:24:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7507A20046; Mon, 25 Apr 2016 21:24:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 273BC3AB5F20; Mon, 25 Apr 2016 21:24:35 +0200 (CEST) Date: Mon, 25 Apr 2016 21:24:34 +0200 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20160425192432.GB18221@elstar.local> Mail-Followup-To: Ron Stana , lmap@ietf.org, alissa@cooperw.in References: <20160405135327.GA58974@elstar.local> <20160419091432.GA2698@elstar.local> <20160425084258.GA16977@elstar.local> <20160425131408.GA17402@elstar.local> <20160425172135.GA18095@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: alissa@cooperw.in, lmap@ietf.org Subject: Re: [lmap] Learning MA Capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 25 Apr 2016 19:24:43 -0000 On Mon, Apr 25, 2016 at 02:56:05PM -0400, Ron Stana wrote: > Juergen, > > RFC-7223 just offers extra information about the network interfaces. My > original question was two-fold: how does an MA let a client know about > vendor-specific capabilities during the Controller & MA > registration/capabilities process and would the approach taken for this be > similar for extending the status to include something like RFC-7223 during > the Controller & MA status retrieval process. I now understand if a device > wants to support RFC-7223 it just implements it outside of LMAP - thank you > for clarifying this. > > The registration and capabilities exchange is a separate part of the LMAP > architecture and that is the part I am still asking about. There will be > vendor-specific capabilities that clients of the MAs will need to obtain so > they understand the limitations of a given device and adjust test > configurations accordingly. For example, when dealing with test devices > that are installed as virtual machines on various hardware platforms, the > number of simultaneous tests and data streams generated supported can vary > based on the amount of memory, hard drive space and NIC. These same > capabilities could also be limited by licenses/software options. I am > trying to determine if this type of information is expected to be obtained > by the controller during the capabilities exchange or if it is done outside > of LMAP. The LMAP capability definitions cover hardware and firmware description and the version of the measurement agent. This is about it. If a vendor wants to provide additional information, the vendor can extend the models. Note that there is already some resistance to report or control the storage managed by the LMAP agent itself. The good news is that there may be eventually an equivalent of the HOST-RESOURCES-MIB in the YANG world and that would give you at least some information about storage and processing resources - but from that you would still not know how many tests you can run concurrently without risking the tests to impact each other. I guess this is all out of scope for now, we are better off with trying to finish LMAP version 1, getting implementation and deployment experience, and then we hopefully better understand what needs to be changed or added. /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 Apr 27 08:09:12 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4114D12D11F for ; Wed, 27 Apr 2016 08:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5yZbtLzn456d for ; Wed, 27 Apr 2016 08:09:03 -0700 (PDT) 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 4FA2D12D1D6 for ; Wed, 27 Apr 2016 08:09:03 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 3ECACC39185; Wed, 27 Apr 2016 15:08:59 +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 u3RF91gi012738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Apr 2016 15:09:01 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 u3RF91vP014968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Apr 2016 15:09:01 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.246]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 27 Apr 2016 11:09:01 -0400 From: "Carey, Timothy (Nokia - US)" To: "Carey, Timothy (Nokia - US)" , "EXT MORTON, ALFRED C (AL)" , Ron Stana Thread-Topic: [lmap] LMAP: Defining the Schedule's events Thread-Index: AQHRmMcIsS7v7zskLkW09Igh4D3XRZ+O62+QgAEVwQCAABu1AIABEw7wgAzLttA= Date: Wed, 27 Apr 2016 15:09:01 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6513FF@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A627E42@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77012A631C28@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4587DEFEC7@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: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A6513FFUS70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: Defining the Schedule's events X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 27 Apr 2016 15:09:11 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A6513FFUS70UWXCHMBA0_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGVhbSwNCg0KVGhpcyBtaWdodCBoYXZlIGJlZW4gbG9zdCBpbiB0aGUgZW1haWwgdGhyZWFkcyBz byBJIGFtIHJldml2aW5nIHRoZSBkaXNjdXNzaW9uLg0KDQpGcm9tOiBDYXJleSwgVGltb3RoeSAo Tm9raWEgLSBVUykNClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE5LCAyMDE2IDc6MDEgQU0NClRvOiAn RVhUIE1PUlRPTiwgQUxGUkVEIEMgKEFMKSc7IFJvbiBTdGFuYQ0KQ2M6IGxtYXBAaWV0Zi5vcmcN ClN1YmplY3Q6IFJFOiBbbG1hcF0gTE1BUDogRGVmaW5pbmcgdGhlIFNjaGVkdWxlJ3MgZXZlbnRz DQoNCkFsLA0KSW5saW5lIDxUQUM+DQoNCkZyb206IEVYVCBNT1JUT04sIEFMRlJFRCBDIChBTCkg W21haWx0bzphY21vcnRvbkBhdHQuY29tXQ0KU2VudDogTW9uZGF5LCBBcHJpbCAxOCwgMjAxNiA1 OjE5IFBNDQpUbzogUm9uIFN0YW5hOyBDYXJleSwgVGltb3RoeSAoTm9raWEgLSBVUykNCkNjOiBs bWFwQGlldGYub3JnPG1haWx0bzpsbWFwQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtsbWFwXSBM TUFQOiBEZWZpbmluZyB0aGUgU2NoZWR1bGUncyBldmVudHMNCg0KSGkgUm9uIGFuZCBUaW0sDQoN CnRyeWluZyB0byBtYWtlIGEgZmV3IG1pbnV0ZXMgZm9yIHRoaXMuLi4NCg0KVGhlIFJlZ2lzdHJ5 IEVudHJpZXMqIGZvciB0aGUgTWV0cmljcyBpbmNsdWRlIFJ1bi10aW1lIFBhcmFtZXRlcnMNCmZv ciB0aGUgU3RhcnQgdGltZSBhbmQgRW5kIFRpbWUsIGJ1dCBvbmUgb2YgdGhlbSBjb3VsZCBiZSBp bnRlcnByZXRlZA0KYXMgYSBEdXJhdGlvbiBpZiBzcGVjaWZpZWQgY29ycmVjdGx5ICh0aGUgU3Rh cnQgdGltZSBtdXN0IGJlIGFsbCB6ZXJvcywNCnRoZW4gdGhlIFN0b3AgdGltZSBpcyBpbnRlcnBy ZXRlZCBhcyBhIGR1cmF0aW9uLCBBTkQgdGhlIGFjdHVhbCBzdGFydA0KYW5kIHN0b3AgdGltZSBh cmUgY29udHJvbGxlZCB0aHJvdWdoIOKAnG90aGVyIG1lYW5z4oCdKS4gU2VlDQoNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0taW5pdGlhbC1yZWdpc3RyeS0wMCNz ZWN0aW9uLTQuMy41DQoNCuKAnE90aGVyIG1lYW5z4oCdIHdvdWxkIGJlIHRoZSBTY2hlZHVsZSBv YmplY3QgYW5kIHRoZSBFdmVudCBvYmplY3QuDQpBcyBJIHVuZGVyc3RhbmQgaXQgYm90aCBzY2hl ZHVsZSBhbmQgZXZlbnQgb2JqZWN0cyBoYXZlIHN0YXJ0IHRpbWUNCmFuZCBzdG9wIHRpbWUgc3Bl Y2lmaWNhdGlvbnMgYXZhaWxhYmxlLCBhbmQgRXZlbnQgaGFzIER1cmF0aW9uIHNwZWNpZmljYXRp b24NCmF2YWlsYWJsZSB3aGljaCB3b3VsZCBiZSB1c2VmdWwgZm9yIHJlY3VycmluZyBldmVudHMg KHBlcmlvZGljIG9yIGNhbGVuZGFyKS4NCg0KPFRBQz4gVGhlIHNjaGVkdWxl4oCZcyB0aW1lciBp cyBzdWZmaWNpZW50IHRvIHN0YXRlIHdoZW4gdGhlIGluaXRpYWwgYWN0aW9uKHMpIGFyZSBpbnZv a2VkLiBJIHNheSBhY3Rpb25zIGJlY2F1c2UgdGhlIGV4ZWN1dGlvbiBtb2RlIGZvciB0aGUgc2No ZWR1bGXigJlzIGFjdGlvbuKAmXMgY291bGQgYmUgcGFyYWxsZWwuIEluIHRoZSBjYXNlIHdoZW4g dGhlIHNjaGVkdWxl4oCZcyBleGVjdXRpb24gbW9kZSBpcyBzZXF1ZW50aWFsIHRoZW4gaXQgd291 bGQgYmUgc3VmZmljaWVudCB0byBzdGF0ZSB3aGVuIHRoZSBmaXJzdCBhY3Rpb24gaXMgaW52b2tl ZC4NCldoYXQgdGhlIHNjaGVkdWxl4oCZcyB0aW1lciBkb2VzbuKAmXQgZG8gaXMgc3BlY2lmeSB0 aGUgZHVyYXRpb24gb2YgdGhlIGluZGl2aWR1YWwgYWN0aW9uKHMpIG9yIHdoZW4gdGhlIHNlY29u ZCBhY3Rpb24gaXMgZXhlY3V0ZWQgaW4gcmVsYXRpb24gdG8gdGhlIGNvbXBsZXRpb24gb2YgdGhl IGZpcnN0IGFjdGlvbi4gV2hhdCB3ZSB3b3VsZCBuZWVkIHRvIGRvIGlzIGVpdGhlcjogUGFzcyB0 aGUgZHVyYXRpb24gb2YgYWN0aW9uIGJhc2VkIG9uIHRoZSBvcHRpb25zIChUMCA9IHplcm8sIFRm PXNvbWUgZHVyYXRpb24pIG9yIHdlIGNvdWxkIHB1dCBhIHRpbWVyIG9uIHRoZSBhY3Rpb24g4oCT IHdoaWNoIHdvdWxkIHByb3ZpZGUgdGhlIGV4dGVybmFsIGNvbnRyb2wgdGhhdCB3b3VsZCBhbGxv dyB0aGUgc3RhcnQgdG8gYmUgYmV0dGVyIGNvbnRyb2xsZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhl IG92ZXJhbGwgc2NoZWR1bGUuDQoNCkV2ZW50dWFsbHksIHRoZSBNQSBoYXMgdG8gcmVwb3J0IHRo ZSByZXN1bHRzIG9mIHRoZSBtZXRyaWMvbWVhc3VyZW1lbnQuDQpUaGF04oCZcyB3aGVuIHRoZSBh Y3R1YWwgKFJFRCkgc3RhcnQgYW5kIGVuZCB0aW1lcyB3aGVuIHBhY2tldHMgd2VyZSBhY3R1YWxs eQ0KZmxvd2luZyBiZXR3ZWVuIG1lYXN1cmVtZW50IHBvaW50cyBhcmUgcmVwb3J0ZWQsIGFjY29y ZGluZyB0byB0aGUgUmVnaXN0cnkgRW50cnkuDQpTZWU6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0taW5pdGlhbC1yZWdpc3RyeS0wMCNzZWN0aW9uLTQuNC4y DQoNCjxUQUM+IFRoZXNlIHNlZW0gdG8gYmUgdGhlIGFjdHVhbCDigJMgbm90IGNvbmZpZ3VyZWQg c3RhcnQgYW5kIGVuZCB0aW1lcw0KSW50ZXJlc3RpbmcgSSB0aGluayB0aGVyZSBtaWdodCBiZSBh IHByb2JsZW0gaW4gdGhlIGRyYWZ0IHdpdGggVGYgYXMgaXQgd291bGQgYmUg4oCcZW5k4oCdIG9m IHRoZSBpbnRlcnZhbCBub3QgdGhlIOKAnHN0YXJ04oCdIG9mIHRoZSBpbnRlcnZhbD8NCiAgIFQw IHRoZSBzdGFydCBvZiBhIG1lYXN1cmVtZW50IGludGVydmFsLCAoZm9ybWF0ICJkYXRlLWFuZC10 aW1lIiBhcw0KICAgICAgc3BlY2lmaWVkIGluIFNlY3Rpb24gNS42IG9mIFtSRkMzMzM5XTxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzMzOSNzZWN0aW9uLTUuNj4sIHNlZSBhbHNvIFNl Y3Rpb24gMyBvZjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjk5MSNzZWN0aW9uLTM+ DQogICAgICBbUkZDNjk5MV08aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5OTEjc2Vj dGlvbi0zPikuICBUaGUgVVRDIFRpbWUgWm9uZSBpcyByZXF1aXJlZCBieSBTZWN0aW9uIDYuMSBv ZjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjMzMCNzZWN0aW9uLTYuMT4NCiAgICAg IFtSRkMyMzMwXTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjMzMCNzZWN0aW9uLTYu MT4uDQoNCiAgIFRmIHRoZSBzdGFydCBvZiBhIG1lYXN1cmVtZW50IGludGVydmFsLCAoZm9ybWF0 ICJkYXRlLWFuZC10aW1lIiBhcw0KICAgICAgc3BlY2lmaWVkIGluIFNlY3Rpb24gNS42IG9mIFtS RkMzMzM5XTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzMzOSNzZWN0aW9uLTUuNj4s IHNlZSBhbHNvIFNlY3Rpb24gMyBvZjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjk5 MSNzZWN0aW9uLTM+DQogICAgICBbUkZDNjk5MV08aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzY5OTEjc2VjdGlvbi0zPikuICBUaGUgVVRDIFRpbWUgWm9uZSBpcyByZXF1aXJlZCBieSBT ZWN0aW9uIDYuMSBvZjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjMzMCNzZWN0aW9u LTYuMT4NCiAgICAgIFtSRkMyMzMwXTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjMz MCNzZWN0aW9uLTYuMT4uDQoNCg0KQXMgSSBzYWlkIGF0IHRoZSBtZWV0aW5nLCBpdCB3b3VsZCBi ZSBnb29kIHRvIGxvb2sgYXQgc29tZSBleGFtcGxlcw0KDQp3aGljaCBhdHRlbXB0IHRvIHNjaGVk dWxlIHRoZSDigJxBY3RfSVBfVURQX1JvdW5kLXRyaXBfRGVsYXlfUG9pc3Nvbl85NXRoLXBlcmNl bnRpbGXigJ0NCg0KcmVnaXN0cnkgZW50cnksIGFzIGEgUGVyaW9kaWMgZXZlbnQsIGEgb25lLXRp bWUgZXZlbnQsIGFuZCBhIGNvbnRpbnVvdXMNCg0KZXZlbnQgYXMgUm9uIGlzIHN1Z2dlc3Rpbmcu DQoNCg0KDQpyZWdhcmRzLA0KDQpBbA0KDQoqIE5vdGUgdGhhdCB0aGUgUmVnaXN0cnkgRW50cnkg Zm9yIGEgTWV0cmljIGluY2x1ZGVzIHRoZSBNZXRyaWMgRGVmaW5pdGlvbiwNCnRoZSBtZXRob2Qg b2YgbWVhc3VyZW1lbnQsIGFuZCBSdW4tdGltZSBwYXJhbWV0ZXJzLg0KDQoNCkZyb206IFJvbiBT dGFuYSBbbWFpbHRvOnJvbi5zdGFuYUB2aWF2aXNvbHV0aW9ucy5jb21dDQpTZW50OiBNb25kYXks IEFwcmlsIDE4LCAyMDE2IDk6NDAgQU0NClRvOiBDYXJleSwgVGltb3RoeSAoTm9raWEgLSBVUykN CkNjOiBsbWFwQGlldGYub3JnPG1haWx0bzpsbWFwQGlldGYub3JnPjsgTU9SVE9OLCBBTEZSRUQg QyAoQUwpDQpTdWJqZWN0OiBSZTogW2xtYXBdIExNQVA6IERlZmluaW5nIHRoZSBTY2hlZHVsZSdz IGV2ZW50cw0KDQpUaW0sDQoNClRoZSBleGFjdCBkZWZpbml0aW9uIG9mIHRoZSBtZXRyaWMgaXMg c3RpbGwgdW5jbGVhciB0byBtZSBzaW5jZSBJIGhhdmUgbm90IHNlZW4gYW4gZXhhbXBsZSBvZiBh IHRlc3Qgd2l0aCBhdmVyYWdlIGNvbXBsZXhpdHkgdXNpbmcgbWV0cmljcyB3aXRoIExNQVAgZnJv bSBiZWdpbm5pbmcgdG8gZW5kLiAgQnkgYXZlcmFnZSBjb21wbGV4aXR5IEkgbWVhbiBhIHRlc3Qg dGhhdCBhbGxvd3MgaW5kZXBlbmRlbnQgY29uZmlndXJhdGlvbiBvZiBtdWx0aXBsZSBzaW11bHRh bmVvdXMgZGF0YSBmbG93cyBhbmQgcHJvZHVjZXMgbXVsdGlwbGUgcmVwb3J0IGZvcm1hdHMgZHVy aW5nIHRoZSB0ZXN0IGR1cmF0aW9uLiBUaGUgdGVzdHMgSSBtZW50aW9uZWQgcHJldmlvdXNseSAo UkZDLTI1NDQsIFkuMTU2NCwgWS4xNzMxIGFuZCBUV0FNUCkgbWluaW1hbGx5IHJlcXVpcmUgdGhp cyB0eXBlIG9mIHN1cHBvcnQgYW5kIGFyZSB0aGUgbWFpbiB0ZXN0cyB1c2VkIGluIEV0aGVybmV0 IHNlcnZpY2UgdGVzdGluZyB0b2RheS4gIE5vbmUtdGhlLWxlc3MsIG15IHVuZGVyc3RhbmRpbmcg b2YgdGhlIG1ldHJpYyBpcyB0aGF0IGl0IGRlZmluZXMgdGhlIGZvcm1hdCBvZiB0aGUgcGFja2V0 IHN0cmVhbSBhbmQgdGhlIG1ldGhvZG9sb2d5IG9mIHRoZSB0cmFuc21pdCBmcmVxdWVuY3kuIFRo ZXNlIGFyZSB0d28gZXhhbXBsZXMgZnJvbSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1pcHBtLWluaXRpYWwtcmVnaXN0cnktMDANCg0KDQpBY3RfSVBfVURQX1BvaXNzb25f VURQLVBheWxvYWQtMjUwX09uZS13YXlfRGVsYXlfU3RkX0Rldg0KDQpBY3RfSVBfVURQX1Blcmlv ZGljLXZhcl9VRFAtUGF5bG9hZC0xNDJfT25lLXdheV9EZWxheV9NZWFuDQoNCg0KDQpJdCBkb2Vz IG5vdCBhcHBlYXIgdG8gZGVmaW5lIHRoZSB0aW1lIHBlcmlvZCBvdmVyIHdoaWNoIHRoZSBtZWFz dXJlbWVudCB3YXMgdGFrZW4uICBUaGlzIGlzIGdvb2QgYmVjYXVzZSBmb3IgbW9zdCB0ZXN0cyB0 aGUgbWVhc3VyZW1lbnQgcGVyaW9kIGlzIGEgdXNlciBkZWZpbmVkIGlucHV0IHBhcmFtZXRlci4g IFBlcmZvcm1hbmNlIG1vbml0b3JpbmcgdGVzdHMgd2lsbCByZXBvcnQgdGhlIG1ldHJpYyByZXBl YXRlZGx5IGR1cmluZyB0aGUgdGVzdCBleGVjdXRpb24uICBSZWZlcnJpbmcgdG8gdGhlIGV4YW1w bGUgaW4gbXkgcHJpb3IgZW1haWwsIGEgVFdBTVAgdGVzdCB3b3VsZCBwcm9kdWNlIGEgZ3JvdXAg b2YgbWV0cmljcyBmb3IgZWFjaCBkYXRhIHN0cmVhbSBldmVyeSAxLCA1IG9yIDE1IG1pbnV0ZXMg ZGVwZW5kaW5nIG9uIHRoZSB0ZXN0IGNvbmZpZ3VyYXRpb24uIEl0IGlzIHBvc3NpYmxlIHRoZSB0 ZXN0IGNvdWxkIGJlIGNvbmZpZ3VyZWQgdG8gcHJvZHVjZSBtdWx0aXBsZSByZXBvcnRzIC0gZm9y IGV4YW1wbGUgYXQgYSBzaG9ydCBpbnRlcnZhbCBmb3IgdHJvdWJsZXNob290aW5nIGluIGFkZGl0 aW9uIHRvIG9uZSBvZiB0aGUgaW50ZXJ2YWxzIHByZXZpb3VzbHkgbWVudGlvbmVkIGZvciBnZW5l cmFsIHNlcnZpY2UgbW9uaXRvcmluZy4gVGh1cywgdGhlIFRXQU1QIHRlc3QgcHJvZHVjZXMgaW5z dGFuY2VzIG9mIG1ldHJpY3MgZm9yIGFuIHVuc3BlY2lmaWVkIGFtb3VudCBvZiB0aW1lIC0gdHlw aWNhbGx5IHVudGlsIGEgdXNlciBtYW51YWxseSBzdG9wcyB0aGUgdGVzdC4NCg0KDQoNCkluIHN1 bW1hcnksIGZyb20gbXkgcGVyc3BlY3RpdmUsIHRoZSBkdXJhdGlvbiBvZiB0aGUgdGVzdCBpcyBv dXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgbWV0cmljIGRlZmluaXRpb24uLi4uYnV0IG1heWJlIEkg anVzdCBkb24ndCB1bmRlcnN0YW5kIHRoZSBtZXRyaWMgZGVmaW5pdGlvbiB3ZWxsIGVub3VnaC4N Cg0KDQoNClJvbg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpPbiBTdW4sIEFwciAxNywgMjAx NiBhdCA5OjE5IFBNLCBDYXJleSwgVGltb3RoeSAoTm9raWEgLSBVUykgPHRpbW90aHkuY2FyZXlA bm9raWEuY29tPG1haWx0bzp0aW1vdGh5LmNhcmV5QG5va2lhLmNvbT4+IHdyb3RlOg0KUm9uLA0K DQpUaGFua3MgZm9yIGxvb2tpbmcgYXQgdGhpcy4NCldoZW4gSSBkaXNjdXNzZWQgdGhpcyB3aXRo IEFsIGluZGljYXRlZCB0aGF0IHRoZXNlIHdvdWxkIGJlIHBhcnQgb2YgdGhlIG1ldHJpYy9hY3Rp b24gZGVmaW5pdGlvbi4NCg0KQnV0IGlmIHdlIHdvdWxkIHdhbnQgdG8gZGVmaW5lIGEgbm9uLW1l dHJpYyBzcGVjaWZpYyBkdXJhdGlvbiBhdHRyaWJ1dGUgb2YgYW4gaW5kaXZpZHVhbCBhY3Rpb24g d2l0aGluIHRoZSBjb250ZXh0IG9mIHRoZSBvdmVyYWxsIHNjaGVkdWxlIChJIGJlbGlldmUgdGhp cyBpcyB3aGF0IHlvdSBhcmUgcmVxdWVzdGluZz8pIHRoZW4gd2Ugc2hvdWxkIGFzc2lnbiB0aGF0 IGR1cmF0aW9uIHRoYXQgcmVzdWx0cyBpbiAoVDQpIHRvIHRoZSBhY3Rpb24uIEFjdHVhbGx5IHlv dSBoYXZlIHRoZSBzYW1lIHByb2JsZW0gd2l0aCBUMiDigJMgd2l0aGluIHRoZSBjb250ZXh0IGFj dGlvbiDigJMgdGhpcyBvZmZzZXQgaWYgbmVjZXNzYXJ5IGlzIGRpZmZlcmVudCBmcm9tIHRoZSBz Y2hlZHVsZSBzdGFydCByYW5kb21uZXNzIChvbmNlIHRoZSBwcm9jZXNzIHN0YXJ0cyBob3cgbG9u ZyB0byB3YWl0IGJlZm9yZSB0aGUgYml0cyBoaXQgdGhlIHdpcmUpLiAgTWF5YmUgdGhhdCBpcyB3 aGF0IHdlIGFyZSBtaXNzaW5nIOKAkyBBIHRpbWVyIGZvciBhbiBhY3Rpb24gd2l0aGluIHRoZSBj b250ZXh0IG9mIHRoZSBzY2hlZHVsZeKApg0KDQpDb21tZW50cz8NCg0KRnJvbTogRVhUIFJvbiBT dGFuYSBbbWFpbHRvOnJvbi5zdGFuYUB2aWF2aXNvbHV0aW9ucy5jb208bWFpbHRvOnJvbi5zdGFu YUB2aWF2aXNvbHV0aW9ucy5jb20+XQ0KU2VudDogU3VuZGF5LCBBcHJpbCAxNywgMjAxNiA2OjM1 IFBNDQpUbzogQ2FyZXksIFRpbW90aHkgKE5va2lhIC0gVVMpDQpDYzogbG1hcEBpZXRmLm9yZzxt YWlsdG86bG1hcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbG1hcF0gTE1BUDogRGVmaW5pbmcg dGhlIFNjaGVkdWxlJ3MgZXZlbnRzDQoNClRpbSwNCg0KSXQgYXBwZWFycyB5b3UgYXJlIG1ha2lu ZyBhbiBhc3N1bXB0aW9uIHRoYXQgZWFjaCBhY3Rpb24gd2lsbCBlbmQgb24gaXRzIG93biAoVDQp LiAgV2hpbGUgdGhhdCBpcyB0cnVlIGZvciB0dXJuLXVwIHRlc3RzIGxpa2UgUkZDLTI1NDQgYW5k IFkuMTU2NCwgbG9uZyB0ZXJtIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcgdGVzdHMgbGlrZSBUV0FN UCBhbmQgWS4xNzMxIGFyZSBleHBlY3RlZCB0byBwcm9kdWNlIHJlc3VsdHMgMjQvNyBhbmQgc28g ZG8gbm90IGhhdmUgYSBkZWZpbmVkIGVuZCB0aW1lLiAgVGhleSBhcmUgY29uZmlndXJlZCB3aXRo IGEgcmF0ZSB0byBzZW5kIHBhY2tldHMsIHRoZSBNQSBtZWFzdXJlcyBGRCwgRkRWIGFuZCBGTFIg YW5kIHRoZW4gdGhlIE1BIHBlcmlvZGljYWxseSBhZ2dyZWdhdGVzIHRoZXNlIHN0YXRzIGFuZCBz ZW5kcyB0aGVtIHRvIHRoZSBjb2xsZWN0b3IuICBUaGUgYWdncmVnYXRpb24gcmF0ZSBpcyB0eXBp Y2FsbHkgMSwgNSBvciAxNSBtaW51dGVzIHNvIHJlcG9ydHMgY29udGFpbiByb2xsaW5nIHN0YXJ0 L2VuZCB0aW1lcyBhcyB0aGUgdGVzdCBleGVjdXRlcy4NCg0KV2hpbGUgd2hhdCBJIGRlc2NyaWJl IGFib3ZlIGlzIHRoZSB0eXBpY2FsIHVzZSBjYXNlLCB0aGVyZSBhcmUgb3RoZXIgc2NlbmFyaW9z IHdoZXJlIHRoZXNlIHNhbWUgdGVzdHMgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gZW11bGF0ZSBzaG9y dCByYW5kb20gYnVyc3RzLiBJbiB0aGlzIHNjZW5hcmlvIHRoZSB0ZXN0cyBuZWVkIHRvIGJlIGNv bmZpZ3VyZWQgd2l0aCBhbiBpbml0aWFsIHN0YXJ0IHRpbWUsIGFuIGludGVydmFsIHRvIHJlc3Rh cnQgdGhlIHRlc3QsIGEgcmFuZG9tIHN0YXJ0IG9mZnNldCBhbmQgYSBkdXJhdGlvbi4gIEZvciBl eGFtcGxlLCBzdGFydCBhdCAxOjAwIHRvZGF5LCByZXN0YXJ0IGV2ZXJ5IDUgbWludXRlcyB0aGVy ZWFmdGVyLCBlYWNoIHJ1biBzaG91bGQgYmUgb2Zmc2V0IGJ5IGEgcmFuZG9tIHZhbHVlIHdpdGhp biA0IG1pbnV0ZXMgYW5kIGVhY2ggcnVuIHNob3VsZCBzZW5kIHRoZSBkYXRhIGZsb3dzIGZvciAx IG1pbnV0ZS4gIEkgdGhpbmsgdGhlIG9ubHkgcGFydCBvZiB0aGlzIExNQVAgZGlkIG5vdCBkZWZp bmUgd2FzIHRoZSBsYXN0IHBhcmFtZXRlciAtIHRoZSB0ZXN0IGR1cmF0aW9uLiBXaGlsZSBlYWNo IHRlc3QgY291bGQgb2ZmZXIgdGVzdC1zcGVjaWZpYyBwYXJhbWV0ZXJzIHRvIGRlZmluZSBpdHMg ZHVyYXRpb24sIEkgdGhvdWdodCB0aGUgcHJvcG9zYWwgdG8gYWRkIHRoZSAnZW5kJyBvYmplY3Qg d2FzIHRvIHByb3ZpZGUgYSBjb21tb24gYXBwcm9hY2ggZm9yIHRoaXMuDQoNClJvbg0KDQpPbiBG cmksIEFwciA4LCAyMDE2IGF0IDg6NTIgQU0sIENhcmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKSA8 dGltb3RoeS5jYXJleUBub2tpYS5jb208bWFpbHRvOnRpbW90aHkuY2FyZXlAbm9raWEuY29tPj4g d3JvdGU6DQpUZWFtLA0KDQpJbiB0aGUgSUVURiM5NSBMTUFQIHNlc3Npb24gd2UgaGFkIGEgZGlz Y3Vzc2lvbiBvbiB0aGUgbmVlZCBmb3IgdGhlIG5ldyBwYXJhbWV0ZXJzIGZvciB0aGUgbWEtc2No ZWR1bGUtZW5kIGFuZCBtYS1zY2hlZHVsZS1kdXJhdGlvbiBwYXJhbWV0ZXJzLCBnaXZlbiB0aGF0 IHRoZSBtYS1zY2hlZHVsZS1zdGFydCAod2hpY2ggaXMgdHlwZWQgYXMgYW4gZXZlbnQpDQoNCldl IHNhaWQgd2Ugd291bGQgc2hvdyB0aGF0IHRoZXNlIHBhcmFtZXRlcnMgd2VyZSBub3QgbmVlZGVk IHVzaW5nIGFuIGV4YW1wbGUg4oCTIHNvIGhlcmUgZ29lcy4NCg0KTGV0cyBhc3N1bWUgd2UgaGF2 ZSBhIHNjaGVkdWxlIG1hZGUgdXAgb2YgMiBhY3Rpb25zIChBMSwgQTIpIGluIHBpcGVsaW5lIG1v ZGUuIFRoZSBtYS1zY2hlZHVsZS1zdGFydCB3b3VsZCBoYXMgYSBwZXJpb2RpYyBldmVudDoNCg0K U3RhcnQgQXByaWwgMSwgMjAxNiBhdCAwMjowMDowMA0KDQpFbmQgTWF5IDEsIDIwMTYgYXQgMDI6 MDA6MDANCg0KSW50ZXJ2YWwgODYsNDAwIChkYWlseSkNCg0KUmFuZG9tbmVzcyAzNjAwICh3aXRo aW4gdGhlIGhvdXIpDQoNClNvIHRoZSBzY2hlZHVsZSB3aWxsIHJlb2NjdXIgZXZlcnkgZGF5IHN0 YXJ0aW5nIG9uIEFwcmlsIDEgYmVnaW5uaW5nIGF0IDI6MDBwbS4gKFQwKSBUaGUgc3RhcnRpbmcg cGVyaW9kIHdpbGwgYmUgcmFuZG9tIGJldHdlZW4gMjowMGFtIGFuZCAzOjAwYW0uIChUMSkgVGhp cyBkZWZpbml0aW9uIGlzIHN1ZmZpY2llbnQgZm9yIGludm9raW5nIEExIChUMSkgYW5kIGlzIHdo YXQgQWwgY29uc2lkZXJzIGFzIEJsdWUgdGltZXMuDQoNCkFzIEExIHBlcmZvcm1zIGEgdGVzdCBB MSBwbGFjZXMgYml0cyBvbiB0aGUgd2lyZSAoVDIpIGFuZCBjb2xsZWN0cyByZXN1bHRzIChUMyku DQpXaGVuIEExIGNvbXBsZXRlcyAoVDQpLCBBMiBpcyBpbnZva2VkIChUNSkgd2hpY2ggcGxhY2Vz IGJpdHMgb24gYSB3aXJlIGZvciBBMiAoVDIpIGFuZCBjb2xsZWN0cyByZXN1bHRzIChUMykpLiBG aW5hbGx5IHRoZSByZXN1bHRzIGZyb20gdGhlIHNjaGVkdWxlIGFyZSByZXBvcnRlZCAoVDYpLg0K DQpUMiZUMzogQWwgY29uc2lkZXJzIHRoaXMgdGltZSB0byBiZSBwYXJ0IG9mIHRoZSBkZWZpbml0 aW9uIG9mIHRoZSBtZXRyaWMgYW5kIGFyZSByZXBvcnRlZCBhcyBwYXJ0IG9mIHRoZSByZXN1bHQg Y29udGVudCAobm90IGFzIGFuIGFjdHVhbCBwYXJhbWV0ZXIpLiBUaGlzIHdhcyBoaXMgUmVkIHRp bWUNCg0KVDQmVDU6IEFyZSB0aGUgbWEtcmVwb3J0LVtzdGFydHxlbmRdLXRpbWUNClQ2OiBJcyB0 aGUgbWEtcmVwb3J0LWRhdGUNCg0KQXMgc3VjaCDigJMgQXMgbG9uZyBhcyBhbiBFdmVudCBoYXMg YSBkZWZpbmVkIG9jY3VycmVuY2UgKFQxPVQwICsgcmFuZG9tbmVzcykgYWxsIHRoYXQgaXMgbmVj ZXNzYXJ5IGlzIGEgc2luZ2xlIHBhcmFtZXRlciB0byBkZWZpbmUgdGhlIG9jY3VycmVuY2UuDQoN ClF1ZXN0aW9ucz8NCg0KQlIsDQpUaW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCmxtYXAgbWFpbGluZyBsaXN0DQpsbWFwQGlldGYub3JnPG1haWx0 bzpsbWFwQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s bWFwDQoNCg0K --_000_9966516C6EB5FC4381E05BF80AA55F77012A6513FFUS70UWXCHMBA0_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxv b25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U ZWFtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhpcyBtaWdodCBoYXZlIGJlZW4gbG9zdCBpbiB0aGUgZW1haWwgdGhy ZWFkcyBzbyBJIGFtIHJldml2aW5nIHRoZSBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IENhcmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IEFwcmlsIDE5LCAyMDE2IDc6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+ICdFWFQgTU9SVE9OLCBBTEZS RUQgQyAoQUwpJzsgUm9uIFN0YW5hPGJyPg0KPGI+Q2M6PC9iPiBsbWFwQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJFOiBbbG1hcF0gTE1BUDogRGVmaW5pbmcgdGhlIFNjaGVkdWxlJ3Mg ZXZlbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JbmxpbmUgJmx0O1RBQyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBF WFQgTU9SVE9OLCBBTEZSRUQgQyAoQUwpIFs8YSBocmVmPSJtYWlsdG86YWNtb3J0b25AYXR0LmNv bSI+bWFpbHRvOmFjbW9ydG9uQGF0dC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgQXByaWwgMTgsIDIwMTYgNToxOSBQTTxicj4NCjxiPlRvOjwvYj4gUm9uIFN0YW5hOyBDYXJl eSwgVGltb3RoeSAoTm9raWEgLSBVUyk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzps bWFwQGlldGYub3JnIj5sbWFwQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog W2xtYXBdIExNQVA6IERlZmluaW5nIHRoZSBTY2hlZHVsZSdzIGV2ZW50czxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5IaSBSb24gYW5kIFRpbSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnRyeWluZyB0byBtYWtlIGEgZmV3 IG1pbnV0ZXMgZm9yIHRoaXMuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBSZWdpc3RyeSBFbnRyaWVzKiBmb3IgdGhlIE1l dHJpY3MgaW5jbHVkZSBSdW4tdGltZSBQYXJhbWV0ZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPmZvciB0aGUgU3RhcnQgdGltZSBhbmQgRW5kIFRpbWUsIGJ1dCBvbmUgb2YgdGhlbSBjb3Vs ZCBiZSBpbnRlcnByZXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5hcyBhIER1cmF0aW9u IGlmIHNwZWNpZmllZCBjb3JyZWN0bHkgKHRoZSBTdGFydCB0aW1lIG11c3QgYmUgYWxsIHplcm9z LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj50aGVuIHRoZSBTdG9wIHRpbWUgaXMgaW50ZXJw cmV0ZWQgYXMgYSBkdXJhdGlvbiwgQU5EIHRoZSBhY3R1YWwgc3RhcnQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjpibGFjayI+YW5kIHN0b3AgdGltZSBhcmUgY29udHJvbGxlZCB0aHJvdWdoIOKAnG90aGVy IG1lYW5z4oCdKS4gU2VlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1pcHBtLWluaXRpYWwtcmVnaXN0cnktMDAjc2VjdGlvbi00LjMuNSI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1pbml0aWFsLXJlZ2lzdHJ5LTAw I3NlY3Rpb24tNC4zLjU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj7igJxPdGhlciBtZWFuc+KAnSB3b3VsZCBiZSB0aGUgU2No ZWR1bGUgb2JqZWN0IGFuZCB0aGUgRXZlbnQgb2JqZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5BcyBJIHVuZGVyc3RhbmQgaXQgYm90aCBzY2hlZHVsZSBhbmQgZXZlbnQgb2JqZWN0cyBo YXZlIHN0YXJ0IHRpbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+YW5kIHN0b3AgdGltZSBz cGVjaWZpY2F0aW9ucyBhdmFpbGFibGUsIGFuZCBFdmVudCBoYXMgRHVyYXRpb24gc3BlY2lmaWNh dGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5hdmFpbGFibGUgd2hpY2ggd291bGQgYmUg dXNlZnVsIGZvciByZWN1cnJpbmcgZXZlbnRzIChwZXJpb2RpYyBvciBjYWxlbmRhcikuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbHQ7VEFDJmd0OyBUaGUgc2NoZWR1bGXigJlzIHRpbWVyIGlzIHN1ZmZpY2llbnQgdG8g c3RhdGUgd2hlbiB0aGUgaW5pdGlhbCBhY3Rpb24ocykgYXJlIGludm9rZWQuIEkgc2F5IGFjdGlv bnMgYmVjYXVzZSB0aGUgZXhlY3V0aW9uIG1vZGUgZm9yIHRoZSBzY2hlZHVsZeKAmXMgYWN0aW9u 4oCZcw0KIGNvdWxkIGJlIHBhcmFsbGVsLiBJbiB0aGUgY2FzZSB3aGVuIHRoZSBzY2hlZHVsZeKA mXMgZXhlY3V0aW9uIG1vZGUgaXMgc2VxdWVudGlhbCB0aGVuIGl0IHdvdWxkIGJlIHN1ZmZpY2ll bnQgdG8gc3RhdGUgd2hlbiB0aGUgZmlyc3QgYWN0aW9uIGlzIGludm9rZWQuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hhdCB0aGUgc2NoZWR1bGXigJlzIHRpbWVyIGRvZXNu4oCZ dCBkbyBpcyBzcGVjaWZ5IHRoZSBkdXJhdGlvbiBvZiB0aGUgaW5kaXZpZHVhbCBhY3Rpb24ocykg b3Igd2hlbiB0aGUgc2Vjb25kIGFjdGlvbiBpcyBleGVjdXRlZCBpbiByZWxhdGlvbiB0byB0aGUg Y29tcGxldGlvbg0KIG9mIHRoZSBmaXJzdCBhY3Rpb24uIFdoYXQgd2Ugd291bGQgbmVlZCB0byBk byBpcyBlaXRoZXI6IFBhc3MgdGhlIGR1cmF0aW9uIG9mIGFjdGlvbiBiYXNlZCBvbiB0aGUgb3B0 aW9ucyAoVDAgPSB6ZXJvLCBUZj1zb21lIGR1cmF0aW9uKSBvciB3ZSBjb3VsZCBwdXQgYSB0aW1l ciBvbiB0aGUgYWN0aW9uIOKAkyB3aGljaCB3b3VsZCBwcm92aWRlIHRoZSBleHRlcm5hbCBjb250 cm9sIHRoYXQgd291bGQgYWxsb3cgdGhlIHN0YXJ0IHRvIGJlIGJldHRlcg0KIGNvbnRyb2xsZWQg aW4gdGhlIGNvbnRleHQgb2YgdGhlIG92ZXJhbGwgc2NoZWR1bGUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5FdmVudHVhbGx5LCB0 aGUgTUEgaGFzIHRvIHJlcG9ydCB0aGUgcmVzdWx0cyBvZiB0aGUgbWV0cmljL21lYXN1cmVtZW50 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGF04oCZcyB3aGVuIHRoZSBhY3R1YWwgKFJF RCkgc3RhcnQgYW5kIGVuZCB0aW1lcyB3aGVuIHBhY2tldHMgd2VyZSBhY3R1YWxseTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5mbG93aW5nIGJldHdlZW4gbWVhc3VyZW1lbnQgcG9pbnRzIGFy ZSByZXBvcnRlZCwgYWNjb3JkaW5nIHRvIHRoZSBSZWdpc3RyeSBFbnRyeS4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5TZWU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1pcHBtLWluaXRpYWwtcmVnaXN0cnktMDAjc2VjdGlvbi00LjQuMiI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1pbml0aWFsLXJlZ2lz dHJ5LTAwI3NlY3Rpb24tNC40LjI8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7VEFDJmd0OyBUaGVzZSBzZWVt IHRvIGJlIHRoZSBhY3R1YWwg4oCTIG5vdCBjb25maWd1cmVkIHN0YXJ0IGFuZCBlbmQgdGltZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW50ZXJlc3RpbmcgSSB0aGluayB0aGVyZSBt aWdodCBiZSBhIHByb2JsZW0gaW4gdGhlIGRyYWZ0IHdpdGggVGYgYXMgaXQgd291bGQgYmUg4oCc ZW5k4oCdIG9mIHRoZSBpbnRlcnZhbCBub3QgdGhlIOKAnHN0YXJ04oCdIG9mIHRoZSBpbnRlcnZh bD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IFQwIHRoZSBzdGFydCBvZiBhIG1lYXN1cmVt ZW50IGludGVydmFsLCAoZm9ybWF0ICZxdW90O2RhdGUtYW5kLXRpbWUmcXVvdDsgYXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwZWNpZmllZCBpbg0KPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMzMzkjc2VjdGlvbi01LjYiPlNl Y3Rpb24mbmJzcDs1LjYgb2YgW1JGQzMzMzldPC9hPiwgc2VlIGFsc28NCjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTkxI3NlY3Rpb24tMyI+U2VjdGlvbiZuYnNwOzMg b2Y8L2E+PC9zcGFuPjxzcGFuIGNsYXNzPSJNc29IeXBlcmxpbmsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOmJsdWUiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTkx I3NlY3Rpb24tMyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtSRkM2OTkxXTwvYT48 L3NwYW4+PC91PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4pLiZuYnNwOyBUaGUNCiBVVEMg VGltZSBab25lIGlzIHJlcXVpcmVkIGJ5IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmMyMzMwI3NlY3Rpb24tNi4xIj4NClNlY3Rpb24mbmJzcDs2LjEgb2Y8L2E+PHNwYW4g Y2xhc3M9Ik1zb0h5cGVybGluayI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyMzMwI3NlY3Rpb24tNi4x Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1JGQzIzMzBdPC9hPjwvc3Bhbj48L3U+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOyZuYnNwOw0KPGI+VGYgdGhlIHN0YXJ0IG9mIGEgbWVhc3VyZW1lbnQg aW50ZXJ2YWwsIChmb3JtYXQgJnF1b3Q7ZGF0ZS1hbmQtdGltZTwvYj4mcXVvdDsgYXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwZWNpZmllZCBpbg0KPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMzMzkjc2VjdGlvbi01LjYiPlNl Y3Rpb24mbmJzcDs1LjYgb2YgW1JGQzMzMzldPC9hPiwgc2VlIGFsc28NCjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTkxI3NlY3Rpb24tMyI+U2VjdGlvbiZuYnNwOzMg b2Y8L2E+PC9zcGFuPjxzcGFuIGNsYXNzPSJNc29IeXBlcmxpbmsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOmJsdWUiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTkx I3NlY3Rpb24tMyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtSRkM2OTkxXTwvYT48 L3NwYW4+PC91PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4pLiZuYnNwOyBUaGUNCiBVVEMg VGltZSBab25lIGlzIHJlcXVpcmVkIGJ5IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmMyMzMwI3NlY3Rpb24tNi4xIj4NClNlY3Rpb24mbmJzcDs2LjEgb2Y8L2E+PHNwYW4g Y2xhc3M9Ik1zb0h5cGVybGluayI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyMzMwI3NlY3Rpb24tNi4x Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1JGQzIzMzBdPC9hPjwvc3Bhbj48L3U+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5BcyBJIHNhaWQgYXQgdGhlIG1lZXRpbmcsIGl0IHdvdWxkIGJlIGdvb2Qg dG8gbG9vayBhdCBzb21lIGV4YW1wbGVzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj53aGljaCBhdHRlbXB0IHRv IHNjaGVkdWxlIHRoZSDigJxBY3RfSVBfVURQX1JvdW5kLXRyaXBfRGVsYXlfUG9pc3Nvbl85NXRo LXBlcmNlbnRpbGXigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPnJlZ2lzdHJ5IGVudHJ5LCBhcyBhIFBlcmlv ZGljIGV2ZW50LCBhIG9uZS10aW1lIGV2ZW50LCBhbmQgYSBjb250aW51b3VzIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpi bGFjayI+ZXZlbnQgYXMgUm9uIGlzIHN1Z2dlc3RpbmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6YmxhY2siPnJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5BbDxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4qIE5vdGUg dGhhdCB0aGUgUmVnaXN0cnkgRW50cnkgZm9yIGEgTWV0cmljIGluY2x1ZGVzIHRoZSBNZXRyaWMg RGVmaW5pdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+dGhlIG1ldGhvZCBvZiBtZWFz dXJlbWVudCwgYW5kIFJ1bi10aW1lIHBhcmFtZXRlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSb24g U3RhbmEgWzxhIGhyZWY9Im1haWx0bzpyb24uc3RhbmFAdmlhdmlzb2x1dGlvbnMuY29tIj5tYWls dG86cm9uLnN0YW5hQHZpYXZpc29sdXRpb25zLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g TW9uZGF5LCBBcHJpbCAxOCwgMjAxNiA5OjQwIEFNPGJyPg0KPGI+VG86PC9iPiBDYXJleSwgVGlt b3RoeSAoTm9raWEgLSBVUyk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpsbWFwQGll dGYub3JnIj5sbWFwQGlldGYub3JnPC9hPjsgTU9SVE9OLCBBTEZSRUQgQyAoQUwpPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbbG1hcF0gTE1BUDogRGVmaW5pbmcgdGhlIFNjaGVkdWxlJ3MgZXZl bnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRpbSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBl eGFjdCBkZWZpbml0aW9uIG9mIHRoZSBtZXRyaWMgaXMgc3RpbGwgdW5jbGVhciB0byBtZSBzaW5j ZSBJIGhhdmUgbm90IHNlZW4gYW4gZXhhbXBsZSBvZiBhIHRlc3Qgd2l0aCBhdmVyYWdlIGNvbXBs ZXhpdHkgdXNpbmcgbWV0cmljcyB3aXRoIExNQVAgZnJvbSBiZWdpbm5pbmcgdG8gZW5kLiZuYnNw OyBCeSBhdmVyYWdlIGNvbXBsZXhpdHkgSSBtZWFuIGEgdGVzdCB0aGF0IGFsbG93cyBpbmRlcGVu ZGVudCBjb25maWd1cmF0aW9uDQogb2YgbXVsdGlwbGUgc2ltdWx0YW5lb3VzIGRhdGEgZmxvd3Mg YW5kIHByb2R1Y2VzIG11bHRpcGxlIHJlcG9ydCBmb3JtYXRzIGR1cmluZyB0aGUgdGVzdCBkdXJh dGlvbi4gVGhlIHRlc3RzIEkgbWVudGlvbmVkIHByZXZpb3VzbHkgKFJGQy0yNTQ0LCBZLjE1NjQs IFkuMTczMSBhbmQgVFdBTVApIG1pbmltYWxseSByZXF1aXJlIHRoaXMgdHlwZSBvZiBzdXBwb3J0 IGFuZCBhcmUgdGhlIG1haW4gdGVzdHMgdXNlZCBpbiBFdGhlcm5ldCBzZXJ2aWNlDQogdGVzdGlu ZyB0b2RheS4mbmJzcDsgTm9uZS10aGUtbGVzcywgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgbWV0 cmljIGlzIHRoYXQgaXQgZGVmaW5lcyB0aGUgZm9ybWF0IG9mIHRoZSBwYWNrZXQgc3RyZWFtIGFu ZCB0aGUgbWV0aG9kb2xvZ3kgb2YgdGhlIHRyYW5zbWl0IGZyZXF1ZW5jeS4gVGhlc2UgYXJlIHR3 byBleGFtcGxlcyBmcm9tJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtaXBwbS1pbml0aWFsLXJlZ2lzdHJ5LTAwIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLWluaXRpYWwtcmVnaXN0cnktMDA8L2E+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5BY3RfSVBfVURQX1BvaXNzb25fVURQLVBheWxvYWQtMjUwX09uZS13YXlfRGVsYXlfU3Rk X0RldjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkFjdF9JUF9VRFBfUGVyaW9kaWMtdmFyX1VEUC1QYXlsb2FkLTE0Ml9PbmUtd2F5X0RlbGF5 X01lYW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkl0IGRv ZXMgbm90IGFwcGVhciB0byBkZWZpbmUgdGhlIHRpbWUgcGVyaW9kIG92ZXIgd2hpY2ggdGhlIG1l YXN1cmVtZW50IHdhcyB0YWtlbi4mbmJzcDsgVGhpcyBpcyBnb29kIGJlY2F1c2UgZm9yIG1vc3Qg dGVzdHMgdGhlIG1lYXN1cmVtZW50IHBlcmlvZCBpcyBhIHVzZXIgZGVmaW5lZCBpbnB1dCBwYXJh bWV0ZXIuJm5ic3A7IFBlcmZvcm1hbmNlIG1vbml0b3JpbmcgdGVzdHMgd2lsbCByZXBvcnQgdGhl IG1ldHJpYyByZXBlYXRlZGx5IGR1cmluZyB0aGUgdGVzdCBleGVjdXRpb24uJm5ic3A7IFJlZmVy cmluZyB0byB0aGUgZXhhbXBsZSBpbiBteSBwcmlvciBlbWFpbCwgYSBUV0FNUCB0ZXN0IHdvdWxk IHByb2R1Y2UgYSBncm91cCBvZiBtZXRyaWNzIGZvciBlYWNoIGRhdGEgc3RyZWFtIGV2ZXJ5IDEs IDUgb3IgMTUgbWludXRlcyBkZXBlbmRpbmcgb24gdGhlIHRlc3QgY29uZmlndXJhdGlvbi4gSXQg aXMgcG9zc2libGUgdGhlIHRlc3QgY291bGQgYmUgY29uZmlndXJlZCB0byBwcm9kdWNlIG11bHRp cGxlIHJlcG9ydHMgLSBmb3IgZXhhbXBsZSBhdCBhIHNob3J0IGludGVydmFsIGZvciB0cm91Ymxl c2hvb3RpbmcgaW4gYWRkaXRpb24gdG8gb25lIG9mIHRoZSBpbnRlcnZhbHMgcHJldmlvdXNseSBt ZW50aW9uZWQgZm9yIGdlbmVyYWwgc2VydmljZSBtb25pdG9yaW5nLiBUaHVzLCB0aGUgVFdBTVAg dGVzdCBwcm9kdWNlcyBpbnN0YW5jZXMgb2YgbWV0cmljcyBmb3IgYW4gdW5zcGVjaWZpZWQgYW1v dW50IG9mIHRpbWUgLSB0eXBpY2FsbHkgdW50aWwgYSB1c2VyIG1hbnVhbGx5IHN0b3BzIHRoZSB0 ZXN0LiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkluIHN1bW1hcnksIGZyb20gbXkgcGVyc3BlY3RpdmUs IHRoZSBkdXJhdGlvbiBvZiB0aGUgdGVzdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgbWV0 cmljIGRlZmluaXRpb24uLi4uYnV0IG1heWJlIEkganVzdCBkb24ndCB1bmRlcnN0YW5kIHRoZSBt ZXRyaWMgZGVmaW5pdGlvbiB3ZWxsIGVub3VnaC48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJvbjwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIEFwciAxNywgMjAxNiBhdCA5OjE5IFBNLCBDYXJleSwg VGltb3RoeSAoTm9raWEgLSBVUykgJmx0OzxhIGhyZWY9Im1haWx0bzp0aW1vdGh5LmNhcmV5QG5v a2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpbW90aHkuY2FyZXlAbm9raWEuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvbiw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGFua3MgZm9yIGxvb2tpbmcgYXQgdGhpcy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5XaGVuIEkgZGlzY3Vzc2VkIHRoaXMgd2l0aCBBbCBpbmRpY2F0ZWQgdGhhdCB0 aGVzZSB3b3VsZCBiZSBwYXJ0IG9mIHRoZSBtZXRyaWMvYWN0aW9uIGRlZmluaXRpb24uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+QnV0IGlmIHdlIHdvdWxkIHdhbnQgdG8gZGVmaW5lIGEgbm9uLW1ldHJpYyBzcGVj aWZpYyBkdXJhdGlvbiBhdHRyaWJ1dGUgb2YgYW4gaW5kaXZpZHVhbCBhY3Rpb24gd2l0aGluDQog dGhlIGNvbnRleHQgb2YgdGhlIG92ZXJhbGwgc2NoZWR1bGUgKEkgYmVsaWV2ZSB0aGlzIGlzIHdo YXQgeW91IGFyZSByZXF1ZXN0aW5nPykgdGhlbiB3ZSBzaG91bGQgYXNzaWduIHRoYXQgZHVyYXRp b24gdGhhdCByZXN1bHRzIGluIChUNCkgdG8gdGhlIGFjdGlvbi4gQWN0dWFsbHkgeW91IGhhdmUg dGhlIHNhbWUgcHJvYmxlbSB3aXRoIFQyIOKAkyB3aXRoaW4gdGhlIGNvbnRleHQgYWN0aW9uIOKA kyB0aGlzIG9mZnNldCBpZiBuZWNlc3NhcnkgaXMgZGlmZmVyZW50DQogZnJvbSB0aGUgc2NoZWR1 bGUgc3RhcnQgcmFuZG9tbmVzcyAob25jZSB0aGUgcHJvY2VzcyBzdGFydHMgaG93IGxvbmcgdG8g d2FpdCBiZWZvcmUgdGhlIGJpdHMgaGl0IHRoZSB3aXJlKS4mbmJzcDsgTWF5YmUgdGhhdCBpcyB3 aGF0IHdlIGFyZSBtaXNzaW5nIOKAkyBBIHRpbWVyIGZvciBhbiBhY3Rpb24gd2l0aGluIHRoZSBj b250ZXh0IG9mIHRoZSBzY2hlZHVsZeKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvbW1lbnRzPzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IEVYVCBSb24gU3RhbmEgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cm9uLnN0YW5h QHZpYXZpc29sdXRpb25zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbi5zdGFuYUB2aWF2aXNvbHV0 aW9ucy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgQXByaWwgMTcsIDIwMTYg NjozNSBQTTxicj4NCjxiPlRvOjwvYj4gQ2FyZXksIFRpbW90aHkgKE5va2lhIC0gVVMpPGJyPg0K PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bG1hcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmxtYXBAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbG1hcF0gTE1BUDog RGVmaW5pbmcgdGhlIFNjaGVkdWxlJ3MgZXZlbnRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGltLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGFwcGVhcnMgeW91IGFyZSBtYWtpbmcgYW4gYXNzdW1w dGlvbiB0aGF0IGVhY2ggYWN0aW9uIHdpbGwgZW5kIG9uIGl0cyBvd24gKFQ0KS4mbmJzcDsgV2hp bGUgdGhhdCBpcyB0cnVlIGZvciB0dXJuLXVwIHRlc3RzIGxpa2UgUkZDLTI1NDQgYW5kIFkuMTU2 NCwgbG9uZyB0ZXJtIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcNCiB0ZXN0cyBsaWtlIFRXQU1QIGFu ZCBZLjE3MzEgYXJlIGV4cGVjdGVkIHRvIHByb2R1Y2UgcmVzdWx0cyAyNC83IGFuZCBzbyBkbyBu b3QgaGF2ZSBhIGRlZmluZWQgZW5kIHRpbWUuJm5ic3A7IFRoZXkgYXJlIGNvbmZpZ3VyZWQgd2l0 aCBhIHJhdGUgdG8gc2VuZCBwYWNrZXRzLCB0aGUgTUEgbWVhc3VyZXMgRkQsIEZEViBhbmQgRkxS IGFuZCB0aGVuIHRoZSBNQSBwZXJpb2RpY2FsbHkgYWdncmVnYXRlcyB0aGVzZSBzdGF0cyBhbmQg c2VuZHMgdGhlbSB0bw0KIHRoZSBjb2xsZWN0b3IuJm5ic3A7IFRoZSBhZ2dyZWdhdGlvbiByYXRl IGlzIHR5cGljYWxseSAxLCA1IG9yIDE1IG1pbnV0ZXMgc28gcmVwb3J0cyBjb250YWluIHJvbGxp bmcgc3RhcnQvZW5kIHRpbWVzIGFzIHRoZSB0ZXN0IGV4ZWN1dGVzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hpbGUgd2hhdCBJIGRl c2NyaWJlIGFib3ZlIGlzIHRoZSB0eXBpY2FsIHVzZSBjYXNlLCB0aGVyZSBhcmUgb3RoZXIgc2Nl bmFyaW9zIHdoZXJlIHRoZXNlIHNhbWUgdGVzdHMgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gZW11bGF0 ZSBzaG9ydCByYW5kb20gYnVyc3RzLiBJbiB0aGlzIHNjZW5hcmlvIHRoZSB0ZXN0cw0KIG5lZWQg dG8gYmUgY29uZmlndXJlZCB3aXRoIGFuIGluaXRpYWwgc3RhcnQgdGltZSwgYW4gaW50ZXJ2YWwg dG8gcmVzdGFydCB0aGUgdGVzdCwgYSByYW5kb20gc3RhcnQgb2Zmc2V0IGFuZCBhIGR1cmF0aW9u LiZuYnNwOyBGb3IgZXhhbXBsZSwgc3RhcnQgYXQgMTowMCB0b2RheSwgcmVzdGFydCBldmVyeSA1 IG1pbnV0ZXMgdGhlcmVhZnRlciwgZWFjaCBydW4gc2hvdWxkIGJlIG9mZnNldCBieSBhIHJhbmRv bSB2YWx1ZSB3aXRoaW4gNCBtaW51dGVzIGFuZA0KIGVhY2ggcnVuIHNob3VsZCBzZW5kIHRoZSBk YXRhIGZsb3dzIGZvciAxIG1pbnV0ZS4mbmJzcDsgSSB0aGluayB0aGUgb25seSBwYXJ0IG9mIHRo aXMgTE1BUCBkaWQgbm90IGRlZmluZSB3YXMgdGhlIGxhc3QgcGFyYW1ldGVyIC0gdGhlIHRlc3Qg ZHVyYXRpb24uIFdoaWxlIGVhY2ggdGVzdCBjb3VsZCBvZmZlciB0ZXN0LXNwZWNpZmljIHBhcmFt ZXRlcnMgdG8gZGVmaW5lIGl0cyBkdXJhdGlvbiwgSSB0aG91Z2h0IHRoZSBwcm9wb3NhbCB0byBh ZGQgdGhlDQogJ2VuZCcgb2JqZWN0IHdhcyB0byBwcm92aWRlIGEgY29tbW9uIGFwcHJvYWNoIGZv ciB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Um9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiBGcmksIEFwciA4LCAyMDE2IGF0IDg6NTIgQU0sIENhcmV5LCBUaW1v dGh5IChOb2tpYSAtIFVTKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpbW90aHkuY2FyZXlAbm9raWEu Y29tIiB0YXJnZXQ9Il9ibGFuayI+dGltb3RoeS5jYXJleUBub2tpYS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U ZWFtLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gdGhlIElFVEYjOTUgTE1BUCBzZXNz aW9uIHdlIGhhZCBhIGRpc2N1c3Npb24gb24gdGhlIG5lZWQgZm9yIHRoZSBuZXcgcGFyYW1ldGVy cyBmb3IgdGhlIG1hLXNjaGVkdWxlLWVuZCBhbmQgbWEtc2NoZWR1bGUtZHVyYXRpb24gcGFyYW1l dGVycywgZ2l2ZW4gdGhhdCB0aGUgbWEtc2NoZWR1bGUtc3RhcnQNCiAod2hpY2ggaXMgdHlwZWQg YXMgYW4gZXZlbnQpIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2Ugc2FpZCB3ZSB3b3Vs ZCBzaG93IHRoYXQgdGhlc2UgcGFyYW1ldGVycyB3ZXJlIG5vdCBuZWVkZWQgdXNpbmcgYW4gZXhh bXBsZSDigJMgc28gaGVyZSBnb2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TGV0cyBh c3N1bWUgd2UgaGF2ZSBhIHNjaGVkdWxlIG1hZGUgdXAgb2YgMiBhY3Rpb25zIChBMSwgQTIpIGlu IHBpcGVsaW5lIG1vZGUuIFRoZSBtYS1zY2hlZHVsZS1zdGFydCB3b3VsZCBoYXMgYSBwZXJpb2Rp YyBldmVudDoNCjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjIwLjI1cHQi PlN0YXJ0IEFwcmlsIDEsIDIwMTYgYXQgMDI6MDA6MDA8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW4tbGVmdDoyMC4yNXB0Ij5FbmQgTWF5IDEsIDIwMTYgYXQgMDI6MDA6MDA8bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDoyMC4yNXB0Ij5JbnRlcnZhbCA4Niw0MDAg KGRhaWx5KTxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjIwLjI1cHQiPlJh bmRvbW5lc3MgMzYwMCAod2l0aGluIHRoZSBob3VyKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+U28gdGhlIHNjaGVkdWxlIHdpbGwgcmVvY2N1ciBldmVyeSBkYXkgc3RhcnRpbmcgb24gQXBy aWwgMSBiZWdpbm5pbmcgYXQgMjowMHBtLiAoVDApIFRoZSBzdGFydGluZyBwZXJpb2Qgd2lsbCBi ZSByYW5kb20gYmV0d2VlbiAyOjAwYW0gYW5kIDM6MDBhbS4gKFQxKSBUaGlzIGRlZmluaXRpb24g aXMgc3VmZmljaWVudA0KIGZvciBpbnZva2luZyBBMSAoVDEpIGFuZCBpcyB3aGF0IEFsIGNvbnNp ZGVycyBhcyBCbHVlIHRpbWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgQTEgcGVy Zm9ybXMgYSB0ZXN0IEExIHBsYWNlcyBiaXRzIG9uIHRoZSB3aXJlIChUMikgYW5kIGNvbGxlY3Rz IHJlc3VsdHMgKFQzKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hl biBBMSBjb21wbGV0ZXMgKFQ0KSwgQTIgaXMgaW52b2tlZCAoVDUpIHdoaWNoIHBsYWNlcyBiaXRz IG9uIGEgd2lyZSBmb3IgQTIgKFQyKSBhbmQgY29sbGVjdHMgcmVzdWx0cyAoVDMpKS4gRmluYWxs eSB0aGUgcmVzdWx0cyBmcm9tIHRoZSBzY2hlZHVsZSBhcmUgcmVwb3J0ZWQgKFQ2KS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlQyJmFtcDtUMzogQWwgY29uc2lkZXJzIHRoaXMgdGltZSB0 byBiZSBwYXJ0IG9mIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBtZXRyaWMgYW5kIGFyZSByZXBvcnRl ZCBhcyBwYXJ0IG9mIHRoZSByZXN1bHQgY29udGVudCAobm90IGFzIGFuIGFjdHVhbCBwYXJhbWV0 ZXIpLiBUaGlzIHdhcyBoaXMgUmVkIHRpbWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlQ0 JmFtcDtUNTogQXJlIHRoZSBtYS1yZXBvcnQtW3N0YXJ0fGVuZF0tdGltZTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UNjogSXMgdGhlIG1hLXJlcG9ydC1kYXRlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBzdWNoIOKAkyBBcyBsb25nIGFzIGFuIEV2ZW50IGhh cyBhIGRlZmluZWQgb2NjdXJyZW5jZSAoVDE9VDAgJiM0MzsgcmFuZG9tbmVzcykgYWxsIHRoYXQg aXMgbmVjZXNzYXJ5IGlzIGEgc2luZ2xlIHBhcmFtZXRlciB0byBkZWZpbmUgdGhlIG9jY3VycmVu Y2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5RdWVzdGlvbnM/PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5CUiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ VGltPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmxt YXAgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmxtYXBAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5sbWFwQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1hcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1hcDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9966516C6EB5FC4381E05BF80AA55F77012A6513FFUS70UWXCHMBA0_--