From Henning.Schulzrinne@fcc.gov Tue Jan 1 19:23:13 2013 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 AABE521E804E for ; Tue, 1 Jan 2013 19:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTPXsVXlR4+B for ; Tue, 1 Jan 2013 19:23:12 -0800 (PST) Received: from dmz-mail1.fcc.gov (dmz-mail1.fcc.gov [192.104.54.105]) by ietfa.amsl.com (Postfix) with ESMTP id 71FDD21E8051 for ; Tue, 1 Jan 2013 19:23:11 -0800 (PST) Received: from P2PXMB13.fccnet.win.fcc.gov ([fe80::6593:6526:65f8:66b7]) by p2pxcas02.fccnet.win.fcc.gov ([fe80::2d69:114:8552:212f%13]) with mapi id 14.01.0438.000; Tue, 1 Jan 2013 22:23:10 -0500 From: Henning Schulzrinne To: =?iso-8859-1?Q?J=E9r=F4me_Benoit?= Thread-Topic: [lmap] Comments on LMAP architecture Thread-Index: AQHN48BZDRacQwUTNkyKe14Q0rqkeJgwvPE2gAKUrgD//7EwDoABT+UAgAEVJ5A= Date: Wed, 2 Jan 2013 03:23:09 +0000 Message-ID: References: <20121227002531.652c715c@nemesis.grenouille.com> <20121231152516.14ff63a2@nemesis.grenouille.com> , <20130101064524.14e414a9@nemesis.grenouille.com> In-Reply-To: <20130101064524.14e414a9@nemesis.grenouille.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.64] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" Subject: Re: [lmap] Comments on LMAP architecture X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 03:23:13 -0000 I'm not suggesting RFC 5655 as an output file format, although there might = be elements in the RFC that are worth looking at.=0A= =0A= I'm more talking about something like=0A= http://en.wikipedia.org/wiki/IP_Flow_Information_Export=0A= =0A= I admit that I lost you at how Shannon got involved in packet formats.=0A= =0A= However, this is already straying into solution space, so probably prematur= e. I'm just trying to make things a bit more concrete, since I'm finding ab= stract discussions less helpful and prone to talking past-each-other.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: J=E9r=F4me Benoit [jerome.benoit@grenouille.com]=0A= Sent: Tuesday, January 01, 2013 12:45 AM=0A= To: Henning Schulzrinne=0A= Cc: lmap@ietf.org=0A= Subject: Re: [lmap] Comments on LMAP architecture=0A= =0A= On Mon, 31 Dec 2012 14:51:54 +0000=0A= Henning Schulzrinne wrote:=0A= =0A= =0A= =0A= >=0A= > To summarize: Two measurement agents, one in the home and one in the netw= ork somewhere, exchange measurement traffic, such as, say, ICMP echo reques= ts or a TCP download. The agent at home takes the metric (throughput, laten= cy) plus identifying information (metric, time, endpoint identifier) and se= nds it to the data collector. The transmission format is likely different f= rom the format made available to users of the measurement data. One proposa= l was to use IPFIX as a way to encode the data, as IPFIX is just a containe= r format for records. (Obviously, this is only about the transmission forma= t, not the other components of IPFIX, which are indeed not applicable.)=0A= >=0A= > The data collector can then transform, combine and annotate data in any f= ormat, or multiple formats, for appropriate usage by authorized entities. I= t might make data available in an SQL database, a downloadable file or via = an API, for example.=0A= >=0A= > I'm not sure I understand why you want them to be the same entity. I admi= t I couldn't quite follow your IPFIX objection, but maybe you can explain, = based on the summary above, where you see the problem.=0A= >=0A= =0A= My IPFIX objection is based a an real implementation of a well know=0A= active measurement (with extras) and whatever how drunk is I am is, the=0A= IPFIX data format do not respect Shannon's theoretical information=0A= system standard speed derivation (the IPFIX standard is fine, but do=0A= not include octet/time derivative unit) and that's a pity for active=0A= measurement. Just state that fact in the RFC and I will never complain=0A= about IPFIX standard anymore (maybe, IPFIX is really a bunch of=0A= crappy point in time metrics from my point of view, but I will launch=0A= that delighted troll on an other mailing list :))=0A= =0A= ++=0A= =0A= --=0A= J=E9r=F4me Benoit aka fraggle=0A= La M=E9t=E9o du Net - http://grenouille.com=0A= OpenPGP Key ID : 9FE9161D=0A= Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D=0A= From jerome.benoit@grenouille.com Wed Jan 2 04:53:30 2013 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 08BA921F9096 for ; Wed, 2 Jan 2013 04:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.259 X-Spam-Level: X-Spam-Status: No, score=-1.259 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXZmtZpR2asH for ; Wed, 2 Jan 2013 04:53:29 -0800 (PST) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0529821F90D9 for ; Wed, 2 Jan 2013 04:53:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id F1C537F255; Wed, 2 Jan 2013 13:53:25 +0100 (CET) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLjG9rUuYXsR; Wed, 2 Jan 2013 13:53:15 +0100 (CET) Date: Wed, 2 Jan 2013 13:53:14 +0100 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: Henning Schulzrinne Message-ID: <20130102135314.54659d83@nemesis.grenouille.com> In-Reply-To: References: <20121227002531.652c715c@nemesis.grenouille.com> <20121231152516.14ff63a2@nemesis.grenouille.com> <20130101064524.14e414a9@nemesis.grenouille.com> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.13; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/MUpxIQAyJ=v.I6klJfaaIG+"; protocol="application/pgp-signature" Cc: "lmap@ietf.org" Subject: Re: [lmap] Comments on LMAP architecture X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 12:53:30 -0000 --Sig_/MUpxIQAyJ=v.I6klJfaaIG+ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, 2 Jan 2013 03:23:09 +0000 Henning Schulzrinne wrote: > I'm not suggesting RFC 5655 as an output file format, although there migh= t be elements in the RFC that are worth looking at. >=20 > I'm more talking about something like > http://en.wikipedia.org/wiki/IP_Flow_Information_Export I will read it when time permit.=20 >=20 > I admit that I lost you at how Shannon got involved in packet formats. >=20 > However, this is already straying into solution space, so probably premat= ure. I'm just trying to make things a bit more concrete, since I'm finding = abstract discussions less helpful and prone to talking past-each-other. I admit I shouldn't have post my last email (don't post when drunk :p).=20 But before I find time to dig further, have the FCC already started an implementation of an measurement system ? Happy new year.=20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/MUpxIQAyJ=v.I6klJfaaIG+ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlDkLboACgkQ+qDLUJ/pFh2ULwCeL5h37BpDHCNW7ta8XND70YlB pcQAoIHRgCjha9tBKEofOpjfpHOVnmG1 =g+cX -----END PGP SIGNATURE----- --Sig_/MUpxIQAyJ=v.I6klJfaaIG+-- From jamesmilleresquire@gmail.com Wed Jan 2 06:14:49 2013 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 4816921F8480 for ; Wed, 2 Jan 2013 06:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgbxclLXraG6 for ; Wed, 2 Jan 2013 06:14:47 -0800 (PST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id AD31C21F847B for ; Wed, 2 Jan 2013 06:14:45 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id m8so14305060vcd.36 for ; Wed, 02 Jan 2013 06:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=51Rbz3UPuv/auZXDoEcLF2VSebaVCMfyEkgtpS+PjnU=; b=sWGUVRll+L+v/6lC6XrFeftlzqHC+fRJjwnzUr0A84qXELpY9cVy0Z1LNQ/9npyBBL LrusSP53FWrIe2uJeqKVYwUBTKTUAPiQc0tmZdbcuQKL6p+nibkgGOYOzy9a/KufXq33 9hPu8vwBlpzOO4XOi22buNoX7NwnfPYMvpvZedzRcaw5WxjKBVyCgcM53uzFAAn2H9MJ NTj3Y1iQhRjKzw5u+DZOp7LeuFgFEvUmbICiLkbvun5j8uMGSkFR02FLSk0vBsPOpt/M jJTCl3lcswtO/XI7GKqHmFtxZUtOQTUKLVJKEU2w/blLS1ZX2E28frxY2iZm0RmGwav8 hTNg== Received: by 10.52.98.73 with SMTP id eg9mr61428462vdb.18.1357136085088; Wed, 02 Jan 2013 06:14:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.13.70 with HTTP; Wed, 2 Jan 2013 06:14:13 -0800 (PST) In-Reply-To: <20130102135314.54659d83@nemesis.grenouille.com> References: <20121227002531.652c715c@nemesis.grenouille.com> <20121231152516.14ff63a2@nemesis.grenouille.com> <20130101064524.14e414a9@nemesis.grenouille.com> <20130102135314.54659d83@nemesis.grenouille.com> From: James Miller Date: Wed, 2 Jan 2013 09:14:13 -0500 Message-ID: To: =?ISO-8859-1?Q?J=E9r=F4me_Benoit?= Content-Type: multipart/alternative; boundary=20cf307d01c64379fd04d24ede79 Cc: "lmap@ietf.org" , Henning Schulzrinne Subject: Re: [lmap] Comments on LMAP architecture X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 14:14:49 -0000 --20cf307d01c64379fd04d24ede79 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jerome, I'm not sure if you are asking if the FCC has done anything with IPFlow Info Export or a measurement system in general. We have been running a fixed program for two years with a network of 8000 some probes and are preparing to release our third report in the coming weeks. We are also currently on schedule to begin mobile performance testing on smartphones early this year. Note our interest is to offer the work we've done as a helpful reference and do not have an expectation that any IETF work would be bound to the particular solution we have. We do implement in our program a push model akin to the IPFIX and the observation points (clients in our parlance) do deliver test results to collectors that are run by our contractor. The significant difference from IPFIX is that our program is an active testing environment so we are fundamentally not doing passive observations. We have collected a limited set of byte count data from some of the probes but it is not implemented uniformly across the platform. I will discuss rfc3917 IPFIX with our contractor again. Happy to answer any other deep dive questions you might have as you are thinking about the draft and ongoing work. On Wed, Jan 2, 2013 at 7:53 AM, J=E9r=F4me Benoit wrote: > On Wed, 2 Jan 2013 03:23:09 +0000 > Henning Schulzrinne wrote: > > > I'm not suggesting RFC 5655 as an output file format, although there > might be elements in the RFC that are worth looking at. > > > > I'm more talking about something like > > http://en.wikipedia.org/wiki/IP_Flow_Information_Export > > I will read it when time permit. > > > > > I admit that I lost you at how Shannon got involved in packet formats. > > > > However, this is already straying into solution space, so probably > premature. I'm just trying to make things a bit more concrete, since I'm > finding abstract discussions less helpful and prone to talking > past-each-other. > > I admit I shouldn't have post my last email (don't post when drunk :p). > > But before I find time to dig further, have the FCC already started an > implementation of an measurement system ? > > Happy new year. > > -- > J=E9r=F4me Benoit aka fraggle > La M=E9t=E9o du Net - http://grenouille.com > OpenPGP Key ID : 9FE9161D > Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > --20cf307d01c64379fd04d24ede79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jerome,

I'm not sure if you are asking if the FCC ha= s done anything with IPFlow Info Export or a measurement system in general.= =A0We have been running a fixed program for two years with a network of 80= 00 some probes and are preparing to release our third report in the coming = weeks. =A0We are also currently on schedule to begin mobile performance tes= ting on smartphones early this year.

Note our interest is to offer the work we've done a= s a helpful reference and do not have an expectation that any IETF work wou= ld be bound to the particular solution we have.

We do implement in our program a push model akin to the IPFIX and the obser= vation points (clients in our parlance) do deliver test results to collecto= rs that are run by our contractor.

The significant= difference from IPFIX is that our program is an active testing environment= so we are fundamentally not doing passive observations. =A0We have collect= ed a limited set of byte count data from some of the probes but it is not i= mplemented uniformly across the platform. =A0I will discuss rfc3917 IPFIX w= ith our contractor again.

Happy to answer any other deep dive questions you might have as you are= thinking about the draft and ongoing work.

On Wed, Jan 2, 2013 at 7:53 AM, J=E9r=F4me Benoit <je= rome.benoit@grenouille.com> wrote:
On Wed, 2 Jan 2013 03:23:09 +0000
Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

> I'm not suggesting RFC 5655 as an output file format, although the= re might be elements in the RFC that are worth looking at.
>
> I'm more talking about something like
> http://en.wikipedia.org/wiki/IP_Flow_Information_Export=

I will read it when time permit.

>
> I admit that I lost you at how Shannon got involved in packet formats.=
>
> However, this is already straying into solution space, so probably pre= mature. I'm just trying to make things a bit more concrete, since I'= ;m finding abstract discussions less helpful and prone to talking past-each= -other.

I admit I shouldn't have post my last email (don't post when = drunk :p).

But before I find time to dig further, have the FCC already started an
implementation of an measurement system ?

Happy new year.

--
J=E9r=F4me Benoit aka fraggle
La M=E9t=E9o du Net - h= ttp://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D

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


--20cf307d01c64379fd04d24ede79-- From mdeleo@cisco.com Wed Jan 2 08:03:10 2013 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 BF62621F84F3 for ; Wed, 2 Jan 2013 08:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sZc9YpJWyyh for ; Wed, 2 Jan 2013 08:03:07 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9274321F84D9 for ; Wed, 2 Jan 2013 08:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12411; q=dns/txt; s=iport; t=1357142587; x=1358352187; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=9T7RJaMUYD6DA8z+SdIKQBRAAkPx2HKL19ppJnC3o2o=; b=LzqQ+3NqNTqVpSpCgvA+g5aBVAdVZHwfq0kPROu6wGTuBx77H3jx7W5q F8htS3UqZ+UTZNKVna+rz6MHjXDozhB3N7Qgl1Sq9CPvZB9dAMeJz8jFM UXmp587WVMqJjghGT0GGisgw8/nfe75py7EcVXTMLwD70RcP4f/oXLcEh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgY+AORY5FCtJXG//2dsb2JhbABFgX9KqG+JBgGJDRZzgh4BAQEDAQEBAQkhQQQMCwIBCBEBAwEBCx0HJwsUAwYIAgQTCBOHcgYMuGGMYgqDTWEDiC2Oe48sgnSBaAkXHg X-IronPort-AV: E=Sophos;i="4.84,396,1355097600"; d="scan'208,217";a="158071462" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 02 Jan 2013 16:03:06 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r02G36dh003895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Jan 2013 16:03:06 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.154]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 10:03:06 -0600 From: "Michael De Leo (mdeleo)" To: "lmap@ietf.org" Thread-Topic: [lmap] Comments on LMAP architecture Thread-Index: AQHN48BXpJqor1bfBEKe0genstKt/JgxJYcAgAI82wCAAAdxAIAA+aQAgAFql4CAAJ9HAIAAFqGA//+4N1A= Date: Wed, 2 Jan 2013 16:03:05 +0000 Message-ID: References: <20121227002531.652c715c@nemesis.grenouille.com> <20121231152516.14ff63a2@nemesis.grenouille.com> <20130101064524.14e414a9@nemesis.grenouille.com> <20130102135314.54659d83@nemesis.grenouille.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.78.2] Content-Type: multipart/alternative; boundary="_000_D4B85298517C1A429AA7F2AE6613A93B455DB7xmbalnx15ciscocom_" MIME-Version: 1.0 Subject: Re: [lmap] Comments on LMAP architecture X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 16:03:10 -0000 --_000_D4B85298517C1A429AA7F2AE6613A93B455DB7xmbalnx15ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm thinking we might want to detail more the use cases for measurement. In= the case of having a server and collector, there are many things that can = be tested beyond bandwidth IMHO that might be valuable to the consumer as w= ell as the ISP. I think this would be important to most users, but keeping = the architecture open to other test for future flexibility (without overcom= plicating). Some work like ICSI Analyzer from Berkeley (I have no relation to the proje= ct), do elements at the IP layer level. Some important measurements are por= t filtering, DNS caching, because we are in transition IPv6 support and NAT= detection. Maybe an XML schema with test definitions might be more flexible? Mike From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Jam= es Miller Sent: Wednesday, January 02, 2013 9:14 AM To: J=E9r=F4me Benoit Cc: lmap@ietf.org; Henning Schulzrinne Subject: Re: [lmap] Comments on LMAP architecture Jerome, I'm not sure if you are asking if the FCC has done anything with IPFlow Inf= o Export or a measurement system in general. We have been running a fixed = program for two years with a network of 8000 some probes and are preparing = to release our third report in the coming weeks. We are also currently on = schedule to begin mobile performance testing on smartphones early this year= . Note our interest is to offer the work we've done as a helpful reference an= d do not have an expectation that any IETF work would be bound to the parti= cular solution we have. We do implement in our program a push model akin to the IPFIX and the obser= vation points (clients in our parlance) do deliver test results to collecto= rs that are run by our contractor. The significant difference from IPFIX is that our program is an active test= ing environment so we are fundamentally not doing passive observations. We= have collected a limited set of byte count data from some of the probes bu= t it is not implemented uniformly across the platform. I will discuss rfc3= 917 IPFIX with our contractor again. Happy to answer any other deep dive questions you might have as you are thi= nking about the draft and ongoing work. On Wed, Jan 2, 2013 at 7:53 AM, J=E9r=F4me Benoit > wrote: On Wed, 2 Jan 2013 03:23:09 +0000 Henning Schulzrinne > wrote: > I'm not suggesting RFC 5655 as an output file format, although there migh= t be elements in the RFC that are worth looking at. > > I'm more talking about something like > http://en.wikipedia.org/wiki/IP_Flow_Information_Export I will read it when time permit. > > I admit that I lost you at how Shannon got involved in packet formats. > > However, this is already straying into solution space, so probably premat= ure. I'm just trying to make things a bit more concrete, since I'm finding = abstract discussions less helpful and prone to talking past-each-other. I admit I shouldn't have post my last email (don't post when drunk :p). But before I find time to dig further, have the FCC already started an implementation of an measurement system ? Happy new year. -- J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap --_000_D4B85298517C1A429AA7F2AE6613A93B455DB7xmbalnx15ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I’m thinking we mig= ht want to detail more the use cases for measurement. In the case of having= a server and collector, there are many things that can be tested beyond bandwidth IMHO that might be valuable to the consumer as well as th= e ISP. I think this would be important to most users, but keeping the archi= tecture open to other test for future flexibility (without overcomplicating= ).

 <= /p>

Some work like ICSI Analy= zer from Berkeley (I have no relation to the project), do elements at the I= P layer level. Some important measurements are port filtering, DNS caching, because we are in transition IPv6 support and NAT detection.<= o:p>

 <= /p>

Maybe an XML schema with = test definitions might be more flexible?

 <= /p>

Mike

 <= /p>

From: lmap-bou= nces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of James Miller
Sent: Wednesday, January 02, 2013 9:14 AM
To: J=E9r=F4me Benoit
Cc: lmap@ietf.org; Henning Schulzrinne
Subject: Re: [lmap] Comments on LMAP architecture<= /p>

 

Jerome,

 

I'm not sure if you are asking if the FCC has done a= nything with IPFlow Info Export or a measurement system in general.  W= e have been running a fixed program for two years with a network of 8000 so= me probes and are preparing to release our third report in the coming weeks.  We are also currently on sched= ule to begin mobile performance testing on smartphones early this year.

 

Note our interest is to offer the work we've done as= a helpful reference and do not have an expectation that any IETF work woul= d be bound to the particular solution we have.

 

We do implement in our program a push model akin to = the IPFIX and the observation points (clients in our parlance) do deliver t= est results to collectors that are run by our contractor.

 

The significant difference from IPFIX is that our pr= ogram is an active testing environment so we are fundamentally not doing pa= ssive observations.  We have collected a limited set of byte count dat= a from some of the probes but it is not implemented uniformly across the platform.  I will discuss rfc3917 IP= FIX with our contractor again.

Happy to answer any other deep dive questions you might have as you are thi= nking about the draft and ongoing work.

 

On Wed, Jan 2, 2013 at 7:53 AM, J=E9r=F4me Benoit &l= t;jerome.= benoit@grenouille.com> wrote:

On Wed, 2 Jan 2013 03= :23:09 +0000
Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

> I'm not suggesting RFC 5655 as an output file format, although there m= ight be elements in the RFC that are worth looking at.
>
> I'm more talking about something like
> http://en.wikipedia.org/wiki/IP_Flow_Information_Export

I will read it when time permit.


>
> I admit that I lost you at how Shannon got involved in packet formats.=
>
> However, this is already straying into solution space, so probably pre= mature. I'm just trying to make things a bit more concrete, since I'm findi= ng abstract discussions less helpful and prone to talking past-each-other.<= o:p>

I admit I shouldn't have post my last email (don't p= ost when drunk :p).

But before I find time to dig further, have the FCC already started an
implementation of an measurement system ?

Happy new year.


--
J=E9r=F4me Benoit aka fraggle
La M=E9t=E9o du Net - h= ttp://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D


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

 

--_000_D4B85298517C1A429AA7F2AE6613A93B455DB7xmbalnx15ciscocom_-- From bs7652@att.com Wed Jan 2 09:10:38 2013 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 CD1CE21F8617 for ; Wed, 2 Jan 2013 09:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Unes3D8Komb for ; Wed, 2 Jan 2013 09:10:38 -0800 (PST) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 16CC121F860B for ; Wed, 2 Jan 2013 09:10:38 -0800 (PST) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id d0a64e05.0.803980.00-380.2211008.nbfkord-smmo04.seg.att.com (envelope-from ); Wed, 02 Jan 2013 17:10:38 +0000 (UTC) X-MXL-Hash: 50e46a0e61541bc3-9dc4ada7db88ec07841f773e36abaea326c95c12 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r02HAbk3009010 for ; Wed, 2 Jan 2013 12:10:37 -0500 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r02HAWsj008996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Jan 2013 12:10:33 -0500 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by sflint04.pst.cso.att.com (RSA Interceptor) for ; Wed, 2 Jan 2013 12:10:08 -0500 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0318.001; Wed, 2 Jan 2013 12:09:59 -0500 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: Terminology: Roles Thread-Index: Ac3pC/zd7+e2Y3KMSxmsgM49OuXIow== Date: Wed, 2 Jan 2013 17:09:59 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113021A719@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.199.78.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=DOc4FVxb c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=XF2aQeIDtRMA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=h2qRYD2qE] X-AnalysisOut: [wwA:10 a=rX7a8p2GKV0frGdiiGQA:9 a=CjuIK1q_8ugA:10] Subject: [lmap] Terminology: Roles X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 17:10:39 -0000 Thanks Marc, for starting us back up with the use cases. I'd meant to get b= ack to working on lmap stuff before the holidays but decided to have the fl= u instead. It was a poor decision. Before really examining use cases, I think it's important to agree on termi= nology for the various roles that "entities" play in the ecosystem we're ex= amining. I'm hoping I don't need to define them in great detail. I propose = the following roles, which are defined in terms of relationship to the End = User. End User: The customer or end user of a consumer / small business broadband= access service. Access Network Provider (ANP): The provider of the physical access technolo= gy that the End User connects to. Application Service Provider (ASP): Provides Internet-based services or web= sites that are accessed or used by an End User. ASPs may have an explicit = "member/customer" relationship with the End User, or an "anonymous eyeballs= " relationship. [I see Marc used "Over the Top Provider" for this, but want= to make sure that we don't restrict this to content providers -- I've seen= providers that are concerned with the ability of end users to access every= thing from simple web pages to webmail, storage, calendar, etc. utilities, = to VoIP and streaming content.] Transit Network Provider (TNP): Traffic between an End User and an ASP will= transit 0, 1, or more TNP networks. [Since we've been focused on the Acces= s Network, we haven't really touched on this provider -- but I have seen so= me hints that we may want to be able to talk about these entities, so I thi= nk they deserve a name.] 3rd Party: No relationship with any particular End User, from the perspecti= ve of providing Internet access, services, or web sites. Regulator: Special case of a 3rd Party that is affiliated with a government= and has been assigned certain responsibilities and powers by that governme= nt. Barbara From bs7652@att.com Wed Jan 2 10:02:07 2013 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 E183C21F876E for ; Wed, 2 Jan 2013 10:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAfnYp3cQdOK for ; Wed, 2 Jan 2013 10:02:07 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id CD0EC21F8754 for ; Wed, 2 Jan 2013 10:02:06 -0800 (PST) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id e1674e05.0.51364.00-281.148353.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 02 Jan 2013 18:02:06 +0000 (UTC) X-MXL-Hash: 50e4761e7d80cb6a-5b8be31722580090d707cd8d089e53e220421058 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r02I2643017154 for ; Wed, 2 Jan 2013 13:02:06 -0500 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r02I20Xu017150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Jan 2013 13:02:01 -0500 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by sflint04.pst.cso.att.com (RSA Interceptor) for ; Wed, 2 Jan 2013 13:01:41 -0500 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.02.0318.001; Wed, 2 Jan 2013 13:01:41 -0500 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: Terminology: Basic Elements Thread-Index: Ac3pEzdJlJxhcRIFS4u5zBp3NncrKA== Date: Wed, 2 Jan 2013 18:01:40 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113021A786@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.199.78.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=W4iPo2qk c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=XF2aQeIDtRMA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=jkm8GPVGx] X-AnalysisOut: [lYA:10 a=mSzCknQvazTDBn6cYpUA:9 a=CjuIK1q_8ugA:10 a=GUjHz-] X-AnalysisOut: [Qyv44pJDOd:21 a=RIx46auKeVqXSLE3:21] Subject: [lmap] Terminology: Basic Elements X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 18:02:08 -0000 Beyond terminology for roles, I think there also needs to be some terminolo= gy for commonly discussed elements. I'm proposing the following: Measurement: Measurement function: Code that instantiates what is specifically and direc= tly needed to "do" a particular Measurement. A Measurement can be a Passive Measurement or an Active Measurement. For Ac= tive Measurements, nothing is implied as to whether the Measurement functio= n initiates or simply responds to messages sent from another Measurement fu= nction. Measurement Agent (MA): A function that contains one or more Measurement fu= nctions. [I read a recommendation on this list not to use "client" and serv= er", since often the same, um, "thing" can act both as initiator or respond= er, and the terms could be confusing in certain contexts. "Agent" was sugge= sted. I think this term will occur often, so I gave it an abbreviation. In = reading discussions on this list, there seems to be a need to distinguish b= etween distinct Measurement functions and a collection of Measurement funct= ions that could be called a "Measurement Agent".] CPN Device: A physical device that exists inside the Customer Premises Netw= ork. A CPN Device can have 0, 1, or more Measurement Agents. [Consistent wi= th my thinking that roles should be considered according to their relations= hip to the End User, I also think that we need to have an idea of "inside t= he CPN" and "outside the CPN".] Network Element: A physical "device" that exists external to the CPN. E.g.,= network router, DSLAM, web server. A Network Element can have 0, 1, or mor= e Measurement Agents. User Interface: Allows a human being to access functionality or data. It co= uld be locally or remotely displayed (in physical relationship to the funct= ionality that generates the User Interface). For example, a screen on a CPN= Device could be used to display locally, and a browser on a computer could= be used to display remotely. [We haven't really touched on this explicitly= , but we seem to come repeatedly to the question of how measurement data is= made available to various people. When it comes to providing people with a= ccess to measurement data, the User Interface is an important concept.] Barbara From shane@castlepoint.net Wed Jan 2 13:29:57 2013 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 0EF5921F8431 for ; Wed, 2 Jan 2013 13:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VVHSVBo44vT for ; Wed, 2 Jan 2013 13:29:56 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4939A21F842E for ; Wed, 2 Jan 2013 13:29:56 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id D52C1300036 for ; Wed, 2 Jan 2013 21:29:55 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 1BD9D300034; Wed, 2 Jan 2013 14:29:55 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113021A786@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Wed, 2 Jan 2013 14:29:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2468D430-0E01-440F-B762-BAC0887D339E@castlepoint.net> References: <2D09D61DDFA73D4C884805CC7865E6113021A786@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Jan 2 14:29:55 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50e4a6d3199631865411838 X-DSPAM-Factors: 27, they+#+#+to, 0.01000, to+#+#+#+to, 0.01000, and+#+#+#+the, 0.01000, that+are, 0.01000, a+need, 0.01000, think+that, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, To*STARK+BARBARA, 0.01000, be+considered, 0.01000, Mime-Version*OS+X, 0.01000, bs7652+#+#+wrote, 0.01000, a+#+#+I, 0.01000, Cc*ietf.org+#+ietf.org, 0.01000, the+#+#+#+to, 0.01000, From*Amante+shane, 0.01000, of+#+#+#+and, 0.01000, to+#+#+#+I, 0.01000, are+#+to, 0.01000, so+#+#+#+to, 0.01000, that+#+#+is, 0.01000, a+#+to, 0.01000, Mime-Version*Mail+#+1499, 0.01000, the+Measurement, 0.01000, and+#+the, 0.01000, to+do, 0.01000, to+#+#+and, 0.01000 Cc: "lmap@ietf.org" Subject: Re: [lmap] Terminology: Basic Elements X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 21:29:57 -0000 Barbara, Thanks also to you for reinitiating the conversation. I've been = thinking more about LMAP and wanted to get your (and, others) thoughts = wrt a refinement of your proposed definitions below. On Jan 2, 2013, at 11:01 AM, "STARK, BARBARA H" wrote: > Beyond terminology for roles, I think there also needs to be some = terminology for commonly discussed elements. I'm proposing the = following: >=20 > Measurement: > Measurement function: Code that instantiates what is specifically and = directly needed to "do" a particular Measurement. > A Measurement can be a Passive Measurement or an Active Measurement. = For Active Measurements, nothing is implied as to whether the = Measurement function initiates or simply responds to messages sent from = another Measurement function. I'm wondering if we should further refine active measurements. = Specifically, I think there are probably two sub-cases: a) Automated (Not [Residential] End-User Initiated?) Active = Measurement: An example here would be periodic (automated) active, = network performance measurements that are "running in the background" = for a "long" period of time, e.g.: days, weeks, months?, until shut-off.=20= b) Ad-hoc ([Residential] End-User initiated?) Active Measurement: An = example here might be examples you've provided in the past where either = an end-user, or some one acting on their behalf, initiates a one-time, = ad-hoc ping, traceroute, "speedtest", ICSI NetAlyzer or other diagnostic = program to "measure" some aspect(s) of performance. FWIW, perhaps such a classification (or, start of one) may help us focus = LMAP work on case (a) above, where end-users won't typically be involved = beyond, say, initially consenting to have such testing done using their = device(s), e.g.: "opt-in". I'm sure we can come up with much more precise definitions than what = I've provided above, but hopefully they are enough to grasp the concept = of differentiating between the scope of measurements LMAP (or, really, = participants on the mailing list) want to or should focus on. Thanks, -shane > Measurement Agent (MA): A function that contains one or more = Measurement functions. [I read a recommendation on this list not to use = "client" and server", since often the same, um, "thing" can act both as = initiator or responder, and the terms could be confusing in certain = contexts. "Agent" was suggested. I think this term will occur often, so = I gave it an abbreviation. In reading discussions on this list, there = seems to be a need to distinguish between distinct Measurement functions = and a collection of Measurement functions that could be called a = "Measurement Agent".] >=20 > CPN Device: A physical device that exists inside the Customer Premises = Network. A CPN Device can have 0, 1, or more Measurement Agents. = [Consistent with my thinking that roles should be considered according = to their relationship to the End User, I also think that we need to have = an idea of "inside the CPN" and "outside the CPN".] > Network Element: A physical "device" that exists external to the CPN. = E.g., network router, DSLAM, web server. A Network Element can have 0, = 1, or more Measurement Agents. > User Interface: Allows a human being to access functionality or data. = It could be locally or remotely displayed (in physical relationship to = the functionality that generates the User Interface). For example, a = screen on a CPN Device could be used to display locally, and a browser = on a computer could be used to display remotely. [We haven't really = touched on this explicitly, but we seem to come repeatedly to the = question of how measurement data is made available to various people. = When it comes to providing people with access to measurement data, the = User Interface is an important concept.] >=20 > Barbara >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap >=20 From jason.weil@twcable.com Thu Jan 3 07:39:16 2013 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 44CAB21F8CB5 for ; Thu, 3 Jan 2013 07:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGNyLIP3532g for ; Thu, 3 Jan 2013 07:39:15 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEFA21F8CB4 for ; Thu, 3 Jan 2013 07:39:15 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,403,1355115600"; d="scan'208";a="6114337" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 03 Jan 2013 10:38:00 -0500 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.45]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Thu, 3 Jan 2013 10:39:14 -0500 From: "Weil, Jason" To: Shane Amante , "STARK, BARBARA H" Date: Thu, 3 Jan 2013 10:39:14 -0500 Thread-Topic: [lmap] Terminology: Basic Elements Thread-Index: Ac3pyHteVAruZykdSw+cnft1h5Jw3A== Message-ID: In-Reply-To: <2468D430-0E01-440F-B762-BAC0887D339E@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" Subject: Re: [lmap] Terminology: Basic Elements X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 15:39:16 -0000 Shane/Barbara, This seems like a useful distinction for the two general active test measurement cases and maps into the first two use cases from the LMAP draft and the subsequent breakout LMAP Use Case draft. Personally I like "User Initiated Active Measurement" or alternatively "User On Demand Active Measurement" for the user controlled test cases For the other "Coordinated Active Measurement" (Could easily substitute Coordinated with "Managed" or "Scheduled") Comment on Term: The CPN Device definition should be generic enough and maybe even explicitly state that this could include a computer/laptop in addition to a stand alone device that seems implied here like a router, modem or dongle. General Comment: I also agree with Shane that we should focus on the Coordinated LMAP use case in the current discussion as there does not appear to be consensus on taking on the User Initiated testing in the IETF at this time. Thanks, Jason On 1/2/13 4:29 PM, "Shane Amante" wrote: >Barbara, > >Thanks also to you for reinitiating the conversation. I've been thinking >more about LMAP and wanted to get your (and, others) thoughts wrt a >refinement of your proposed definitions below. > >On Jan 2, 2013, at 11:01 AM, "STARK, BARBARA H" wrote: >> Beyond terminology for roles, I think there also needs to be some >>terminology for commonly discussed elements. I'm proposing the following: >> >> Measurement: >define it; this term is *not* specific to "lmap" or large-scale >>performance measurements> >> Measurement function: Code that instantiates what is specifically and >>directly needed to "do" a particular Measurement. >> A Measurement can be a Passive Measurement or an Active Measurement. >>For Active Measurements, nothing is implied as to whether the >>Measurement function initiates or simply responds to messages sent from >>another Measurement function. > >I'm wondering if we should further refine active measurements. >Specifically, I think there are probably two sub-cases: >a) Automated (Not [Residential] End-User Initiated?) Active Measurement: >An example here would be periodic (automated) active, network performance >measurements that are "running in the background" for a "long" period of >time, e.g.: days, weeks, months?, until shut-off. >b) Ad-hoc ([Residential] End-User initiated?) Active Measurement: An >example here might be examples you've provided in the past where either >an end-user, or some one acting on their behalf, initiates a one-time, >ad-hoc ping, traceroute, "speedtest", ICSI NetAlyzer or other diagnostic >program to "measure" some aspect(s) of performance. > >FWIW, perhaps such a classification (or, start of one) may help us focus >LMAP work on case (a) above, where end-users won't typically be involved >beyond, say, initially consenting to have such testing done using their >device(s), e.g.: "opt-in". > >I'm sure we can come up with much more precise definitions than what I've >provided above, but hopefully they are enough to grasp the concept of >differentiating between the scope of measurements LMAP (or, really, >participants on the mailing list) want to or should focus on. > >Thanks, > >-shane > > > >> Measurement Agent (MA): A function that contains one or more >>Measurement functions. [I read a recommendation on this list not to use >>"client" and server", since often the same, um, "thing" can act both as >>initiator or responder, and the terms could be confusing in certain >>contexts. "Agent" was suggested. I think this term will occur often, so >>I gave it an abbreviation. In reading discussions on this list, there >>seems to be a need to distinguish between distinct Measurement functions >>and a collection of Measurement functions that could be called a >>"Measurement Agent".] >> >> CPN Device: A physical device that exists inside the Customer Premises >>Network. A CPN Device can have 0, 1, or more Measurement Agents. >>[Consistent with my thinking that roles should be considered according >>to their relationship to the End User, I also think that we need to have >>an idea of "inside the CPN" and "outside the CPN".] >> Network Element: A physical "device" that exists external to the CPN. >>E.g., network router, DSLAM, web server. A Network Element can have 0, >>1, or more Measurement Agents. >> User Interface: Allows a human being to access functionality or data. >>It could be locally or remotely displayed (in physical relationship to >>the functionality that generates the User Interface). For example, a >>screen on a CPN Device could be used to display locally, and a browser >>on a computer could be used to display remotely. [We haven't really >>touched on this explicitly, but we seem to come repeatedly to the >>question of how measurement data is made available to various people. >>When it comes to providing people with access to measurement data, the >>User Interface is an important concept.] >> >> Barbara >> >> _______________________________________________ >> 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 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. From jason.weil@twcable.com Thu Jan 3 07:47:59 2013 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 1E91321F85DF for ; Thu, 3 Jan 2013 07:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMC1wJZa2zQd for ; Thu, 3 Jan 2013 07:47:58 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7388121F8596 for ; Thu, 3 Jan 2013 07:47:58 -0800 (PST) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,403,1355115600"; d="scan'208";a="6322871" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 03 Jan 2013 10:47:02 -0500 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.45]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 3 Jan 2013 10:47:57 -0500 From: "Weil, Jason" To: "STARK, BARBARA H" , "lmap@ietf.org" Date: Thu, 3 Jan 2013 10:47:58 -0500 Thread-Topic: [lmap] Terminology: Roles Thread-Index: Ac3pybOH9a9XiTfhRKyMzhIMXdNzqw== Message-ID: In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113021A719@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] Terminology: Roles X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 15:47:59 -0000 Barbara, I would add an additional Role: CDN - Content Delivery Network. If we will be discussing measurements into the network I think it is useful to have this role included to offer more granularity to the roles of ASP and TNP for test point consideration. Thanks, Jason On 1/2/13 12:09 PM, "STARK, BARBARA H" wrote: >Thanks Marc, for starting us back up with the use cases. I'd meant to get >back to working on lmap stuff before the holidays but decided to have the >flu instead. It was a poor decision. > >Before really examining use cases, I think it's important to agree on >terminology for the various roles that "entities" play in the ecosystem >we're examining. I'm hoping I don't need to define them in great detail. >I propose the following roles, which are defined in terms of relationship >to the End User. > >End User: The customer or end user of a consumer / small business >broadband access service. > >Access Network Provider (ANP): The provider of the physical access >technology that the End User connects to. > >Application Service Provider (ASP): Provides Internet-based services or >web sites that are accessed or used by an End User. ASPs may have an >explicit "member/customer" relationship with the End User, or an >"anonymous eyeballs" relationship. [I see Marc used "Over the Top >Provider" for this, but want to make sure that we don't restrict this to >content providers -- I've seen providers that are concerned with the >ability of end users to access everything from simple web pages to >webmail, storage, calendar, etc. utilities, to VoIP and streaming >content.] > >Transit Network Provider (TNP): Traffic between an End User and an ASP >will transit 0, 1, or more TNP networks. [Since we've been focused on the >Access Network, we haven't really touched on this provider -- but I have >seen some hints that we may want to be able to talk about these entities, >so I think they deserve a name.] > >3rd Party: No relationship with any particular End User, from the >perspective of providing Internet access, services, or web sites. > >Regulator: Special case of a 3rd Party that is affiliated with a >government and has been assigned certain responsibilities and powers by >that government. > >Barbara > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap 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. From Henning.Schulzrinne@fcc.gov Thu Jan 3 14:55:17 2013 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 2E93321F8DDC for ; Thu, 3 Jan 2013 14:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUswk9wbFE-z for ; Thu, 3 Jan 2013 14:55:15 -0800 (PST) Received: from dmz-mail2.fcc.gov (dmz-mail2.fcc.gov [192.104.54.11]) by ietfa.amsl.com (Postfix) with ESMTP id AAC2B21F8DE3 for ; Thu, 3 Jan 2013 14:55:12 -0800 (PST) Received: from P2PXMB13.fccnet.win.fcc.gov ([fe80::6593:6526:65f8:66b7]) by p2pxcas03.fccnet.win.fcc.gov ([fe80::8db2:ac93:84fc:c36b%13]) with mapi id 14.01.0438.000; Thu, 3 Jan 2013 17:55:11 -0500 From: Henning Schulzrinne To: "Michael De Leo (mdeleo)" , "lmap@ietf.org" Thread-Topic: [lmap] Comments on LMAP architecture Thread-Index: AQHN48BZDRacQwUTNkyKe14Q0rqkeJgwvPE2gAKUrgD//7EwDoABT+UAgAEVJ5CAAPS3AIAAFqCAgAAea4CAAa7Jeg== Date: Thu, 3 Jan 2013 22:55:10 +0000 Message-ID: References: <20121227002531.652c715c@nemesis.grenouille.com> <20121231152516.14ff63a2@nemesis.grenouille.com> <20130101064524.14e414a9@nemesis.grenouille.com> <20130102135314.54659d83@nemesis.grenouille.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.64] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] Comments on LMAP architecture X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:55:17 -0000 I agree that we don't want to be too specific as to the end points and thro= ughput/delay measurements. But all measurements have a set of features in c= ommon: - they have one or more endpoints, with "two" being a common case (the othe= r end point may not be fixed, as for the DNS example you mention) - they are either a single event or repeat - they generate results (tuples) Just to make this more concrete again, imagine a simple request-response pr= otocol that has the following functionality: "Hi, this is your controller speaking. Dear measurement agent, please start= the X(5060) metric (=3D port blocking test for port 5060) and the Y(exampl= e.com) metric (=3D DNS caching test with parameter example.com), run it onc= e, and deposit the results at collector Z. Thank you." "Hi controller. I can't do X, but I'm happy to do Y." I suspect that this functionality can be expressed in XML, JSON or even ASN= .1. I wager that the latter will be the less likely outcome. Henning ________________________________ From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Michael De= Leo (mdeleo) [mdeleo@cisco.com] Sent: Wednesday, January 02, 2013 11:03 AM To: lmap@ietf.org Subject: Re: [lmap] Comments on LMAP architecture I=92m thinking we might want to detail more the use cases for measurement. = In the case of having a server and collector, there are many things that ca= n be tested beyond bandwidth IMHO that might be valuable to the consumer as= well as the ISP. I think this would be important to most users, but keepin= g the architecture open to other test for future flexibility (without overc= omplicating). Some work like ICSI Analyzer from Berkeley (I have no relation to the proje= ct), do elements at the IP layer level. Some important measurements are por= t filtering, DNS caching, because we are in transition IPv6 support and NAT= detection. Maybe an XML schema with test definitions might be more flexible? Mike From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Jam= es Miller Sent: Wednesday, January 02, 2013 9:14 AM To: J=E9r=F4me Benoit Cc: lmap@ietf.org; Henning Schulzrinne Subject: Re: [lmap] Comments on LMAP architecture Jerome, I'm not sure if you are asking if the FCC has done anything with IPFlow Inf= o Export or a measurement system in general. We have been running a fixed = program for two years with a network of 8000 some probes and are preparing = to release our third report in the coming weeks. We are also currently on = schedule to begin mobile performance testing on smartphones early this year= . Note our interest is to offer the work we've done as a helpful reference an= d do not have an expectation that any IETF work would be bound to the parti= cular solution we have. We do implement in our program a push model akin to the IPFIX and the obser= vation points (clients in our parlance) do deliver test results to collecto= rs that are run by our contractor. The significant difference from IPFIX is that our program is an active test= ing environment so we are fundamentally not doing passive observations. We= have collected a limited set of byte count data from some of the probes bu= t it is not implemented uniformly across the platform. I will discuss rfc3= 917 IPFIX with our contractor again. Happy to answer any other deep dive questions you might have as you are thi= nking about the draft and ongoing work. On Wed, Jan 2, 2013 at 7:53 AM, J=E9r=F4me Benoit > wrote: On Wed, 2 Jan 2013 03:23:09 +0000 Henning Schulzrinne > wrote: > I'm not suggesting RFC 5655 as an output file format, although there migh= t be elements in the RFC that are worth looking at. > > I'm more talking about something like > http://en.wikipedia.org/wiki/IP_Flow_Information_Export I will read it when time permit. > > I admit that I lost you at how Shannon got involved in packet formats. > > However, this is already straying into solution space, so probably premat= ure. I'm just trying to make things a bit more concrete, since I'm finding = abstract discussions less helpful and prone to talking past-each-other. I admit I shouldn't have post my last email (don't post when drunk :p). But before I find time to dig further, have the FCC already started an implementation of an measurement system ? Happy new year. -- J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From bs7652@att.com Thu Jan 3 15:18:37 2013 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 F081F21F8A67 for ; Thu, 3 Jan 2013 15:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toSIPyZgvEnH for ; Thu, 3 Jan 2013 15:18:36 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF0D21F8860 for ; Thu, 3 Jan 2013 15:18:35 -0800 (PST) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id bc116e05.2aab04459940.571476.00-563.1603968.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 03 Jan 2013 23:18:35 +0000 (UTC) X-MXL-Hash: 50e611cb43113fcf-f7d4ef32e06da7485bd107369fa220c7956a5a45 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 6c116e05.0.571443.00-357.1603873.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 03 Jan 2013 23:18:31 +0000 (UTC) X-MXL-Hash: 50e611c70995432b-7087079ef0e3f9e0234b55040b5cf2d10fb53b80 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r03NIUdf001505; Thu, 3 Jan 2013 18:18:30 -0500 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r03NHp9a001140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2013 18:17:58 -0500 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by sflint03.pst.cso.att.com (RSA Interceptor); Thu, 3 Jan 2013 18:16:50 -0500 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.02.0318.001; Thu, 3 Jan 2013 18:16:50 -0500 From: "STARK, BARBARA H" To: "Weil, Jason" , Shane Amante Thread-Topic: [lmap] Terminology: Basic Elements Thread-Index: Ac3pEzdJlJxhcRIFS4u5zBp3NncrKAARvySAACYMJQAABCRDwA== Date: Thu, 3 Jan 2013 23:16:49 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113021B189@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2468D430-0E01-440F-B762-BAC0887D339E@castlepoint.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.149.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=W4iPo2qk c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=KOS29LrdRgEA:10 a=mEtjrsW8C1sA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=WGBmYu2y3SsA:10 a=XKfbYx4oAAAA:8 a=RRoA82K-_u54eq] X-AnalysisOut: [VvgysA:9 a=CjuIK1q_8ugA:10 a=uI1Or78iWTcA:10 a=Hz7IrDYlS0c] X-AnalysisOut: [A:10 a=n_w8kLGJAp70gkw7:21 a=v2gy5wLlrDGxj9HH:21] Cc: "lmap@ietf.org" Subject: Re: [lmap] Terminology: Basic Elements X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 23:18:37 -0000 In-line. Barbara > Shane/Barbara, >=20 > This seems like a useful distinction for the two general active test > measurement cases and maps into the first two use cases from the LMAP > draft and the subsequent breakout LMAP Use Case draft. >=20 > Personally I like "User Initiated Active Measurement" or alternatively "U= ser > On Demand Active Measurement" for the user controlled test cases For the > other "Coordinated Active Measurement" (Could easily substitute > Coordinated with "Managed" or "Scheduled") I agree with having some sort of distinction, but I'm not sure if use= r-initiation is the right distinction. Some ISPs have web sites where the u= ser can log in and initiate on-demand tests against their line. Since the t= ests are actually done from the ISP, I would still call them coordinated an= d perhaps even managed. To me, the distinction is whether the End User is i= nitiating the testing using Measurement Agents that are wholly managed and = controlled by the End User. The End User-owned Measurement Agent might allo= w scheduled or on-demand testing. > Comment on Term: The CPN Device definition should be generic enough and > maybe even explicitly state that this could include a computer/laptop in > addition to a stand alone device that seems implied here like a router, > modem or dongle. It was my intention that "CPN Device" should include every single IP-= connected device inside the Customer Premises Network. We should certainly = make that explicit. I was also wanting to include mobile devices connected = to a mobile network (not in-home Wi-Fi) in the definition. =20 > General Comment: I also agree with Shane that we should focus on the > Coordinated LMAP use case in the current discussion as there does not > appear to be consensus on taking on the User Initiated testing in the IET= F at > this time. I definitely agree that we don't need to focus on Measurement Agents = that are managed/controlled by the End User. In addition, I agree that we d= on't need to describe how to provide End Users with access to controlled-by= -other-entity Measurement Agent functionality and data. It should certainly= be possible for such access to be provided, if desired. It just isn't very= hard to do, so not really something that needs focus. Such access doesn't = necessarily need to involve "initiation" of tests, and it could even provid= e results of passive Measurements.=20 =20 > Thanks, >=20 > Jason >=20 > On 1/2/13 4:29 PM, "Shane Amante" wrote: >=20 > >Barbara, > > > >Thanks also to you for reinitiating the conversation. I've been > >thinking more about LMAP and wanted to get your (and, others) thoughts > >wrt a refinement of your proposed definitions below. > > > >On Jan 2, 2013, at 11:01 AM, "STARK, BARBARA H" > wrote: > >> Beyond terminology for roles, I think there also needs to be some > >>terminology for commonly discussed elements. I'm proposing the > following: > >> > >> Measurement: >>define it; this term is *not* specific to "lmap" or large-scale > >>performance measurements> Measurement function: Code that > >>instantiates what is specifically and directly needed to "do" a > >>particular Measurement. > >> A Measurement can be a Passive Measurement or an Active > Measurement. > >>For Active Measurements, nothing is implied as to whether the > >>Measurement function initiates or simply responds to messages sent > >>from another Measurement function. > > > >I'm wondering if we should further refine active measurements. > >Specifically, I think there are probably two sub-cases: > >a) Automated (Not [Residential] End-User Initiated?) Active Measurement= : > >An example here would be periodic (automated) active, network > >performance measurements that are "running in the background" for a > >"long" period of time, e.g.: days, weeks, months?, until shut-off. > >b) Ad-hoc ([Residential] End-User initiated?) Active Measurement: An > >example here might be examples you've provided in the past where either > >an end-user, or some one acting on their behalf, initiates a one-time, > >ad-hoc ping, traceroute, "speedtest", ICSI NetAlyzer or other > >diagnostic program to "measure" some aspect(s) of performance. > > > >FWIW, perhaps such a classification (or, start of one) may help us > >focus LMAP work on case (a) above, where end-users won't typically be > >involved beyond, say, initially consenting to have such testing done > >using their device(s), e.g.: "opt-in". > > > >I'm sure we can come up with much more precise definitions than what > >I've provided above, but hopefully they are enough to grasp the concept > >of differentiating between the scope of measurements LMAP (or, really, > >participants on the mailing list) want to or should focus on. > > > >Thanks, > > > >-shane > > > > > > > >> Measurement Agent (MA): A function that contains one or more > >>Measurement functions. [I read a recommendation on this list not to > >>use "client" and server", since often the same, um, "thing" can act > >>both as initiator or responder, and the terms could be confusing in > >>certain contexts. "Agent" was suggested. I think this term will occur > >>often, so I gave it an abbreviation. In reading discussions on this > >>list, there seems to be a need to distinguish between distinct > >>Measurement functions and a collection of Measurement functions that > >>could be called a "Measurement Agent".] > >> > >> CPN Device: A physical device that exists inside the Customer > >>Premises Network. A CPN Device can have 0, 1, or more Measurement > Agents. > >>[Consistent with my thinking that roles should be considered according > >>to their relationship to the End User, I also think that we need to > >>have an idea of "inside the CPN" and "outside the CPN".] Network > >>Element: A physical "device" that exists external to the CPN. > >>E.g., network router, DSLAM, web server. A Network Element can have 0, > >>1, or more Measurement Agents. > >> User Interface: Allows a human being to access functionality or data. > >>It could be locally or remotely displayed (in physical relationship to > >>the functionality that generates the User Interface). For example, a > >>screen on a CPN Device could be used to display locally, and a browser > >>on a computer could be used to display remotely. [We haven't really > >>touched on this explicitly, but we seem to come repeatedly to the > >>question of how measurement data is made available to various people. > >>When it comes to providing people with access to measurement data, the > >>User Interface is an important concept.] > >> > >> Barbara From jerome.benoit@grenouille.com Fri Jan 4 16:04:52 2013 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 79CD721F8B4C for ; Fri, 4 Jan 2013 16:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cHpeyetudeV for ; Fri, 4 Jan 2013 16:04:52 -0800 (PST) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 966DE21F8B4A for ; Fri, 4 Jan 2013 16:04:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 469937F2A8; Sat, 5 Jan 2013 01:04:50 +0100 (CET) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfOFmChKSvux; Sat, 5 Jan 2013 01:04:42 +0100 (CET) Date: Sat, 5 Jan 2013 01:04:41 +0100 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: James Miller Message-ID: <20130105010441.0a0374d6@nemesis.grenouille.com> In-Reply-To: References: <20121227002531.652c715c@nemesis.grenouille.com> <20121231152516.14ff63a2@nemesis.grenouille.com> <20130101064524.14e414a9@nemesis.grenouille.com> <20130102135314.54659d83@nemesis.grenouille.com> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.13; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/RTh/Pd1tjt/Y15/nlTe86Zb"; protocol="application/pgp-signature" Cc: Henning Schulzrinne , "lmap@ietf.org" Subject: Re: [lmap] Comments on LMAP architecture X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jan 2013 00:04:52 -0000 --Sig_/RTh/Pd1tjt/Y15/nlTe86Zb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, 2 Jan 2013 09:14:13 -0500 James Miller wrote: > Jerome, >=20 > I'm not sure if you are asking if the FCC has done anything with IPFlow > Info Export or a measurement system in general. A measurement system for switched network in general.=20 > We have been running a > fixed program for two years with a network of 8000 some probes and are > preparing to release our third report in the coming weeks. We are also > currently on schedule to begin mobile performance testing on smartphones > early this year. >=20 > Note our interest is to offer the work we've done as a helpful reference > and do not have an expectation that any IETF work would be bound to the > particular solution we have. We plan to do the same (+ FOSS implementation). I think we should continue to discuss all the glory details that we have encountered. =20 >=20 > We do implement in our program a push model akin to the IPFIX and the > observation points (clients in our parlance) do deliver test results to > collectors that are run by our contractor. measurement agents push measurement results, and pull measurements definition. You can't do otherwise when you are behind a CPE. =20 >=20 > The significant difference from IPFIX is that our program is an active > testing environment so we are fundamentally not doing passive observation= s. > We have collected a limited set of byte count data from some of the prob= es > but it is not implemented uniformly across the platform. I will discuss > rfc3917 IPFIX with our contractor again. I very well understand that the proposed architecture mimic the IPFIX one. But again, IPFIX is thought for passive measurement.=20 To make this sentence clearer :=20 * when we push active measurement results to collectors, the results do not fit in the data model that IPFIX propose without cheating around the model, we have for example instant bandwidth, we have RTT between fixed hops that=20 might fellow very precise time series. Try to express a traceroute result in the IPFIX data model, it's possible but not the right solution to do so. But I'm OK to take part of the IPFIX data model and extend it to fit active measurement requirements. =20 * when we need to coordinate n measurement agents, there's no logical component that permit to trigger such a coherence in the measurement system. I have a measurement that need i agents behind the same edge router as a requirement and to achieve this kind of active measurement requirement, we have introduced a measurement agents states and capabilities tracker logical component. This component is also responsible for not overloading the network for intrusive measurement. I think this component is a must have in a large scale measurement system. It can be added to measurement controller functionalities. We do not have worked on the coherency and scheduling side so much so far but we plan to start to work on a syntax that will permit to express measurement dependencies and trigger coherence to the measurement system. We do not know yet where we will put this kind of intelligence, WIP. The active and passive measurement intelligence is on the measurement agents (datagram filtering, datagram forge, datagram injection, sampling results, etc.). I hope I've made myself clearer. =20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/RTh/Pd1tjt/Y15/nlTe86Zb Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlDnbhkACgkQ+qDLUJ/pFh0gkQCg1qhqVs+4d0jGQZo0wdsiX3d4 IRAAnj3J3FKPVR3ULFo/KlnrOfhyWna5 =iMn2 -----END PGP SIGNATURE----- --Sig_/RTh/Pd1tjt/Y15/nlTe86Zb-- From jerome.benoit@grenouille.com Fri Jan 4 16:40:14 2013 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 C98F421F8B19 for ; Fri, 4 Jan 2013 16:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arobeCNIQ1QN for ; Fri, 4 Jan 2013 16:40:14 -0800 (PST) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id CB39B21F8A71 for ; Fri, 4 Jan 2013 16:40:13 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 956887F071 for ; Sat, 5 Jan 2013 01:40:12 +0100 (CET) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kCnXCvqZKz2 for ; Sat, 5 Jan 2013 01:40:01 +0100 (CET) Date: Sat, 5 Jan 2013 01:40:00 +0100 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: lmap@ietf.org Message-ID: <20130105014000.536527d2@nemesis.grenouille.com> In-Reply-To: References: <20121227002531.652c715c@nemesis.grenouille.com> <20121231152516.14ff63a2@nemesis.grenouille.com> <20130101064524.14e414a9@nemesis.grenouille.com> <20130102135314.54659d83@nemesis.grenouille.com> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.13; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/9vkhwspnimzh3DhTEI9ve=1"; protocol="application/pgp-signature" Subject: Re: [lmap] Comments on LMAP architecture X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jan 2013 00:40:14 -0000 --Sig_/9vkhwspnimzh3DhTEI9ve=1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, 3 Jan 2013 22:55:10 +0000 Henning Schulzrinne wrote: > I agree that we don't want to be too specific as to the end points and th= roughput/delay measurements. But all measurements have a set of features in= common: > - they have one or more endpoints, with "two" being a common case (the ot= her end point may not be fixed, as for the DNS example you mention) They also can have dependencies, the most important one is connectivity for all active measurements. > - they are either a single event or repeat This two points go in the measurement definition : a way to express what the measurement will do, how and when. Some measurement inject packets fellowing time series, some open data streams, etc. You will need a deeply flexible syntax to cover all the needs.=20 The other point I really want to talk about, is the runtime bias : you express the measurement definition in whatever language you choose and your measurement need a very precise injection process. When the agent will execute the measurement, you'll have to check that all packets seen on the wire have :=20 - been injected;=20 - followed the wished time series to a tolerated unprecision.=20 otherwise, you'll have to return an error code to the controller with the result (keeping the biased results is important also). =20 > - they generate results (tuples) yep (tuples or not tuples)=20 >=20 > Just to make this more concrete again, imagine a simple request-response = protocol that has the following functionality: >=20 > "Hi, this is your controller speaking. Dear measurement agent, please sta= rt the X(5060) metric (=3D port blocking test for port 5060) and the Y(exam= ple.com) metric (=3D DNS caching test with parameter example.com), run it o= nce, and deposit the results at collector Z. Thank you." >=20 > "Hi controller. I can't do X, but I'm happy to do Y." >=20 > I suspect that this functionality can be expressed in XML, JSON or even A= SN.1. I wager that the latter will be the less likely outcome. > the exchange protocol and data format is a detail at the moment. The logical components matter most at the moment :) --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/9vkhwspnimzh3DhTEI9ve=1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlDndmAACgkQ+qDLUJ/pFh3+egCgyay1z97OcXxIfJGXilaTlbpl DfcAn1jzFdt9M0yQYy/jrE3hbXyzqPC5 =VW7O -----END PGP SIGNATURE----- --Sig_/9vkhwspnimzh3DhTEI9ve=1-- From mlinsner@cisco.com Fri Jan 18 12:47:58 2013 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 D51FC21F85AF for ; Fri, 18 Jan 2013 12:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ganvw8iYsUhp for ; Fri, 18 Jan 2013 12:47:58 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8464521F85AD for ; Fri, 18 Jan 2013 12:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47031; q=dns/txt; s=iport; t=1358542077; x=1359751677; h=date:subject:from:to:message-id:mime-version; bh=A0TQsTYGIuLA1sVR0PPoG8od5KjVXKGE43uWwJovgAI=; b=I3UaUmOyzXz6uo/tm3CwXuXDKLYJK4Gj1Bj7PTPfijr3nlEswPatnniy kZzF7LKzGLNKYmIHtCPExTFJfZB+KglDmy0LX9hC541BSH2blfnUN6uT2 WTumqtimaUbR5RsDVgxxZjC+HbqqaaaD2TroRS/LQeFzHP7MvaBKGLM8J Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAHa0+VCtJXG8/2dsb2JhbABEgkhwug11FnOCJS0QTxomAVYUiCycB6BXjhCDKQOIYY0rhWuKXoMT X-IronPort-AV: E=Sophos;i="4.84,494,1355097600"; d="scan'208,217";a="164650271" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jan 2013 20:47:49 +0000 Received: from [10.116.195.122] (rtp-mlinsner-8719.cisco.com [10.116.195.122]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0IKlltC021191 for ; Fri, 18 Jan 2013 20:47:48 GMT User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 18 Jan 2013 15:47:46 -0500 From: Marc Linsner To: Message-ID: Thread-Topic: Proposed LMAP Charter Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3441368868_1626588" Subject: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jan 2013 20:47:58 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3441368868_1626588 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Let's discuss possible charter language for the proposed LMAP work. At this point, IMO, we should propose a charter for the work that could either be added to an existing WG's charter, or standalone as a WG charter. That's an AD decision. A follow-on discussion to this would obviously be the output documents and milestones. Here is a strawman to start with - " Measuring broadband service on a large scale is important for network diagnostics by providers and users, as well for public policy. To conduct service measurements, user networks gather data, either on their own initiative or instructed by a measurement controller, and then upload the measurement results to a designated measurement server. There is a need to standardize a logical architecture and describe key requirements for protocols to connect the components. A large-scale measurement system needs to support residential and small-enterprise networks, using either wired or wireless networks. The architecture needs to consider the management of the active and passive measurements. The LMAP work will include describing various use cases considered to be Large Scale Performance Measurement systems, define the requirements of the management of these systems, and finally define the management communication architecture and protocols. This work will also include discussions about the privacy and security concerns and will address them within its documents. " Fire away! -Marc Linsner- --B_3441368868_1626588 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Let's discuss possible charter = language for the proposed LMAP work.  At this point, IMO, we should pro= pose a charter for the work that could either be added to an existing WG's c= harter, or standalone as a WG charter.  That's an AD decision.  A = follow-on discussion to this would obviously be the output documents and mil= estones.

"

Measuring broadband service on a large scale is important for network diagnostics by providers and users, as well for public policy.  To conduct service measurements, user networks gather data, either on their own initiative or instructed by a measurement controller, and then up= load the measurement results to a designated measurement server. There is a need= to standardize a logical architecture and describe key requirements for protoc= ols to connect the components.  A large-scale measurement system needs to support residential and small-enterprise networ= ks, using either wired or wireless networks. The architecture needs to consider= the management of the active and passive measurements.

 <= /p>

The LMAP work will include describing various use cases considered to be Large Scale Performance Measurement systems, define the requirements of the management = of these systems, and finally define the management communication architecture= and protocols.

 <= /p>

This work will also include discussions about the privacy and security concerns and will address them within its documents.

"


Fire away!


-Marc Linsner-

--B_3441368868_1626588-- From philip.eardley@bt.com Wed Jan 23 01:54:50 2013 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 98C0621F86FB for ; Wed, 23 Jan 2013 01:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6UzNFQNcyCm for ; Wed, 23 Jan 2013 01:54:45 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4B33F21F85CE for ; Wed, 23 Jan 2013 01:54:44 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 23 Jan 2013 09:54:42 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.111]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Wed, 23 Jan 2013 09:54:42 +0000 From: To: , , Date: Wed, 23 Jan 2013 09:54:39 +0000 Thread-Topic: Proposed LMAP Charter Thread-Index: Ac31vRvSd/2nZWr+TdaAM1GHJHEaMQDj5S+w Message-ID: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F340D4BF0B5EMV65UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jan 2013 09:54:50 -0000 --_000_9510D26531EF184D9017DF24659BB87F340D4BF0B5EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Marc. We're very interested in discussing a potential charter. One thing we think is worth trying to do is to simplify the proposed work a= s much as possible, as the potential scope is big. Of course this could be = done entirely as part of the WG's work, but doing this beforehand would ena= ble a more rapid start. Below is our attempt to suggest some simplifying as= sumptions. Each of the simplifying assumptions has some penalty, so it would be great= to hear whether people think they're reasonable, or over-restrict the use = case that you have in mind. If it's helpful we could write up the architect= ural assumptions in an I-D - co-authors very welcome. So a key question is whether the prospective WG should start with a phase o= f reaching consensus on architecture and choosing starting protocols, or wh= ether we can reach enough consensus before the next IETF to move straight t= o standards work. I'm not sure that we can decide this right now, as it dep= ends on how the discussion goes over the next month or so. There are some w= ork items below that might apply in the latter case. -- Measuring broadband service on a large scale is important for network diagn= ostics by providers and users, as well for public policy. {Comment: operat= ors may want measurement to help network planning and network mgt like faul= t identification; not sure whether this needs explicitly noting.} To condu= ct service measurements, Measurement Agents (MAs) on user networks gather d= ata, either on their own initiative or instructed by a Controller, and then= upload the measurement results to a designated Collector. Currently measur= ement platforms contain up to a few thousand MAs. However, the vision is th= at MAs could potentially be embedded in every home hub, cable modem, enterp= rise edge router, set top box, smartphone and so on. Standards will help th= is capability be more pervasive, manageable and directly comparable. RFCs from the IPPM WG define how to measure metrics - requests to define ne= w tests should be handled by IPPM. These tests effectively define the commu= nications between a MA and Test Server. {Comment: there are likely new metr= ics that need to be defined (eg latency under load) or tests under new cond= itions (eg current test for speed may not scale well to high line speeds).}= . In a few cases the IPPM definition may need to be extended to move resul= ts data from the Test Server to the MA for later reporting. The LMAP WG makes the following architectural assumptions - in order to mak= e rapid progress with an acceptable loss of generality:- * We assume that Measurement Agent, tests Controller and results Co= llector are all under control of same organisation (eg Samknows, FCC, BT). = Reason: Inter-organisation interactions (for example to share results) is b= etter handled by business-level negotiation than a control protocol. * We assume the MA initiates a measurement. Reasons: having the tes= t schedule on MA avoids it having to check frequently with the Controller; = it is easier if the MA is behind a NAT; and the MA knows whether the user i= s active and therefore whether to run test or delay it. * We assume measurement results are sent from MA, and not from test= server. Reason-1: It is easier to secure the MA to Collector communication= . One implication is that for an upload test measured by the test server, t= he result is reported back to the MA which reports it in turn. Reason-2: Te= st servers may be controlled by a third party ('load time for IETF home pag= e'). * We assume no negotiation is needed between Controller and MA. The= Controller already knows the characteristics of the MA, for instance via T= R069 for Broadband Forum devices. The Controller simply instructs (securely= ) the MA "Measure this"; the MA replies "OK /error". * Similarly we assume no negotiation is needed between the MA and C= ollector. The protocol simply delivers (securely) the measurement results f= rom the MA to the Collector, and returns an ack or error code. * We assume each MA is controlled by only one Controller. Reason: t= o avoid different Controllers giving the MA conflicting schedules. Note: a = measurement platform may have several Controllers, with each Controller con= trolling a subset of the MAs, for example one controlling wireline MAs and = one mobile MAs. * We assume the raw measurement results are reported; filtering /av= eraging of measuremnts by the MA is not in the initial scope, except as def= ined by IPPM as part of the metric definition. * We assume that uploading a new test capability to the MA is out o= f scope. This can be done as a firmware upgrade for home hub, or new app fo= r PC, etc. * We assume as out of scope a network parameter server (which store= s nominal values such as the contractual data rate). The functional role of= the Network Paraemeter Server may be fulfilled by existing OSS (such as ne= twork or home gateway management systems). Interfaces to the NPS are pre-me= asurement (used by the Controller to decide which tests to schedule) or pos= t-measurement (used to analyse the measurement data). * We assume data filtering is out of the initial scope. Filtering i= ncludes: removal of outlier measurements, archiving (curating) data for sci= entific research, and so on. There are certainly some aspects where best pr= actice would be useful but data filtering is not a first priority. * We assume that data privacy issues are out of scope although secu= rity is considered. The MA, Controller and Collector are all under control = of the same organisation. IPPM considers the implications of any passive me= asurement tests that it defines. The LMAP WG standardises the following items: 1. The data model that defines the test schedule, which includes: a. The IPPM metric to be tested and values for its parameters. {Questi= on: is the restriction to IPPM OK? Ie non-IPPM tests are out of scope} b. Test schedule: when the test should be done and how often repeated = ('once an hour at xx.03'). A test may also be a one-off, done immediately o= n demand. c. Output parameters: some IPPM metrics may define a choice of output= s d. Test Server: which server or servers should be used for the test e. Environmental conditions: such as 'no user traffic' which means a p= articular instance of the test is delayed or abandoned. f. (perhaps) Metadata: such as a mobile's location when the test sho= uld be made, the line's nominal rate etc. There may be privacy implications= for the scenario where the measurement plaform is not controlled by the op= erator; the initial scope will exclude this scenario. g. (perhaps) Metadat to report: for example, the MA may be able to mea= sure Layer 1 o 2 charcteristics such as DSL sync speed and interleaving; th= e actual test is out of scope. As for the previous bullet, there may be pri= vacy implications for the general scenario, which we exclude from the initi= al scope. h. (perhaps) Priority: the Controller decides which tests are done whe= n. However a test might get delayed until it overlaps with another schedule= d test - which should be done (or done first)? Or should it simply be aband= oned? 2. The data model that defines how an MA should report test results. = This may be combined with (1) above or specified as a separate reporting sc= hedule. This includes: a. Where to report results to (one or more Collectors) b. How often to report results for the different tests c. What to do when Collector is not available (fail-over, try again) 3. The data model that defines the report, which includes: a. The metric that was measured b. The time of the test c. Whether the test is scheduled, one-off triggered by the Controller= , or user-initiated d. The measurement result - usually several results are batched togeth= er; the result of a one-off test may be wanted immediately e. (perhaps) Metadata, such as the mobile's location f. Comment: it would make sense to use the same language as for 1, f= or instance XML, YANG... 4. The application level protocol for the (secure) delivery of the tes= t and reporting schedule (#1, #2) a. A simple instruction - response protocol, with error codes defined b. LMAP could specify how it operates over one existing protocol (REST= style HTTP(s), Netconf...) 5. The application level protocol for the (secure) delivery of the rep= ort (#3) a. Same comments as for #4 6. A document explaining the simplifying architectural assumptions in = more detail. This document could also define some terminology and explain t= he use cases. Looking forward to the discussion, Best wishes, Trevor and Phil From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Mar= c Linsner Sent: 18 January 2013 20:48 To: lmap@ietf.org Subject: [lmap] Proposed LMAP Charter Let's discuss possible charter language for the proposed LMAP work. At thi= s point, IMO, we should propose a charter for the work that could either be= added to an existing WG's charter, or standalone as a WG charter. That's = an AD decision. A follow-on discussion to this would obviously be the outp= ut documents and milestones. Here is a strawman to start with - " Measuring broadband service on a large scale is important for network diagn= ostics by providers and users, as well for public policy. To conduct servi= ce measurements, user networks gather data, either on their own initiative = or instructed by a measurement controller, and then upload the measurement = results to a designated measurement server. There is a need to standardize = a logical architecture and describe key requirements for protocols to conne= ct the components. A large-scale measurement system needs to support resid= ential and small-enterprise networks, using either wired or wireless networ= ks. The architecture needs to consider the management of the active and pas= sive measurements. The LMAP work will include describing various use cases considered to be La= rge Scale Performance Measurement systems, define the requirements of the m= anagement of these systems, and finally define the management communication= architecture and protocols. This work will also include discussions about the privacy and security conc= erns and will address them within its documents. " Fire away! -Marc Linsner- --_000_9510D26531EF184D9017DF24659BB87F340D4BF0B5EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Marc. We’re very interested in discussin= g a potential charter.

One thing we think is worth trying to do is to simplify the p= roposed work as much as possible, as the potential scope is big. Of course = this could be done entirely as part of the WG’s work, but doing this = beforehand would enable a more rapid start. Below is our attempt to suggest= some simplifying assumptions.

Each of the simplifying assumptions  has some penalt= y, so it would be great to hear whether people think they’re reasonab= le, or over-restrict the use case that you have in mind. If it’s help= ful we could write up the architectural assumptions in an I-D – co-au= thors very welcome.

So a key question is whether the prospective WG should start with a p= hase of reaching consensus on architecture and choosing starting protocols,= or whether we can reach enough consensus before the next IETF to move stra= ight to standards work. I’m not sure that we can decide this right no= w, as it depends on how the discussion goes over the next month or so. Ther= e are some work items below that might apply in the latter case.=

--

=

Measuring broadband service on a large scale is important for networ= k diagnostics by providers and users, as well for public policy.  {Com= ment: operators may want measurement to help network planning and network m= gt like fault identification; not sure whether this needs explicitly noting= .}  To conduct service measurements, Measurement Agents (MAs) on user = networks gather data, either on their own initiative or instructed by a Con= troller, and then upload the measurement results to a designated Collector.= Currently measurement platforms contain up to a few thousand MAs. However,= the vision is that MAs could potentially be embedded in every home hub, ca= ble modem, enterprise edge router, set top box, smartphone and so on. Stand= ards will help this capability be more pervasive, manageable and directly c= omparable.

RFCs from the IPPM WG define how to measure= metrics – requests to define new tests should be handled by IPPM. Th= ese tests effectively define the communications between a MA and Test Serve= r. {Comment: there are likely new metrics that need to be defined (eg laten= cy under load) or tests under new conditions (eg current test for speed may= not scale well to high line speeds).} . In a few cases the IPPM definition= may need to be extended to move results data from the Test Server to the M= A for later reporting.

The LMAP WG makes the followin= g architectural assumptions – in order to make rapid progress with an= acceptable loss of generality:-

·       = ;  We assume that Measurement Agent, te= sts Controller and results Collector are all under control of same organisa= tion (eg Samknows, FCC, BT). Reason: Inter-organisation interactions (for e= xample to share results) is better handled by business-level negotiation th= an a control protocol.

·         We assume the MA initiates a measurement. Reas= ons: having the test schedule on MA avoids it having to check frequently wi= th the Controller; it is easier if the MA is behind a NAT; and the MA knows= whether the user is active and therefore whether to run test or delay it.<= o:p>

·=          We assume measurement results are sent from MA, and not from test serv= er. Reason-1: It is easier to secure the MA to Collector communication. One= implication is that for an upload test measured by the test server, the re= sult is reported back to the MA which reports it in turn. Reason-2: Test se= rvers may be controlled by a third party (‘load time for IETF home pa= ge’).

·         = We assume no negotiation is needed between Controller and = MA. The Controller already knows the characteristics of the MA, for instanc= e via TR069 for Broadband Forum devices. The Controller simply instructs (s= ecurely) the MA “Measure this”; the MA replies “OK /error= ”.

<= span style=3D'mso-list:Ignore'>·         Similarly we assume no negotiation is needed between the MA a= nd Collector. The protocol simply delivers (securely) the measurement resul= ts from the MA to the Collector, and returns an ack or error code.

· &= nbsp;       We= assume each MA is controlled by only one Controller. Reason: to avoid diff= erent Controllers giving the MA conflicting schedules. Note: a measurement = platform may have several Controllers, with each Controller controlling a s= ubset of the MAs, for example one controlling wireline MAs and one mobile M= As.

·         <= ![endif]>We assume the raw measurement results are reported; filtering /ave= raging of measuremnts by the MA is not in the initial scope, except as defi= ned by IPPM as part of the metric definition.

&middo= t;    &nbs= p;    We assume that uploadin= g a new test capability to the MA is out of scope. This can be done as a fi= rmware upgrade for home hub, or new app for PC, etc.

= ·   &nbs= p;     We assume as out = of scope a network parameter server (which stores nominal values such as th= e contractual data rate). The functional role of the Network Paraemeter Ser= ver may be fulfilled by existing OSS (such as network or home gateway manag= ement systems). Interfaces to the NPS are pre-measurement (used by the Cont= roller to decide which tests to schedule) or post-measurement (used to anal= yse the measurement data).

·        = ; We assume data filtering is out of the ini= tial scope. Filtering includes: removal of outlier measurements, archiving = (curating) data for scientific research, and so on. There are certainly som= e aspects where best practice would be useful but data filtering is not a f= irst priority.

·         We assume that data privacy issues are out of scope alt= hough security is considered. The MA, Controller and Collector are all unde= r control of the same organisation. IPPM considers the implications of any = passive measurement tests that it defines.

The LMAP W= G standardises the following items:

1.   = ;   The data model that defines the test = schedule, which includes:

a. =      The IPPM metric to be test= ed and values for its parameters. {Question: is the restriction to IPPM OK?= Ie non-IPPM tests are out of scope}

<= span style=3D'mso-list:Ignore'>b.       = Output parameters: some IPPM metrics may define a c= hoice of outputs

d.   = ;   Test Server: which server or servers = should be used for the test

e. =      Environmental conditions: = such as ‘no user traffic’ which means a particular instance of = the test is delayed or abandoned.

f.=         (perhaps= ) Metadata: such as a mobile’s location when the test should be made,= the line’s nominal rate etc. There may be privacy implications for t= he scenario where the measurement plaform is not controlled by the operator= ; the initial scope will exclude this scenario.

g.      (perha= ps) Metadat to report: for example, the MA may be able to measure Layer 1 o= 2 charcteristics such as DSL sync speed and interleaving; the actual test = is out of scope. As for the previous bullet, there may be privacy implicati= ons for the general scenario, which we exclude from the initial scope.=

h.      = (perhaps) Priority: the Controller decides which tests are= done when. However a test might get delayed until it overlaps with another= scheduled test – which should be done (or done first)? Or should it = simply be abandoned?

2.       The data model that defines how an MA should rep= ort test results. This may be combined with (1) above or specified as a sep= arate reporting schedule. This includes:

= a.    &nbs= p;  Wh= ere to report results to (one or more Collectors)

b.   &= nbsp;  How often to report results for the different tests

<= p class=3DMsoListParagraph style=3D'mso-margin-top-alt:auto;mso-margin-bott= om-alt:auto;margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level2 lfo2'= >c.  &nbs= p;    What to do when Collector is not available (fail-over, try again)=

3.      = The data model that defines the report, which includes:

a.      The metric that was measured

b.      The time of= the test

c.    =    Whether the test is scheduled, one-off= triggered by the Controller, or user-initiated

d.      The me= asurement result – usually several results are batched together; the = result of a one-off test may be wanted immediately

e.      (= perhaps) Metadata, such as the mobile’s location

f.        Comment: it would make sense to use the same language as for 1= , for instance XML, YANG…

4.   &nb= sp;  The application level protocol for the (s= ecure) delivery of the test and reporting schedule (#1, #2)

<= p class=3DMsoListParagraph style=3D'mso-margin-top-alt:auto;mso-margin-bott= om-alt:auto;margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level2 lfo2'= >a.      A simple instruction – response protocol, with error codes defi= ned

b.=      = LMAP could specify how it operates over one existi= ng protocol (REST style HTTP(s), Netconf…)

5.&nbs= p;     The application level pr= otocol for the (secure) delivery of the report (#3)

a.      S= ame comments as for #4

6.=      = A document explaining the simplifying architectura= l assumptions in more detail. This document could also define some terminol= ogy and explain the use cases.

Looking forward to the = discussion,

Best wishes,

Trevor and Phil

From: lmap-boun= ces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Marc Linsne= r
Sent: 18 January 2013 20:48
To: lmap@ietf.org
S= ubject: [lmap] Proposed LMAP Charter

<= p class=3DMsoNormal> 

Let's discuss possible charter languag= e for the proposed LMAP work.  At this point, IMO, we should propose a= charter for the work that could either be added to an existing WG's charte= r, or standalone as a WG charter.  That's an AD decision.  A foll= ow-on discussion to this would obviously be the output documents and milest= ones.

 

Here is a strawm= an to start with - 

 

"

Measuring broadband service on a large scale is important = for network diagnostics by providers and users, as well for public policy.&= nbsp; To conduct service measurements, user networks gather data, either on= their own initiative or instructed by a measurement controller, and then u= pload the measurement results to a designated measurement server. There is = a need to standardize a logical architecture and describe key requirements = for protocols to connect the components.  A large-scale measurement sy= stem needs to support residential and small-enterprise networks, using eith= er wired or wireless networks. The architecture needs to consider the manag= ement of the active and passive measurements.

 

The LMAP work will include describing= various use cases considered to be Large Scale Performance Measurement sys= tems, define the requirements of the management of these systems, and final= ly define the management communication architecture and protocols.

 <= /span>

This work will a= lso include discussions about the privacy and security concerns and will ad= dress them within its documents.

"

 

<= span style=3D'color:black'>Fire away!

&n= bsp;

-Marc= Linsner-

= --_000_9510D26531EF184D9017DF24659BB87F340D4BF0B5EMV65UKRDdoma_-- From ford@isoc.org Wed Jan 23 04:07:41 2013 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 6EE9721F865B for ; Wed, 23 Jan 2013 04:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMWvLVoEbHME for ; Wed, 23 Jan 2013 04:07:41 -0800 (PST) Received: from smtp130.iad.emailsrvr.com (smtp130.iad.emailsrvr.com [207.97.245.130]) by ietfa.amsl.com (Postfix) with ESMTP id 0245F21F8654 for ; Wed, 23 Jan 2013 04:07:41 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp23.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 79852349DDD; Wed, 23 Jan 2013 07:07:40 -0500 (EST) X-Virus-Scanned: OK Received: by smtp23.relay.iad1a.emailsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id AD6C5349EB5; Wed, 23 Jan 2013 07:07:39 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Matthew Ford In-Reply-To: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> Date: Wed, 23 Jan 2013 12:07:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <49B53DD1-B801-4412-B503-0825F646816F@isoc.org> References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> To: philip.eardley@bt.com X-Mailer: Apple Mail (2.1499) Cc: mlinsner@cisco.com, trevor.burbridge@bt.com, lmap@ietf.org Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jan 2013 12:07:41 -0000 Phil, Nice post, which I think I completely agree with. On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: > =B7 We assume that Measurement Agent, tests Controller and = results Collector are all under control of same organisation (eg = Samknows, FCC, BT). Reason: Inter-organisation interactions (for example = to share results) is better handled by business-level negotiation than a = control protocol. I think we also need an assumption that nothing will preclude having = collectors, for example, be under control of third-parties. I think it = is worth explicitly stating that, unless there is disagreement on this = point? Mat From trammell@tik.ee.ethz.ch Wed Jan 23 04:16:02 2013 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 6624821F878F for ; Wed, 23 Jan 2013 04:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g0hISUSBIGp for ; Wed, 23 Jan 2013 04:16:02 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id CCE1C21F8742 for ; Wed, 23 Jan 2013 04:16:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3CD0FD930C; Wed, 23 Jan 2013 13:16:00 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2wkfjiQ9n4G3; Wed, 23 Jan 2013 13:15:53 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 280F2D930A; Wed, 23 Jan 2013 13:15:53 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <49B53DD1-B801-4412-B503-0825F646816F@isoc.org> Date: Wed, 23 Jan 2013 13:15:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <49B53DD1-B801-4412-B503-0825F646816F@isoc.org> To: Matthew Ford X-Mailer: Apple Mail (2.1283) Cc: philip.eardley@bt.com, trevor.burbridge@bt.com, mlinsner@cisco.com, lmap@ietf.org Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jan 2013 12:16:02 -0000 hi Mat, Phil, all, I agree as well, though other comments on finer points may follow. One = inline below. On 23 Jan 2013, at 13:07 , Matthew Ford wrote: > Phil, >=20 > Nice post, which I think I completely agree with. >=20 > On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: >=20 >> =B7 We assume that Measurement Agent, tests Controller and = results Collector are all under control of same organisation (eg = Samknows, FCC, BT). Reason: Inter-organisation interactions (for example = to share results) is better handled by business-level negotiation than a = control protocol. >=20 > I think we also need an assumption that nothing will preclude having = collectors, for example, be under control of third-parties. I think it = is worth explicitly stating that, unless there is disagreement on this = point? +1 on this point. I'd suggest that we leave the component = ownership/control issues completely aside; i.e., we don't necessarily = want to preclude organization(s) from agreeing to use a measurement = infrastructure in place (which uses this control protocol) for sharing = of intermediate or final measurement results (in support of an existing = business-level agreement).=20 What's _really_ important about this assumption is that it makes the = problems of inter-domain measurement control and exchange explicitly out = of scope for the charter, and simplifies issues of trust among the = components. I think it should probably be explicitly phrased as an issue = of scope rather than an assumption about deployment. Cheers, Brian From ken.ko@adtran.com Wed Jan 23 05:30:57 2013 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 DFF5B21F85DC for ; Wed, 23 Jan 2013 05:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gulFDlEYScbt for ; Wed, 23 Jan 2013 05:30:57 -0800 (PST) Received: from p02c11o144.mxlogic.net (p02c11o144.mxlogic.net [208.65.144.77]) by ietfa.amsl.com (Postfix) with ESMTP id D7ACC21F85D7 for ; Wed, 23 Jan 2013 05:30:56 -0800 (PST) Received: from unknown [76.164.174.83] (EHLO p02c11o144.mxlogic.net) by p02c11o144.mxlogic.net(mxl_mta-6.16.0-0) with ESMTP id 016eff05.53c42940.92981.00-573.161522.p02c11o144.mxlogic.net (envelope-from ); Wed, 23 Jan 2013 06:30:56 -0700 (MST) X-MXL-Hash: 50ffe6107252dee6-7048437200e83bf6c6cdde883a06082a315f6a65 Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c11o144.mxlogic.net(mxl_mta-6.16.0-0) over TLS secured channel with ESMTP id c06eff05.0.92958.00-399.161465.p02c11o144.mxlogic.net (envelope-from ); Wed, 23 Jan 2013 06:30:54 -0700 (MST) X-MXL-Hash: 50ffe60e58082538-a3108d5214d36c38e07db4e9e0c9ac48dedf0318 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::d50f:ceda:4e38:ebf0%14]) with mapi id 14.01.0438.000; Wed, 23 Jan 2013 07:30:51 -0600 From: KEN KO To: "philip.eardley@bt.com" , "mlinsner@cisco.com" , "lmap@ietf.org" , "trevor.burbridge@bt.com" Thread-Topic: Proposed LMAP Charter Thread-Index: AQHN9b0b6JLI8AqAN02ugsRwPcUpfZhXGGyA///Qg+A= Date: Wed, 23 Jan 2013 13:30:51 +0000 Message-ID: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.196] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB7045CAAD8exmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=VcVAyiV9 c=1 sm=1 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a] X-AnalysisOut: [=aQomRHkrLCgA:10 a=qZHQZMT3apYA:10 a=BLceEmwcHowA:10 a=xqW] X-AnalysisOut: [C_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YSXpvylFH_cA:10 a=XRL4tow7] X-AnalysisOut: [Frr9-goef5oA:9 a=CjuIK1q_8ugA:10 a=yMhMjlubAAAA:8 a=SSmOFE] X-AnalysisOut: [ACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0] X-AnalysisOut: [A:10 a=frz4AuCg-hUA:10 a=q9TGD1mseraJoGQc:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jan 2013 13:30:58 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB7045CAAD8exmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, Trevor and Marc, Great, detailed proposal. A lot of good information here. One additional item to consider is the association of measurement results w= ith service attributes such as uplink and downlink speed. In recent trials,= these attributes have provided a useful baseline to which results are comp= ared, but the process of collecting and validating the attributes has been = largely manual and is not scalable. Associating applicable service attribut= es with the data model sent from the MA to the Collector - either by refere= nce or by directly including them as metadata - would eliminate any need fo= r a manual process and facilitate synchronization of attributes (which occa= sionally change due to upgrades and service redefinitions) and measurement = results. Thanks, Ken Ko --_000_D14B7E40AEBFD54EA3AD964902DD7CB7045CAAD8exmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phil,= Trevor and Marc,

=  

Great= , detailed proposal. A lot of good information here.

=  

One a= dditional item to consider is the association of measurement results with s= ervice attributes such as uplink and downlink speed. In recent trials, thes= e attributes have provided a useful baseline to which results are compared, but the process of collecting and = validating the attributes has been largely manual and is not scalable. Asso= ciating applicable service attributes with the data model sent from the MA = to the Collector – either by reference or by directly including them as metadata – would eliminate any need= for a manual process and facilitate synchronization of attributes (which o= ccasionally change due to upgrades and service redefinitions) and measureme= nt results.

=

Thank= s,

Ken K= o

=  

--_000_D14B7E40AEBFD54EA3AD964902DD7CB7045CAAD8exmb1corpadtran_-- From trevor.burbridge@bt.com Wed Jan 23 08:49:23 2013 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 9273221F84D9 for ; Wed, 23 Jan 2013 08:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlNu4xoy3slT for ; Wed, 23 Jan 2013 08:49:23 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF2221F90C9 for ; Wed, 23 Jan 2013 08:49:20 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 23 Jan 2013 16:49:19 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.116]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Wed, 23 Jan 2013 16:49:19 +0000 From: To: , Date: Wed, 23 Jan 2013 16:48:56 +0000 Thread-Topic: [lmap] Proposed LMAP Charter Thread-Index: Ac35Yj/J1I2XlBEYSDCKqojhrDr2/AAJwrug Message-ID: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <49B53DD1-B801-4412-B503-0825F646816F@isoc.org> In-Reply-To: <49B53DD1-B801-4412-B503-0825F646816F@isoc.org> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mlinsner@cisco.com, lmap@ietf.org Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jan 2013 16:49:23 -0000 Our position is that nothing should preclude 3rd parties operating separate= components of the measurement architecture. Of course data protection woul= d have to be considered/observed but we will not need anything explicit in = the technical work of LMAP to do so. What we want to avoid explicitly is two or more controllers connecting to a= single Measurement Agent and having to manage such conflicts. There might,= however, be two or more controllers for disjoint subsets of measurement ag= ents (e.g. one for mobile devices and one for home gateways). There of cour= se will be multiple test servers (to test multiple network paths) and could= also be multiple collectors (where a MA replicates or partitions its resul= ts). Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000=20 >-----Original Message----- >From: Matthew Ford [mailto:ford@isoc.org] >Sent: 23 January 2013 12:08 >To: Eardley,PL,Philip,TUB8 R >Cc: mlinsner@cisco.com; lmap@ietf.org; Burbridge,T,Trevor,TUB8 R >Subject: Re: [lmap] Proposed LMAP Charter > >Phil, > >Nice post, which I think I completely agree with. > >On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: > >> * We assume that Measurement Agent, tests Controller and results >Collector are all under control of same organisation (eg Samknows, FCC, BT= ). >Reason: Inter-organisation interactions (for example to share results) is >better handled by business-level negotiation than a control protocol. > >I think we also need an assumption that nothing will preclude having >collectors, for example, be under control of third-parties. I think it is = worth >explicitly stating that, unless there is disagreement on this point? > >Mat > From trevor.burbridge@bt.com Wed Jan 23 08:53:51 2013 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 6392E21F8686 for ; Wed, 23 Jan 2013 08:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aFpbVPsYePj for ; Wed, 23 Jan 2013 08:53:49 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 60B3521F854F for ; Wed, 23 Jan 2013 08:53:49 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 23 Jan 2013 16:53:48 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.116]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Wed, 23 Jan 2013 16:53:47 +0000 From: To: , , , Date: Wed, 23 Jan 2013 16:53:02 +0000 Thread-Topic: Proposed LMAP Charter Thread-Index: AQHN9b0b6JLI8AqAN02ugsRwPcUpfZhXGGyA///Qg+CAAD7v0A== Message-ID: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB7294A222D5CEMV64UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jan 2013 16:53:51 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB7294A222D5CEMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes - good point. We certainly do need to consider how best to enhance the = measurement data with line/customer/CPE data. One question would be if we n= eed to define this data within LMAP or simply define a mechanism for retrie= ving/carrying it (e.g. between the MA and Collector) whatever it may be. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: KEN KO [mailto:KEN.KO@adtran.com] Sent: 23 January 2013 13:31 To: Eardley,PL,Philip,TUB8 R; mlinsner@cisco.com; lmap@ietf.org; Burbridge,= T,Trevor,TUB8 R Subject: RE: Proposed LMAP Charter Phil, Trevor and Marc, Great, detailed proposal. A lot of good information here. One additional item to consider is the association of measurement results w= ith service attributes such as uplink and downlink speed. In recent trials,= these attributes have provided a useful baseline to which results are comp= ared, but the process of collecting and validating the attributes has been = largely manual and is not scalable. Associating applicable service attribut= es with the data model sent from the MA to the Collector - either by refere= nce or by directly including them as metadata - would eliminate any need fo= r a manual process and facilitate synchronization of attributes (which occa= sionally change due to upgrades and service redefinitions) and measurement = results. Thanks, Ken Ko --_000_ED51D9282D1D3942B9438CA8F3372EB7294A222D5CEMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes – good point. We certainly do need= to consider how best to enhance the measurement data with line/customer/CP= E data. One question would be if we need to define this data within LMAP or= simply define a mechanism for retrieving/carrying it (e.g. between the MA = and Collector) whatever it may be.

 

Trevo= r.

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F49= 7D'>Trevor Burbridge
Network Infrastructure & Innovation | BT Innova= te & Design
Tel: 01473 645115
Fax: 01473 640929

This email conta= ins BT information, which may be privileged or confidential. It's meant onl= y for the individual(s) or entity named above. If you're not the intended r= ecipient, note that disclosing, copying, distributing or using this informa= tion is prohibited. If you've received this email in error, please let me k= now immediately on the email address above. Thank you.
We monitor our em= ail system, and may record your emails.
British Telecommunications plc
Registe= red office: 81 Newgate Street London EC1A 7AJ
Registered in England no: = 1800000

 

From: KEN KO [mailto:KEN.KO@adtran.com]
S= ent: 23 January 2013 13:31
To: Eardley,PL,Philip,TUB8 R; mlin= sner@cisco.com; lmap@ietf.org; Burbridge,T,Trevor,TUB8 R
Subject:= RE: Proposed LMAP Charter

 

Phil, Trevor and Marc,

 

Great, detailed proposal. A lot o= f good information here.

 

One additional item to consider is the association of measuremen= t results with service attributes such as uplink and downlink speed. In rec= ent trials, these attributes have provided a useful baseline to which resul= ts are compared, but the process of collecting and validating the attribute= s has been largely manual and is not scalable. Associating applicable servi= ce attributes with the data model sent from the MA to the Collector –= either by reference or by directly including them as metadata – woul= d eliminate any need for a manual process and facilitate synchronization of= attributes (which occasionally change due to upgrades and service redefini= tions) and measurement results.

<= span lang=3DEN-US style=3D'font-size:11.0pt;color:#1F497D'> 

Thanks,

Ken Ko

 

= --_000_ED51D9282D1D3942B9438CA8F3372EB7294A222D5CEMV64UKRDdoma_-- From julm+lmap@autogeree.net Thu Jan 24 02:26:38 2013 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 8F79B21F8949 for ; Thu, 24 Jan 2013 02:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obS7JrHSPzZE for ; Thu, 24 Jan 2013 02:26:37 -0800 (PST) Received: from chomsky.autogeree.net (chomsky.autogeree.net [91.216.110.36]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5A521F8942 for ; Thu, 24 Jan 2013 02:26:37 -0800 (PST) Received: by localhost.local (localhost.local, from userid 1000) id 9328721D28; Thu, 24 Jan 2013 11:26:26 +0100 (CET) Date: Thu, 24 Jan 2013 11:26:26 +0100 From: Julien Moutinho To: lmap@ietf.org Message-ID: <20130124102626.GA7215@localhost> References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> X-Operating-System: 3.5.0-julm x86_64 GNU/Linux OpenPGP: preference=signencrypt; id=F2E027182397AC0775714F2AD15AF7F467E8299B; url="http://autogeree.net/~julm/pub.gpg" User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 10:26:38 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi everyone, Interesting post Trevor and Phil! I've made below a few humble comments derived from my (still young) experie= nce in developping the Grenouille system. Le mer. 23 janv. 2013 =C3=A0 09:54:39 +0000, philip.eardley@bt.com a =C3=A9= crit=C2=A0: > The LMAP WG makes the following architectural assumptions - in order to > make rapid progress with an acceptable loss of generality:- >=20 > * We assume that Measurement Agent, tests Controller and > results Collector are all under control of same organisation (eg > Samknows, FCC, BT). Reason: Inter-organisation interactions (for > example to share results) is better handled by business-level > negotiation than a control protocol. agreed for an initial scope. though, what is the precise meaning of "control" here? because shouldn't the MA be "under control" of anyone but the owner of the system it runs on? which for instance would mean free/open source software, and being able to precisely see and filter what is sent to whom and when. > * We assume the MA initiates a measurement. Reasons: having the > test schedule on MA avoids it having to check frequently with the > Controller; it is easier if the MA is behind a NAT; and the MA knows > whether the user is active and therefore whether to run test or delay it. agreed. > * We assume measurement results are sent from MA, and not from > test server. Reason-1: It is easier to secure the MA to Collector > communication. One implication is that for an upload test measured by > the test server, the result is reported back to the MA which reports it > in turn. Reason-2: Test servers may be controlled by a third party > ('load time for IETF home page'). agreed. and we should also keep in mind that a Test server (wouldn't be Landmark a better name?) could run on the same system than the MA so as to have MA to MA measurements. > * We assume no negotiation is needed between Controller and MA. > The Controller already knows the characteristics of the MA, for > instance via TR069 for Broadband Forum devices. The Controller simply > instructs (securely) the MA "Measure this"; the MA replies "OK /error". agreed for an initial scope, but I think there should eventually be a more complex MA<>Controller negotiation, for instance to synchronise several MA, a Controller could tell each MA to recontact it in a given amount of time, until it has accumulated a given number of MA to trigger the probing. also, some characteristics may be volatile, like the geolocation, and may be used by the Controller to filter its MA, therefore I think a mechanism to keep track of the MA's characteristics should be part of this negotiation; be it via TR-069 if it is flexible and supported enough or else. moreover as it is a botnet which is designed here, preventing usurpation is= critical, thus maybe a level of mutual authentification should have to be inserted he= re, for instance I think that using an horizontal public key infrastructure like OpenPGP's should be considered: each MA/Controller/Collector having its own private key (self-generated with possibly a designed revoker= ). > * Similarly we assume no negotiation is needed between the MA > and Collector. The protocol simply delivers (securely) the measurement > results from the MA to the Collector, and returns an ack or error code. agreed for an initial scope. though mutual authentification should eventually be done here too. > * We assume each MA is controlled by only one Controller. > Reason: to avoid different Controllers giving the MA conflicting > schedules. Note: a measurement platform may have several Controllers, > with each Controller controlling a subset of the MAs, for example one > controlling wireline MAs and one mobile MAs. agreed for an initial scope. though I do not really see how this would be enforced at this point; at least I think that each instance of a MA should choose an initial Contro= ller, which in turn may suggest the MA to contact an other Controller. > * We assume the raw measurement results are reported; filtering > /averaging of measuremnts by the MA is not in the initial scope, except > as defined by IPPM as part of the metric definition. what is the need for this assumption? I think the MA should just be able to perform computation when the concept of the probing allows it, for instance for certain kinds of local anomalies detection having the MA doing some computation is cheap on the MA and saves a lot of computer resources when data mining the Collector. > * We assume that uploading a new test capability to the MA is > out of scope. This can be done as a firmware upgrade for home hub, or > new app for PC, etc. agreed for an initial scope. and not exactly that but related: I've been suggested that some kind of sandboxing of a minimal language (=C3=A0 la google App En= gine) should be supported so that the casual user can develop and deploy its own = probe while keeping it safe (with several levels of safety) for the MA running the probe; having such possibility may also further the adoption/deployment of the MA. > * We assume as out of scope a network parameter server (which > stores nominal values such as the contractual data rate). The > functional role of the Network Paraemeter Server may be fulfilled by > existing OSS (such as network or home gateway management systems). > Interfaces to the NPS are pre-measurement (used by the Controller to > decide which tests to schedule) or post-measurement (used to analyse > the measurement data). agreed for an initial scope. > * We assume data filtering is out of the initial scope. > Filtering includes: removal of outlier measurements, archiving > (curating) data for scientific research, and so on. There are certainly > some aspects where best practice would be useful but data filtering is > not a first priority. agreed for an initial scope. though best practices for the archiving part would be very welcome. > * We assume that data privacy issues are out of scope although > security is considered. The MA, Controller and Collector are all under > control of the same organisation. IPPM considers the implications of > any passive measurement tests that it defines. what is the need for this frightening assumption? does it just means that privacy concerns must be specified within IPPM RFC? > The LMAP WG standardises the following items: >=20 > 1. The data model that defines the test schedule, which includes: > a. The IPPM metric to be tested and values for its parameters. > {Question: is the restriction to IPPM OK? Ie non-IPPM tests are out of = scope} what is the need for this assumption? I think metrics should be easily extensible according to a common schema (for instance specifying a hierarchical namespace for probes gathering them by ///..). > b. Test schedule: when the test should be done and how often > repeated ('once an hour at xx.03'). A test may also be a one-off, done > immediately on demand. I think that a variety of common temporal series should be considered (like, raw-list, periodic, exponential-based, gamma-based, uniform-random-b= ased, ..); for instance some tomography probes require these kind of distributions. an maybe that these series could be reused to vary fields of network protoc= ols, for instance some probes discovering the network topology accross load-bala= ncers use them. > c. Output parameters: some IPPM metrics may define a choice of ou= tputs > d. Test Server: which server or servers should be used for the test > e. Environmental conditions: such as 'no user traffic' which means > a particular instance of the test is delayed or abandoned. other environmental conditions could include: - cheap network connection available (not 3G at per consumption rate for i= nstance) - stable power supply available > f. (perhaps) Metadata: such as a mobile's location when the test > should be made, the line's nominal rate etc. There may be privacy > implications for the scenario where the measurement plaform is not > controlled by the operator; the initial scope will exclude this > scenario. > g. (perhaps) Metadata to report: for example, the MA may be able to > measure Layer 1 o 2 charcteristics such as DSL sync speed and > interleaving; the actual test is out of scope. As for the previous > bullet, there may be privacy implications for the general scenario, > which we exclude from the initial scope. > h. (perhaps) Priority: the Controller decides which tests are done > when. However a test might get delayed until it overlaps with another > scheduled test - which should be done (or done first)? Or should it > simply be abandoned? moreover I think versioning the test models (I called them configurations) and report models (I called them samples) should also be envisaged. > 2. The data model that defines how an MA should report test > results. This may be combined with (1) above or specified as a separate > reporting schedule. This includes: >=20 > a. Where to report results to (one or more Collectors) > b. How often to report results for the different tests > c. What to do when Collector is not available (fail-over, try aga= in) I think there should be a simple local queue, filesystem-based for instance, or possibly a local mail server could be used to post results (just an idea, or at least a source of inspiration), moreover environmental conditions could also intervene here to delay the re= port. > 3. The data model that defines the report, which includes: > a. The metric that was measured > b. The time of the test > c. Whether the test is scheduled, one-off triggered by the Contro= ller, or user-initiated > d. The measurement result - usually several results are batched > together; the result of a one-off test may be wanted immediately > e. (perhaps) Metadata, such as the mobile's location > f. Comment: it would make sense to use the same language as for = 1, for instance XML, YANG... I would recommend to use a language designed to be a data interchange forma= t, which for instance means more JSON than XML which is rather a document stan= dard. the few MA I happen to know use JSON. > 4. The application level protocol for the (secure) delivery of the t= est and reporting schedule (#1, #2) > a. A simple instruction - response protocol, with error codes defi= ned > b. LMAP could specify how it operates over one existing protocol (= REST style HTTP(s), Netconf...) yes, I think that ReST HTTP should be used, which AFAIK would boil down to specifying: - URI schemes for identifying resources; - representations of the states of these resources, transferred between components. > 5. The application level protocol for the (secure) delivery of the r= eport (#3) > a. Same comments as for #4 > 6. A document explaining the simplifying architectural assumptions > in more detail. This document could also define some terminology and > explain the use cases. looking forward to the discussion, julm --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQJNBAEBCgA3BQJRAQxOMBSAAAAAABUAEnBrYS1hZGRyZXNzQGdudXBnLm9yZ2p1 bG1AYXV0b2dlcmVlLm5ldAAKCRBeJxnPcP6KnhlmEACIMd71hmO6KiOPK5++w89+ z97pZ7sulw/2iJAdHc24AJaEnQ1vtwAYv4qJ+zGue5hFGxIF+4BEfp8bRmJpxQvb Z4up/Q4+kdtOps8xnZ/rAjFL2dyc42m/JI6CAZ8UvfrBMI3obAQIzQOZTvlDGIBx jH206DpaONdhYevgRTnbEml3IOVgYEmEaiezWek1ZKGeN+DNs+B1OkHeUHFB9fI5 IPd6DNnbSnmW6sPrnCpUF5gTpZSKyiFXC8QbBjGdyEOffR69T4tXhKaQ92LHw9mb JlCezj5k8oCiB9m1Pf7SEMZNGYZH4VTKyc64wqmSEtNjdZ/hjD4CwW855ypNc9ZE rCrjh4GRtQ90dN2VmYwva/vQEu2jPSYj8aflcSIshPNqDoeRxhxbqiisqqPpPIms 7NM5c91reLoaZs3yxpFas6tD4oQgjYu1l7Q83Rz/7yv6czahIJ7Fb3RWIH6e3wPW sxgvrHgHMZLL4TqIWQyVujt5kY8FnMWiNy+ssxfXQmxTPf2jt/SJb22/OynVTf8b 926JhVSbBGhXkGe35cNFNK/5G9aMN5PnalexZiXly3YpInjbuxO0qHFXu00+4U1a bogpM/DN+qAC5BN3i+0NozZMW9aUcjsJvnesSFP7lQmbSmQALeEb1pOuGTZg408F fcCS2UkyJy3AYegLC61BTw== =lZBZ -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From aservin@lacnic.net Thu Jan 24 02:50:40 2013 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 EDDF421F8497 for ; Thu, 24 Jan 2013 02:50:39 -0800 (PST) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwdNaezMpRgt for ; Thu, 24 Jan 2013 02:50:39 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0E521F8449 for ; Thu, 24 Jan 2013 02:50:39 -0800 (PST) Received: from [IPv6:2800:af:ba30:d049:21e:52ff:fe76:b63] (unknown [IPv6:2800:af:ba30:d049:21e:52ff:fe76:b63]) by mail.lacnic.net.uy (Postfix) with ESMTP id 580F730844E; Thu, 24 Jan 2013 08:50:28 -0200 (UYST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Arturo Servin In-Reply-To: Date: Thu, 24 Jan 2013 08:50:31 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <49B53DD1-B801-4412-B503-0825F646816F@isoc.org> To: lmap@ietf.org X-Mailer: Apple Mail (2.1085) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: philip.eardley@bt.com, Brian Trammell , trevor.burbridge@bt.com, Matthew Ford , mlinsner@cisco.com Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 10:50:40 -0000 Hi al, I was going to ask something similar. For example, we have a project where we have done some = measurements but those are confined to a specific region of the world. = It would be interesting to share that data among other organizations = doing the same but today we can't because there is not a standard (that = I asume we are intent to produce) and because privacy implications (that = I am not sure that we are addressing in the chapter). So, is a WG goal to address the problem of sharing and anomyzing = data (or address any privacy concern)? Regards, as On 23 Jan 2013, at 10:15, Brian Trammell wrote: > hi Mat, Phil, all, >=20 > I agree as well, though other comments on finer points may follow. One = inline below. >=20 > On 23 Jan 2013, at 13:07 , Matthew Ford wrote: >=20 >> Phil, >>=20 >> Nice post, which I think I completely agree with. >>=20 >> On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: >>=20 >>> =B7 We assume that Measurement Agent, tests Controller and = results Collector are all under control of same organisation (eg = Samknows, FCC, BT). Reason: Inter-organisation interactions (for example = to share results) is better handled by business-level negotiation than a = control protocol. >>=20 >> I think we also need an assumption that nothing will preclude having = collectors, for example, be under control of third-parties. I think it = is worth explicitly stating that, unless there is disagreement on this = point? >=20 > +1 on this point. I'd suggest that we leave the component = ownership/control issues completely aside; i.e., we don't necessarily = want to preclude organization(s) from agreeing to use a measurement = infrastructure in place (which uses this control protocol) for sharing = of intermediate or final measurement results (in support of an existing = business-level agreement).=20 >=20 > What's _really_ important about this assumption is that it makes the = problems of inter-domain measurement control and exchange explicitly out = of scope for the charter, and simplifies issues of trust among the = components. I think it should probably be explicitly phrased as an issue = of scope rather than an assumption about deployment. >=20 > Cheers, >=20 > Brian >=20 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From trevor.burbridge@bt.com Thu Jan 24 03:45:50 2013 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 9BECA21F8953 for ; Thu, 24 Jan 2013 03:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8L+cVjVsTaf for ; Thu, 24 Jan 2013 03:45:49 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id A4F7521F872D for ; Thu, 24 Jan 2013 03:45:49 -0800 (PST) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 24 Jan 2013 11:45:41 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.116]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Thu, 24 Jan 2013 11:45:48 +0000 From: To: , Date: Thu, 24 Jan 2013 11:45:47 +0000 Thread-Topic: [lmap] Proposed LMAP Charter Thread-Index: Ac36IKlZjVzdY+/yT3KDVqJ7MOmnnAABtunQ Message-ID: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <49B53DD1-B801-4412-B503-0825F646816F@isoc.org> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: philip.eardley@bt.com, mlinsner@cisco.com, ford@isoc.org, trammell@tik.ee.ethz.ch Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 11:45:50 -0000 I would argue that the scope of LMAP is to define the overall measurement f= ramework. If this framework is used to run the same (IPPM defined) tests th= en it will yield comparable results. How to process these results into equivalent statistics is post-measurement= and beyond the scope of LMAP (and would probably fall in the remit of IPPM= in any case). Similar argument for data sharing - data can be anonymised/a= ggregated (if necessary) and shared after collection. Trevor. >-----Original Message----- >From: Arturo Servin [mailto:aservin@lacnic.net] >Sent: 24 January 2013 10:51 >To: lmap@ietf.org >Cc: Matthew Ford; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; >mlinsner@cisco.com; Brian Trammell >Subject: Re: [lmap] Proposed LMAP Charter > >Hi al, > > I was going to ask something similar. > > For example, we have a project where we have done some >measurements but those are confined to a specific region of the world. It >would be interesting to share that data among other organizations doing th= e >same but today we can't because there is not a standard (that I asume we >are intent to produce) and because privacy implications (that I am not sur= e >that we are addressing in the chapter). > > So, is a WG goal to address the problem of sharing and anomyzing >data (or address any privacy concern)? > >Regards, >as > >On 23 Jan 2013, at 10:15, Brian Trammell wrote: > >> hi Mat, Phil, all, >> >> I agree as well, though other comments on finer points may follow. One >inline below. >> >> On 23 Jan 2013, at 13:07 , Matthew Ford wrote: >> >>> Phil, >>> >>> Nice post, which I think I completely agree with. >>> >>> On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: >>> >>>> * We assume that Measurement Agent, tests Controller and resul= ts >Collector are all under control of same organisation (eg Samknows, FCC, BT= ). >Reason: Inter-organisation interactions (for example to share results) is >better handled by business-level negotiation than a control protocol. >>> >>> I think we also need an assumption that nothing will preclude having >collectors, for example, be under control of third-parties. I think it is = worth >explicitly stating that, unless there is disagreement on this point? >> >> +1 on this point. I'd suggest that we leave the component >ownership/control issues completely aside; i.e., we don't necessarily want= to >preclude organization(s) from agreeing to use a measurement infrastructure >in place (which uses this control protocol) for sharing of intermediate or= final >measurement results (in support of an existing business-level agreement). >> >> What's _really_ important about this assumption is that it makes the >problems of inter-domain measurement control and exchange explicitly out >of scope for the charter, and simplifies issues of trust among the >components. I think it should probably be explicitly phrased as an issue o= f >scope rather than an assumption about deployment. >> >> Cheers, >> >> Brian >> >> >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap From philip.eardley@bt.com Thu Jan 24 04:34:24 2013 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 F0B9121F8A43 for ; Thu, 24 Jan 2013 04:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39h9OikZq812 for ; Thu, 24 Jan 2013 04:34:22 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE1821F8A4A for ; Thu, 24 Jan 2013 04:34:20 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 24 Jan 2013 12:34:18 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.111]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Thu, 24 Jan 2013 12:34:18 +0000 From: To: , Date: Thu, 24 Jan 2013 12:34:18 +0000 Thread-Topic: [lmap] Proposed LMAP Charter Thread-Index: Ac36HU13KUCKypJXRPuJWMLHayJ/ngAC3naj Message-ID: <9510D26531EF184D9017DF24659BB87F340D7963AE@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net>, <20130124102626.GA7215@localhost> In-Reply-To: <20130124102626.GA7215@localhost> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 12:34:24 -0000 thanks Julien for your detailed and intersting comments, some responses in-= line phil ________________________________________ From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] On Behalf Of Julien Mou= tinho [julm+lmap@autogeree.net] Sent: 24 January 2013 10:26 To: lmap@ietf.org Subject: Re: [lmap] Proposed LMAP Charter Hi everyone, Interesting post Trevor and Phil! I've made below a few humble comments derived from my (still young) experie= nce in developping the Grenouille system. Le mer. 23 janv. 2013 =E0 09:54:39 +0000, philip.eardley@bt.com a =E9crit : > The LMAP WG makes the following architectural assumptions - in order to > make rapid progress with an acceptable loss of generality:- > > * We assume that Measurement Agent, tests Controller and > results Collector are all under control of same organisation (eg > Samknows, FCC, BT). Reason: Inter-organisation interactions (for > example to share results) is better handled by business-level > negotiation than a control protocol. agreed for an initial scope. though, what is the precise meaning of "control" here? because shouldn't the MA be "under control" of anyone but the owner of the system it runs on? which for instance would mean free/open source software, and being able to precisely see and filter what is sent to whom and when. [phil] "under control" - I'd say this is the party who owns /manages the MA= . For a hardware device this is "the owner of the systme it runs on" - for = a software MA then it's the owner of the app (not necessarily the owner of = the system it runs on).=20 the Controller instructs the MA what test server(s) to use and what Collect= ors to send results to.=20 > * We assume the MA initiates a measurement. Reasons: having the > test schedule on MA avoids it having to check frequently with the > Controller; it is easier if the MA is behind a NAT; and the MA knows > whether the user is active and therefore whether to run test or delay it. agreed. > * We assume measurement results are sent from MA, and not from > test server. Reason-1: It is easier to secure the MA to Collector > communication. One implication is that for an upload test measured by > the test server, the result is reported back to the MA which reports it > in turn. Reason-2: Test servers may be controlled by a third party > ('load time for IETF home page'). agreed. and we should also keep in mind that a Test server (wouldn't be Landmark a better name?) could run on the same system than the MA so as to have MA to MA measurements. [phil] I think it's possible that the device with the MA functionality will= also have test server functionality.=20 personally I prefer the term test server to Landmark. > * We assume no negotiation is needed between Controller and MA. > The Controller already knows the characteristics of the MA, for > instance via TR069 for Broadband Forum devices. The Controller simply > instructs (securely) the MA "Measure this"; the MA replies "OK /error". agreed for an initial scope, but I think there should eventually be a more complex MA<>Controller negotiation, for instance to synchronise several MA, a Controller could tell each MA to recontact it in a given amount of time, until it has accumulated a given number of MA to trigger the probing. [phil] please can you explain a bit more, I don't follow. also, some characteristics may be volatile, like the geolocation, and may be used by the Controller to filter its MA, therefore I think a mechanism to keep track of the MA's characteristics should be part of this negotiation; be it via TR-069 if it is flexible and supported enough or else. [phil]i agree that it will learn these charcteristics via TR-069 or somethi= ng else outside lmap. i think the implication for lmap is that no negoiatio= n is needed in lmap. [phil] let me see if i get your scenario. we have mobiles with MA functiona= lity. the Controller wants tests to be run by mobiles in Cambridge. from an lmap point of view, i think the Controller would liaise with the mo= bile operator's location database to select mobiles that are near Cambridge= , and then send an instruction to those mobiles "for the next hour, if you'= re in cambridge then run this test". an hour later it would re-check the lo= cation DB to re-tweak the set of mobiles and re-send the instruction. i don= t think this needs lmap negotiation. moreover as it is a botnet which is designed here, preventing usurpation is= critical, thus maybe a level of mutual authentification should have to be inserted he= re, for instance I think that using an horizontal public key infrastructure like OpenPGP's should be considered: each MA/Controller/Collector having its own private key (self-generated with possibly a designed revoker= ). [phil] agree that security is needed for the MA/controller/Collector comms. > * Similarly we assume no negotiation is needed between the MA > and Collector. The protocol simply delivers (securely) the measurement > results from the MA to the Collector, and returns an ack or error code. agreed for an initial scope. though mutual authentification should eventually be done here too. > * We assume each MA is controlled by only one Controller. > Reason: to avoid different Controllers giving the MA conflicting > schedules. Note: a measurement platform may have several Controllers, > with each Controller controlling a subset of the MAs, for example one > controlling wireline MAs and one mobile MAs. agreed for an initial scope. though I do not really see how this would be enforced at this point; at least I think that each instance of a MA should choose an initial Contro= ller, which in turn may suggest the MA to contact an other Controller. [phil] i agree there is some initialisation activity needed.=20 i guess this is part of the Collector's job. would be interesting to hear p= eople's views about how to do this and what we want in prospective WG's sco= pe. > * We assume the raw measurement results are reported; filtering > /averaging of measuremnts by the MA is not in the initial scope, except > as defined by IPPM as part of the metric definition. what is the need for this assumption? I think the MA should just be able to perform computation when the concept of the probing allows it, for instance for certain kinds of local anomalies detection having the MA doing some computation is cheap on the MA and saves a lot of computer resources when data mining the Collector. [phil] the reason for the assumption is to simplify the defintion of lmap's= Reporting data model.=20 reporting the raw measurements would, i tihnk, be the most usual case. I agree that there'll be some cases where the MA wants to do some averaging= (or other data manipulation) rather than leaving all data manipulation to = the Collector - but I think it is Ok to leave this out of the initial scope= . > * We assume that uploading a new test capability to the MA is > out of scope. This can be done as a firmware upgrade for home hub, or > new app for PC, etc. agreed for an initial scope. and not exactly that but related: I've been suggested that some kind of sandboxing of a minimal language (=E0 la google App Engin= e) should be supported so that the casual user can develop and deploy its own = probe while keeping it safe (with several levels of safety) for the MA running the probe; having such possibility may also further the adoption/deployment of the MA. > * We assume as out of scope a network parameter server (which > stores nominal values such as the contractual data rate). The > functional role of the Network Paraemeter Server may be fulfilled by > existing OSS (such as network or home gateway management systems). > Interfaces to the NPS are pre-measurement (used by the Controller to > decide which tests to schedule) or post-measurement (used to analyse > the measurement data). agreed for an initial scope. > * We assume data filtering is out of the initial scope. > Filtering includes: removal of outlier measurements, archiving > (curating) data for scientific research, and so on. There are certainly > some aspects where best practice would be useful but data filtering is > not a first priority. agreed for an initial scope. though best practices for the archiving part would be very welcome. > * We assume that data privacy issues are out of scope although > security is considered. The MA, Controller and Collector are all under > control of the same organisation. IPPM considers the implications of > any passive measurement tests that it defines. what is the need for this frightening assumption? does it just means that privacy concerns must be specified within IPPM RFC? [phil] sorry, didn't phrase this bullet very well. We meant: as a consequen= ce of the previous assumptions, therefore data privacy can be excluded from= the scope (becuase MA, controller and collector under control fo same orga= nisation).=20 of course the Collector may send some anonymised version of the collected d= ata to other parties - this would clearly have privcay implications. but th= is is out of scope -- the range of things that the Collected data could be = used for are large - for instance how could the operator use it for their n= etwork mgt? this requires interaction with the OSS, and i think this is out= of scope of lmap. Basic rule of thumb therefore is that lmap avoids thinking about "how to us= e the collected measurements" - its scope is "how to control and collect th= e measurments" > The LMAP WG standardises the following items: > > 1. The data model that defines the test schedule, which includes: > a. The IPPM metric to be tested and values for its parameters. > {Question: is the restriction to IPPM OK? Ie non-IPPM tests are out of = scope} what is the need for this assumption? I think metrics should be easily extensible according to a common schema (for instance specifying a hierarchical namespace for probes gathering them by ///..). [phil] thanks - interested to hear people's views about this > b. Test schedule: when the test should be done and how often > repeated ('once an hour at xx.03'). A test may also be a one-off, done > immediately on demand. I think that a variety of common temporal series should be considered (like, raw-list, periodic, exponential-based, gamma-based, uniform-random-b= ased, ..); for instance some tomography probes require these kind of distributions. [phil] sounds like a good idea. an maybe that these series could be reused to vary fields of network protoc= ols, for instance some probes discovering the network topology accross load-bala= ncers use them. > c. Output parameters: some IPPM metrics may define a choice of ou= tputs > d. Test Server: which server or servers should be used for the tes= t > e. Environmental conditions: such as 'no user traffic' which means > a particular instance of the test is delayed or abandoned. other environmental conditions could include: - cheap network connection available (not 3G at per consumption rate for i= nstance) - stable power supply available [phil] ok > f. (perhaps) Metadata: such as a mobile's location when the test > should be made, the line's nominal rate etc. There may be privacy > implications for the scenario where the measurement plaform is not > controlled by the operator; the initial scope will exclude this > scenario. > g. (perhaps) Metadata to report: for example, the MA may be able t= o > measure Layer 1 o 2 charcteristics such as DSL sync speed and > interleaving; the actual test is out of scope. As for the previous > bullet, there may be privacy implications for the general scenario, > which we exclude from the initial scope. > h. (perhaps) Priority: the Controller decides which tests are done > when. However a test might get delayed until it overlaps with another > scheduled test - which should be done (or done first)? Or should it > simply be abandoned? moreover I think versioning the test models (I called them configurations) and report models (I called them samples) should also be envisaged. > 2. The data model that defines how an MA should report test > results. This may be combined with (1) above or specified as a separate > reporting schedule. This includes: > > a. Where to report results to (one or more Collectors) > b. How often to report results for the different tests > c. What to do when Collector is not available (fail-over, try aga= in) I think there should be a simple local queue, filesystem-based for instance= , or possibly a local mail server could be used to post results (just an idea, or at least a source of inspiration), moreover environmental conditions could also intervene here to delay the re= port. > 3. The data model that defines the report, which includes: > a. The metric that was measured > b. The time of the test > c. Whether the test is scheduled, one-off triggered by the Contro= ller, or user-initiated > d. The measurement result - usually several results are batched > together; the result of a one-off test may be wanted immediately > e. (perhaps) Metadata, such as the mobile's location > f. Comment: it would make sense to use the same language as for = 1, for instance XML, YANG... I would recommend to use a language designed to be a data interchange forma= t, which for instance means more JSON than XML which is rather a document stan= dard. the few MA I happen to know use JSON. > 4. The application level protocol for the (secure) delivery of the t= est and reporting schedule (#1, #2) > a. A simple instruction - response protocol, with error codes defi= ned > b. LMAP could specify how it operates over one existing protocol (= REST style HTTP(s), Netconf...) yes, I think that ReST HTTP should be used, which AFAIK would boil down to specifying: - URI schemes for identifying resources; - representations of the states of these resources, transferred between components. [phil] for this and your JSON comment it would be interesting to hear peopl= e's views (to see if consensus can be reached in the next month or so, or w= hether the (propspective) WG needs to do the selection. > 5. The application level protocol for the (secure) delivery of the r= eport (#3) > a. Same comments as for #4 > 6. A document explaining the simplifying architectural assumptions > in more detail. This document could also define some terminology and > explain the use cases. looking forward to the discussion, julm= From acmorton@att.com Thu Jan 24 04:53:38 2013 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 ECF7E21F8996 for ; Thu, 24 Jan 2013 04:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKx4KmE5RQeq for ; Thu, 24 Jan 2013 04:53:37 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id F1C2E21F8960 for ; Thu, 24 Jan 2013 04:53:36 -0800 (PST) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 6BDA41203BB; Thu, 24 Jan 2013 07:54:50 -0500 (EST) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id A3349E36D7; Thu, 24 Jan 2013 07:48:16 -0500 (EST) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Thu, 24 Jan 2013 07:53:36 -0500 From: "MORTON JR., ALFRED (AL)" To: "trevor.burbridge@bt.com" , "aservin@lacnic.net" , "lmap@ietf.org" Date: Thu, 24 Jan 2013 07:53:33 -0500 Thread-Topic: [lmap] Proposed LMAP Charter Thread-Index: Ac36IKlZjVzdY+/yT3KDVqJ7MOmnnAABtunQAAIgPbA= Message-ID: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <49B53DD1-B801-4412-B503-0825F646816F@isoc.org> In-Reply-To: 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 Cc: "philip.eardley@bt.com" , "mlinsner@cisco.com" , "ford@isoc.org" , "trammell@tik.ee.ethz.ch" Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 12:53:38 -0000 Hi Trevor, You are right that post-singleton measurement processing is part of IPPM's work (singletons, samples, statistics). But LMAP could easily=20 use what has been specified in IPPM RFCs to specify some form of results format. So I tend to agree with Arturo. For me, the simplest LMAP framework is the one which ensures the same measurements are performed according to the same sampling plan (schedule) and reported the same way by each organization in their network. Thus, there is freedom to choose the best implementation within a network. regards, Al > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > trevor.burbridge@bt.com > Sent: Thursday, January 24, 2013 6:46 AM > To: aservin@lacnic.net; lmap@ietf.org > Cc: philip.eardley@bt.com; mlinsner@cisco.com; ford@isoc.org; > trammell@tik.ee.ethz.ch > Subject: Re: [lmap] Proposed LMAP Charter >=20 >=20 > I would argue that the scope of LMAP is to define the overall measurement > framework. If this framework is used to run the same (IPPM defined) tests > then it will yield comparable results. >=20 > How to process these results into equivalent statistics is post- > measurement and beyond the scope of LMAP (and would probably fall in the > remit of IPPM in any case). Similar argument for data sharing - data can > be anonymised/aggregated (if necessary) and shared after collection. >=20 > Trevor. >=20 > >-----Original Message----- > >From: Arturo Servin [mailto:aservin@lacnic.net] > >Sent: 24 January 2013 10:51 > >To: lmap@ietf.org > >Cc: Matthew Ford; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; > >mlinsner@cisco.com; Brian Trammell > >Subject: Re: [lmap] Proposed LMAP Charter > > > >Hi al, > > > > I was going to ask something similar. > > > > For example, we have a project where we have done some > >measurements but those are confined to a specific region of the world. I= t > >would be interesting to share that data among other organizations doing > the > >same but today we can't because there is not a standard (that I asume we > >are intent to produce) and because privacy implications (that I am not > sure > >that we are addressing in the chapter). > > > > So, is a WG goal to address the problem of sharing and anomyzing > >data (or address any privacy concern)? > > > >Regards, > >as > > > >On 23 Jan 2013, at 10:15, Brian Trammell wrote: > > > >> hi Mat, Phil, all, > >> > >> I agree as well, though other comments on finer points may follow. One > >inline below. > >> > >> On 23 Jan 2013, at 13:07 , Matthew Ford wrote: > >> > >>> Phil, > >>> > >>> Nice post, which I think I completely agree with. > >>> > >>> On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: > >>> > >>>> * We assume that Measurement Agent, tests Controller and > results > >Collector are all under control of same organisation (eg Samknows, FCC, > BT). > >Reason: Inter-organisation interactions (for example to share results) i= s > >better handled by business-level negotiation than a control protocol. > >>> > >>> I think we also need an assumption that nothing will preclude having > >collectors, for example, be under control of third-parties. I think it i= s > worth > >explicitly stating that, unless there is disagreement on this point? > >> > >> +1 on this point. I'd suggest that we leave the component > >ownership/control issues completely aside; i.e., we don't necessarily > want to > >preclude organization(s) from agreeing to use a measurement > infrastructure > >in place (which uses this control protocol) for sharing of intermediate > or final > >measurement results (in support of an existing business-level agreement)= . > >> > >> What's _really_ important about this assumption is that it makes the > >problems of inter-domain measurement control and exchange explicitly out > >of scope for the charter, and simplifies issues of trust among the > >components. I think it should probably be explicitly phrased as an issue > of > >scope rather than an assumption about deployment. > >> > >> Cheers, > >> > >> Brian > >> > >> > >> _______________________________________________ > >> lmap mailing list > >> lmap@ietf.org > >> https://www.ietf.org/mailman/listinfo/lmap >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From trevor.burbridge@bt.com Thu Jan 24 05:26:55 2013 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 A575221F8A4B for ; Thu, 24 Jan 2013 05:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcjAIluZgNE9 for ; Thu, 24 Jan 2013 05:26:55 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 9715621F8A4A for ; Thu, 24 Jan 2013 05:26:54 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 24 Jan 2013 13:26:53 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.116]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Thu, 24 Jan 2013 13:26:53 +0000 From: To: , , Date: Thu, 24 Jan 2013 13:26:52 +0000 Thread-Topic: [lmap] Proposed LMAP Charter Thread-Index: Ac36IKlZjVzdY+/yT3KDVqJ7MOmnnAABtunQAAIgPbAAANCAUA== Message-ID: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <49B53DD1-B801-4412-B503-0825F646816F@isoc.org> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: philip.eardley@bt.com, mlinsner@cisco.com, ford@isoc.org, trammell@tik.ee.ethz.ch Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 13:26:55 -0000 I was thinking really of statistics produced across a set of MAs - this cou= ld not be done on the MA and is beyond the scope of the LMAP measurement co= ntrol and collection. Statistics for a single MA, I guess could be just another test that the pro= be could operate. One more question for this group would then be if this st= atistic just looks the same as a singleton measurement to the LMAP framewor= k, or whether LMAP contains support for constructing statistics in differen= t ways from singleton metrics. Obviously the former simplifies our work con= siderably but means different statistics have to be coded as a single test = and may not be able to operate in conjunction with other statistics based u= pon the same singleton test. The other problem is that streams or statistic= s will overlap - contention of tests needs to be done on the singleton leve= l. Options: a) only allow singleton measures - streams and statistics are constructed a= fter collection. Obviously not good if the singleton test is a ping every s= econd. b) allow streams and statistics to be coded as tests but only allow schedul= ing/contention to be managed at the test level within LMAP. If streams/stat= istics overlap they may affect each other. Contention management for sub-te= st elements (e.g. singleton ping tests within an average latency stream) wo= uld be coded into the test. c) allow streams and statistics to be constructed on the MA but manage cont= ention at the singleton level. In effect same as (a) but with processing ca= pabilities on the MA. Could get very complicated. I guess I would advocate (b). Trevor. >-----Original Message----- >From: MORTON JR., ALFRED (AL) [mailto:acmorton@att.com] >Sent: 24 January 2013 12:54 >To: Burbridge,T,Trevor,TUB8 R; aservin@lacnic.net; lmap@ietf.org >Cc: Eardley,PL,Philip,TUB8 R; mlinsner@cisco.com; ford@isoc.org; >trammell@tik.ee.ethz.ch >Subject: RE: [lmap] Proposed LMAP Charter > >Hi Trevor, > >You are right that post-singleton measurement processing is part of >IPPM's work (singletons, samples, statistics). But LMAP could easily >use what has been specified in IPPM RFCs to specify some form of >results format. So I tend to agree with Arturo. > >For me, the simplest LMAP framework is the one which ensures >the same measurements are performed according to the same sampling plan >(schedule) and reported the same way by each organization in their network= . >Thus, there is freedom to choose the best implementation within a >network. > >regards, >Al > > >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf >Of >> trevor.burbridge@bt.com >> Sent: Thursday, January 24, 2013 6:46 AM >> To: aservin@lacnic.net; lmap@ietf.org >> Cc: philip.eardley@bt.com; mlinsner@cisco.com; ford@isoc.org; >> trammell@tik.ee.ethz.ch >> Subject: Re: [lmap] Proposed LMAP Charter >> >> >> I would argue that the scope of LMAP is to define the overall measuremen= t >> framework. If this framework is used to run the same (IPPM defined) test= s >> then it will yield comparable results. >> >> How to process these results into equivalent statistics is post- >> measurement and beyond the scope of LMAP (and would probably fall in >the >> remit of IPPM in any case). Similar argument for data sharing - data can >> be anonymised/aggregated (if necessary) and shared after collection. >> >> Trevor. >> >> >-----Original Message----- >> >From: Arturo Servin [mailto:aservin@lacnic.net] >> >Sent: 24 January 2013 10:51 >> >To: lmap@ietf.org >> >Cc: Matthew Ford; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; >> >mlinsner@cisco.com; Brian Trammell >> >Subject: Re: [lmap] Proposed LMAP Charter >> > >> >Hi al, >> > >> > I was going to ask something similar. >> > >> > For example, we have a project where we have done some >> >measurements but those are confined to a specific region of the world. = It >> >would be interesting to share that data among other organizations doing >> the >> >same but today we can't because there is not a standard (that I asume w= e >> >are intent to produce) and because privacy implications (that I am not >> sure >> >that we are addressing in the chapter). >> > >> > So, is a WG goal to address the problem of sharing and anomyzing >> >data (or address any privacy concern)? >> > >> >Regards, >> >as >> > >> >On 23 Jan 2013, at 10:15, Brian Trammell wrote: >> > >> >> hi Mat, Phil, all, >> >> >> >> I agree as well, though other comments on finer points may follow. On= e >> >inline below. >> >> >> >> On 23 Jan 2013, at 13:07 , Matthew Ford wrote: >> >> >> >>> Phil, >> >>> >> >>> Nice post, which I think I completely agree with. >> >>> >> >>> On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: >> >>> >> >>>> * We assume that Measurement Agent, tests Controller and >> results >> >Collector are all under control of same organisation (eg Samknows, FCC, >> BT). >> >Reason: Inter-organisation interactions (for example to share results) = is >> >better handled by business-level negotiation than a control protocol. >> >>> >> >>> I think we also need an assumption that nothing will preclude having >> >collectors, for example, be under control of third-parties. I think it = is >> worth >> >explicitly stating that, unless there is disagreement on this point? >> >> >> >> +1 on this point. I'd suggest that we leave the component >> >ownership/control issues completely aside; i.e., we don't necessarily >> want to >> >preclude organization(s) from agreeing to use a measurement >> infrastructure >> >in place (which uses this control protocol) for sharing of intermediate >> or final >> >measurement results (in support of an existing business-level agreement= ). >> >> >> >> What's _really_ important about this assumption is that it makes the >> >problems of inter-domain measurement control and exchange explicitly >out >> >of scope for the charter, and simplifies issues of trust among the >> >components. I think it should probably be explicitly phrased as an issu= e >> of >> >scope rather than an assumption about deployment. >> >> >> >> Cheers, >> >> >> >> Brian >> >> >> >> >> >> _______________________________________________ >> >> 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 r.b.marks@ieee.org Thu Jan 24 08:59:20 2013 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 89CFD21F8834 for ; Thu, 24 Jan 2013 08:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.436 X-Spam-Level: X-Spam-Status: No, score=-100.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qq7sBg1qAWQC for ; Thu, 24 Jan 2013 08:59:20 -0800 (PST) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id DC18321F874C for ; Thu, 24 Jan 2013 08:59:19 -0800 (PST) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta12.emeryville.ca.mail.comcast.net with comcast id rqFP1k0061u4NiLACszKUD; Thu, 24 Jan 2013 16:59:19 +0000 Received: from [192.168.1.146] ([76.25.27.99]) by omta21.emeryville.ca.mail.comcast.net with comcast id rszH1k00C28HmlY8hszJ66; Thu, 24 Jan 2013 16:59:19 +0000 From: Roger Marks Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E0C99E61-5EBB-4A37-A73F-10115EDCCE35" Date: Thu, 24 Jan 2013 09:59:17 -0700 In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5CFD1B7EA0@EUSAACMS0703.eamcs.ericsson.se> To: lmap@ietf.org References: <504099B8.1020609@centurylink.com> <60C093A41B5E45409A19D42CF7786DFD5CFCDD0365@EUSAACMS0703.eamcs.ericsson.se> <2E663B95-4A85-4DD8-80D6-B3B8AA269083@ieee.org> <60C093A41B5E45409A19D42CF7786DFD5CFD1B7EA0@EUSAACMS0703.eamcs.ericsson.se> Message-Id: <5C0258AF-F4FF-437E-AA34-5BCBADC08A02@ieee.org> X-Mailer: Apple Mail (2.1283) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359046759; bh=2LG59iNVXvxQUkYxYDtk7RGky61W4E+rrXaAQWc5eWY=; h=Received:Received:From:Mime-Version:Content-Type:Subject:Date:To: Message-Id; b=BtXZc8xUWgax6Lj2JxrV/WruFOHLxJLeHtge599elx9o0QNWWKc4cq4NZWA0BeoSh ROS9o06vQ3cUGBfhbI6SVnv6C3ReZ9fBqTx0JbMBPdpsJZ1mFHuJ5TcO1DIpNa93CE Dwtx0oy7DVtKhbt0AMFqwWfaj+NX+pKNkZ7GhgmkfO2jHdawasCmt5TsjEsMVameCE YSZ4I0EAsVAD5yOoEeJEzh5w+x1quvYRfe5/RRmfgj3vr3oZ5zQoFHG2QGG5OImpeQ bH9541hnF5RtlOPdzusDL2/GSVVn/xgmEyShVkRACVeqWUh4tiorgMrorejCRUmS0m KRE2ouj2GNTwg== Subject: [lmap] Progress on IEEE Project P802.16.3 Architecture and Privacy X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 16:59:20 -0000 --Apple-Mail=_E0C99E61-5EBB-4A37-A73F-10115EDCCE35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The attached report has been provided by the IEEE 802.16 Working Group. = It calls attention to further development of the separate public and = private functional entities in the draft P802.16.3 architecture. = Comments are welcome, with instructions provided in the report. Regards, Roger Roger B. Marks Consensii LLC Chair, IEEE 802.16 Working Group on Broadband Wireless Access = --Apple-Mail=_E0C99E61-5EBB-4A37-A73F-10115EDCCE35 Content-Type: multipart/mixed; boundary="Apple-Mail=_1A7FA3F8-9044-4B78-8D27-619EA8C6E699" --Apple-Mail=_1A7FA3F8-9044-4B78-8D27-619EA8C6E699 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
The attached report has been provided by the IEEE 802.16 Working Group. It calls attention to further development of the separate public and private functional entities in the draft P802.16.3 architecture. Comments are welcome, with instructions provided in the report.

Regards,

Roger

Roger B. Marks <roger@consensii.com>
Consensii LLC <http://consensii.com>
Chair, IEEE 802.16 Working Group on Broadband Wireless Access <http://WirelessMAN.org>


--Apple-Mail=_1A7FA3F8-9044-4B78-8D27-619EA8C6E699 Content-Disposition: inline; filename=16-13-0041-00.pdf Content-Type: application/pdf; x-mac-type=50444620; x-mac-creator=4341524F; x-unix-mode=0644; name="16-13-0041-00.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjYNJeLjz9MNCjU1IDAgb2JqDTw8L1ZpZXdlclByZWZlcmVuY2VzPDwvRGlzcGxheURv Y1RpdGxlIHRydWU+Pi9NZXRhZGF0YSAxMjQgMCBSL1BhZ2VzIDMgMCBSL1BhZ2VMYXlvdXQvT25l Q29sdW1uL09wZW5BY3Rpb24gMTI4IDAgUi9UeXBlL0NhdGFsb2c+Pg1lbmRvYmoNMTI0IDAgb2Jq DTw8L1N1YnR5cGUvWE1ML0xlbmd0aCAzODgzL1R5cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94cGFj a2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0 YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNC4wLWMz MjEgNDQuMzk4MTE2LCBUdWUgQXVnIDA0IDIwMDkgMTQ6MjQ6MzAiPgogICA8cmRmOlJERiB4bWxu czpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAg ICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4YXA9Imh0 dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iPgogICAgICAgICA8eGFwOkNyZWF0ZURhdGU+MjAx My0wMS0yM1QxNzozMDoxMlo8L3hhcDpDcmVhdGVEYXRlPgogICAgICAgICA8eGFwOkNyZWF0b3JU b29sPlBhZ2VzPC94YXA6Q3JlYXRvclRvb2w+CiAgICAgICAgIDx4YXA6TW9kaWZ5RGF0ZT4yMDEz LTAxLTIzVDEwOjM1OjI4LTA3OjAwPC94YXA6TW9kaWZ5RGF0ZT4KICAgICAgICAgPHhhcDpNZXRh ZGF0YURhdGU+MjAxMy0wMS0yM1QxMDozNToyOC0wNzowMDwveGFwOk1ldGFkYXRhRGF0ZT4KICAg ICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIi CiAgICAgICAgICAgIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyI+ CiAgICAgICAgIDxkYzpmb3JtYXQ+YXBwbGljYXRpb24vcGRmPC9kYzpmb3JtYXQ+CiAgICAgICAg IDxkYzpjcmVhdG9yPgogICAgICAgICAgICA8cmRmOlNlcT4KICAgICAgICAgICAgICAgPHJkZjps aT5Sb2dlciBNYXJrczwvcmRmOmxpPgogICAgICAgICAgICA8L3JkZjpTZXE+CiAgICAgICAgIDwv ZGM6Y3JlYXRvcj4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAg ICAgICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5SZXBvcnQgZm9sbG93aW5n IFNlc3Npb24gIzgzOiBQcm9ncmVzcyBvbiBJRUVFIFByb2plY3QgUDgwMi4xNi4zIEFyY2hpdGVj dHVyZSBhbmQgUHJpdmFjeTwvcmRmOmxpPgogICAgICAgICAgICA8L3JkZjpBbHQ+CiAgICAgICAg IDwvZGM6dGl0bGU+CiAgICAgICAgIDxkYzpkZXNjcmlwdGlvbj4KICAgICAgICAgICAgPHJkZjpB bHQ+CiAgICAgICAgICAgICAgIDxyZGY6bGkgeG1sOmxhbmc9IngtZGVmYXVsdCI+SUVFRSA4MDIu MTYtMTMtMDA0MS0wMC1XR0xTPC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOkFsdD4KICAgICAg ICAgPC9kYzpkZXNjcmlwdGlvbj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnBkZj0iaHR0cDovL25z LmFkb2JlLmNvbS9wZGYvMS4zLyI+CiAgICAgICAgIDxwZGY6UHJvZHVjZXI+TWFjIE9TIFggMTAu Ny41IFF1YXJ0eiBQREZDb250ZXh0PC9wZGY6UHJvZHVjZXI+CiAgICAgIDwvcmRmOkRlc2NyaXB0 aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxu czp4YXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyI+CiAgICAgICAgIDx4YXBN TTpEb2N1bWVudElEPnV1aWQ6ZTVmOTQ1YWYtNWRlYy0xMTRmLTllM2YtNzliOTljZTJiNDhiPC94 YXBNTTpEb2N1bWVudElEPgogICAgICAgICA8eGFwTU06SW5zdGFuY2VJRD51dWlkOjcxZmIzNTBi LTg3ZmEtMjM0OC1hMWJjLTU4MjI2YmI2MGY0OTwveGFwTU06SW5zdGFuY2VJRD4KICAgICAgPC9y ZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0idyI/ Pg1lbmRzdHJlYW0NZW5kb2JqDTMgMCBvYmoNPDwvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0NvdW50 IDEvVHlwZS9QYWdlcy9LaWRzWzIgMCBSXT4+DWVuZG9iag0xMjggMCBvYmoNPDwvRFsyIDAgUi9G aXRIIC0zMjc2OF0vUy9Hb1RvPj4NZW5kb2JqDTIgMCBvYmoNPDwvQW5ub3RzIDMyIDAgUi9QYXJl bnQgMyAwIFIvQ29udGVudHMgNCAwIFIvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL1Jlc291cmNlcyA2 IDAgUi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMzIgMCBvYmoNWzMzIDAgUiAzNCAwIFIgMzUgMCBSIDM2 IDAgUiAzNyAwIFIgMzggMCBSIDM5IDAgUiA0MCAwIFIgNDEgMCBSIDQyIDAgUiA0NCAwIFIgNDUg MCBSIDQ2IDAgUiA0NyAwIFIgNDggMCBSIDQ5IDAgUiA1MCAwIFIgMTE1IDAgUiAxMjMgMCBSXQ1l bmRvYmoNNCAwIG9iag08PC9MZW5ndGggNDI1MC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0K eAHNW8ty3MYV3eMrOuUNWMWB8H54FYmhE7ksJzKZeGF5IYomGcsaUCONZOUzk8r/5PTj3G4APcMZ OVVJqUoAgcbt27fPffe8Vc/VW5XjX1uUqhtKtflJfa/W6tHZu0K9eqcK9e7V/P1N5EGCYW8xWpNa FarKqyxvVFNlQ5PnoPRGPblUmMK+19eiUJdv1KPLyyLDH+ryRqXFibr8OTm/BFOYv9Tz6/G55iEg nhtGHcnaDFgVtSryLmvbflB97SiXWZ4Yyj+o9OmJyrNSpefn58rd9idqZZ7lvCl5k7kh4MgOaU8S e8OPvz9RRa8Jjm7ohkNf8+bv7s3aXW/dVZ0kZto/zr8kqa17cS8fWN75ngQtL0n6hDMKDxz5km+u Hakrd5UXpGUHJGmwvj4bVMpFCOmfSPIXR0oevOMbd2OIVV1WqfQxX71a3EQ//1Fdfq0MEPT2FzN0 7QBAWfZZ2xUDkJB7BFhsAQF3ht8kff+ecv3ykVsCr9jU4xadpPNFq/SZLPZbLjZz83BbRJiAhFtq 8twAeS/WvfrUw5DlederouJSoXBuqUn63XgLsRqQbdSTTD0jI9h2+/Q1+PZC3qVcwYRQ6HaooGV1 k1i99ROq9OyOlAO81LlKT9XTczfn/Kr6vMyKFtoARSpUqoVvmBs3r0llfaugJVbzNuMWG7eX6WRq ZOoeEwxdpYp2KSWVYheaRqtwdpW9cUxyGRsIyGn87/Ur8EeeKNn5NRtB0C7Fb6uxr2IWDXCThTGs hzZre4ii6BoHXBFuWnTaKlplmO/TklSTQwd2kYJuH0GpKHZSgjZ9zW2hxNZbe5ekm08PbNPMFzQ1 VDayclXmxUmyi+OlT2k6aECETuWWDRWbC3BJpGox7WIXsODLEwX66fjliWoHY9rgdPpC20hBLmVB 0/jeoYpQ2SgR23i3FjPJYeP6VJ3dzXF2c6qoOqRLerCmRmNIYDO+cb6FnNyuOZZjSJ7fqjN8ZMnc 8ys7NhHIX/EjMsC/SfST+gPxwFcfeCPL5AO9zK84/OzsOLB0pSrLPGKCRLJcBFdFATg+VOrNoeUo SbksXvkJFNoasT+T3Ruq+A1XQznabwCM8Ub2a33LUbINQlre3CpyvL6GhloLcnmSaLRxNCe5W4/k cbyFmrW1xt/B4lzaCy3OKgb3P3HFZGG9Dji+oHEUxrbk6x8OTBsZLmuPolvs/6VVMM4nlMMlk6bs JQEoIkjSz0FUE/MPf+Minz7WngLAOXdrOxP4XhyP3j6GXlEfYkHUR2PCuilwYT0hRf3LTNm1+RhX IjiSotAEzU82I99dX/EO4PuKCx43W2qPrBnvKewxfLjgbmMZSFKxZPxuvrV8vt3wzQ5vf5Dl1lAe YlA+uxMsilPn1OP9ncy9WAnlzMEcORWkDeZngnQ7FQrSq7ZxJCQm2wX9sqT4hDtDNgJLzd3h1pJD Xn9ypDgJ3Aqp8RMsYm8sNXPS8ItVGQv9yC2v8I9IAHUesSqavtLRv4SAl05/nPrAWH7jnjwjth/z 5i8nqupAh0ud80+p2PUkKULF6SPlY3OI5Zi1AklVHdNS8GQ1kMyI1VMS61O+r8VSz/f1TttBUuBw wZQI69yJhlcdL0PxLEZ+5c5S7FtuPQl+4IidsEEq5KbglZ/geoy8NDa6mLxgHa28tlc/u6kAD6Rp emPxrm1bfSti3Yy3zhTEEis1rvdkEwERzmWXk6SUEZepZKxNQYDRhe47K4a0kQJ9P9OpOVVjxY4S G2L1sm8AtqjwwrBAGBZL9oEAIhs+6Ia1ZPnmwHQSG1hLziyphwl6LdxCI+mXeHCRxueRDWo0TVs2 er5IELcX/CZZdPGRhNwmWbRMzpNF9UJH5iZAliTyxYlG0S4HaE10oj+rzXfce3FQNDHUFAlE5GYO JQ8/7tSebz9SYUaxLNeBWbPrfE0CgUPe3l8TEES5jPo0bjfqVqfPnsmPdPVcIb+607BDvKHDnaOt QF3EPITMyjnmnG5lBMqPbsfuxw0V7lTdiC2l/EeRFBeA3Sf9EK2sLVjRCQ7+TYX3U19Q9mRBXsmN nStJAaEvUD30mvBwXlk2eda18GiQkc/xbXkyrXYn5ssMtWxgNHdR0tmHKaPGCwYRah2scTP0Ub7q o/jq692UVscxNWhSzRBlqjuGqSqH2HdRAsAPry7okvYuSvvqIagzedMcKQcttwSxR1YOKIrE1enU K8ktNWlzHaiBdxbjZ3hCYPthZCdBKb8eUDOtUHfxyK6lFoly6LioHlDB9EQJC70Pq5D2UlLuDKdA /RsSQ+EJIWOrE+LxJcJxJCzfciZaho+6RmdDEpTpjYnXwYC54dgNTSNyffPCf4NY1MV/67kxV8/4 /UsxF1uQsgzxnRDggzU5w0cPmZNQ6GVXZHXeloFExG+n2YPAnpLqsqJH5uSFK6Rs3ctIQeIgWZ4x y9auLs2yH0WMqnsx7pLcjlPTb4kZ0+82R5uzwQfXo0S1TAuuKMmNLheWHrvHR0FNVWV1V8JEC8qM IBLdm3qRemMRxj2mQfYwdhv0Qeq2h5mtjot7QljkWdM3RtU+2gbZ2UVi+iPq4ixa2gxnzYa6btUb 1bRYZdMUmhP77Bd1oe0SfJEmhuRt0l/xsZvWvzpwXq5rZ2PoVVGu8rbPtZRsCy8mFEuCrBRFmQ1D CRDXTchKGL0mMTLTMn9IxrtWx92LE9EGi4jD2orTVS+KykmoGEBgU2e9TWnKutMpDeFJ8It5hgUp ObYY8qxKUo6hSeHV12WpXqQiynXHeawWIAuGPVn1g+5qQBVWhXZasIcwZSXKifpRWVS6m3GB24nZ E5ruxld/R/QIi0En8vb7Ut8eHf/UZdbUHSDULWLEA+IfdGCaBs5cXb4K28il9pJLgtgdBVkVTWuK AEVdG94fMrBaInmel8lsklYbSCgPZlrg6yWEsyeImHWkys7wu6ACwe4hMivFlKiq9CXaWvGVx1OB B9ceePQKIWqctgFAm2sAa0wVsEgzyYa6u7BJy/pzBf9Y1yXs4lK22EWJ8ic9QUwMPLomTFUAjdcj lUYKl/QLRiM6ExaAey+GiRHf12D2pqCu6qwaSiP4+RaCWZe8Jum5CxxwrQrWOsqyzgDHibWEyURc 7Hma2zotr3BSGk4T0HY7beZC7ogxZ0B0FCKr0Ftc2LrMA6FgZDehI0OslP5PJ5EfpM69odW7sRFQ kv6IieGSnJmpq1IbsVhBoDCC1HzCnuhwj1UcPClh3GxzrkI6AgKP8dDYuVhBZxr4EUIMyXRBJ6lN b1pP1li0k+81TkzAqbtKFk656Nm+I+rebmmrJehha45DwtBvVQ7aKJs1IQqBUt2YbnJLQ17rNA3B NFejg+pp6AWygKez+7qjDCI76hwgAulam7jSYQBEJvVLskcphCoIxfPfdab3JMkGv9uAcy5VZEXR mkF2obtRH8mIWtXkC7cBlRN5cHbOKN7M9xZirtJsmozN/uVgin04lr0qxt73PNJA9qSmR48uc48+ q0N0bLeWX8kW8MG10FFCgPtFCfBvtgKmy1cmUjDLVze6bezibX7lSygzDFnOTLPIKda0x+HlNjGw sSNcEftRaJuGU2hNtCcZMwZ2CYFV7fJqlecniWdkblU1vuDiZCZa1RrqDOve69ntMxMZJ3td2hKs IZmZfdVho2wdZChdAElr5O31tRgO2WK54Z5e6yjHSID7JkM+A8JNLDMRLt5uiT6Zg5MiEdwoqrhF to9qpWK96JjPkcq1wO3IrKhwWMRNKhyc2KN0IxVCcimShJzvt5v7UXp/MgLJ5f32iqrI6bmQCQFZ hau7+96JULvZSlGA/JHkuOZaOZniZ/ACdoEcO/+WA0XqOp/hIQG7+UFqzlOK8SDQKsvxxq2NGTfJ vCkwrpHGhJyLIF0vz2OD5SnAhx/LMu/5OclTMLrEyXsAwErPI0ZqC0KJkgWu8Gm4+rmJOiDZLOGe 0b5o2kUq4CNAnDJ1bJ3TrgYGqu0fCvu0TfHzGFOUwGTpUwAl0hDMHZino3s9AZlIBwZNExEcd4BX sTZrJUeFUKXXIPTZIrdLGhjc2Y33VSTIsdxOu1Omvo7I58VJuFcxKz6tA9RDl/UVqsaTzZETwKeC MR267XcPU8JNWaD3VBaacExkC/88AdnDjKMq0kRPhSwI03xQcOK4KVFlmj27IwjZW90Go9gD++F8 urwa7xmMcEqtQ+zSKqldkJRAhEYgKObRlIuZFKapoQFL8o6E5mXkJJUhZI1Ik0VyhDaZuzc8Eoe0 OA/PPEbOp0PBEdB1gw7ESVkwRbcnc4/qc3ePWrC+l6a+TANntiDrfQkFgYYfZYGDwM5CAhl+W1GM HcVSXstqhAClzqsdYetLxovIOr3ljXcjdPPRFMggtceyDQed6KmRhg4l6r/xzfhNB40oHwj0OKag rG3JXxgINtLvdldwlviq0b3Iq6GIUQLKuB2LJDKRuiKHhEnkboQvg9QCZ6/bJq81B86kyVp0kHot AHL5OU5JQ1AF2vcxLeDwxFdsrCWimGkfeF3wTxMgZgleQOAKN+/yEwkMaQn5Rs5DiETUGSfnOTl+ Y+LVs1FGSnB3JQrn2fFAtzhZ/j7lwBaATrSrAQX0CXzEPT09d2ucX905+VWh85pi0nZG+W0ouqEd 1Mdo/T6YssnqAuNQ/0fFrULxEIcw7CNb/g+TnAPCIE9lqQpScFfPde50bMG9QaXYMjghrbswQKac xDVm5RjIa8VFcnf5Jgl/dASScj71V6JTjfeB39rKyVe+/+SQqTEqiBSg3I8wKhw6arDRinpAOjgH 9tZaaY70c3IIvyVhj1DvEeg5CHRelZRHSQ3SmxP0dhDdINtWevfqACgg4oKVHjon3clPuiDdANd2 icQ3f/9xwZoWVVkEKTfBWr/oa+jh3q5xwNBA1OufgjQ9jjm0lXtmYZ+bBtqe35cF1V9PQqNoss4U YfNRv1WoBxyxQTMvJrS0P+pXD3mxm9LqOEqapzLKUnnU6hr4iV2UALN9HcJ55K17nlGWAK1nFjk+ n/Q1XvHpB524QDs0G3LtDat+7g11Ufbw3ow2MjjRJ/AQ847mdCXB8Xqiaw8nCCj1V1Wl0dugOTWF XmgTN1R46vb6Gj85220kl5FJoYvrOKA3XYXrpZ7uEYUjZRtosy5dUea7iX71zW75RvhDjbttcRB2 IuXfyh8O3Owk+teLx0cxiJ9k4FhrjD/slO5Gu8PP6KBtPCAiRfOIodcVDFjuGwlTfHVbzklbK+qz ozmZ9a2YVZ+Q0y1IoHUt6TvzB/nq1H9Gi83rBNZ0IYtu1HJXa31KBq3AHVK74xp4vccpYpOFPHLJ zSP3Nx0FGZpfdRnGNFZMHHvLz4oWd/udSsAizk+4UAq4qVodxuOHzubZEUcpNEiWqsyNoAIzdOVC 1nLMEweZcOoASVUm4mHwACuwX+e1pNHUdsvAz2WzoceP3uSZ840mCjjINwYk2rmBSrPd+rNMTMBa Fx5FFgN6wTCBe7woI0gkRivofyBlBbL7XMrU62gepkeA9M/Tob7yu1qcNfvv/K5WT/U//UXt/+dx aA9feygpDsJZTxuyrCqnUw1PIIbuO8xxDrBKVR4QRAXQehnA4HeAYt/DZhVWz2b5BCLeaaR7zuyV VWCdydUF/luhoGQMmRxMhjc0DwB3JwSUSp7/B5XTdtINZW5kc3RyZWFtDWVuZG9iag02IDAgb2Jq DTw8L0NvbG9yU3BhY2U8PC9DczEgNyAwIFIvQ3MyIDkgMCBSPj4vRm9udDw8L1RUMy4wIDExIDAg Ui9UVDQuMCAxMiAwIFIvVFQxLjAgOCAwIFIvVFQxLjEgMzEgMCBSL1RUNS4wIDMwIDAgUi9UVDIu MCAxMCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0+Pg1lbmRvYmoNMTEgMCBvYmoNPDwvU3VidHlw ZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciA4MSAwIFIvTGFzdENoYXIgMjEzL1dpZHRoc1syNTAg MCAwIDUwMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMjUwIDAgNTAwIDUwMCA1MDAgNTAw IDUwMCAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMCAwIDAgMCAwIDkyMSA3MjIgNjY3IDY2NyA3MjIg NjExIDU1NiA3MjIgNzIyIDMzMyAzODkgMCA2MTEgODg5IDcyMiA3MjIgNTU2IDAgNjY3IDU1NiA2 MTEgMCA3MjIgOTQ0IDAgMCAwIDMzMyAwIDMzMyAwIDAgMCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMz MyA1MDAgNTAwIDI3OCAyNzggNTAwIDI3OCA3NzggNTAwIDUwMCA1MDAgNTAwIDMzMyAzODkgMjc4 IDUwMCA1MDAgNzIyIDUwMCA1MDAgNDQ0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ0NCA0NDQgMCAzMzNdL0Jhc2VGb250L1BPUFhL WStUaW1lc05ld1JvbWFuUFNNVC9GaXJzdENoYXIgMzIvRW5jb2RpbmcvTWFjUm9tYW5FbmNvZGlu Zy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMTIgMCBvYmoNPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVz Y3JpcHRvciA5NSAwIFIvTGFzdENoYXIgMTE5L1dpZHRoc1syNTAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjExIDAgMCAw IDAgMCAwIDAgMCAwIDAgODMzIDY2NyAwIDYxMSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDUwMCA1MDAgNDQ0IDUwMCA0NDQgMjc4IDAgMCAyNzggMCA0NDQgMjc4IDcyMiA1MDAgNTAw IDAgMCAzODkgMzg5IDI3OCA1MDAgMCA2NjddL0Jhc2VGb250L01MSlRQQytUaW1lc05ld1JvbWFu UFMtSXRhbGljTVQvRmlyc3RDaGFyIDMyL0VuY29kaW5nL01hY1JvbWFuRW5jb2RpbmcvVHlwZS9G b250Pj4NZW5kb2JqDTggMCBvYmoNPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciA4 NyAwIFIvTGFzdENoYXIgMTIxL1dpZHRoc1syNTAgMCAwIDUwMCAwIDAgMCAwIDMzMyAzMzMgMCAw IDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgNTAwIDAgNTAwIDAgNTAwIDAgMjc4IDAg MCAwIDAgMCAwIDcyMiAwIDY2NyAwIDYxMSA1NTYgNzIyIDAgMzMzIDAgMCA2MTEgODg5IDAgNzIy IDAgMCA2NjcgNTU2IDAgNzIyIDAgOTQ0IDAgMCAwIDAgMCAwIDAgMCAwIDQ0NCA1MDAgNDQ0IDUw MCA0NDQgMzMzIDUwMCA1MDAgMjc4IDAgMCAyNzggNzc4IDUwMCA1MDAgNTAwIDUwMCAzMzMgMzg5 IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAwXS9CYXNlRm9udC9DWkxWTUUrVGltZXMtUm9tYW4vRmly c3RDaGFyIDMyL0VuY29kaW5nL01hY1JvbWFuRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTMx IDAgb2JqDTw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgOTAgMCBSL0xhc3RDaGFy IDMzL1dpZHRoc1syNTBdL0Jhc2VGb250L0RKUVZCRytUaW1lcy1Sb21hbi9GaXJzdENoYXIgMzMv VG9Vbmljb2RlIDkxIDAgUi9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMzAgMCBvYmoNPDwvU3VidHlwZS9U cnVlVHlwZS9Gb250RGVzY3JpcHRvciA5OCAwIFIvTGFzdENoYXIgMzIvV2lkdGhzWzI3OF0vQmFz ZUZvbnQvVUhGUVNPK0FyaWFsTVQvRmlyc3RDaGFyIDMyL0VuY29kaW5nL01hY1JvbWFuRW5jb2Rp bmcvVHlwZS9Gb250Pj4NZW5kb2JqDTEwIDAgb2JqDTw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERl c2NyaXB0b3IgODQgMCBSL0xhc3RDaGFyIDExNy9XaWR0aHNbMjc4IDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMjc4IDI3OCA1NTYgNTU2IDU1NiAwIDAgMCA1NTYgMCA1NTYgMCAzMzMgMCAwIDAg MCAwIDAgNzIyIDcyMiAwIDAgNjY3IDAgNzc4IDAgMjc4IDAgMCAwIDgzMyA3MjIgMCAwIDAgMCAw IDAgMCAwIDk0NCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYgNjExIDU1NiA2MTEgNTU2IDAgNjExIDYx MSAyNzggMCA1NTYgMjc4IDAgNjExIDYxMSA2MTEgMCAzODkgNTU2IDMzMyA2MTFdL0Jhc2VGb250 L05KU0dNUCtBcmlhbC1Cb2xkTVQvRmlyc3RDaGFyIDMyL0VuY29kaW5nL01hY1JvbWFuRW5jb2Rp bmcvVHlwZS9Gb250Pj4NZW5kb2JqDTg0IDAgb2JqDTw8L1N0ZW1WIDE0NS9Gb250TmFtZS9OSlNH TVArQXJpYWwtQm9sZE1UL0ZvbnRGaWxlMiA4NSAwIFIvRmxhZ3MgMzIvTWF4V2lkdGggMjAwMC9E ZXNjZW50IC0yMTIvRm9udEJCb3hbLTYyOCAtMzc2IDIwMDAgMTAxMV0vQXNjZW50IDkwNS9DYXBI ZWlnaHQgNzE2L1hIZWlnaHQgNTE5L1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgMC9M ZWFkaW5nIDMzL0F2Z1dpZHRoIDQ3OS9TdGVtSCAxMjE+Pg1lbmRvYmoNODUgMCBvYmoNPDwvTGVu Z3RoIDEzODY4L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDE5MTYwPj5zdHJlYW0NCngBnXsJ fFRF1m9V3a1v793pPUt3p5NOSBOydQiBSG4giUAEgiym0UjYBFwTZXEZJeOGgEvcNxyio+CAMzQd xYRljMu4fvOBo6PobHwzOKgjT74ZRh0l3e9ft4PizHzv/d67Sd1T26nl1KlT55y6vfrKNcuJmfQS gWhLL1vcTfQn1AvwytK1q0N6kuSMJURZeFH3isuy6cBthEiXrLj0mouy6fDthJTuXbl88bJsmpwC HL8SGdk0jQMWrbxs9dXZdPAk4O2XXrF0tDzcjPS0yxZfPdo/+S3SocsXX7Y8W39GErC0+4qrVo+m pwGu7L5y+Wh92kGI41e8TGLZGoRYCaGIR8hfSQO5i8iEETupIPMJkb9mLxEJaV4usbtufCl0YJGt 4e8Gv0FHfuJPDfk88rLYfc/XX58asRODG3VVvT4vAJ4yOT2LTLWTr7/++lp7tidecvqJ7J7X22QR niG7ENAx3iGEfgQQWnhmQLFUa4OATpcOU55Y9VBmWHgmNbFGzy+/r7p3v7CTLCI1yN6Zms+zdw5o zbz6zoGaSVlYUaXDlCFbrLiqg00BoFUgMGIbjc0GvAthK8ILCDIGtJP8ASGDIAhPC0+kWoNo+Ck0 ZGtyCU9hihreBxEyCAJG/xTm8hT5fDRHxKh+PKCaefc/1rFyhR8Dy4a3HaEXYRfCQQSJXIH3VoQM goDYEyh7gjDhCeHxlD1obzIKPyLrEZjwCLFRSoJo/aEBu06bhwdsOdVak124n7QjMJIUZpJhBIZm 7wba3YSheluqvEonYduA0VptR/3NGPRmDGQzuuzHm+ppDTFef/NAjocP/qaUzaHjXZeqjGcjA3Zf dTuocDWhwnLhcrBQULgBsABwKWA+4BJhGbHo49QGbPbqXvTXiOqNgpuMQXGT4CHVgM1CgOTq1dak rNl+1qRKy6ox46mCT69iEywkjqoGQUlVB0P7BE0n/m0DqomP77aU3V19QLhFUIgLtXpRyxu0HRCM WGOjPpN5A6qluq/JLMzDNOeBLEGMkYLK/K0Jl6fQUJNDaBHyiAdllwj5xA3YKhTocLvwOGlF+rGB aF5weJ9wr451D28U3U/OstbkAYu1erhJFSajNCnciQW4U++8byA6oZo0RYVSUonAQOP1iK1HzC5s QmwTVm0TVmoTVmoTBrUJ3EeEjSjZiDoVwrWkW1hH+hC2Is7Zyp0CQflmcKeKSquHBL/gA2Hs+0BK itzAgGrlI/OlnDl6Nd+A2VrdeEC4isxGYJjy6gGvr/qKfUKZPpWxA75cjtCdArseELzZpUFLHr4k B4Q8EIITJl8oSLmDyaYg0pyRg4SyN9khTiT2Dvs1X252EGkO3xqFvxyF/5mFmWF2KLsp2K84PNKU xz5CY4vY78hWxBjbx14mlWjgQzbIV599wIZII+BhpJcBDgHWAO5NhV8PDrLBAQCM/dGUxcMny15O xSpGI8Hi0Yg3dzTi9FQ3FbOX2IskD028D1gE+CIbJoWALwD6AIfZavI64HOslkwCfHYUvsL2cxZn z7M9ZALgQMrKh5BMKRzsSskc/CxFsqn2iuB+9jO2kwRQ9aepaACFTw9Ei4K2fWiPsqfY6lR+0Nlk ZI/TDnoSlfrJYQ6Jkz2RquON9KX2h4JDrI/1ab46rVgr17YJlcWV5ZXbhFBxqDxUF9oWarKzOyFA tjLsX7YZ7zoSYuAeBA2hj21MiXXJphHMic+LkV68+/VYF97deozgbddjvPSEHmtkt5DZCAxt3ICw HqEX4YdExPtahOsQfoBwvZ6zGrE1COsgTbqB0Q2MbmB06xjdwOgGRjcwunUM3nM3MLp1jC5gdAGj CxhdOkYXMLqA0QWMLh2Dj7cLGF06Rjsw2oHRDox2HaMdGO3AaAdGu47RDox2YLTrGBowNGBowNB0 DA0YGjA0YGg6hgYMDRiajlEJjEpgVAKjUseoBEYlMCqBUaljVAKjEhiVOkYIGCFghIAR0jFCwAgB IwSMkI4RAkYIGCEdww4MOzDswLDrGHZg2IFhB4Zdx7ADww4Mu45xBBhHgHEEGEd0jCPAOAKMI8A4 omMcAcYRYBxh63YLh5p+AZRDQDkElEM6yiGgHALKIaAc0lEOAeUQUA6NTp0TgjPMMHCHgTsM3GEd dxi4w8AdBu6wjjuMmsPAHdZxk8BIAiMJjKSOkQRGEhhJYCR1jCQwksBI6hj9wOgHRj8w+nWMfmD0 A6MfGP06Rj8w+oHRr2P0AaMPGH3A6NMx+oDRB4w+YPTpGH3A6ANGn47x/7w07Ie0w4CzlvXSMTpc Tz7T4Q3ksA6vJ7t1+AOyTYfXkRt1eC2p0+E6EtUhllqHq0nQQFPBOluTByJgNsIihCsQtiLsQngB QdFjBxH7A0KG1WqFok2ZrWxVdikvKNIu5YjCbPJseau8S35BlnbJR2QWasplFl2OQrSQu4BHyXq8 P0fAIYJ3ox5rZHH0G4ecrcVfnMU1x/HQ52X0YBl9oYzuKqN3ldEmlZ1NRV3ShUgdAwFoh2aOTg4e RqiLlkyGZLpzz2feYCo6PjhI92fBGC2G5GcIuxG2IdyIUIdQjVCOUIwQRKiLlgGtQyscbXI/YAlC GCGEUEc8HqiJTodBG2IWum3gFxai8n5KSoG3L1VSCTCYKpkN8HyqZEmwSaV7SAnXiuhz2FQ7AXel gkdR/NMseCYV3IfU06lgHKAzVTIO4PxUyS+DTRY6nwRFjjpvFM7FgvP0uangAlSbkwqOAYilSqK8 dhk6KkbpGGjURwER17GLsj1FUsFJqF2YCtbz2gZSwheeyqRcH56EOE8LAxjQ50O0Q6SaKXg8eG/w M4z3LyAs2OOD0KAIcLB4kC7QjMH95T9C5aZgqsnI6+N82D0Kkxw+F9xWvDH4KNqixXuCDwfHBe8s HzQg+w6Me6PeRSp4Y2iQ7dRygr3ByuDq8qPBq4IzgouD5wY7i5GfCl4Q3M+HSRK0g+3cE2xHg9Mx i+JU8OxijAVDbA1eE9SCJcH60H5OXzKBdw1OLt/PKUCqs72PBX3LitF7Kji/bpA6tDLlhNKnnK9M USYpEaVQKVDyFZfBabAbrAazwWgwGGSDaGAGYnANZo5oMW4nuGTdXJBFnhD1uB02CwUf8zdh1MDI DJLMEdpY29wptC05vJS0LQklv5gbGaTGOQuTUmQKTTrbSNu8KckJsbZBJXNusi7WllTaz+/YTemd CeQm2W2DlMzrGKQZnnVLbtI5FYXkljtyhwil/lvuSCSIz7O20dfonOyob23+N68uPbOrOfbd4zsz mp98oG1uR3JHfiJZzSOZ/ERb8odzQxd0DDEbs7Q0DzErB4mOIbGb2VrO5flid3MC1Y7q1cDNVlQj JRygmmEKCfFqkCdTeDWsUbZeFOioF+YA9YwWEtXrRY0WvZ5Ieb3dh0MtzbtDeKFOMSGH9TqHi8kZ dcAxwG3eHcULtSIh2sFr0Y5ISB/YGL2hYBBVyvFCFQp9T28oSPXOkhXfVSkerVL7bZVavS8hOx69 Gf5CM67S03VcpajzHSH//2LLp8ToQNWaG15uWR5p6Yq0LEfoSm5eu9KX7F0SCu2+YQ0vCCWFaNeS pSs5XLw8uSayvDl5Q6Q5tLtKx/un4pd5cVWkeTd5uWVex+6XteXNqSqtqiWyuDkx0NjQ0fS9vjZ+ 21dHw7/pq4E31sH7atTx/qmvJl7cyPtq4n018b4atUa9r5ZVnO/bO3YbyJTEVKwrhwPMZAQPd+WG E1M89u7JnKGHJoV9N+TuFQl9mphiiaQ5MiVpQeBF5U3lTbwI+4wXWZFtGy3y3TApnLuXPj1aZEe2 IzKFnF4IwvHbkrVz2pLhuQs7OKskNZDg363ZVfzRi32kZVUz/pFerYfVV60+3SKHhNf812f1v3vW rFlz1Wq81sSuIqQtWTa3LTl+DkaiKOiqqzmBvHGn8wRBz9utqi2DmWEUxjAIupp3x2MxGgMFNSOR icL65X6FcSti9UAgv/qKA9Ab1iPAHGbrUnAl8KJ1A4XFsJZQpaI2C2Gu8nQqEK5GDwN1QOWwOAs1 RzkifcV95X11/cX95f11Mkr3bENmcBs/SlMV2wSyOnbVaWIgujoBYmNYvL/HU3n5esf9PBKLJWJX UZ1ep+t/B/V8JL8jLOaoP1fpzXN66xTGm0dBdF6K9cj2voan+JON6Ligs46EXNTKpvQs/vruQQqu or0kTw/bSZ4YhY1FMkdPh/SqzFFexiH7FJIcHiQeRp8UeYa8T0tpiAzQr4mXfEX9tIpMB3d+CXti Fxkh98O8n0ceoE5SBGt0PplORdSJkdvpo5m1mU/IWeQe8kTmeXpjZgfK7yKvkq8wgt/jxKwjs1B/ PllOPhE+IonMI8RANhATmUTOpR6ymLyHv79jHPeS+8jP6Q8yX6FXF7kR7TWQJtKUeTFzipSR28U+ 6bD6HLmb7KNyZmlmFTSkQrKJxTLvZf5AoiRBfkyewZhidFicRsLkEnILeYj6hVcRu588SdLUzDqF qdIL6Gk6WUAuJ+vIJrKDvEmdtF06LJ3IXJc5Bi7MIaUY0yryCa2lM9lTojkzOfMhOZ8MkdcxX/43 LJ4vbpfOTzdmHsu8BOv7eWqk++mLUrV058gPM49nfgZ/ZZRUgSKz0M8SchN5kbxB/pv8la3PrCfT yFz0/AuaT0M0Coq/x/zsBnaD8A4Zh9l2YrRryFaSJCmyl+wjB0Cb35Aj5CPqorl0Bl1C76Z/ZWa2 jB0UHhWeFd4VqfgT0DtCikGj1eQpsof8B/klOUgltF9J2+nF9Ar6IH2MHmFJ9hn7UjSIN4nfiCNS NH0k/U1mVubvsLkD5BxyLVkP2v6YDJBnyX+SX8Mr+TfyBbXTCXQlfZwm6RH6GVNZIZvNutkDsJ5/ KswS7hZeFGvFKeIl4i/FD6Vbpc3KYiV9alv63vRP029nns+8Dd6xov0oHDiryA/BFU+RF8g7aP0D 8jvyR84/aH8SXUgvRC9X0dvoffSn9Bf0bfopZgmNA3+FbBJrRq9XsCtBpxvZvew+9H6QezrgpPgd +wv7uyAJhcJ4oUd4XEgKg8Ih4c+iXYyK48Qqcba4UMxgZaqls6W50tPSTukl6YTcIC+Tu+WPlRuV mw3/MVI28vs0Sa9MJ9MD4F0DOOlaUOJHBE5A0GIfeRMU/U+M+Ag5iVUI0DAtwbjraSttozPpefQC upzeSDfQe+hD9FH6BP0ZZoA5MAVjj7EmNpctZsvZzWwDuwO+jGfZXvYGew8OleMYuVeICDGhSpgu LBTOFy7HHFbDlXczKHu3sEM4KLwjHBM+Fo5j1bxigbhGvFZ8WNwuPiu+LZ0jXYa/J6QXpGHpbemU dEpmckDOkyvki+Wn5T8qsjJeaVc2Ku8qfzN00zxahpGHwPvfPsyPPVjAdjCXuJ4eR3Y+rA4bZh7D OszFrvgbaRTSWBcrL8fY3Mwv5nB0WROTUARX032klv6CrJeZAMVQPEJS9LfsiPgyO4v8mnZRv7hd uFx6k4XJTkijPraf7aNTyLOsgS1gWwRCP8Kp+BH4/WpyH72EXkV20uN0Ir2e1tH15F3mEebSm0lD 5gkmUpVOpycIRkB+KC4jF347hX8bofXwzn+S/pFoEX8A+TRIHsCKPkP+QH9CvqZS5jNINwHSaDGk zO3g91sIl3qd2GfrsR/9kCCXygfJs1SGD71OnixeS06Qf5BPpL3gqCmQpsfSq8QfiX/K1GXKscOw y8jT2HcrydnYMR+BSw4gzVMXYKcbIUvgfCTtZCGcZ9dD6t2dSWa2ZG7KXJO5grwF3K/pWPo17ceO GARGA/xer2OXfEA3Yx+e/W+n93/NTC8jw+RT6qPFtBr74bi0VuqTdkjPSj+XfilXgdo3k0fB0X8E Nxsxg6XkbfIp+ZIasDZ+MpbEMd4JGHsHuZQlhANkKg2QbuzZUsjxKaMzuQqt3AjqbcF+PoC9cQJy 4gLyc/jPGPViRkvRvwHttIHOi8hVZBtW8CY6gJxlkNpl5C+Yt5VOgHtgLNHQ0gOQWsMY02/Jn0Ht jD6usZALzXQB2vqSnEeWoYfxpJ3uxgrsIfWQrM3Cf4DeRdROptBC+iTwurBDrXB+10t/ooyMTc/K TGCrhAM4YzLI78fplUvOoj0YhQ3zGCFuOpvUps/FGN6hgpikv9JH8TBbntkgrEtfSt4iP8GaaOJa pZkQrWme1jj5rIZJE+sn1NXGa6qrKivGlY+NlY0pLYkWF0UKw6FgQX5ebsDv83rcrhynw26zWswm o2pQZEkUGCVjWyKtXaFktCspRiPTppXzdGQxMhafkdGVDCGr9ft1kiGOtxhF36upoeZF/1RTy9bU vq1J7aEG0lA+NtQSCSV/2RwJDdKFc2BNJO9ojiRCyeN6fKYe79PjFsTDYSCEWnwrm0NJ2hVqSbau Xbmppau5fCzdbTJOjUxdbiwfS3YbTYiaEEt6I927qXcy1SPM2zJxNyMGC6aYDESaW5L+CFDRjFDc snhZsn1OR0tzbjicKB+bpFOXRpYkCdd+Y3oVMlXvJilPTSp6N6FV0G6TZHNo99jhTbcP2smSrph5 WWTZ4gs6ksJitNGSdMTQb3PSe+1R33dJNA49ecOZpbnCphbfqhCvvGnThlByeE7HGbi5Yd5CIoE2 gMuKW7s2taLr27FSbdykSrJbEh1Jegu6hLFQrM8qO7+sJVPcdXEoqUamRFZuurgLSxPYlCTnXhNO BQLaUOYICbSENs3riISTjbmRxOLmvN0usuncawb8Wsj//ZLysbvtjixhd1ttoxGz5czIchA9W6bH 9Oo81nbut5SlfIyR6dDHk6GlIYykI4I5TeCv5RPIpqUTsAB4EhRYyWVYkVVJdWrXJvtEno8p0qRU bI+ENv2dgAMixz/7fs7i0Ry52P53wgs5n3zLakm6+HQ8GYsly8o4iyhTsaYY42Q9XVs+du0gGx/p tsM3Mh6GIGkHbRcnJlaA/OEwX+DNgxpZgkSyd05HNh0iS3JTRKuAvcS6eAkWMFvins9Lek+XfIve FQEnP8v9FsSdNES//bfZPTktKycmqef/ULw8W942N9IG6ybUsqlrlGvb5n0vlS3nBAXdUDYaS+ZM 7RByGfJ4jOUKeimY8oKF31ZBosOcFIvxL/NBY3cIYEo9g4Zak/auadl3whgOj26Zf8UZVAxnIA1m TnAsHXyHNjqL5MTY6Dizo05O+l76e6MzbxLa5kHisLZ5CzdtMn6vrBWybNOm1kiodVPXpsWDmd4l kZA9smmIbWfbN3W3QAplF3Qws3dzbrL19gSmspJOBNsyMmV3hN42Z7dGb4P5OgQXU+i2eR0pRtnU rimJRDmUcHib6qFh1JN7WX1mRLyKLEB4AqEG4TyEuWwHeUN6DTbPa+QBaQG5X64nS1D/dnkHuRt5 Dyl3EAX1pot/IhsA5wPOA2zS4Z/IPbxtpDfq8E/kbuSfi7AZl4+8fiXaDyJ9BxiH6uxDoNXLOCEw Wmj1nKH+p4dBvxCJhNrZRwHgF/fqaDoLjNC++GNGsCDgcwD9seErgH9+HP+cgbQTlooL1gf31Xqh Y/sB+V0ugdWVj1OWwC8Ygh1UiBi+dcDffNKL83kq87CksF54Rlwl5Us/kIPyUuUOw+3qT43PmqpN h8zTLLOsDdb9Novtx7YP7LPsrzqaHXtyEjmfuDrh+0NTEv4wQ4VMeZbRtKwMskYth0hiWiBGRUxT 4jfIUpoJ+2mUqDAcfMQXs3/RMNIwy36yYeZIA2lE3H4Kr6rKsCPsKMYLnkZyKiQMn9Ik8g0JicOc 6vfi9Qz1o68izc0mECOL2vRJVaK2X1yx1hdDk50zR0jjzONVlTVo615uoKWPATEzkjnGJknvAHuC lg+X4nQmuBjj5zDGSf/CApLwF7Ry76V6KzOPz7J/MfM4xtbYsEEaF7ve/kpVpUJrqEAveSd9t1/6 7GsXGJIsyBwTrdIwVitE7tXarjbeZtxOdyg71O3W59XXVcMCR8KTCCwIrnCs9KwMrAga6lm9PF4d b5nOpsstaqtlu/oWe0N+RX3F8gH7jfyu+q7FYfeFfMwHp4RW7PTEfdsMlqCtwsZsGlK2bUTKPzwb Vl6g0HXY5A+/89J34+3hAz4e6+GhqpJ2ks5OWu31OOyKHCkkDnvdeG+hrMgOu8dTUz2+brzDHo2y 6l9ffVfful+/l/4a75p2T358dk0WSMMPPZtelO7a8wDU7W30R3se+KRp3mVpPC9C+7kUvMNebMK6 PIHlj4IGKlmgqZew63DtKTBxkI4ZWCRRaZBd+LxBlSgxq7DUO0Azyjo1i0TEoBgSk6Io+o176Xbo vNnla5jJeUMn/MnO4/VVlaQzHHbISu34oroaIZo+9sjbl1NWeVSM9LVkit64lXNGDawNM0aQTxu1 Rc/59gSGct8UX/Md8h3yHwoYpuZOzZuav8D/qHi/b4e4Lc8gB0KkVK4LTBOn+qb6pwYMRb4if1FA 8ETFBeJtvi25W/K25O/I25FvcJJ8e34ovyp/bf7N+X357+Ub8vm6eFzueD6zm235dqw7C+GGXAMb cS8T1ogMsscHGDXb+IVBJGiuMDMzXzvzthxJPezxQM2kJBC0HbavY/6C0wt4knNcT0PDTDsWcSTW cxTbItbZ0+Bw1lNHTayTu59IfmY45ajnY0jZdKBZ7fWiwV4vGRyAjvqsByixW2ZT53VoJjXXn8ty cyi309AQ/jsTnDPa5nQcILlQQvIQ8jNHJkyYkKA9neAXR3i8sw68URuPRsAsxeOLaqqhv4JtRFkR zadK7P2f/Tw2cXmiY6Uh/bGfGl794KuzZ9akvzjbQ6X0N/dR9Te7G8+bf+Hyi6/L+/jNT3+2dGBJ 08n2KN8r52GvlGGVvPBOHNAmXWxaY9hgeNC/Xdpu+Il1R86QdY/jQM6w42COxS2NdzTbr/U8x35l P+RS9pGDQBep4nPac0OYEF+DAlA0d5vNEgxXhFmY0ze8rVGlmnpIzagCLqhmD+yilA7SsFYYFCtE JvI64ja3RA+TdQWHZ5upOVDsO+z0F51eAn0FZh4/mV2Ak51fdPaM7iYKynECdma3FZWiOnXG11Q7 3S6iby4COlEX31hZ0om29AnjvKmJ6+yrtiS/SX918PfpP9Ky/7X9NyOP3zBn1srueXO6xbkF89r7 R36QPvnuf6VP0ATdSO+ly/ad+mTj/dduvuuW9WCpuZk/i17QzAcvWyW1PFdpyA/Go4OZr7RLEXnN 8VrO+9L7irjGvtZ1s12IkjLzeDLJ3ErOMV8uLjVA6rjXlWwoedDykO9Jy098PwlsK9hesm3sTyqH As8XeNfl3Jpzq2tDifggaPEgmDJv3EOIxVQeLxbGcYI1jps9jo3bi48a8kB0u8cX787rzWP9eTQv T3aW8pVQUa2yVCtlpfCeahanpbFwdiEr5NiFPCcgS8HD6rrY4dk2agtU+w8L64oPe/xV35I9y/pZ wh+PdTaOdMbsjvqKzp7Y8c4YJ30nDzr99RXo6SQ9nbEYjUZr41gCnT09eIuRwhKelXPGMghnxOm0 y5Z+9M7bxy7uunZ9euT91295bO3QotntXYtmzekKrEucd+XqxIrlgnfc411PvvfekxdtLavaf91b 6VU/OLzuNTpn3oWL5s1e1DVy1uobr1+74vo7OUe/AeHzR/gy+Ok3TssVJlBZniAa1V0CY3KUhqRK iUm7DL/cyU+8Tn7MNXwBCd2I0ykHpxM2m+MNfj7BLWnh8NTfsqcV40c0PDl70a6RNg0RJXNYU+vq 43IpXopO9NLauKzhhdRhrT1cgjK8xpAy7LFSY4V5AqmTGs0Xk4vZcuEiaaVhhfFjwTZDpsygUsGo qqKiUhoiCo4xRVZFMSTJLkmSDUYtkD/ZyLswBfLjxmImCLLI73s1q6wwSYQD12D2egOQcotxE4k2 4Fbsxbk4yIo0NajSSrVXZepeVkRE1FBDOAP8pguXnj6c/dhVJzt7fCOzWpY3/xlyHkRpbJh5HEtc AYkX04/bDde/smGcLwag2BsaNrzySlagPavGVUucxLgMa0uacKVQAEV8iAiZdMogGvdm0qDUqd2y CHmWlWhZeRgOC/ij4RxBkF5I/7x3ZM816VfZJFpf9uardGZ6QNp7ahMLjRzheswDoPwSUD4Hkn0s Oaw1riujK61Xl/1Z/EIU1bBblUvHhos9zqB7tptVune5mdvtihQWO3MMIVcxFNXckm65F863ttKS XdhNoCS+jIubB9ntWrhynDaufVzXuO5xveP6xvWPM4TGVWJ7uQpDJJRTmcNyBtnmgfKquaePwhEc B509X8RwsuMw1DUlri3pm0M/ENyZ3lR+vRudpAIc9O7O4WdAApVOy6xvaWXjVzLGECQ9NIOccHUB 43KdbxwZ4l0K45iprhvPxVdJNCI4wqOJaOQBNuNnOzcsvGLRrX2dj6+dkf4obaGlL/207Jzz2maM fXsHdfbHpszVrnlT2pt/wcOLVjwTK9m/ftmBHouBia+mfyqp553dPF+VRobSV6vmzllTLijjZ/b9 OLNPgM4m0qedZZBExVAsO4MSrZR2YdNIqiAWQ8EwqsUmAo9Jm8CmQUOmpkDIUmnRLIJFVENg30rs Qk4z85k0m2WH6G6YebLhZFa5/D7JJNAqv14CrUAyDr4jmSCB23TN0Q0lVA/3i42nPmFHRkJCjbT3 q/S+L9M9X2L0SzLHpAPQJkPgkNYJBW0FC5S1hrXmWww3m2/x3pyryl451+l15pY6Sn2lgdICwzTT +eI8daHpYvE68Vrf6sAe6x77a5ZX7e/bj9mtQp4c4tqDFgzU4ys+gplTT165rDo1qzPubJudQ3M0 ty+eM0hLtTJPuQ3eUhryL0J2iXMBC4ZCAguECishdf0l/UZqMwaNlUbBCJ4bCN+wNctN4CFOGK5y 208e79H3GzSNk7HOo7HG42CphpGeGFc3uMpFoQrUQu2CSC1itXGoBDUhHET6see2O7n6WCs0shs6 01uf+3N6xzPDQ3f8ijpozdj0h8GdvS999PH+zn1TWe6XI4MLN75IV7zzEV22aPpHb9Zdev0Xf01/ k/5menwv5omvsOmz4AGBXDFEsC4D1fE4VmR4IFKsQ63R5Y0TSZPapV7piCQFpS6pWzohib0S1z4F YmDCB5TgduQIEYbh8mOcIw4hJZLLxarTE79y1MxoxNrSzp4rsUG4cXA7LZX2ft2KcdwNH7Yf4zAz n2YyCVFD1CSIAhXAHJqaNzFuDE2cFFfxScTAKNSezBuHXLxk1WD8k/qZEbLBaMxheaJdDRojbKwY UiuMK9hKcbl6sXEdu1p8Ut1hfE7da/xC/dro2Sr2qVuNr6pvGN9nh8X31A+Mx9jH4kfqp0bLOvVq 403sdvEm9XZjH1M6TMvZxeIKdaVxLbtGVJpZm9isthnPM5yndhgVn7HCGmcTxbg6ydhoVQRmFmVV NbpZQPSqyqgWGGQiBL5kVpRq2WquhpCzC8zQbrDETfylz9JqssQNmrUkbuIvZG3R7DxiMgiwxShT jDBZIasbwSDeUS2zk1Yct78Lwe2th0Y2SStHLyHRoKrVgugSBBEX4MZqgSHK0IxgFhkzG3HyKIag lVoHqWWAe0L3wpLjS39+Z3bJvXPnxaVqRVPWG6jhwHqswgFTyGRmg2yC5sRaa6hINFQi1UEuXtGM pWoNDtiTUNZi9ob/ZW8I+O0jPSM9DQGfHQcKMuxHezB4QIwfo+UG3XcnzOhpkjMXB4khc2S3KcSP DujCeHRewa1sTycYhlIIBQeuexx3033wSSt0f/p4+nfpP6V/jwPEJ3z8dat44zc38ACeegjnSAQ8 pdL/1KyqIBv8gtcgOsGxoC4ZcJoaAfVpc6iVYUZCtWJwKYpBMDCmCCroBVoJIp+xyGcsVssHdYtq s+bXTO2mLpPQbeo1sX7TsImFTJUm0BlcqjfKoWadOzeuVutichibjAtKI6cVN5OxJ3DY4njBJLm0 5CkQqVE/N+qJs75+wzh+eoJQWT7ix+wRTQVXGEJZHhl+HqexQdOPZH7oVFXiOwbU6t1jqjX0mmr1 iZ0VGBc3zMVLEjxCtaAJYqtwi6HP0G9IGY4K8ivCQcOHBiEkVBjiwiTDbMM9wlZDv7DLkBReMJiy qk5NbZxpeCF1RLNUVMdZiL8UVy1yHtTU8Lg4m4eXXru1IIQUXgamKD4meJWxrESZxGqUWUxTLmAL FNXFcpWZrEV5RNmpvIUvmj9mx5R/MFMJK1VmKFcrtynPMJnLCS4osg8s6SwrJIjOCeADsMFDNMQ6 aE76/ZHdYIBy4Z2vW4X9p3A5QKG3EWUzlyg0ozljQkwOmWpMIpGpSQtMjOOLg94BQBDoW5jy12LN jmkq17r8eEFzyKYIT0EsHtESsM7FEF4KNrlsDhC3OoYUq8onxmPmL9V/GL80S69JbxhfM39I3oVM ec/8KflIVXeKP5Z2Gp8y7xMHpH3G58yvi+o4sVCqMIbMj4r3So8a7zcbRvUrA7Va+OcQA9YwHxx0 e0QgEsJ8yFsGstJii+bmsmMZT5lkHEUKBISqywdIiO/kA1dA6nOffckkSqHBTOWADPEwmKnWLhCI OUSgIofwdRm+vzPKklRtMrpMuByRFSVkUF0GgyqazOZRQYJOBDOcTaJZkIwmRcVXaooiQRVlOAR0 kUIMVqikFZAYg7RSM4bkA6YDWgWX4EiaQ1xFZdRvOa2FBvwzRzoDvpGRgH+k03daEc3KB/7mf/ro MQFHfT3exMHFxswz5caogjoKwCe6Zc2FxijPcNDTydVOyIwcQJijy9NP0IrfUTOc4/S/aFl6S/rV 9G/TvwP7OITPT+HYggyZ9s0gtJrpmY9xYz0ZtnI17dFWKgFDnpTvCczInZY3vfg39j841PH+Vv95 0Yv8K6K3Ru/x3xvYBrfHa4HXc82ybHF7ZL+nRB7jTvjXsVvZNvk5+VXZ/EL8AzvLL6qucoy1FGmx cfEirbAUL39+/IqiU0WsqFV3b1RabfGz8in3fSTz/5Ev5uePpTVEQy73tzEyP6zlORrDWq4dL18g HsbXNs+JitliHMt5B2U6RLEOUWMsamiay1RQFTWMUUstiaB5q5lBfmcgwjUrfCOB2XEa78LOubMS ZKoZE17kpX/w0tneRd4rvILXX7OqaVSNuRK6cM/xTq7LwD/CU0e5vwjCPwbxBTEWO9kZOwprAguR ZetURT7tSRw/LcaKMsPP5+bH5xUtK2KdsUQnMMCpghW6H1cQYF129tCS8dyy9LhhP3rDUIhLZPjQ uHEJ3wju+7j5D2NPkd3cvtQdJnR5Jvarg/sH24Tc4vSnJrsiTHuy88kDCx695xfntF/RNo9eOP7T orqO5nNaauwm9sdxj9yX2Ph8evD2W87Jq/MbWltTty28oy2vOJQ3p2VS+lfOal9Jw6QF1dG6ouUg +QZww32QJzZ4cx8bIk44AKpM9XW5Z+cy5wJ5gXGBZ4EvkfelIteKkyyTcmpzW8Q2S1tOS+59ysOq 0WwF+5MA/yhKUlx8LXJMJhsxesOGQHcBLbCPYUIU7qoxmpl2k170589vzNK7B6bZSMOfZ9l7Rt2h sF65HgULnHZOhYvpIvki40Wei3yr8qROSEddswLpcN8Jv0i0xJ3j8oJCo06RDdR/Y+qldHpk6Pzd mjM+/ZrOm25esfxWae/IifvSx9L/SJ9If3h+Ygsre2p299adex5/jMvS+Zh7I3aCn/yXNqfDlnAm PCttq5yrPNf7rvE/yB40v2p/1fe+/T3fJ/Inhk9yPnF/JedMyJngnuGc4Wn1JcyrzMpEZ52nzies k9bZNki32jb6n3Zu9ww593hUK+dYX26cw+ecrri1xsJz/AVxHdoccctefAdhBM2cDhPRUJVoqEdq +sCneyG+RBSFvArluTRMKiw8YgnPho4TyFXCLn+gI0tK3afcOfN47OTxGFe8oXfHuP4dA+Q6dw9Y b9SzpHPV+DqJMx0ct9y3JFal/2JdOnvV9esvab/ITV2xk7/8JP0X6jn+0kfss+q58+7ecWDL+VdU /PwlfLUAVxkt3s49FPNAu8WjfNOnlTsTcsKYcGa55SGwxleq2l3QW8AmCnHzRHfcP0NoNs9wN/sf VlXOJynJxLlGs5oUqw1LYfSOsVqicKqN0Ww2EriL807Y4M/vaNA3J59hDywMzjG6LpH1dcCc6OG8 YlklrzKucma5Re7ErXLt6ARhUHhxop7JKuLi9DdNuxc+D2vhpdSN1D/irGi+dvFtN69YtmHL+Ql8 coOzivrvY/ZT3TvOufypJ59/fCvm24T5loBXXCSP/niI2LFPWk31D6uPWB6wPy1tN+5T91kGAwaD i05jZ8utxtkFT1v2yHsCrxlfN79nPGz+SvnSYsmz5bk1SAi3ZnXEbe4X3AfdAjexB2wFjTq0egHZ HZrZZnW2W7uszOpzUlTY48+N0xqn7gjOD8ERDJzCMVkYK89CX54ONRvEaT9IiusdRhY5nSDzgGhy +ji5i0wKCdMKd5aJKgoWFVxRsLVALLCFDZrFFgfBR6VhLGvTgam40/I4XAKay6eVuhp9WoENL4hg H5fVEHGxROOI7jJwYlCo4eSDQyUdoh6HqdNV4aDhKPo3j/jCYjgF9ycv93KQHFCNk/VkU7hR/2Qx cZRLUO6i1lxWDVSy8k6tvHurBmLpnzUmdPcOdCocrTW6IQZpQTmLh+C14zxOhLB+M5HDzUxF9rKv qW/8J7vSf7llFXW9c5w65RFNuHHxlIUlwtULLmhooPTcikcef+7u34EXYunX0geu3zyNXnrt+qlT r9J5Pz1H7NJP0Ao6S1uyLn9DPnOaLd1Vt1p6q8QQjbCIUElrWI2g4RZsqnC+LeFKFC8YsyCWqLjE 9pXjqxznJEuNZ1Jpzdg2S7OnrbR57AnziNd4J84sk9liKjNbSqwer7vcYvZ6RF8R54DndA7QF97q 0Ik0YDJnYWlZlgFg2+rlVfEsI6juXP3gW4SrktWpoK2EA6uxnDOCya34/HLZGFM04OObTvX7A4G7 qmgVtuAgPpKtKQo7/ZXf7j7uSOX7z37cPnKUb0AurEdOjuqxp88/rOcAGFtfQdUcB2cc5V5WrC1X 2HhQDPbTIr5H37e2Va5VxSvGXBRbVYF9Szq9kodLdf3cq4WMGl1AL1wGLiuLhHBQnumEvYY2GfJL F1xeV5xjuWH4veuXUPrCL3qpMrl7313pv/7x1E1dK+68beXym1pLJrgLwp6qyIWPPvPcXb+mJhr4 6f2nzt6/9+KGoTut7KafPPb4j57qfwy75h54jxKQax6S0mI2GsTnd1hI+xQ6xfF7+g+qKpJHKmId jpUOiVKW43I4c3DdR22cqPmCAlvd5TbiqtRkjBpULVQU36XSjEpVkBlar6ewKN7n6/exbt8JH/vc hztLV9TDt75mQ91+Nz3hpm6/tzEr9mAacA8DNBLEvhhN6fKPW5zHQVOvrl4YdP8DpKEDByS8b7Ai 4rpHReZRuvO2A4u3zM5PHwvNOav18pr0MRyLH22d1n3bXSN3s6rtC2ubN9468hkmDYGh34Uiyj3P 64aIipE1OoyNmtqusl41qQ7jGuRzVQqqXep6tR8ZkiAruJQVIMU13UMikE7oBLKEWx0jU3Bm8Nmp 4aK46DeMzkufVVaON4zgKkp3j+keMsjzK2OnXdi4ZOUubHEPFdOnvpkhRr/5ECu0ESu0CCM0kb9x m/B3AxaHbvFq1/vL4wpcEDlyiXqRvMv4gvF19S3jh0bjXKFLYBbFp7bK5xnWytIe9Q/icfGU+HdZ mqXMMlwkXy/eLj4qbpEekR9RHjEYg6JTjokxqUwuU8oMFZY2sU0yQidT8Y2VUTLC5hZNkijzS2qT yaDAH2Y0iYPsMi0gVRjqgwpVlluYKUp7CeVON7+58bpRFZOvph+3cT6IVW4LgAZ8JUe9BwZcBhsa Tu8mIfN6Sg2POqW59k+uhEbJ/Utc4Q9TxbERl9DT6cL0/fSW9Nvpv98EZf8Lujb9g5EL6e82pp9B 19+t5lzdD6aN4WsJrxfrlZL4nvOQ9HnW+bVe6keGlL20hs5G+SbWVw1X1/+yaroye6U+FqzRd74u MQGp6CFbNZ+S481ZaFhpEPGzorghbm82NNs+sUuyvk0cCoxBs8mEY5/RqIfo2wQ36Rjw/7RNjKao GZ6dMSmLBebr6G4x0xOQmN/fLVxC/euGyRIZtyO6xoBr3zO2R9id3TRiIn2saE799NUxMJ20+Z3O R2YHWcEzyye035xKB8Xolmenrrz5Or5HzoUu8AhmaoHm+KA27WN6zPBlzpdu8TX2scScfsmvsoR9 Qc4CT8L3IHtIfsjwoHlQ/TX7jfRb9dfmY9Ix+WOLfbvhLfYf8suGV83SGsNG+WaD4ODi2WjychK5 RMVVrwS6crtxKWkNw1A/Q9XLKsz6ZY+uLHNJqq6yXwT9Z5VPpJ0Qo7QzJ+7EtIh+iVgULT7jsurc TSNb/pvG0298dk/6y0009MDll99//+WXP8AKb6fypvRrn/93+uWbM0//6Omn+7c8/TSf7+b0peKD mK8dNsIj2rgJOdNymDMu1Fvqc+K5zcJ0y/Sc5tx/5KrcXjitA36h/CMXvzWTz7QNPCYTvlU8bRs4 xlittqjdrit9pn+2DmYeb8BC2o/+i33A7xgoPzu4fXCGzsdvHtzctuJqLTcQuNrn+dZA2Ezlmp9d PERZ+tRQx12zscSeOy9acuOtS1fchqVtX5b+fXok/UX6g9b5I58IQwM7HxvY/sRWMOQGQoQ6fe5P a6UPSlS10rnSRdIaSahwdlhXWruduJazmYNmdpc5Y2aN5tm4lB9k67QxigL+FphsLCWqXa1Uu1VR Dax3bnWyRc71zl3OQ07RaSdR7koYo5kYfnzaz30JjsYhmpf9ZAEm0rfs/EWnf+ZR4uOiovE4joN6 fBfKSdGDn8B4cV9Vq9/BVE/A4oO9s5TwKtyalB20n3P01EuauxLnnX3WpHMrxOiDlzTX/n1c0470 f2OOleBnO+ZYxl7ShmWHHDGUeB3eyEPOh1wPltxfpiquVhdz7rMMWV8LfxT5yvJFoTzGMt+y3HK/ 6UHn9sIhs9IU0YqaoysKl0U3ODe4bi28qUiti7bIraYZltm21vCUQqWwqCRaZ64N1xbWRmqLFNko OdSwz1JiLiwsjChFhdrYq8xXu65xrx2zpuw2981lj7jvL3u28NmIpZfe5b3d93DZT8qSY2Vv2KOF I3GPlodfIHroHzzUU2MItxffVcyKNV9+vDjAHQOaF1KufSytHEsrxtKxBeFKO7XX0LCuHdnURh2i SlbGcS+jP3b1IBfRp6Ca6l6A0SNXvx/jDrrjJCuWtVqZUpl6aLRwfLg1PI8mvMvoKu8X8Np6mRgI F7LSHIuZlQYW4Uua1lJTe4AGWnMU3Dzjn6tCp0NnT+4QKcy8NQDtLTyYhYX8IqCgiKePDASLcMkN 6OduELjochG5xELHF7YWPmS5r/CVwncL5XCh2SKKuDHN6oekhmuKA97yRkBdmdbThcVxDrX8ACwE OKw0/FhD7MLV6gkKH5sdqS4Ydhwzx4OalGoz4ZlfJJ7Apw2YgkeD6ump8Wpo16tBQ/dqtXVxL/fy eLXiMXihXZs3qDtURO/8gAYlxxag7YFMgI1Ovoe7TvQHV0I48XE3xKnKLVROkNOeLe7o4nfweDqz 36UUZd7QVJOz0VaKV3gw89keS73ZZa7n0ZS5HhT6dLepXjcD8KOoBORhTjFX9fl3JvCtgOmyN/nZ GybuVYFGzb+bhm4ZraQB5+VLL6srdrmnp585/4YPP/rw3dL0l45FHVdUhvKi9MVEx8nPPxihFbFz 55fmVYTcLkfb5AUPb9p/5+aqyVOCnkiBO++iGW233vOrJHZRMPMxu1t6DGfCL7UxIQIzwDjGNtE6 w5qwKX438QkeN/E6c1zU62Qu6hNUxaiYoXxTzUa8/d6kV+gCGIZPapCKKRjiOAgGiJt/9wY72WzC tU8FIRV0EaQEamilPiHqdc53N7q2una5hC5Xr6vPdch1wiURl90VclW6RLgIru4/7d1qS9ZBTkzS 77VdmeEJiYaZ/Ns4OOztJ/1ctMD9wm/wOnuOQlV31NjwcBlD3RGHS6eplxMNLqtaR6S2prbYwa4d NpXklczwLfnBOdfWm9Qf/pAGxOiR9LwbY3m5H5bVzGmpup8ePPLOk+mNoM8dkDJz8U2Dh2zRvOc5 VjgekARV9ssNrMGBX/g6jjFF16IdoslDjG6XC07bHFfU7SZcQFo9upbgoRns+f+DlqAaOKvryrSB noDf9vvqwZm6QfaI+VYFy2oHnVnXAb4AgaKlTxsX14gKsyYeWHXJjnOoP3hu47Qry6h/6/wlF+54 gPWnfUeWT5q95igdhnqKR//GArZtCXmfJ//liSBHIA5y+rtKP76lzMdXOMX45UMZvgyoJFVkImkm Lfgt09n4fcQM/LrhHPwOYTaZQ87Fb7rm46vQ8/CrCe7BciLwh/+ajMyaMffsme2xpitXLb60fMoV ly6bOQ9F/xu8ClFZDWVuZHN0cmVhbQ1lbmRvYmoNOTggMCBvYmoNPDwvU3RlbVYgOTUvRm9udE5h bWUvVUhGUVNPK0FyaWFsTVQvRm9udEZpbGUyIDk5IDAgUi9GbGFncyAzMi9NYXhXaWR0aCAyMDAw L0Rlc2NlbnQgLTIxMi9Gb250QkJveFstNjY1IC0zMjUgMjAwMCAxMDA2XS9Bc2NlbnQgOTA1L0Nh cEhlaWdodCA3MTYvWEhlaWdodCA1MTkvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAw L0xlYWRpbmcgMzMvQXZnV2lkdGggNDQxL1N0ZW1IIDg0Pj4NZW5kb2JqDTk5IDAgb2JqDTw8L0xl bmd0aCA0NDc2L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDY2NTI+PnN0cmVhbQ0KeAGFWQl4 FFW2Pvfe6iUb6QTI2klX06SRdGIkwAQSJuksHXAiQiBoNxNMB4gEBIkkLCpCM4pAszk8hxFccBkV 9SmVTmQ6gEMUdUYU4Smj4wqi89T5BkG/Tx231PtvdYPg+M2rm/+cc885dzt16tatTteSpW2UTCES 5J2zqLWDjCt7LljOnGVdaqyekkVkbrq2Y96iWH3wQiLTZ/MW3nhtrJ69Hrywva1VtpPX98Av2qEw asTGgA9vX9S1IlbPbga3Llw8J27PDqFuXtS6Ij4+vYu6en3rojZwXNlGvWNxZ1e83gt+SceStrg/ 8xMl/YloHOY5/iRRhUo0iIjBi9MXNIHuJQskG5XQVURKu5JHJtSl3cS3bvti01ctqRO+tOZaoSB6 8MMRhZIfUjru+HbPD/NsZE1GNcHwlwa0s1QOXEm1Nvp2z7c32WIjScu5i/dRk7ikx53lOHZAjKST ABcjI548R58YIfIiFQ5vVLh60oeWplYXCxU9lhhUBV0M7AEOAgq1iHxYbaCrgRCwBzgIHAPMRKDS qgKLgV3AScAs8oQ9ojps1SNENtpmY72pIpPOADogyAFaAkwBWoCtwC7AbPhJzWJgNXAQOAuYySsy I9tGY+6ZkY0G61mwsNSotsaqzbOMas/VgRif3BjjdZfH3MpjbqPGxNSX1sT4iKIYTy8oDaHznsSU 0v7qDJGBRWZg4h2gjD9PqYyRg+4XQ0kDuMBUDY1XpPcMd5fuOigUYoILRnPJofcLFklJK61O5Do/ Q+nk4J/x0zELP90zKK10V/Wv+CnaAxwEBD+F8gH/gFbzkzLmoFXALuAgcBQ4A5j5SZQTKO/z9ymV v0clQBXQAuwCDgJnAAt/D9TG35UZY1ApVwGcvwtq4+9gWe+ApvK3Ib3N39b7+euRsvGlfYbgKYkL joK4kJkbF9IzSqP8tcg3I5FRbtxpZNR+MYwqabQYFikY5YiKrMiE+Y4o/7BH9Tjur76MHycN4JjJ cYx8nFRgKhAEOgAzpDcgvUEh4A7gfkADkGWgNkDlh4FXgDfoMsALTAWs/FgEw0T50Yi7xlGdwV/l f6ZMRPwI/4vBX+EvGvxl/oLBXwLPh/0wfzGS76DqJNgJbWzgNvAS2E382Z7h6Q69Oo0fRAQdoCVA FTAFaAG2AmZ+kA+LzHWko5P9dBjPsINH6FODP0IPWsm7wOF11yIBVUnc5b+EBLJL3eXmXvf2HahK 4t6yDZIk7ts2QZLEfdMaSJK4Fy6DJIl77gJIkrhntkCSxD2lCRJIlN/3x+EjHGVTrmNqdSpfjigt R5SWI0rLSeHLZaFvFDnHuyOFhYjYTq9nZKEjtI+FDrDQNBZ6kIXaWGgVC61hoQksdA0LeVjIzkL5 LORlof1sHEIRYt7ei6rjvVksdJiFnmShThZys1ABCw1nIZWVeaPcGbkcTx2Yz2A91fKh486eX1Zi 90nlTkTUiZx3Yk84CHoU0I2aF07qsJhzdr7kw3oKq2L1S8tLF1dP4ofQ8BBuwyE6ASi4QYeQRofQ ySF0lwpaBbQA/cAZQAfM8B6GdWw1aCpoCVAFtACrgTOA2ZjOGUyF02JQOcU9xsRKQKuAKbLGD6EM Q3FypzfPZrd5bJPEVjtLzWdT8vV8XkYZGdiX09OsaVGWsvfrlH99nUIJ1Ql8C99KebgRd8T51sg3 eY4ouyvi3u+oHsp+T/kKso6NJzcrAB9HnUZ9LNmtUj+G7PwJ8NKI/So0S424ixz72CDZaq/jG/tH jk/tUQ7xE/t+x5tqVGERx1+heWKv47h9g+OlkqgVmgPuKAPbpxquffZxjicPG65rYNgZcaySbK/j FvtEx3V2w9AWM1zTiZo31THNPdMxCf3V2Wc7vJ3oc6+jyn6NY0LMa6xss9dxGabgiYmFmOxIuzGo K9/ocEZZlLV7iyzbLX7LFMsvLKWWIovT4rDkWXItQ6zpVpt1kDXZmmi1Ws1WxcqtZB0S1U96PfKt N8RsvPzMSGhGiiHbsMMwuc2AEmdWTr8ibbBo4A3Ta1iD1j+HGmar2lfTXVGW2DhTM7lqmJbeQA1N Ndo4T0PUok/TyjwNmmXqr/3djG0JQKvx9VFGTf4o06Vqba6WXuvvI8bS1m7OlfyStZsDAcrKWFaV VZVemTa+vu5nSNBQBus8P15ZP4qeLE+etr1hul97PC+glUpBzws0aP81XW3297Ev2FlfXR/7XLKA v09Usi9806ReVNYFAg1RdpXhRyr7HH7IGDD4WfFiln6kWvNjfjtjfgVoD7/hksEvIYEKDL+ChATD T2HSr7tzuK+uezgIfDJV6jR8OjPVC30OF8CnAAQ+GSE6bPgczghJH63S6MZuh0s+CFxYDtkNFzvL MVyMmXcbLiVxlw3nXTYYI4nYbAwfSdBNyslzPikn4XNBIP+z2Fbj8bCeisCcZl+byxd0+dqAoLZx WXuWFpqtqt1zAtKgasIdnD2nXfLWNi3gaqvT5rjq1O4Ko91PzM3SXOGq66ZmX5O/u9nbVhep8Fb4 XK11gZ6JU8eUXTTWhvNjjZn6M2NNlZ2NkWNNNNr9ZKwyaZ4oxyqTY5XJsSZ6JxpjkZHjU/3dVqoJ 1OL+Sd7DkxKRr8FcZ6Amw9ZRaSRvhTNrVe4+nFZ2U5InoCW7arQUQOZ1cXVxtTThmZKmQVCnxk1Z qyqcufvY7rjJBnWaq4Y8XUs7l1KWb35d7K8TF1RdS+WtiFGP1P3sBRef5m2tk2frBq1weoNW1TjT 322xQBusC0BXfk6XlOSL6v0x5aVQlktHIc47St0EqUtIiDv+ey4Yc4Ia0enDQWN/D/Pmsy7qDAgt v6GJYytomokwNM/078NZSr4kOgNYYCfzsM5zvcl1GDLFNIRld55D19K4FI9FV5wbrp0e8nSeC8m5 7jwyWAYxYtXlwdZm2kfZQI7pUcpW3ITvCv1j4BPJB+brn0i75Pwf2OiicRDtpifZfHqSDtJz7Cxa 7aE+6iV5BKqje2gl3Unr8FqbCc0GmoZigv5Olq334svkAbwwH6Aj8L2aVtE+ymBZ+qe0mtaK19Fq LaXQMKqmqbSYNrMr9KXUTCeUW6mMrqDrqYOFdL++Rd+m/4Eepj7xF/0HSqIcmoNyRP/M9Df9XSpG i9/RDjrBtiU8TV6MEoLnvbSEdopZCtPn6d9iBk5ajjkoNJmOsH7uQe9t9DHLYitFLXp5SNf05+Fl p1nUTjtpHxvLJnKnqVmfrB+hDIyxAr3uoAjtRYnSM/Q2Szad1f+gn6VsKqLLsZ5eepX1i4Ef1gxU IW4mRGkkjYdlMf2J/kzHmIs9yxebkk2lJq/pJv04DaFRNAOzfRQt/5d9zVehrBYvKvV6DT7y1tJv ZbTpBfqA5bASNoVdxUfyxfw+sYSsGHEUylyaj3jfhd7fRxrt5cn8qHhIeUL5zpw3cFIfhDviprvp XnqWpWClKutkv2FvsA95LW/hd/NT4k7lMeU1SytWfQ0tos30BH3N0tk41sh+zdrZSraO/ZbtYEfY MfYJr+ZN/Dp+RrSLG8QzSg3KdKVTudV0u2mj+ZMB/8DzA/8z8LVeqt9OjciHNZj97+g+rKyPjtJb KCfoFDOxJDYIRWVONoPdjLKKbWYPst3sMdaLUY6xU+xTvJK+ZN9xvGm5mefi8COPQC6+BCfMO/k9 /CjKMf5P/o3IFMOER4wVE0RALMas1ok7UJ4WHyg5ylFFR5xLTdtNu0y7TU+YnjOdNSdbfoN3/Cvf P/RD4Q/vD9DA+oHtA5GBXv0DGop7iLcHPsEmYPatKAtwv7cj4/bQ6ywZscthhaySXYHItLAF7Aa2 ApG8je1kDxtzf4odQJTeZGcw5xRuN+Z8KR/La/gUlGt4G78Bh7FtvJe/wb8VFpEkUsVQUSgmilmi TXSJG8V2oYlXxHvilPhKfI+iK4mKQxmmuBWPMlFpUZYq9ykfKx+bmk0vm/5uTjQvMt9ujpo/x6mm 0jLV0miZZdlq2Ws5bg0iOw/R0/RHZOD5i50Ua4RPPE1b+GglG58wryKfW2iumMyRqXw3W89vYb18 uGmFuYJXsCvprOJGrF/ku/hXvEJMZg1sOi3go2Idmocoj0OaoByi08oBrO1V9LzCnMxW8TPmZIrg jDQeZ6QXxGWKR7xMb4sTzKI8QO8oiSyTneaPiqnIgmeUSpOfnOIeekrcwG6hp7mPKPE76ybk8ZXs cewLTayU/UvoOAZfiSwqEx/SrXQd/xudxnO8nn7P5irzaAuNZivpY3oET8VI0/XmQvNQ9hKfr4T5 YNZLXHkMqxvPhjNhGkK3sVlip/kMf4uW0lElkd4X/43ZH+VPicnKWdM01o4n4Ba6nW7Q19CNJr/y GptHgl1FBcpJ7G4rRaniBF+NXaUZe9pePN37sA9Ui8nQZCFzrkBezMAOsRPlLuwTCjJoPp7xq7GL vUq95iYepXmmQQy7Dn6peXlgGs3UH6Ed+jy6Xt9GxdgP1ukr0eNu+jttpd1s7cDN1IFPybfwbF9h qudHTfV6MQ/zt/h0vv3i+4toF7As+gfKU7gzlab9FFbepOlUpW/S/4rsvgQ77A6ajQPrR1jlZxhh kuin0QNX8m69XnRgvSeoUX9Ud7BEatcX0hQ6QA9bTNRq8eAea+w1rPdmauPT9C7RNjAfcdiKKHgR raXYfzZ4a2c0VXurKn85oaJ8/LiysWNGl466rOTS4iJP4chLRrgLhruGOVVHfp49Nyc7KzNj6JDB 6Wm21EEpyUmJCVaL2aQIzqjI56oPqpo7qClu16RJxbLuaoWi9QJFUFOhqr/YR1Nlu1aYLvL0wvPa n3h6Y57e857Mpk6gCcVFqs+lakfqXGqUzWz0Q95c5wqo2mlDnmzIdxhyCmSnEw1UX1Z7naqxoOrT 6pe1h33BuuIi1p2UWOuqbUssLqLuxCSISZC0TFdHN8usZIbAM33l3ZysKViiluOq82nZLjRFN6LA 1zpXm9ro99XlOp2B4iKN1c5xzdZInpQ8hgvVGsNo5lrNYgyjzscZR6ONandRf3hT1Eazg57kua65 rc1+TbSiD5+W5sG4dVrmTR9l/VhF5ziTrbvQmivCvqz5qnQOh9ep2v2N/gva5jplD4EA+kBbXlAf DNdj6E24Uw3yLK7xtQG/xtZiSBwsC4xVxdYXO/UWBBeoWoKrxtUeXhDErckJazTtRmckJ8fbp5+k HJ8abvK7nFpVrivQWmfvHkLhaTf2ZHvV7IstxUXdtrRYYLsHpcaF5JQLhTYEPWYzJMNdSg3TzkeW yTm6LsdJUFPnqJiJ34U1jZOkbRyF54zDDcAVYGilzcUdma8l1AbDtnKpxxKZZiqwudTwl4QMcJ3+ 58Wa1rjGXGD7kqRR5sn5VNNY6zlZ83i0wkKZIpZa3FPMsdKojy0uWhblLleHDd/P8qOBpiK2rYHy EoTf6ZQ3eGPUS7NR0UKN/lhdpdm5EfKW4GzNg9LSf84ydIa0hM5ZzjcPupDJvfJ7loZqVvf5v1Rb xmBfe7nGMv6DuS1mb5juasDRWPWFg/GsbWi6qBazy4AibrDFJW1wrV/kcuikxHOFYY2dkM+54Ljs T9aUAvyZjaSeG7VYkZWGhqn1mi04KUYDiU5n/Jn5/xpF9bOylcF+bBZfhlbuiU80Nm2t4qL6RdNL DouGJmw5HCf7cDjxIhtSLTbLy+MMGY8Pfadaq9EMPJkF+MMnxziJQK7mRchgacJTZKgDufHqRY65 8UYBXDI7i4vqsWeGw/UutT4cDLdG9dBsl2pzhfv4c/y5cIcPu10scaL6vo25Wv2mACLWzsrxeHCq 6Xax9Y3dXrZ++kx/H37iUNc3+SOc8dpgTUDeFl7b5I+HxbghMvVxD/EPDWSMfMfjYkbyEP7TYgbQ x3kNUgpF/lICYkLB6dpC5ExzphWA4FcV+l4V/d97TfQdqUo/vIwfV8D0ETh7/dzFoRSGgVF6fGSz /IfIjEn1jdOneKqXzG9dOLnp/wD7sNImDWVuZHN0cmVhbQ1lbmRvYmoNOTAgMCBvYmoNPDwvU3Rl bVYgMTAyL0ZvbnROYW1lL0RKUVZCRytUaW1lcy1Sb21hbi9Gb250RmlsZTIgOTMgMCBSL0ZsYWdz IDQvTWF4V2lkdGggMTcyMS9EZXNjZW50IC0yNTAvRm9udEJCb3hbLTIwMyAtNDI4IDE3MDAgMTI3 Ml0vQXNjZW50IDc1MC9DYXBIZWlnaHQgNjc2L1hIZWlnaHQgNDYxL1R5cGUvRm9udERlc2NyaXB0 b3IvSXRhbGljQW5nbGUgMC9TdGVtSCA0ND4+DWVuZG9iag05MSAwIG9iag08PC9MZW5ndGggMjI5 L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQp4AV2QwWrEIBCG7z7FHHcPi8neCiKULQs5dFua 9gGMTrJCozIxh7x9Rxu20IMD/v984+/IS/fSBZ9BvlO0PWYYfXCES1zJIgw4+SDaMzhv836rmp1N EpLhflsyzl0YIyglAOQHI0umDQ7PLg54LNobOSQfJjh8Xfqq9GtK3zhjyNAIrcHhyONeTbqZGUFW 9NQ59n3eTkz9dXxuCYETMdH+RrLR4ZKMRTJhQqGaRqvrVQsM7p+1A8No74aEOream5sn4GJKcRXa 7YKXbz5i2ZWIE9Vd1LAlhA/4WFeKqTxazw/ijHCDDWVuZHN0cmVhbQ1lbmRvYmoNOTMgMCBvYmoN PDwvTGVuZ3RoIDMwODYvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgNDc3Nj4+c3RyZWFtDQp4 Ab1YCXAUVRr+X/dcCTRJECWEhO6xSUzITCYHBCIhdMJMJIlILmBGLJghGUgiMWBiFljBeIAwyMKK Amq8z13XpTMEaoJXVnG1FEvLLVbX2zUe5VHrrqK7Aun9Xk+MQlFb1tbW9l/9/vt4/3vdr2e6rrwq TGOph0TSmtpDa8i8Uo4CpTV1dylx3pFOZJmycs2q9jg/tpTIunXV6vUr43zKV8CrW8Kh5jhPJ4GL WyCI82w68NSW9q51cT7lCLBjdUfTiD7lU/C29tC6kfz0NnjlilB7OG4//gbgqWs6OrtG+MuAs9dc GR6xZ364P0s0K5Wo5H2i2QrROCIGK4HWko32UAKoZMBsIvunsLVAy/W4Er7ac2B5UulxluIw+fvn LDXxCzvfnTEcPLlbuj3Rxc1+sOfYRsMQSc8NB4eD0u2jGtMPgxCjgtwYXZCrJSW80siSGtncV3PY 3Y1MK5fYCZjnm6NijsnmSOyENoaRwnbZ2S4b+6p8ocBr/JsgYhwUeLU6M0gH9bTgwHrtB7UflEB3 C/zm1DUC4ebYQTtB7wTdI1iBHWSnDkg6IOmApAMSCy0HV4sMy8GJtBAcz7rQ5PLBzQWXb3IeZPOA 85icLDiizKEdZh+xBaz+YJL8zNpx8hOshi2gFSSzguiWhfJT7CFSSGI7zfE6bZwivatIbyrSTkW6 RpGeYtupFurV5si0cbXSG7XSvFppbq10Ya30OJtN2VCL2oRs6clsKZYtPZwtXZ0tdWdL7mx491E1 1A+b4y2aUi19Vy29UC3tq5Y2V0sbqqWV1ZKzWlqRLk1NlyanSzG26VDSzUm7kigBZP8u6eZdkB0/ UOCRy2Ps64NFcq6rWI6xbdFGF9D10cZH5fJz2bWUY2GYUQ/loAEyu5q8Jl7P8k28juWb+l9EPTlw 64yW3QW0Nlo2hHZcTnmmsi1aNATprGjjMrk8gRWNxCwkr4PHdEfLdkM9Lep6WS5PYRdQHsuEeCoV mWqViswo549gW7QxC+bWfhRq5MQYi8rDW2MCOySf8NTL3+bFLJAcz4s5gD7IiQmPRuV3PEDaRPkt zzL5L2XV8hFEeLZxSH7as1o+7DIdfuN9gmehR1g+u10bIz/o2S0/4Nkm31dmqu8pMuPtaTTRrTkQ HpK3IUxnXowtjspXFvEMY+TLEbHNVSM3QXy7liTnuWbKDZ7H5TrPlfLCeKYqrxlxvuewOa2vNak8 Qy73ZMhzyl6WZ3sxk6hcwt2j8vR48sI8c3oFZRfLuZie5ZA8rbFAPh8pmeaWF62yL7cvss+0z7Dn 27PsmfYp9gz7BMd4R7JjnGOsI9HhcNgcFgf2rWNCzHhfy+Uvhgm2ZI5sFj5aTDoZTwfDM8RHEphD wNaKMWOzznac1z03de74spSSSu9ZhqApDHpzz3Zl6HtqGvz6bzMCeiEnjIxAjT6jQbnMP8A+YR/5 vAPsY44C4J3sE1+9KXd6A4HUGv3iWn+MfexrjUHRGtI1rvwYAl0LwaBGX2zGoRyIvAPUyBHiCMWU w+NgyxabZtviZh5EgZmXI242RB7TzCMMmWYvc7O+rTk+b18OBphY82irabLVmsdN0PB45flw9fZ5 MMAqUWf5Zt35iboZKMMMVFQEkzIMAX9fYREM+ooKTbXnR7Urrq6Pq+tN9dIf1Xlx9T1x9T1Qn63F /40sXPHzvA4svePaXl9Y9QVVXxh3UN/e3ZKq96xQlL5r7+AKRRezgiuaWjgOhfU71LBXv1b1Kn1L Tb8z1L1cvVT19lGvr9Hf16uFvdGl2lKfigU9sGXHWt9pubaN5lq74yy5dvBga3muLabfGbl8XL2F 5/LxXD6ea4u2xczFZ+9rbajoPMvVddVVyzo7l5G1iwRrDWXgThX30jlExoe4v8T92XAFvgCgG37S +LM4Bc9MP7+F4bmllEXptJH24TzZSO/SDJqI9/iHrAx8P71K79HFdCkdwbP1KLuIInQJlVA7m0NT 2WtUTD66i56Cx3rqgG0l/Zqc8DpsPANZMT1KMfoW53AGzSE/otxEtxlH6B76lI4b9xqfURFthsUx 46/koR5oBUqjTMRsozXMLXQZN1IZ8u2jw/QuO88oo3NpOpWSl1ZRC7XTFXQDdE/SMXqdpWM2bspH nkpaQttpN+0lnf7IZPZLdqclwWgx2mgxKmiD382Yzav0Cf2dpbCn2fNGutFvGMit0iyqMPW9dCfd S/fxmdDzgCH6kjWwJaIqTjcko9A4AfskdE2jGroMHu10NWayj56jlwDvIWs2K2aL2BrWwyLseaFC PMdit15iXIcqHej3HMBC1N+JSnfRrejhI/QY4Fn6EzqfwFShXOgRvhFTRM1SZ+02rjH2G08Zr2BF rPhMKkHWGqxKF62jrbQN87mZDtEz9AbW6is6xewsmU1EDf3sHfa5QEKKkINoL4odYkTcbyFLr+Ud a5n1xuGHhoeMVcatxkvGPzF7Ad8bmVj5mYBZyDGX6qiBAtSMXl9u7o/baD/10QB6d4zepHfoFA2z KZjnTFbBLmUb2P3sCDvKvhMEIVmQkTNHuFG4GzAoHBWOiWlihpgtFojLxD3i3eIjlt3WZuta6y3W Ptvn9q3DTcPNw93DVw8/YdQYe43fGYOoxolq+JrOpyrMto4asYIraYPZ6wjfS6jnAB0EHEJVj9MT dBS1fUDfYM+dRB8SzD6kohP5rISVsjLUOY95WRU+exayRqzPEuZnIdbGNrJN7AbWC7iT3Yt59AMG 2OPsJfYqex0wxL4AfCdYBbuQKqhClqAJNYAlgJDQJLQIrUK7sAPwkLBf6BdiIollYqUYAujioHhM fF18T/yXJc3SZfml5Q+Wo5Y3LUOWf1i+tSZb862LrIttqbYSW7ftAdsB++X2x+xvUhQ9/j3m9NOr idYLe4TvaZNwEZ6zF3DmvSjMx0psZAfYA+jUg9SL52M6vsXfxs7UqACQCLgOPZwGIO2CrMyp6vlO RZ6SkT45bVLqxPPOnXDO+JTkpHHS2DGJCQ67zWoR8Znk8qmVQUXPCuqWLHX+fDfn1RAEoZ8IgroC UeXpNrrC/UJQnWapwXLlGZZa3FIbtWTJSimVul2KT1X0l72qEmOX1vlB7/CqAUX/0qQXmPQuk5ZA O51wUHypLV5FZ0HFp1d2t0R8Qa/bxQY0dC/R7cLmQDfG8MA6zQttxHFA87iFT09TvT59kgoaOjHT F2rWa+v8Pu9kpzPgdulsXpO6Qie1Qk/KHXHnfnhtZ9b7kdvtasXJrtP2sc1q8/aYRiuCnApd5tfF UEAXgjxHSq4+UfXqEzd8lPoj+wPlu+knSl3IrAyFI5W6FtyOpnM2yLnQTeBq+CmrC5sDfp1tRnG8 CLP2+CziB1tmsE3RE9QKtSXSFkTPqd4fTdPSzBNEp1p/dJI2yWTcroHUTbOdaMqAu9xdzvFsZ+qm OP7k+rj8tUGOUzcdeR+4pn60L4znVqtQpq40mUlU1DqLD+FZFGmahfbhCjDMslVPmBeMJF+I9dCt mcmqEjmOn0VB9csvTpeERiS2zOTjxJV8OUd3hI7HNL478BvNVROjhFp/H2O/CvDvvRh5MwZwyojL l7ljlM23Q6sX3mByXBBMc4Ka5lIqUXUlXzclokSqmiNKpdKCBbdkmhiKcCTgwXQa/K0YG/1OXQtM HiXDgcCFiJPL48AF5pEAIrSNRAA2RZ5TMHK5avjRXuuv8+s93sm65g2gJdhig7V+fRC7KxCAFeY4 UinwxtbUkZrzULN7GvSeeBR8g/YgRCAS4TEb/KpTH4xEJkf4MxHnY4zOFGgjghhxE75VYqynFr5A qnMyF6hO1YmyAl6kysf2+mF58Uv4P3e4cLRueBah2kKzw9P/Rx2e8XM6XPyzOjxztNLTOjwLNc/k HS75/3X4wp902Po8OQW8m3D98J/GWPxBMRa8c1SC/2MAeMlDRta9+HYTcSbO6xdYldWGn3BaOlns VSIlWi1VoiikJdjsVYwmORI+d1bWp+bmXvJN6YJTpZckf1u6IPlUKc0tPVWa/A2GgvyiFGfKBbid 1u7Yie+tNd8fjIlvncw0c2HA12KYRv7HMdkfB150vHBG4/mvLlw2UOStrltccVFuY2t7uNNd39Ee uuLfIjrWvw1lbmRzdHJlYW0NZW5kb2JqDTg3IDAgb2JqDTw8L1N0ZW1WIDEwMi9Gb250TmFtZS9D WkxWTUUrVGltZXMtUm9tYW4vRm9udEZpbGUyIDg4IDAgUi9GbGFncyAzMi9NYXhXaWR0aCAxNzIx L0Rlc2NlbnQgLTI1MC9Gb250QkJveFstMjAzIC00MjggMTcwMCAxMjcyXS9Bc2NlbnQgNzUwL0Nh cEhlaWdodCA2NzYvWEhlaWdodCA0NjEvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAw L1N0ZW1IIDQ0Pj4NZW5kb2JqDTg4IDAgb2JqDTw8L0xlbmd0aCAxNTMxMy9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoMSAyMDM4ND4+c3RyZWFtDQp4Ab28B5xU5bk4/L6nzDnTz/Te+07dnZ2dna1n K0tf+i6wyFKUIiLFBVQQNQqiRqLBgkYgsZewVBcrV0FNJAlJsATRmIjGq3LNTZAUmNn/855ZUHPz fd/9fb/v983seesp73nepz/P7OqV1yxEKrQR0Uicv6z/aiR99PdDdWz+wGpvuc87EWLcl199xbJy X9WAELv5iivXXV7uG44jVO9dtLB/QbmPLkBdswgGyn1cDXVw0bLVa8t93RGoT1y5fP7IvIFcd+Wy /rUjz0enoO+9qn/ZwvL5E6+HOnj18lWry/0Jf4b6jqtXLhw5H/cgJHuNzLFU+QyENAhhaOfQCiRD 9yI5opAA33qEuM/gXAZmyTx85H++d99l2oavsY6X+j9pnCXVb971Ya4098I96u2KBDnt4vmklqES DKmPluaW5qq3X5qRroMiN4Qq40MoEhe18l9NxdqpuPl4DO+YisUWNT4Pp2ek0iuVglQifF5UYuTF Wzm8VYb/3DKRImv8iqKhPEyR1Q7iYTQIrVcoHvZrN7R2Q4tCOyhykNYN8Po3QO8G6N0F7bugvZFi oeYRh5bDyHIYWQ4jy2GEQZdBrxuecBn0aDQReuSpE6VeBnrN0MtIvTQ8LQ29tNTzUPxezIvP40/w eDz5gNbz6gqN50U8Fo9H85AHV+69daLnZfwY8iI1vksqbxI1XvWHXvVJr/our/oGr/plfDvqhukr pRKLmm71e93qtm51c7e6rlv9Aq5HUZimRWNU/VJUPRRVPx5VXx9VD0TVyShcvQeNgenHpfKHoneM +m9j1G+OUd8/Rn3LGPW1Y9SXj1H7xqjnOdVBp9rhVA/hDQe1d2u3apEcmvu3qu/eCmNf76tMe1qG 8F8PZD3xRI1nCN+2d2oCqpv3Tn3a02LCN6IYg+GNNqIYAMCDr0ftUr0OZ6R6Lc5I82v2pmNw2aq9 TQ9DtWJv02kAx1KUkiaX7M2ehtHavVPneFrkODtyzyrUzpN7Jvc23QPTFXsTv/C06HAEpXAIhoMo K00HUFa6i3+klu2dGobT2f2w0OHYEMZ7PaXNQxQ+6Dmfnuw5lxpiYOTr1BAP1R9iQ9TTez0fpKES LZ7303M8v2sa4zkCd3ht6mnPK+krPc8npAuebH+RPAU9gTN4u6j0PJq+x/NI+jbPj5uk6Z1Z6X73 TpWqbTEYPOi5DW6zKjWEp+/1rMySJyg9S+GOSxJjPfNheLuo9aQSec+U9AueSemVnonlJ41ul+7Y lX5eeq2/iuoWl6cl7fI0Nv3CU98Ob7LXUyCX7/VUlx9elZJer7JpnCcOr8cc9FRMrfT44ZFYTHqm XcFdxk3j8lyOy3BhLsS5ORdn5PW8wGt4Fa/geV7GMzzgLW8cGv5IjBPGYJQJpJIxpGSktgDUgYGG SIkozFOAWkN4+JZBfKd5oNnarG/SFTrb/00xVxqc2x7/dx/X4L1jp/QMPuXqHawijWFX79jB3BTv 7J5D+E/4k472Q/hTUvVC34f/1DFZGve19/Zaxw6O6+4Zwp92LB6CicX9gyKZ/BQGBsV+OGHs4HTp PigGQ+2H0FRSwX2oGhQj9wGUrZFOu618WhruAqe1k4qcdhqlpdPS1GnptF+Q0/ZsjnW074lBAaew KbRZOmUzmyKnAMDLK8/Ape170lDAWYpBnJHWnVEMSjdySTfKZuGUJih6e/ZUZeGEPdkqaTr9zXSi PD25PD1Zmp71zXSqPL2zPL0Tpv8diP/fjC1s/d9dtW/Wgzc+1LEw0DE30LEQjrmDtw8ssg5unOf1 7rnxQTLhHaTDc+fNX0Tq/oWDDwYWtg/eGGj37pklXfcv0w+R6VmB9j3ooY6pPXseEhe2750lzuoI wIbuu/XOFR3fedZtl5614s5/86w7yc1WkGfdKl33L8/qINO3kmd1kGd1kGfdKt4qPYu8fcfiKa2r /s1n9TXXzFm1ag5iVyOKHYtccFjp+5ABoeGP4TgDx+elVpC1MFd6afgd2g00s58cVKm5AYWRE61H 94M8WY8+BPlrAT7+MW6C/n50HP0ejUMz0RGgrafxKLQFTUAFtAw3oiD+DapBHehh9DJcsQ4th3M7 0Q+QD656fvhVGKtBT6MhdA7ksAs1oh64yx3ogeEjaCf6DH09vGv4c5RFt8AZbw//EaXRRpilkB2F 4J5L0NU4Sa0e3oSa4Hn3o+fRh9g83IRMqBo1oHZ0BVqElqGr0Pdg7iX0NnoXO+FtkigDz+lEM9Dt 6B50HxpEr2MPvg7/iJEPLxpegqbDCpbAdXfD2xxHf0L/jXX4FfzGsHN4//AwPDuAalGrNP8Q+hHa hX5M3gS9Ad/T6AyegmfQAbp6WD1cNXweztcC1EQ0Fs2GK5ah6+FN7kdH0Vvw/T08NYpr8DR8Nd6I t+A3qFbawHDshOGbYJU8wLsRvhNh/atgpVvRNoDhE+hZ+L6GfguQl+MA1UJtpM7SOlpkJrEDwzcM 7x5+efhXsCMsqEkFeOpY2JXVaC3ajG6D97kbHUSvovdgr/6MipjDArbAGvbjD/AXFKJ0VAzu9nN6 Ob2F3s0g5iHmA7aJ3VR6rHR6+IrhbcNvDf8d3p4CfSMEO5+Hby08oxlNQlNQL1oAsF4q4ccDaDfa gw4B7N5GJ9EHqIhK2A3vmceteCa+Fv8EH8HH8N8oihIoDzwzRm2idsD3MHWMepu20y46SlfSc+h7 6R30E8w97AJ2BftDdo/sC25zaX5pQWmgdH3pxeGxw/cNPzN8GFbjg9WQPe1Co+FtJ6GpsIOXo2sl WG8huATr2YcOwPcgrOoF9CI6Bmv7AzoLOHcB4CCX4GAFSGRwATfgJlhnG27Ho0HtmYinwv7MwD24 Hy/B6/EG/D38EHx/hHfBe+yH7yH8An4LH8fvwvc0/hK+f6NYiqOsVIAKUyI1Fr4z4NtPzacWUYup ZdSd8H2M2k3tp4ZoRDfRnXQ/fAfpw/Tb9Lv07+l/MHZmNXMd8x/MMeYkc5r5C3OOFdgMO42dLrPK CrIB2SOyfdxS7lnuJNoLMP4pvNO3P/PROupe6p9oAzUK6OxNkHk/p7pgJ9bjffgRgNSj6CGgj2rQ xU8BZoqoEr4K+N4EMKyALxIj4VAw4Pd5PW6X02G3WS1mk9Gg1wlajVqlVMh5TsYyNKhJiY5A51zv YHjuIBMOdHUlST/QDwP93xqYO+iFoc7vnjPoJdf1w9R3zhThzMv/5UyxfKZ46UwseBtQQzLh7Qh4 B3/RHvAO4ZmTeqB9Z3ug1zt4RmqPl9pbpbYa2j4fXODtsC5q9w7iud6Owc6BRVs65rYnE/iQCNBT JBOAHAANJbnxIGrrXw/iALWRMzoG7YH2jkFbANowR4c6+hcMdk/q6Wh3+Hy9ycQgbpsfmDeIAq2D 2vjI5eQ6YNuhyT3w7GRiMUj2QXS7akFgwe1DIpo3l7T6Z/cM0v29g9Rc8gxdfNASaB+0XPuJ9Zvu xVbHHd+aHKRCnf0Lt3QOinNvB6CT7lzS678DemOJlB2kbuntGcS3wOLIIqS1l9+iLNhCc5d4B+WB 1sCiLUvmAszR5J69dtEuSZBB1N2z1ybapE4ycci6od4HQDmUbEm2kLreZ91Qrv90c3n8N4dJbd1w 5COox06+BBdMnh0YDcsc9M6XHhKAtdaSYmEt2jK/FsAHn14Mb7l4UN42d4tQB/sxyIaEgHfL12AW zQ2c+fK7I/0jI7KQ8DUik2Q7L2HEIJBpGTvARkuMHULy7p49GH+/l+h7Q6jddQikDH3ZnOQQihJ0 WNwOV0MnloCBCh+0KhLeTlh1J9k37xbvltELtng7vYtgw5mQVMPEwi29aXidKT2LoZza4xsUex2X mgt7e+vgPnFyH7gETt/SC3dYMnIHqKWhdBFOSiTGEtHe3TOpZ3Bju2NQbO8FkACKHe7uGTwM2NXb C2fBO46sFOr1i60ja07BmpMVMJ8u3wV00I1wi94tW8g9p/QEfIOHt2xxbCE0Ue4PYfSvA+LIwBAi pxBUGcIbu+FaqAI+BxkI+AI+WFZvOzwqA+h1cXvBEv6/h3DVpXXDlVlYbZUE4er/jyCc+99AuOZ/ BeH8pZV+B8K1sOY8gXDh/z8I130LwuwbyEcBbwJbBlFPoTlw1ED/Xai7oT5FFRADc3o4PoajEY5e OCxwdMKxDOYfhXu42elgYX4M46uQBfqVcL2P9DmX1G+EeTI3Deac3J1ITt+JxsL1HNRpqCuhjsI1 UWjXwKGH+0bhCMkKcB8kHdVQy+Eg95bTLrQI5m3kXDhCcN8KqANwEP3ron9GBc6Wl6HvBX0LLDP4 kJctf2jppUEVhXM40IXkIJ+U4M9SwzQ4gECrQuDz+fZHBx09HAZkBP0PIbM0aUFWqG1S244cUJMV uKT+dws32Mhe0CX8oN8FQcMJS9MR0C1iIBPjKAGSMwX6ZwakZRVopMTzBfCA7y+xGS/AT+E38V8o L/UwdYHewjiZ61mG/UxWwcm47Xwrf1y+QX5cUaM4oZyrcqsV6q2aY9r9Qo1wRLdFX6F/2HCTMWzc ajxletO80vy5Zbt1gvW47SFbyX6/I+pUOf/s2gqw8QE47gPdnAaItO2n8GhWBia66EQMN5pGCpYZ TdOUXS7jRmNk4+Vf+DonW+PxCWcbxhcbJgjnGsYLxQbU3FBsEM5CUZnJ6ny6CBw+dmDo/D/Zsf88 MES/fyEEbyXtA11kR8OzPOhlsW+6E/MYCwajhdGqMbIzGhVFOxilXMa6GYVLwdLIaGKZlNtht5hZ 0XOYVyg1WkpGYYOe5VJylVrQsbzM5bRZFTaNVat0uhSi4rDWbNLrNM/jPyMt/mqvzuckTRf+6qCH 5xiPz5s+1nDkxBHhwpfCCThI037MzgkN5Atv0tDQbGkoWhpIS7CfsksdjhUsDZf+8Io+bAjQvqwh kM8asrR0cAE6C0cAJuCg6me/N7v07MnLTgrvD1w38N7qdWtOGk7OPml+d/X1a6C3+l38d9xTegLP HIOfLU0hx5jSY2PLLfwswQKM5pTuoZazi5AOdYhOlZqh1bzKwDAqNa1TGwwWi535Kd+ls+kNQ1i5 z3dzeWPGF89O6FjY/ilqbtYXClinL0CFfib8rDKjN9TkLTJOphMsegsXjlC6Occ3/tSwq2NdatJH 9uvuOkPPwdyueb6N635b2lW68GTpvXt89c9gF7impPXUwHpGwXqMaIzolVNYK3Ay+KOVWk4rE3Qy gxnWZOxS/lRrM5mlNY2fLiHL+LPF767JUkCCtCTUhyjAZhkXqcnX6IQIFcmbLXodNWrC2Infm1Fv 2D5qQ92kE/aHN/8azy+dG9iwrMvlu+ba9/B87DmI8T2+nr2l/yo9A7B6t3QKnwMN3ABrC7/JYJri aYqWqSmaF+7llCZY2Q4ZlsUNR9Q2o+mIb+3IyorXn1lpHVnc+DOFbBYgJq2uMoP7GFhXE85VhwOc P5yrrslWmU343N1TDXNH6xVtFZ11rc0Lun8ajtZsqNDwXL46Om5+D6ylG3+fGkVpAM+9ogI10tjO At9ih/Bu2CXpuaeFT1F6/JnKjMFn8nXjv5XklGajBONTw5/hV8COU6KwaGArlEo1rJyvoGwq9Wu+ td8vg/MiNMkdmIsLM8oC2N3alk63tmSspGpNp9ukezLDH1Jp2DcaNYlWRNMT9RSFKRocaoimlCOr ex5XIB9+Ys+P4BG2CbBAKxBDcwMG7Nk0PhVfLxwFiGRxAL+1oFR/ObvonwNwbwrph8/Qe9i5wD/d 6G7R/wz+QvWJkT6K3kGfILoS5diCmh7Hy3a6Wc1Os5rarB+i+H1exWb7EMXt8XrSx86eEc6dQc1n muFd2taJtcilCltDxjAfcoaFEBNWWxQ5hExUDnMuaLFaaCltmhzCBijkDlkO0zooiI9CKkgDPjcC laK+oF5XHaECflpmMlrMWT0xOjjK54+EdUK+Jkutv8rX9NRTzT6/OPjxDQubril9dPSGzbOuGw6B uVb51x9gTenzH/7l480ltv6/Xyu+MVg6sO8V3IWp54uEPj8G+IXYOSAVlou2AeOtRipsrDFSquI8 /iM//Y953EcB40fgN75qr2GeEfzIok6toimGN7E8p7LCvlL0EM4cUKnUNov1RbwW4P8o7kMj/BUY 6wheNjQDSo7/+swF/HU8XplB8GJmk85otph8OUBPHeCnX8blQllqHp58dfHYujHWqH1KEC9Xsb2s /Py48RWM0y2rmUk/nKlyCU4w7DD4ABD9FrsApNeQOC6kB8f6VXixgV5A3as9pz1nZFitzGjShoxM nDeCjMBWm0KJlQqaRnbaatPZrEoFZmVG2VINazI+YheRz6GiN+tetL0ArlMQhbC7Lmf62Gnh3FnY XXvjMasd5EPzGUJdZaZEWoQJAG+1A27B3jsZgQ9xathluUKlZLV0DstVsLWMAAUi20t49MWtXZHn JdL0E+7RhAltGinsqwIeR/sa8VVYtnP5bdPS8XjVV7c9+es/lm7Fb82dUGlffuEPFnw9XvDkDx9c kF8p/3Tf29sfKR0vXZfqVZX+E1AaYNM7/N/0ALsE5PI2sWG0bRZHcUFzMMYVuLHcEm4Jv467jn/S 9npQafFZrRZEJ7BfUFstlEFFfR0T/WrfYTmWy9MG4MurRK2DTW+OqYWlbnbpzjAOvwRysBJiETUo Qcn3VGaAAgBIfZ+cKBMB8Ot0X6P9g/UAMKF4EVoFAiu7FXg44EdfjTlbVZOrjkjbPsKgvg0FAIiZ IDrylbnWOwea79ic7/tAbRWonUM/6LtqairniZ6864HHOyKT59YtK71d+vK6+b7QT1e+tHzppNsw Za+797plKyclZnP3H3ziqv5JqUIsv3jXy6UPR1fYMwRGFHjYEP0G4D4F2tMtomctjVm1jJFTtBph vEqvVtNYjVQ0o0AYuPALeDXoFyp83wEFzSpUiiHsFuXoEXmG+YihmCFc85xXJsp2ymjZC5QC9DAV gEarkdCn72xfQ/E0SDNQML5u0JVFGkCpsCkVZ4ArIWhrCVzk2GfI6rKmgC6g8+WoaSUT/qL1sl// ekfxMLO1OIb+3oXrbyk9jafdIq2/c/hz+mV2LbxHCG0VA7O0OMfLFZaQ4DBOXO7Ajk4HJSp8cta/ k1KHNiMLtgDj2h8RPJtZwrkiYdi34vojVtg6aePsjb+wW/WFgbS174xOwvCChNNhb9BkR4wtbDeF cthHe3IogKFlNTty2Mv4c6AXQgHYXeZeN954I5GJAT/SCaEan0WDOfgD4UjwO0y2nANWpicIQL/8 xYuDpd9j6z9xLbv+wKjRG61Nye5JO957rqLziQez7tvvXXMlFkon8Risx/3FEz7LxFFdHy4L672n jtVe8czsmg0/Kb351maynzRaBvDYzM4HuWNFWRwXn9rCbXdtc2/z3Re/N/lAalv2UfeT8ceSj2b/ mlSzSXOSijONTJ2srrKuqk02ytIZ6agcVTWT7mOuZBaz1zGrVAPqa8yrLNdYV4fuYG5nb7HcFzpA H2AOss/5fhc9x3iiTNCao2kFo4jY1LZgA1MXbojMZGfZZtlnZZcwS9gltiX2JVmhnc+GrSyjNUmV Ur/Twyp3JtTapf7nqKUothM8fbAxojJnWuo8yC99JY0hesXtyVXD/vSdIcKFlJJ80Umcx1Lel6qK lMsnGOWAn4okTzYA5IrBbcohnVcLfCelBAlTAYXRpc9hwQcF2aNLm3TjjUCJoAeu6AsCKYYjGmwy gnzJkw5wY+hYmMgl0QwU6YYTZAFCkPmaPDUwsP7V6RPuXLY02HTNmtlr71xV+mNmzPu7d73cX7v+ qXt+d/An/zkpd7N/49xlm26reab7th/TTcnxyy67ZfWUObtGKZrnrv7e0E9XXdOX69jwwg1bjxz4 4Q39zRDUJnT56PBX+Db6WdhHC8qJTqqC53QVFqWNaGYVGmUFy2psVttrvgvLL4qZM8I36gQRwqi8 SgnhqEtvAMrF9zoSmSYxleh4uEVMpztb87S6uT2RamlOXxhsTSfbWlKJTgmXwMPPPgq4RBHbBzeI T9FaWrDRNkav1QsOj8Mbp+NMTFagC0xB1uBp8E5TTLPcQd/BbOZvld+svllzs/Zm4Q7PHd7t9Hbm HvU9mnu09wjbPdu9wXZ1u4biIESHLGYzpqxWOGw2zDjox2WCQ6t2aKIKHzxA6zXbKCuNgHzWYl7u 5WWyhB5OlCsUMT1cKbPRZnA5+lgNtpkVMsbqxRAQT1isQ3iaqJKLPjlPe7Uamg+0yIEhafBR4Gpd 8Do0JUf+9Fm7rVi0gopNrIWGBjsxgorAm0bYtYWo3Js0qTgL/Alqq9SIE6YFf1ZSp8GpnybOJkxa pLFJYNcfadgkNIApApUGbCliZygxBhmfB83LjUfkfXU4jX0E3yygAWD67jOfl+ZPnDgXPx3FpWxj V/FvM6uN+mnFz7o9FfYuHKE0VHXxWPEvIfnlf6TPnF+zOq8IhXhLUjuu4ujPeu3VRpUsBJsFu5Ud /hB8wvMlW/UZ0f4756eWj610r3WxlYryZgvrkG0QeYeP44Zwi+iHDrUrbOa0oLCrUsEArU855MGg h+vfYXnF8isLDRxTti+sneoZotg94ZCk6pX6ToOAI+TYAGxS4pPI3viZ3XoWoGBvPGO1A7ESW4Wo A06/WucK+cI6pzaP1H4oBLc+jzReVR40PUnZI9wSCJEIRDDFAhKDBM6JslVAZcTWCXjLqp7PTy/8 XOOqVsQN6VjrhrffLX2FPad23Dp+drh94TM/Kx18dd9Lb+Bmjp3f6vWXqm+b+nDpmdI7YFwcGhef EZ7ectVvX8NBHH/rbYATyD7mDbCZiRX/c3HpwshA5JYIrXlT6dAqsOJ6jet+u0Nrw7aki/YhRzQa ZHwOPhow3m9xICu2Jo0uo4a2eYJyayiioINhP2PQ8Nrwbn8qqk3xRkPC5XZHYzwAPRajbdbV8rGK 1SjcHabCQ5TiQFzviTH0EEXviVcATInpfa7v7NmzDRJgm0lFxs4IZ0DZAoQj6IYB1lAT/ETC1334 zJfxeLke6RIBmi/rkpGczxBI4YAPuJiOqFNZndQFhVOCMu3DlhVtrSsZkau2L9pf+jxpwvU3d5kz GUvXTaWj4w8ff31ioe/8s9TskKqwmr5rWRsfLp3c3O2KlvIT1pTCa8aX2EbzrN2lxwCE8MESPPuh E0RPijP/LRjHIEfwf4LR43MEooEyMGmPOwhgvAS/AE8FA7zN+k/52IyiW3FcQSsI8MKXgCchZBl4 4wF4xNi5CLkCoWQJOS2FETD9D3D9PwMLqNWyrh7g1MYVTKufLn0Ws+DoJTi917G6+GpI3XwLvaYM oDvHOmOXACSuaJaXfSaVwx+zu4AmiY/oFdHxKYWjfOBah/txv83ncEUD3yZKTqwsE2U6FLDResCi iCqVSQNhRuRcf8BmjQUzmXhwR+BXASodmBh4BVwVQxSzr0o7NU5otKpSotFzfX0EiYCnCaB3EUol gCEaaKP9S0KgGBpnCMkSa4QQajSl1sVCybAuSgg1RQi1ghBq4ruE+u/ItOYbQJqAXMGsYS6RbIBe 9qkuEVInhXRz27pXj5bexhXvhxYkRwfbVlCKcbaK0o6flE788uMDb+DRPiBcv7c0advojaDOPln6 pPSqRmsN+PGogTouHGaN3gWlZcG1u/8Dd2D3sT9IshLsGuoGwDvi3esRo2qfQ570E5I1JCWSTQY0 PoceSnC9MAajnKcMet5oBpCJcg2QsFoDhHgIEqJMaUKGgDPCp8DbiEgAaI0n6kJl5lvvBzy7bLVh 3/oxY9ZTc0hZ/DFOh+SFNfRdK1pk4bCsZcWFFWsK8pBEHGXa+Bm07WiF2LjQdo3tVts226O2AzbZ N8u1XyQNm8VMa2izkVHz1t3GlB1WbOeR1WvtttJWgv5OacmEdzgdl3gH6NbgxgNuATyCYD0gPVn4 txmCaWTpbpz1AkOgfRIHoNpWjLdELNlOrDs8s3rB+b3fEHxY1nT5hag/wtLUzEOlH12ic9ln8C4h wOTFn/owJ5crZU6b0uKMKQvKTud05xXOn8shFqhQKhN6h8OpkMtjerfb5XYowD+p5hwqJbwSClho o8PsdAVDrIkXnT6XKaqK6sxRezDq4aOhKA03cDlZu8dhjwk62K4DEbcnUeaZkuIukb20Y4DUX34p fAnc8ssvG9P2N+3g9bjk/iNbaimwnBBnQCyzQlzgiVQGC+ybTQWr4yJwRqxxcJHoJNHss9zQ1Xk9 3oZP4qP4/pWtrSuLr17fWDzrLBYrvctLnpC698e0uLxNFj7/N0Ye5tuWXVhxdTMIZ0XHTfT951cy cy786omsTwWMgEaNwAeuAx+OEix2J3pUrH5d/3Pjz+30O/qTxpN2+i3NUeGo+S0r877mbeFt8/tW po3nU04tTaUscqfTwU6da8AGEMjP3ad8XEkppzoIwbtdhOD7QEUGCi+TukTQVchuC5nC6rAuhK3K PKLNbB7LNdDiBGghO5VHjBEKhYrPY5keCoLsUkEaoBsDkPoQmClEGAf8kAaQr/F5LWYd+At9RCRj HCodOoBx6cLeoeHPfvkSNmLTS7848XLpr6WPXv4PageeV3oLJ6VgeUXprdKLuOv1AwePloZK+44O vvYGrqVeIzglyWK2HnBKCf70P4tru+zvOKiI81DgqP+E/7T/786zfo7xm/ymQIUz5Ged/FOu512U dozKURENCj6HMRrQhoIVAqcM+P0xvcsFWOV3OoPg60gFuoNzgxuDg0EmGFQZDA4uZaS8qqgj5ued Ln/AiVlfiJ5qWyb6sI8QV0IRiglaQlyJ+CXiOit5PBrTxJtWBG1REsrpviPEdgSGARNQbgLcWg/e Z2jCXwE0c9QnbYTebGVklhAblpnpaZixctOwBGWwPoh3CxFzQ3IDmHSQYUA8QSC9q4jtL+PKCiPm yiyHWn3ZT+6ecOOMSGnjQF3Lciq/Z+CjN57Gj0UmNJYOlqwrQRy9QR0Ntx3a2xKwpUpccZGycyO9 5so2eTg57fQDj9iL/8gkZCFqgC0tW9moAJyk0LThT+gzgJM1KI/TYlgXWKe4TrlFuUX1p+AnIW4s 36uYFqKUCi50m+I29abQ+4oTIa5mCHOiOrdB7K1cXElV7kqkHGTEY98gTjdfbqbMu8KGaEitYBhP Km+gmVRKLlY7ckN4sahFjhq1oAj5ow4ub3PYYeyA0+F29IA+mhW1eYeQiX8VHwbjolDT4x/C1z+H hIxACYXa9LETfevPnLYKJ/oAvuPXn7GetdrBLExDD+CtKwjQsY9opcTT0vhlH5FvlxorVkrbUe1N svqgxj8NyWOwFWwSCq8euoBE01AwpFHzFYppOBaVK2QJZhry6TzTiNkoua2k4pLSCr5yok6R7Utj UFvL3uURNRa0L2JCWsweLDlyiEVGXHwBGn+vuvPaA/Pu6krft3tiesYvn+o8qgm7+IpkZdUHV05d n8ks3P9kR/tfX7rsV9qgjUk2QsrtQ1sm33X98gVj0nOWVWX7r3nwlx1BX2nc0Yfm90ysLTQtXzSj Z+2u97oSNryfPlamKSfwmp9IfDqMfiDOnmaf6uhz9brvV97vftTxguufHnmICylruBplB9ehnG5f 7FjsWux+0vWkWwWaLor6LZeDCPVrLifC0+dzhKIBcGQwTDhk0CNKnnLKw2GvVaNOWMFEYA5EGTbm BQqi90QjF+mmLE7LPAmMLEkkEdcnKPu4zG8J+AD9yyhfHiqzlpEhqn+gMzH5k/PTM91X45NrRres LQ2W9q9t6VhNgTwN880riit2zXzkiTlHKNPj05ThsLp3V/GLE2vef2/1y9TGq5vlJFaHkXz4M241 wKIWMjruy0BWDxKw0eZFXhxVQLYSrlXUVvXmrrAtdqyxrXVsQ9vwDu0O4VH0KH5MvVv7rPBY6LHw frQfv6B9QXgu9Fz49dDrYb90Zx3EMTkbZ6e4DM5kKpOKeCKZrFAo5GnopVLKbHUuV4UdaIDXO3Qv 2cKO0OMVWocQVQYcwQFH3lEbzYmJkD2BqoaG1+yTV1V6oRan2lNJb6bSXZnQy+WKimQyobfbHcpU Kga1LVdVFYNxPldVyTO1mVTSplTI5I6KkD2XqYCkHJKHo6iqDQWBa1NVlamkvA4cB6Eh3Lnfi+zY /gIYwRuRHL8qKryodmMtVWsr1A3hP+7zXT1b8if02W3ji3ZrEerixbBK2UiGEoQpcf0SZyYoGSSq oAEDmd0EBvL/bJCIA/BBOJ9cY7dKxvL/VcGBvQyGM9+gaeChhs6msqheQQQRljRL8MhgQwRIDVjk xQE5Bs8aocGRMY7m6ECExgElpmAMDzfaU0oljp7sd9R4W6jgeFeKFyC/Dpl5tsbdgO/Nu6rtJ6dd 55lytnTUc8/gsmkzAbcouS5pDLsvlKjWv7WDCyIcxgpdTu+oKCLqufqUXShAJCQc5nWuUcUdX5Tu OEMNXPgRxHp/j6ObWClETKOx4IO+jd4Pck1ELVglXv55+HyY4iKdMkoV2K7YXnhS8aTyCfWL8p/L 30q/lTklP5U5Wfml/ExGO4NPVFZYnB6jB2W1WqwdXZWqKVQmtAokM/LGbIhLNdUo+aZGZQvXUogI ynRLhVi5Lpau2F1BVQxRSFS0WSOOdn8r0y5CCu+etlaiJJwtEi91w6ewF8WG00CYJGJTdufD0EC6 z3rmGDSkzZJ4ZX1TcyCqsmCOCqnDsrA+jDVMGHFNjBuZghY3MlsMYcGNI1FahcIYI42WbebdSBcx ui+xTAzefuLwlz7gGSXGPvhEiJ1AojnAPoP5mlBZBJIxEty55L0CKUj0MMJSyXYDC42Uqxymxq4a u7UhkmldV0I/mI0NRv/SbCqlCJlcycyzj7/aEeLVMYs75A3V1rU30uNqZk2evgGvpyrCqd4Vs+LO MYWl/Q1XTLs82mZ3pFUFvtasrg92PrCh43ul5XXmiMZRHbGFexpbvTXr+ihIgCWykoM42UuQI2sF 7fdOseJrFZap8HY1DvD4pKkbOfHWgCzEQXaMzKSkka9JyTnm65Tuds0QBY7oSCgiSxsPm7AJco7K zmfiFb8YOSOR3ovAR1KcSNoCq9OrErwqdxg7BSg8al8Yu7QOwDBJVxsBpwH8S1mA1YiP2QjqWliK KUnm2og7U8etPMhR9urZa+85XvrLqeXveOuwfEv1HZs23DlqM/N3v12UyYo7MvGxf3/9ROk3PQnG V1d5vj/5m23bijPaShDyIDBIAwzG0rulbIgnxdG3Wx7hj+je0b1j/aPuUzeXU4IsUS6RL1EsNi02 Xytfp7jWdK1ZGeUtVk4hWKyUxWrgFGpWnQUf+D2gzbY4lQGqNeABy4baFxLawc+E94SCBFuFc/oC QdIzfaB1Hbto2EjCfsS55HD5FHqE9S4hjDQ+KBQ6tyGMtF51WAo1CaDFSj5eEmuTHLeSmC67dr/x LhF/LsoGqGsPpDKBHETyvL6alT969p5Fk1J1zkLzuh0P/RnL3kzQu28c7ytkUpmc2fTGo/f9uT0y Tbe289Zzv/0VRF0l2FQCbM6wA5APUofeF5fdH30y+lb0Z4mPE2cTMrQsdX3q9tSDqafjz6Sej7+Q +kX8WOr12lPx91Nv12ro+LgYFeCVJ5luhVO5Vef2WrpdTvfdvioILjEWxh+pSoPFxFbXMfqkDldn k1xdUyTiU/qZtD4iSpENdLAh3/5wBQb6x3sa6gGEfcRzflbK7RAIpUsYRhybI/FxCcvAeUSCkmVk yxWiiVwiH0aFKBQ18eowro3VfQvZJG85OG4tFwOWYEURLx0EOEx02blkkmlxJCeRKZWr1mf1koAf ATqVaoyGHFmV3jM5OdMvhCARhKK8HUqzUnb7j7ja2Oi5T/22+Nyqube3brhj2w/pPV5TCDc1pija Z1LZVayGWlxYV3/hVy3VmPJRmXr5dY32JOae/R3OX3hidgw/e9PS3/9k1wWwtaLDn0Gm8FPgF3BC KPN3Yt9ifolquf5K03XcOv5a1XrdDfr1xvWmC5pzWvU0/nJ+ru4I84b+BPOp/I9avpGEkaxgglJy BS0DZZLG9Cha5nTOdxm4u2U/llGyFrXSZQXh4BJ+Bf5Cgr0e+n2BgN7jLmNvn74A2mkZf4kXj/BX CAaW2SvUI0hcoXEg1hSyh416iaOCe9GNbVZWQ4eRWeeENoaC0cqkXQDL4SI/veg2NfnAoicRUw1o nBLEAfacj7hR89S8E8VbFC/ftHhrYyD2h5+8+Iv/euWZBq8GP6Z0VK5K0k+9tu+zE1ctVN3wHnYe +hkOjl5YM3lBZc9o0JmiYLAKgMthtEbM5xXggLcpYgCMMN2MnOEPg75mZ+hDyJ9hwwazVbfNmlVi D1twuziZLBxS0G5vFEfLThaXL82lAYCH4LdskTSJBDYc+7qvIJSdLNAj9lSZ9wFLswpHrN+yzwO5 LMRapLgw4f5pTNRqTubCJEYoRc+jS9qefjo++f2e2zN+V4VLpwn7xzm05//ReGPxCyfbsZy6qe3h Zb/urPdVBxJ2k2tstOVMW3ED+OZIvheDakqt9KvAzwyQJT4dMv+Pi/2jW7vabm+9re0pB8tG2by8 zd5WaFtCX1n7mPExq7zFIKS6EnE7Yw77HVR4nNBSJYc+HZsunwSaGTU92+WJTYy9EqNjoyZmZ9i9 No5qKmhmzAibx03aGt4peYCRqOplszXe3lRjR8QMMebfiJqGQ1PaBXPGvNW808xA6s3wnt6e9LGi FAADbnjsRJHEwQBxJI36WENDceBU3wDBqLQUYx5BLdDLiG4GVF4Go16SsUQ9SmHyR2KP+m9MlXps Cly0TyJlgyULNr4JXHiEL9Y0gw5FaiDyclhMktFZ+mcvXfvY8anVPwhN9pvnWVXpTGTh80+NHpxk mmZQPatX6F7aaWtxXdaZqsV49n2lHfsfOZwd26pKWaIdK74ONfSvmBcyDMzhS38VV01tA00Kcn2w hm0Wa6jI9rnX/KaDnlThqate+Yp8nserVbjSDz784i2jgx3t9Sq9zhMN9S4wujNrLvuvvsqua1+l xgK+QoYf/QnI5gw6KJo7zPgfFiy32C3gOxPSngwVaHbCL+jOi/V+gr8Zb9De7HR7A/FmZ9obuMh2 Y4F4PBaw62hZJMMIJi2KNJm4TNrjVgQDaRtku6CDVUIkngYvFOyO5GmVBDjgMCAzcQxcZLFE3S0L caL2gLdJYq9CKGy2hs1BiAJZQ5aIG/wAQMxAx4SrjrijiIkIwrwZW8rCXNKAzN/JEhlxQOonZ121 SpM6caNtLtVc2XP5j+u9leNKE2dUtcyccHf1tNIop7L+KvpwbY6mguoQ7+aK27v8DZu7riktWiIq nE5V3VV4G/wCV1cyXF2rIuQA8h3ontIAHJWg4/SJ4YBK26xyhrzBgNdr9QrdFqf1bqfXI2gZZ4jf RkFaaCioiEgap1e5jY14vB8IWkLpYcmdCnhLImzNzeMlF0pZ1AhfAw+DTLZvyDpHS46PcjJEjqAa UWYk8n6iIRFvbIwnGjYurZVrM0pTVXx3h5On8v0lO1vT1CjNntcpctfgD1psMUbj0RRcKo4vVq2s Iz9iJvYfcXRo2OshRgE5byZEtyGnxRs0e/Wqk0yd0qnaqteBcxj4p8WssMG77Nfp0zRD3sIqvYX0 CkBU5fSdkeWX92tkyTV5iOyXF1zR16o0Nmp8tk0vc3TDnJLTKS9MoX/daquQyXzBBpXx/KQZWQ5W hknepqyafgJ+ofRP0Vljq/ZSOu/jGmpibGIDJdQL4z0T6OZ8ss0Zexl+L+xHImjYTtQAWDzOz9Qh 5wRvMFjnjHoD+WZnvTcwus453htQedlueKW7tW2jHXlxdFebmK9JBh1GllF1TDBoqzqaLFVNHo9F y00Y31Afiyq6yeYpA8F06q7k8STVlRzCo0R1p1iTT7fcJR4XqS4RRp7rZAyR0WlWgspEApXTwsDZ gT4r4P6lRjmYKoVTwRctEF41Ek0FbjSiZ5TtAF0KvItlV4DEWL6lTQCvd4EfLAseMIukzv4LBRCI g3wrAxsoBdTc8iaUR3wT7NFI0mTSdEX2siw1f+u4Kxq9pjH5y+bvqvE0Ty41zsibQle2iKGawuxS 7rJqo29p40Ay11sq2DmDawbFjkkxbMCqbldoNs3s6Ay3jA023TxmZ6l/VJa3O/maKXh3f2py3JYv oUlTabtd1X4Ltm6vm9dWU/xgXB22ExqCfaU/pn8q5QI/J/ba7OPt1L2axzTAjDw+ocqTTfuafWyo 2enz+gkyZr1BZ53T6w2AvllFtrCMldpUMuQ0MDSX1WtjTZaIlstW+byKaq4a4l7VjMMJO/dcjT6S StM05N8M76nJgebRIBCbAoI/xQZi4RG2BP5LYqyXqY9sANvHlBlSJGq1R61hUDLsEVvsG4bUN8KO LqJ3Mya78u+249u7gUOjCipDvdygiT0wh6NnV0+Y2l57ZV17adroOnF6faO/RuwojcWnnPLcbMBi e5iiAqoqj0J+z3RvZWTca6Vkl4idTkXj5fjp6SuillzxeFcl5QRI0qh6+A8gp58CvmSFrO27xcTr 8k/k1L3CA+adwtPmrxWsGRkZi2WaYqrA1vHWrI3i9FleaTO125SQ7UMddGjbteARJhqawz6iHOsL koIG0TEJHAlkUYdUWBtGFtoUxjo5tAwctDTIGsZmBgpBoQ/DT4mhIHAsO8sl/t1nB5RFkL0GWT85 RISklN9TTQXy1cU3XsfMhTcPl87h3roFu+66et32u0PUfdhQuvDeG5DbY38bP1w96/d7S8d++fiz uKqB4JBc0kv2QGZ7Fh0Re2vkNb57bQ+Engo9Gjkd+TrCK0JsZEyIfiyIO4LYzwttamf2ZDDV5qz6 MGD16iRGDaEWSNVKCalYNunRqRQs5XbwTQHOwVHzY8pslYZth2g0mKY5NyCR7rCABYJG5bybi6Yp kWrgIyAIdEnDuETLZashGAWXS5QNYy4IBROhwkgW4sMAHfgru7khxaashwC+QIBwxNEtCTtgAJeQ C/QOACDoKmVixv1XdF75wI7FY64tvTonG8oqDfrL2CMs21o187Itb3x1oDYm1rQuL+lWt717eOjg rERJXnxa1j6aPjwuDhaDB7fLZZtavbVfHHuz9LzGVFs6tDDFB8pyrhLg+xnofQJoDL8Wpyni9ng+ Tm9LPJk6lDqW+h31WepcghufwLV8qM3p+9DvkAiU5kOQJGikHTJLxhGq8IWNPM0IkLuezXBWTmiq UPq8GlkklLaLkH8G9HmwSt2+I4mTBO0khUGyyQC2RCp+B7C6ctYygfFISDYaT3MGPQBSG1eHkTIN hVwnc4OrQ5MAY1eVUgDEDQqgWgD0iItlRJkIjoRkJfqVkpqAmwKgIYFpJK4lcc4RXwpYvxSaFMgY rcn1399024ZZ1YFRy+XAPQ2uKSVn74zO7NTF649j/IulgsEezePHJia6v7hvz0m63aCKtjKYYZTn xZw9wjt9uG4BXt/hrvzTR7+ErBiQcXJA5j0A5xjaLI474sZ5P/bEMOF6MRBfbUR8Kb1MM1i9dwt+ j5uOB4N+EMYxo8vg3ejCXlfGRbm2uYSIhQNhtRH8l3FDJFhWwfbvBgSD/Ik+SRwd6SMwHX/62JkV YHqBAjySKnYJWfFFiVOOsoxoWiPoRyTOiJNAwlCjOW/yyWc3hCoVPn1hraUqx9HiGjErVobC482B y7v7SgYfX9mNX5s/jWV8xgq5waoQHuld0JiK1XauaCg1Tm+jQBAQWl40fIb6Gb2H/D4E06LPgAzY TMXUBfUi1WL1OuU61WaVIsZnnJW/BvYH1wzhH+yDNkhin6j1V1idtl+LDqfP7oG3J3PQBR+ST4z7 9Gqk4CGuALEW1pOt0nNstkJZpbXjr+zDdsreybdUoUwER6ohlPJXUUCRq7U7tYe1tLYTVYMXAUA3 cMLad/oMBFWAFw4c6VthlawLSOy5mOKLRjIGPumTUgbKyT2QRACxlU+kdB8SZJH4gDMKIQD4CQEn i/Fu7NX53YiLsm7kEzySO1BiBsRqNWQvBk4kg+47YRNithIzBKImZZcN2aYAXuKzRDo3jZ1R1Xz1 dat3rsvdwOsFmZXzGP1N13R2b/ne23vuarhfo9KzdhzC9Ssbr57SWjEhJLbeOuvqrVGFsvSf/TUL ptfN7hq1evvAvVGdij4EuGmDfalndoFqNUOskOuww08ZqYLbLxOVPsUorkmrhPRRZVB0w49/qLTR YRV1CSOYAsdOQZD5VCMkjhaPHIOm8A4UqLk4cMJufdPefExKIwDri3itA/SI/5K4SAhry5FMHGJQ geOE8D1KfoxSWzuDOb/dXL26ZqDCsoxl5daOxhVqlt7eVTw8LtLhD5ndnXWLCwupObSMVSiNhVH3 M+pzBLdI7v7bIBfJ75CeECeM5cZ6ZnIzPcu4ZZ513IPcgx65R+3RUC5eUefUeAPhOmfcGzCCJm9w GrfanLawS1DI2bgGyUBONvmUCc4ZUaS1iURI0II7Ax1IIchtCBO5kEoS9YKkKpE0CcgtIRm9wMNI aAfCb5dy2yGbRO8PUgwdZvzYjQJBKgBYUGZRZXecFFyXHHDl0A9w+zyEf0Ct84cbiWu4DCjJpx/C jYbQ/PaWULhhJm6rnJivbrT3sFR77bTLZoyf4Dd34a/oh4sb22PjkrYEePczrK8otmdpp1ZrlPvl sl2TIg1NjVsprtuh45wqyR4AmB2nd6EAxODnRJQRU16ZN/XwM4QZuhmWXoiSLeKvEK7QXWFZ5Foj X2Ne694k32Te7H4APYAtPMfL5QU9IDBvMXPcFCm1gZNDLMHm9wsGGjt1BJQhHhIjzJR+CF84OMri 5gKUC5oHRm0NYFC1X+8buGC16AofDBStklh9nWhq8IMloi6PJCl8K1dBipaBNeQgYnMk0AHQwgSh whESeYQwx1B1XK48vl9tCZnBV1wZj5V+z0MWhoYv/TJUYcvQuzwyo19wOYvn8c99XYaITk57PEzh imLGoLHoqFO9Xr3MQ/gVRhXDX7LfB/jUYV68NcyFMwVTwVHw1fllcg7+w4qWN8ozVn/Mv8a4ySiH n/vQESZP5ek8I6vK2TOZgj6ZcTgdzpzdaIIt5fmC3khasin6KkcOzkgmp+j9fp8/mclVOeAEo89p Ult1oWgt0rA6Z11EkHmsygYjT5kg+IshWgd6SVFUjzLJ4AKmYM9IjJCMeAu4EHb6k5QvDL9MLR4Y 5YX0/Pr06ysAwASYHwjER7Ki3B64APyNjL5DJAU4UL4FcIg4HTkSF45AoojAH+F4SBbhSQvImETp AdYkHbi8AwDuLEFXsgFhiDRJFXimSACKnAey1oHzEMeXhuihhjq18uBelTOVKNm8rtJhRiZTUX8s /YPiWBVVervSm8YrU5Uxa2jlfipuNGZTeBd9E2ePmJLuUgjvdc6yhOwyl4sNj7rwhZyXMVS6+FuW g/oP6+IcbKIt5lrR0lc6jW9SGZfFkwFmZB9B1QHecB+qx4J46E8chn/dgOEnkGYco9JUxlXT4+vx 9wQGzJuYTexB50HXUdmnEX0n16XtEkZZmJpcPpBT8DJFTmbhFQrweptiMng1mSVmisbyASjhqMnn FPmAqaBXxAr6HJx2r+xR2UHZOzLGktYHZHDkA/l8LhawmBQyvqoOa/V0nVPQ1dNI5kpX0XanM1NJ OxR5mcLE1Ot0o+vJufU6maOSqFCNlQ3p10+9DiF/SyENifmkJtk9F+DHfVJJBlIpjo0L8T6ooSJ7 J22fcISHPFw4YFNHdpT4Hcr7eXGjym6t8s5p8UiCLrHtRzxmxLEtOSJAYYJcBrKj+GQ4l3PG612V FWHcmu1xPI357KhUab7L4gnrg7o2yy6XxlNdeq+mOv6fh+sSY+j7nJCWbuhJtU1KjTHb9bTTyaQj fytdPSFFOZ0UZdUbWrx5x1z/+aRbYVBxTqfS3wT/LyQwwwuOAnCylET6LeDxJH/wx+JVM22YA/d0 tCKWGCNvd4xJTHcsSmxWbE7cnziUeDeh6UrgSFyRiEs5WAW9FdRTuXyKPpGIJ+RKqw3m+HSI0pvo tNOAZP5Qu1OT4TIX5zJyI9poxMYqz0ZgBURnfafviDCyA8Cmike+y6mAcEhOFQ/kMwJb+D0csPBv kUsaS4QxwrAuins9SbknVBNy4seqrCmF+vMXafjfXR5siMW0paOT711VO68+ab/CXHu9jCkd9mer 8Cn6Pg/m1WGNy1X8B6XkaxV2K0V5PGwqduHl916tbYxmwQBJyO0Kav8YcDuX9S9SouGFaKHU+NcC fjcA9qUMLEsV0oI9ADF9KZsQCAU8RjbI1XJBVmtYyhSuAClLdqEKbLwaVAtxnnb4bzOdaBR4j0ej MdJ/VZkI/95sEpoM//tkKpom+ZR74L+gzESz4D+9EO4KEStpCTLis2ybOW76+I741MXLFq5KTl6+ rP+q/wM0RL6rDWVuZHN0cmVhbQ1lbmRvYmoNOTUgMCBvYmoNPDwvU3RlbVYgODUvRm9udE5hbWUv TUxKVFBDK1RpbWVzTmV3Um9tYW5QUy1JdGFsaWNNVC9Gb250RmlsZTIgOTYgMCBSL0ZsYWdzIDk2 L01heFdpZHRoIDEzMTIvRGVzY2VudCAtMjE2L0ZvbnRCQm94Wy00OTggLTMwNyAxMzUyIDEwMjNd L0FzY2VudCA4OTEvQ2FwSGVpZ2h0IDY2Mi9YSGVpZ2h0IDQzMC9UeXBlL0ZvbnREZXNjcmlwdG9y L0l0YWxpY0FuZ2xlIC04L0xlYWRpbmcgNDIvQXZnV2lkdGggNDAyL1N0ZW1IIDM0Pj4NZW5kb2Jq DTk2IDAgb2JqDTw8L0xlbmd0aCAxMjkyNy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSAxNzQ2 OD4+c3RyZWFtDQp4AZ17CXxU1bn4OefemTt7Zt9n7uxLJstkliSTbW42thBZEiABAmFfRAEBBRXB FQgqVsVdwbpWVCYJwYAbtWhr+3zaXfv6U/oarbZNtS1an5KZ/3fuBMS+9+v7/d/cOec7673nnvPt 59ytV2xbhVRoN2KQsOKyZZuQ+LMdBvCjFVdu9YhZpJqGEHfP6k1rLivmDWcQkixbs2HH6mLefh9C Uc/aVctWFvPoHMDqtVBQzOMUwMDay7ZuL+ZtbQAXb9i4YrLevhby8cuWbZ98Pvot5D2XL7tsVbF9 mwxgatPGLVuL+dZRgLM3XbFqsj3uQUgxjlCtFaHMGYTqPQhpEMLQyoL+hhrQDUiCCNKiSjQPIfZe 0oNYyNN6CUIdt4z1LS1p+Fxmo49B6DF+9GUKf8Bt/+qcZOJWxc9kcWgtF9vTCujHefPtaIHiunOS r2YrfoasiKMVF36WwW7UrGJeQnEIAoTDEHIQJIVTzIvD7e0JYRRgrEKEQ5Fo4oRYYQ8ldjcbmBfR IQhHIbwNgUUIYh4CYV4kR1EY8dD4xJDZIfYaHWppmUxU1xYTw6XliQ+aFcwo+hQCYUaZEyhS7DUc qUh81lwCBfAWzAsIQ2DgvXnmFeZVFBMbvToUKE2cYI4z1w/V8SXNFmYYaZkh5IEwG8ImCGcgSGF0 w+gDCJ9CKEBgkZ55eug/9/GvMIfwpfgBuOt96C4ZFlT8LnaXhOwiuxiy9EWSQ7hwCluGbKsTo4VT w6vsq2Hcu/EWWvAycxO20AEVTpGjQ1VJYRRAhQiGYZ5odjgULkJvsAidHhEO+YutbcnDL8E85SCc IUdHGIHxRuFBfxuuCzUmXmJuoBeqk6ERXgguTrpH4T0Xr4QGfxkOViSNkKULs+4V5nqYowEx1tCy yoSW1s1ZlFBReMmchI/CqZ0JDcChKUkFAEEemprQB1t7xEZDiSTtM1Sa1NOmNY0J/Ytww0aULJwV TMHGpDWYXpTQBkOphDRYmlTB80cLeSEQLE+q6iqTifuDzwRPBt8MspJgNdQmahO2umhdbR1jDVrg hsciwdog+xJzPb1QUIYELV/C08Hz23mi5ONJeKu/DvPia+9m4EI8NDLxNUu5oxxZKj0qJb5nob38 2Up48G8FxbO8L+Hzx+bSV9o1FE2KwEcnZdeQ2wN3+8ML7lgy4YbJoBi76/jMWYlEqCzZrCj8hdmF MvBiXwKMAfwjdKlLeqDncHZKAmZ513BlXQLmYRcsp5gFLBXvH0qytHb6jBSFMJEi8CatkBNUrqQv FE8kfKFkLTz/S0ERgofLQw5vYuAVeBRmdtELheDFKvgaXlopzUqZQ+QoeZW8TdhDzFHmVeZtht0I rQ4wDM9UMllmFrOUkZQ0p8k4LPFSiA9B+AACgyohzkLYKOaOAg5hNAtiuCMwgUqIs2IqS7FYrFn6 TzWUPjAzxAyRcbhycMFdBHsNRnEsYIIxkmOCZMhiAX6h18mEZiW5hvhRCqlxoxjXiLFDsKfUB1Lq m1LqtSl1b0rdnVJPS6nLUupISt2sJWnkQWrioDE+J8Y/EOPZYlwm2D3qzzzqVzzquz3qHR71eo96 mUe91KNu86ib1bgJ1yI1ahTjuBi7aIwnjpV0liD5q3gCdSI1MwhTa0I8MQ2FUvwoMQ6FsgBkQ+4X +WYbkSK3DEOtBMIRCOwkZBDP0nKMqigXwF8jP54P8PmhUCk/ip8rgiP0ns0m/DQK0d74CeTGQYCP oyNi/ruoSoSPTsKHh/wboPdDFDTL8YPITx8CD0iKD7lyKFQB1RuGqq7gm3X4UngmffZaFBCbtQOK 0ObZyW7+Ifcj/EvYi9wwTB6jY6Ed/AT0Dw7xXyVHZXiI/6/AKDkyxH8cGsWQ+xDqHhjix6ogJyj5 31eN8f9ZtY//WWiU4OP8O6G3+LeCoyw0fAFaQMPnQ+JNnnVDIbR/pGoJf2/oEf6u4r0HAmKjG2Ey jwgG/gZ4pW3+MX4T3Gal/wp+SfFWfX5xBPM+Em/cBeOB+89KioWXhOiNDfzUqjX8lNARvrXqLb7J v4Sv46H8OJ8JjPE1fnEIFX6xe6kbXg5GEvUf4cNVR/h5NS/hNxCHByDEhApuF7eZW8et5jo4gavl qrlyzsd5OaNML9PKNDKVTCGTyaQyVkZkSGYcLZwRYlQUGqVaCqQgpTBixbSW0DREECOCZQTNQDkD 00E6ulpyNbGOUa4wN1cb68jJZy/qGcT49l7ckTu1AnUs9+S+6PKPYsWchTmJvwXn9B2oo7vFCo1z ZO8oRt09o7hAe9zsyOlbe0CIYeHm2xwU9t58W28vMl+ZtWb1TbrMlLb/IeoXC/vbYt/8rN8kxZTV lbuno6sn94yrN5egiYKrtyM3tcuzuOcE2UmuaW87Qa6loLfnBJ5CdrbPpeV4SlvvhWaAUNdCM0Bq ALTZLuSmzQC7d4nNloh3A/LYSZsFKaDNnka82IzHT9NmgGa03eARvr1tkIcI2rCb0BGxzRF2U7FN UGzz0UVtJFr0kdjmI4lWfJxFbBIIwG2qIOrtGfQFoMFgwCdWz/mm2l+s3lms3ilWX/5NdbJY/Uyx +hmo/qfJ+z9nV7X8b13b13W14I7ZPYMy1NLbCtNCoVm7qUnEA91I427HSexk3kPKWG9O4W/JKf0t KJu1xrQNuLJPqspJoYyDQNGm3mu9znGSRTDltLkKitWTVeXN5c20CtCZVmmguGSyynpdvRce8vRk lRaKdfAQwOOKLsDLS9tzpf0A/G29yNq+rg3+k2AL/LZt27Zly1aIt22DDqGujlzjnIU9g6FQe87W 39Yba7eua9v6LyYBdeRKoVOWduK49pwAnbZsiYn9YrFtxQTcmyb/+be1WEYfEUMx6DT5wwARjA0A hikdLbw/7HaKUncklrSGYskThc+Y6wf1Sdq+F2+h44P+cLfiPWiKpoHQJbdDmIl4CE5mMwI9vPA7 CB/TkJ9ROCcBbpxfW/hPpgkaH5wMAOAXRE+j27ES7QQtvR0l0OPox+hStAnNQUdBc/8M/xpNhdUI oqtQFAloApnxMjQF10DudmQp/BhqFhU+IR8Bv7kfXQ/a/jb0K7QCvQHq6QM4iQKoFv0baiysQQbJ u6ga3YIOFv4DcWwKPYHeLfy2kEfT0HfRu7gBdzG7JU1oAboaXYtuxRZcimvxtSgEY9iOXkaniFY+ ApZSJ7oEdaMetAYdA6lCwH6YjY7iXzKt8KQetB+n8anCsyCAg9CzHDXjahIrnERuVAoivR5l0c3o bnQf+jWuwI1MFXsC7BMBLUMnsAabsQ+/WngI8XB1osUw0lvRPegZ9BP0E8zjblLJ9Eu+l/8YDJuN MMKdaD/6JforVuAFeDsZZZ7LZwvrC8OF09C7Bp7TBjx3O7S6F97uKXQcnULfhzl5F7vwbHwv/gu7 VZKYuD7/0/yZgrnwV1QCY52H1qLL0S60D9bnEfQa+g0aQ19iFsuwDr9G4uQ3jIZ9RGIpoMIeWDUP 2FLNMFvb0R60F64T0ON17MERnMRb8a+IhpSQDeQ6coT8mdkHWsTv2T8UWgtPF34Ac/4JWEt+uEJo LqzqTli1A7B2z6Ln0QgaRT9Cf0SfobMwk+vxfjyIR/A/iJE8R37JnpO8K/ms8HDhHFLCbAdRGYrD lYQZnIqmw1guRw/ASr2J3kK/RV+hr7ADZ/B1eA8ewLfjg/ge/AH+gtwCSuH7zD3M95gc8yMWswl2 vWS/5Ix0Drcsf0/+gUIHvJ0B7p0CvGmCOVwFuLgFcOIhmMch9AJ6Fcb2D/Q1zIsB3jaA6/FcvB1f i6/HB/Bh/B6ZRtaTjWQTgxkX42fCzF6WZ4+wP2V/I7lasj8fyvcWKkTZqABsqIdx98C1FK2Gp1wN 136Yh6PoJVitHwLWfgLY/Dn6Gp5GYJ2V2IS9OIzb4ZoHq96Dl+BleC3eiR/DR/Bv8F+IlliJjxwg d5PHyM/IH5jNzF3Mg8ww83MmzxYkSkkCrg5JL7zvEcnfpPOk+7gWbjn3lOzfJkonfjTxfl6VN+XD +a78TfkXCz2FKwtXFR4tPFV4rnC0cIoSKijHdyMX4JcHrjCqAMrpQDPREhj/pWgz4OQAugN9B66n 4B2G0TF0GjDup+hn6H30AVwfoY9hZf8kvtPn6By8kxX7cRXgSw1ejJfj1XgTvlq8bsD34fvxgziH X8Wn8I/xz/Gv8bv4DFxf4H/gL4meGEglqSFtZCqZReaSFWQV2QTG5X3kQfIkeYGcJK/DKv+K/Jp8 SPKME1ainZnG9DFLYEZ2gKn0KPMC8wvml8y7zO+YL2FuWFgjL+tng2wdu4a9kT0jicA8rZSslxyC 6zWpUroeLKVh6U+kH3NSLsJN42ZzT3JDXAEo5Si6E6j0oh9g3NM4ShbBKBn8A3IM34XfIkPsONHg Xnw1g0g5WwY43ok+IvuYIG5itmMH0PFtaDphYA415GEyFbCb/uYCFScBD7slP2dN+CnQpW4BbXY2 ehv4Tge02YtOomDhXaRD3ylcikawBShqVeF+oIXduAOfAhpaQzaTP7LnGC1g6O+Y9wBvPgLaT+F7 pD9Bi0kMsK0RHUJmsNvCsEo7sIdUoIXofmYvrLQX2VApu0ECPBz/DUyaZ8g9ZB85VngTFLs/A99b yE4Fhe8M8P1SUJ//hJ6Hsf2Y/JzswyOsFD+KZ8EYnOBaWAK4HCAPo1XMNsyS3eTv7LvoPZIhC5ky /De2imHQbFinG1Ev/hOWoWfxPeRL7EUH8W54+w/xn8iHaCv6Oy6QCeYAWYt/hH+IzSSGW5g4ypPf 4eUwmgD6i8QCamYN0JEU8Ooj8gyzGsyDn0teY37LdjLHEYtfwTXkHOMhbbiTqS2Mo6D0S0ad/2Wh FbWRQuFOVjnxKczOZvRe4TRTzi5jZ3w98vXbxILvZC6T9BT+lt8puZE0odWST7hGtIO0Aod4G2TR UVSKPyV2mHceSupgpizsHV9/TeYgF/kMf4624wNAHQF4k27gHEfRGtA4QjB3UuDQ96GvwLp5DXUy 24DPHEenAduvBd5uICtAzqzFc0F1rsBgUcH1AGDDX9l1aAfaDev/MkjTI5ByS57IC+jfge/NB1r8 D7wfqG4aybA9qAtk6Q3Ih5DQ3C1kmxob6usytTXpVDJRFa+sKC+LlUYj4VAw4Pd5Pbzb5XTYbVaL 2WQ06HXaEo1apVTIZZxUwjJgGpW1+6f0e3Kh/hwb8k+bVk7z/mVQsOyigv6cB4qmfLtNzkP7LYOq b7UUoOXqf2opFFsKF1piracBNZSXedr9ntxbbX7PKF44pwfSt7X5ez25cTHdKabvENNqSHu90MHT bl3b5snhfk97bsqVawfa+9vKy/CgUtHqb12lKC9DgwolJJWQyln8mwaxpQmLCWJprxsEw1wNr5iz +9tAM/NDV7gNE2xftjI3e05Pe5vD6+0tL8vh1hX+5TlEtcOY2AS1io/JSVtznPgYz7ocvA3a7xks OzVw66gWLe+PqVb6Vy5b3JNjlsE92nO6GDy3LWe5esz6TRZuDirqnotrHcwA6G4e2nhgYI8nd3hO z0V9HV56h95euAf0JcEp/QNT4NG3wkphayUMjg6fvkrxpVb522lJ/3pPTu5v8a8dWN8P62EfyKG5 O7xDdrtwonAG2ds9A909fm8u6/D3LmtzDhrRwNwdwzbBY/t2TXnZoFZXnM1BTclkQqW+OLEKZrpY J6bE5jTVMffCdGI6Iv90UGpznhUeGEmPH16klkaratHAilqYdfj1YuiVWwnLsC4nb+0f0NbRcphK nJMEtX7PwOcIlt0//udvlyybLJEGtZ8jWkmR4wJ+5UCITuJaLhbLlZZSvOBaYSFhjE1iPl1eduUo +Yt/k9YDAKYPze6Bbr11lTDnXi9d1f2jAloOmdzuOT3FvActdwwhoRKMCNJPa06drzHNozW7z9dc 6N7vB/Q9BtoBQqacLHThX6I1G9rX1uWw+V9UryrWd3T5O8BE8LQP9E+iakf3t3LFejqhMG9QN5nK GVp7GAehqA0p4mDEWsDExQsvNIFMjyrHBuEvFTF55SgnA1QUS7BnSk7bP60Y9yq83klC+d86jRY+ o71E8E23ydfI1cUmB1ocdq7+W/lvDU81wHR0A58hHd0LBwYU36qbAhxsYGCK3zNloH9g2Whh93K/ R+sfOAE6YG5gUzvwnuKKjhZO7nfkptzaC6+yFtcB3hLUMujHe+cMCnhv18KeE+Df8Ozt7hkimLT2 t/T2lsNiSTPYCVIIsb8v/FT6TOFlyfzCDyH9NtiJcQjVzG2oFmAYoEAy+QdJBvVA2ghwluSH4I2C OggNjAuVMq7COJR307xkPujICPCBYgQCmSAFeQ/PB42xWCIW/58jOuT//mOo5QsS6n/7SUGHl8Ge iAJ0cfpTQVCDbVICuyw6sUQPerQRfIcI9Av6S6EUXgCWyhB7m+QnoHt2yPbImxXzlRHVPLVd80LJ T7XdOoNuRH+p4Q7jHSD7nDAMJwyEgSdljxH8pZQbJasFA5KwXzJIwbFfYmSTSSVfwv4GnjEs/+5v wdj/omGi4RLt2YbOiQaUhbT2HERVca/OqwtChJ0sOudhTp0TJKBXe9hTiCn8FFbuBNitXrAnavCD wpUca2aJviyeDWbjs+KLUuuT1yQ3ZW6NH1Q8HDkUf1zxfPRIfJgdUbwUfDVumF92miW+mvLyMoPd 6DKALufCZeXlbrvDaLc75OlAZYWhtALXVPgCyXRFpe+Aj/h8BkwMMl9NWbm9NuKwa+XycHmCesCz Kqw6iVsAVXaNSAWdPiWl2yNaK0BsGcmUvVz+e8co0y5o9HbB5kjl7Kfs79gZOzQa0aXjdmwfxVuO 18rtFnut4iTegk0I3FvahlgMpqQv1hcDAj6B7HBLpy5Lew2HLBTuHo5YxfzxcsgLugw168Hg7xyb GLtE+0Us1vnJ2c2f2HT6TCW9m/YUhmQGWbNZKOmbGNeKF5TtkVTEdmpPW5F2HGtPFWNO2wALgPs6 chHwX2wD5jSUsgVhI6G2thecGjEobILCkUDEH/FFaqEU98E4BVXcZ8okfN5MGII4nD5c402YQUuR cmIs5aR+b021eBmq06mQ32cwJxPFFIcvSlZq8NjVry793qvXbF372Ja5z+dL1Jc4Izpr5O98Tafu pWbXOz+5dm+gNv/dDY0P/fXgk54KSTg4c+/MbS+XV9y3aNXoaqsuSNQ6Z2gvk15bGoxN/DsZ2btm i+rrRZqXHr1mgAEaLcCOIbcSsKiKOIdt4OOH2RUajKrsfLzQTfQ+Wdo11THF1eNc4ALPgffXrn+4 FGHnGy6y2nWL67iLCblwuU+ra0JxiNw0NSglrd09QlhRlkw4XFUq7ASPRNDNYnc5E3fpjIGwK8TG XVUGV0jGVBHA9mxDg3bidfi//rpOb8n0wYKIC+UQ1lWVQ0tGzroYEUtDZdBZr9C59EE+4AqC99Tt chtdmLjccoViEnfhJfxOh9HpdJSXlfl5t5Hn3XqDwRkKBl0up6wKMYQg4nJixs7bE4DHbl6rGMWP H6MYJGJV61MpEcusLgp3D7vrxPyQMU2LBaVGl/LYd9kPAwq/TPaDqYNwJyrDW8BHLWh1KV5QqWHP AdAUbgBw9zDckEJBB3fir0vYLbzFzicUDRtFNAc8106IqDs+RvG9mASMFXEWkNaSgVmi2WJMU3s0 FTENoOwetsIak9CEBhJiiWyy5FvYfDFmX5zuBRSH5/XBjyJvidMKa+/yQYRoBFW9qC+G+8Br4DUB 4ko5RmoyWszJJOetSSZqqqtrDNjP0EKzZbKoBodC4RqybydjwB0bDN4az9dmR2iuVT7xusIxM8JX lZ0590lk19/46rXKfLPSsaLM48dhb8MchWTm1y+xbUGOU1+y8dzjHbGw0RUMmrW99zP6rwfZWedO XBoMhrlgMBHYzvzdZ+WCFIN/WPid1AoYHMXLhW2cwaKPGKv1daEpqF0/1bSW7CCPW5Xdhiutx6zM jRgr9SqX0hVwu1zRYMQVVRC5S+E0O1xOikxGk9GIidFEUcigNxowMuiDgYAfaBcoN6pUKhQUc2RG g9xsKI3oDSazFlcaRpkmwWgUapxZo5CwZQXjJuNu42EjC7uP5cNydD9smQBumGkDM21gBtwYMmQo GI6Wp0ToCohQsNnTWfMs8y7zAfNRs8R8XancYDFbDOZSQNEtg6fPI0zsAqLg8bHYF4A0OD92AWVE oioiywVEoWjx/4MfRTo+hj1yTQrFAE9QH+7rw3iSY4VrvFwIvApSDpwhF5a/yNSK69+BH/u9MzVV pVbiY6o2b6XF481/P5Bv/KujarEiP18z2xE1ugJYHe5dooSFf4+xL68OAqsI4hKTt3Lb199lt58b 7k+G6IITld5Vdh1ztKGcgTUnhbdB9n0Ja+5EEZwSbFJiJlO9e4N3ex8MPsE96TnOjXgVUgUupeS6 1FaXklmj3nrvFMmCyDXBx8gR73H1Se8rQaXZp83ofCXaJldEoXBFIkq92eDSI4vThXRKrUsXUSrd ZgusvUUhc/GhCiRL8rwOEdj8VLj85mjEYtb6TzK7wE63DJdGfqE8yWBkIYZj+t1mbKZCLSo3W8xR ce2uv0imiQLNDJwBBJm4/CDIAO5+AQSZWbCKqDGiz5jPy7RvhFrnJ5OijEoy4J0gyUCK6TIgxIAl UE7wP9A9pwFhxmmoPANaj6HNfRgkEggk1u8LX1i8BNAyFUJhURqdF0cCMf/snZvy5+5d8p0NoerV iokPleu74mcimWVvbG6/bHjVtde1LZPMHLlhzWs7fPnbbyr1lEqDwelPMOz+Sn+FZOI518Jjy1Zd CaoVQfHCx8z3mX3gSUjj9wSr3CPzpvFN+KbSg/g+x12l91U8mzweU8bBny9YVMbs4+bHq0h16QwP UflsaZXGF0lpaF0GElnLLMtSC9MYxyoBsirBlj5hfi/0cYjBhGURrFgwFDKp1OZwZSIUNLNVprKk KzTKHAQ9LBzw+RAXQeA+M4WMJlOoEo4QDLv12cpRpkJQ2+1apak6EjJp1QOql3ErYsHBBeogYV4I PWcSoJ2JopXGH0whk9YUNzF3mDAU7R7qSpteJgdRGZxp0CMXEHdFKuWibS2hcMq1uyt9yPWpi7gS 1SaLqVqR+EERIUQdJ1bUcWin2ZEs7TQMjEKE1sm8yV/Ml0yWw0DEekMxP2gpqj+UZYPeE+vbHIud HddOfDFeRBgqQsZj59lBzJpFkNeOYV0G5K0uA39EBa/2zT2US8hAwmhPn6YKEAKUuUIUEpN7OXWg 9ryK0oVfoBSECGyWhAsfgwIEepEoKhiuKCJAOtRYpFK/L5RO1dRQrYem9DXVyYTZUgObtFICfJUK EUA65vs/MDMKmUptCjf72u9sisXMphsvnzVz+vpX79qyunGOKfC6MG31obayy3YfaWH2TSxcpJZr VXKta5F17WWxaNXsjiNtVTvWH8LL1ncLM65wNszLD+1pm/Xor343bybFvWqKe7DbY0EBLBG0ixxY psCcfA5aIHnRyYbohDvdKQoF4MEpnQREQMBqRZZ2zR8j5ril06rGXjuG01kR2CWyWHm1xqhWa7wB d8YbZjn1mD2gVKqDEY1aSw/mCCUcrPcB7m2O8BzmlltfAiSy4ABSw4NK4yk1PGgokhZBSAT08TQr KOHxp9TvqD9TM+pRXD8SVFvUQcUo4QcnEUZL2T38xsYn+vpik/wAZcfHs8X1lcH6wfpivbii+szn 47Fz+HNYz4aGnXRFATH6ECwpU01XwmQklAtgWIQwaKJcmqEKqF5US6UcmfV6/4FLLr91NP/HPfce wnG/1lJuikVXzux5ef+ipr6hkOT2ic6VM+7c+Wj++0ObWcsOk12t50JffVlzPU48tHjtwZvB5muA ud8AdB/BamEKEiyabIRGFaAzxcIVkSbUhOskTeGmyK1kv3df+Ah5PDDCDwe0PLITO2uT2MN8RHpz CF8dHgg/6WXMEpGxD+nSlL8PmUUA9Jg+FDkaIRFYIbVNN4rZY66AggON/f1hhzYL8LeCz50Jhhkl etO4yRZWwwJVqrPqWeqlarZEzauJ2l5KT0YJbilUZaWzpEulG6XsbulhaU56SvqOVCK1RWPzraJV shmMi0u0eaCyzvHxMZj9WAxWQNRbtW/2FbWqzX1AMV4wFCqAYuAkHFCKm1JKL9qMN8MaBieJQx8Q 12GSQJpIcSWAYETyqK5hHGt/ceXth45g7/7LNoScUT5aUqkwuNLLT7XN3bqy894lv9m57fCe+3Hk xKKWpjJfxG3wlBuVJo1xYNcDD6y+qnMV4D+QKNsN+F+J6vFrwiOcGxt9tpKsEhinAoJSqG5IKWik tKbSKaWQSEI2kU45FHblOsU65QeK95XSrGmWaalpXpL9ppuvLlWdnu6eXj+vYk/6Hvyg8QHTk+g4 HlWMuI6lhtOaboRDGP89jVVWaKoQIFLSqFEIphsFfwASzrTRaPIHQiHDBgVWKCvzoVH8dyEUqYhX dvqNyUw85Kir9hsZA6U9OOjE8IaQ0WAIJQMeLjNa+M2QO5OhnFtptWqUhoZIyKBFowwzHDpqUFKC UlTD6yUeSSkHFJB9oRpeuPWRFMjkVkHBjFUeRAatgRiKDNxwEhh4NeCAxgE44IBBOgRQzRwU0SJp CgQdcPVPHdhhazBYDA2KxFNFNn6eKoH1bh6bAOMTMEJ79lvMNztO2e958gRuC1IbYsp3J4kUUEek U5lIqCKVxzaDbg48OHYFvqJYAJvZoIcVkeNfsVgDaGMXiJpamUjEJ8R255926uRqvW+2b9pdgq/M Hf7OVXM7Zm5+5aFr1lRfElqu5FSgglnSjhmZ6/KftlSAS0ly+9cr+90Kvdrab1p5bbws03/tmfn1 e7YexHPXzytL4sVBc8Ru0ui44MQW4ZJ8/ysds/BrlO8KQPubgfbtsM+QF6pLtMqgVWsNsggO5xB9 l2yOnETkpcFaeb17GjddNl0+TbFItkA7L3gX+132CcMQezyoDdNpbwyl5T6w/2U+vTIrk8vkEgeS yU0eNOAQZIomtcPlqHQwDofSH9BzkrBS6akrMfEmYrKHYYuKkrVFA0uq2R2ZndUIcKNDGqyxhWLA VCclcOd/Ua9BXyecowNWSl0EsSJB0yXKZLRvFqkaeKeovsmBscBQ5JTB6BRZ2STkKJSrmmh+CKC4 ZiAZcZ/hPD1bJiXhebLnpGFYqqLCJT3LXbdw2s03msZ/fefdo9h81/rVLQu+t+n03X3XXJOuWv0h 3pHw9u6sX+X60+jGg7j2ufn1XTNXNEbtumjN/e2lqffAIsofyk9h3gRab8WrT4Cj6P3hheVZhs6h YV4sKxUszZaWDGL17UIkmvLTcrvNn0ICRO1A8u2CGYIVgkabaofqQXV60qhXeVm2vQ37BbiPH46M CNpAAEmTBxsD5Uh70BGQl6DsxBj9g0Ufa6DcsPIthxDz+sJhniGtLaw/wPKkNdwCuhcfBss8DN2K /S+6q4Held6Nb4uEeW11XaYqPkryQ5Yq9ShhBG3cIADBPtfGW/g2ReI/JunvLHh0JsYvENx4cQww GO3Yea0HlB1KcJk9p09rTu+RaE9rGiYNYHGVxGVlYb7g9Qgsn+CABOtrcGcJ+ESyPl/5wqyXRu2C 4byyBV4fsL04P0OoMQSCFFScolg9rwWBiQyKtb8mISYmZW4RA86TJzWjyAr9nZdPn7Fux+LFDaV8 MugImrSc3BBbOsOraXz+eU1XS01ZffWMx6bNXFwR4MN2udqWTbSmHdOYzS35jvwHj3wwrzlgi3gq fWazQcPJJVz1patK/0SeaLE0924Hl29nuT8esGkrZRpOEUlvrv8jUGdP4WNSITGDLzSKA0LYcnld 2nxlXVofE/TpGHXV9aqwzY/Nlmi7d2EkEo92qtAm6SjzkGBXcRFViSpawru9Rrfb61C6SyNet9Yy AHZP67ES+SZGNYqnDjH9JaPY/0J0g94tONJuQKfhuvqUCEtTIhTkIAXcAu8p5gwGcyruPuAmblup 2+IuVVx1y7f0ZFgp6qlQuikNuwU1RPSmZrUIJ7XgXuoC/Aj022+034tYL/piXFtUikSapqIYbjli EcDoABXs/eOGjMVnyNDkSEnGIpScdyzCSotmk6jIVhtEy4nqr6DmTgrvogVF1Sj849K6+mi0vq7m DaNBXWLK1PnbFrc1RVO2Gzy8w9wuMdeVRuvro6V1+S0TrVM1WqO2vMuydmq6Khicj09d7jQ7lWGg ZmQEDvoHoOYkHhHiKp8xkxbUJam0YEqnBW1aoVSorEqbai66WfeElquxZNNTLPMtrCNoC9nLmUnC 5XEYZGeEB9UBJAIOGdmIKhFPdoL/WxpR+JRw4iyb/Xycut9EFabyz0lKJw4hzIA5hQ1GozUUDgXC OozZcCSsiyA3r9Zp4moVq4yrkvnYKHYKpoh4S6PVygdCxkAgBIdNEEvZREIXNup0YRyGB6vCGFQ0 GE0ShhMzRqMxtUoajSjcB+1hnzIW1artafcAnFk9cdw6Fhg1joVeYSpBktyGIqBCx/CLQ4mfR+mK A3ZSOORMi1ngZSIErKJQUNSlo7ZU1CLKZ+DwIoV3jo1NfPTF+FlgFJdoPwLDCGU7KbfKNlAXMJXM 4B0GxRkYvkU0qGkRYE7RdQKWdRFtLvagad/kZNoGsJdovJPyFWo4UbYCgps+FGNAEMrcQ34/OE3A hSblOPAKWETTp2ghhUMMx/ihoah2c2kyIz92xYu1epW/zK/EI4qOy5KrPPPNnmqDwaizpOr9l22N l1oiffvWPIRnOiVBvyUhuf1cdNkjM21gFilCITYc6nDNnHb9ryIRXajLtm+Btx7fc1X+YXbbMpvB 6lHABg0cAgfqXwaY5cJRYQZ8JqKH8xC8YE93o27np/x/WViFRxlXCsrZSlbpajctjDjjLkAZ0MFc DK83GfV6U4lS746Y9NpvGm4AD/6LcMuAoGKCeqTHp/Tv6IkeLBlB4ZbrLXq34qqZRYqGbY++zSLT 1cN6gkWgpwsnB8NXL0SMYm44aC6WGvwmKPVCKTUd9ILWUawHa7jYS2OBUnWx9Yg1oxfM51m0uPLg QRkfO/vnvvPG8Hl2AOt9fk37qIAHC5YOSVAq6XMUNAKf+PuDfno3YPbfUrzOEz01nkC/gnVbln/G ZtAAC8u4l86uT4eSHlziDUUslaBALew1lhh10fn8LelQyhfYxDyzRWflwYmJkb/wseRy0JK6SLtw kw1jfW057pUvUi1VLzAuru2r66tf0jBv7lrDOvP6sh2qHeary7Y37GP2l+1v2Nf6MPOg5sHqh1uf wkfUj9Z8r/Zo5mjd0frnG55pe6x9pPZ43fFpwUur19asb2Pmot62uXOZfdV72+5rZ1Zlrq7eVndN 25XTHstIIziYCU+tnLexW+L1deXhEK9T6I7MjXfBWfo6Dk9vVivqMOpIVel0zVUc1wXnr402Gx+N AwHHFXV1fH2Tsb6+CY5zdE3jp3cYp0/vCCmnT5tWX1+niHaD4Giq75iu9Q14QTgM24zB+ChFEFsw KmjS/dEPoiQ6SlLHN9bho3W4jgp5U73gT9cLDmdqYz2unw2GQbDpufqTcDpoGmGOdTw3983plPgt GRH40yLgRTAMncSsrZgtLROzgqUyldo4/dPpZLqtO2qpt0y3RLsViUnpMrnXVMQVYBPjZ8+O92nB VB7v2ww+eWAZRVky6ZU/75A/zzYATrpXKbMo8pExcLDAnzJU+FMtH/4XCx7qdQeXqohvOrVVlWmA gHyqzAyA1fT1SjIlgHwA2CJAxcKuIrBA4XGDsQk25i7GdapsMlTpmNRDuKLLxWQ877sXJZaGFB0z F1kJlDP5J/274JzhpIzfcJ4lhfFLNyxoXLowXZdosUx97M45syrq9ZcH5FKFwpZJeG27Fob8ldFF PGGUqpLSyoHts9rvPeI0a73BhpdTtiV3n7ByEV5dL2f25RsPzb621iMkqmblcdU1bdmWuub8Nbs0 GgVnKJtmityaiPvj38HNG1UGvU2jie368N4/k77lXofdGi6gbTX5X5G93eCA96so5YBdyzwHlFON DwhyDPNWDgHsvPeFh2BmjDAzskozchBHJTuHmyuf657j2YGvKd/nfjL8eOQkORlSLsaLI69iZqF8 oXuhh1knXSdf794h3+G+JiSdXzonvSEEdEON5bQBAsakFOwvg7G6vXxhJB2v7kTYX4ZR+SE/9leB 55HjVCre4TE6HB74mqg6xpeVG8vggEtMYVU6aiIe2JTSGgcMlAxUXBBOBwWGVEHRvFwM5iU5OJR+ s/wl8BPFQNiViQheRhd7cVoEdSIYBhlHs8OgOInFTrFYMIDn6NMyXGarcVjKLI6ab5B70sKh2N05 PjZ29mJ8hn1REP8XBKAo7YoIDMh7BcVeiroX8HaPVrMT3IOiLQTY25FLgIOjGhwcgx4f3QOllg6Q Dcg9Rj+JgP9KTyqKwwtYx4Xx6Ztf/OHiRLPrapNWrtKls3xfV11FsMy31Ww3OMMzDvdW8ol7jnv8 dpU7JAV0ymBLriXdsDK/aLpWY1CXzjfcnAmXh+Lb8J0dpUabtfztR+eteoJcsdli9rLSAGi91B81 DDijhpOCzwnNMiJnpArmccPz1sOOIf2Q+RWrdJG113az4VbrQcPD1if0XLWhzjbVMN22QDZf323g FCqVLqDkGInEEmCV9Ms7Qc/t7uhKcbtbwel3iCOczQ6fiF0vhEV3FxKgDgmtaQT2FRLcaQSnIeJI QIfhxMIPHEUbdNKrR91KdBOw8xMwQ+meH42oYAIvQB8WnXXUi0ptR44KnaIPVc8MH8qP3bLvue9h x003HXly0bS7/tE//bZ/kNn35H/z7NH9d+HIs89P6VuRX/TO0jX4MSr9S0GQN8IsRNF/Cc0EqMYL YQ6exyyRL1HMjT7DPFvyjPUJu/xm+0F7IcbsY+9niZuHD47avX+MROOoE3bKPAS+lfJWqjF4Kg8J PiN4tDAXgWPfiOc9XqPHA8f0FBGvRxuXC/LZckZ+kgjw/QgzFH3TAwgsVFgyHiHVmPIIZWmPEIDg gwCmgEdwulLIg5HnkOdVzzueTz0FjxSoZe9IzGNJiPrD2SKaAaaBri/K9W+QuOjehmKR+V6MwKJ3 e3IzKxYzBJkLzJGaZGG4QI5TRiiqaSJeikWX4t47jh6Yk/SGfNZyi5clnEypK7Gnu5aVukulnvtP eEqMXlMtM6c2b8exq9rCwZaGcjdvkMpkGmH5Qy1dV1iuI5dtqNCrtHKY/cI46F5/gNmPoxeEQAJj iw+clDIlW2JVmkrqwpKI0l9yP8NU4iwcSF0KmjQ4NAVFxRsozkkCUc42CtZAyvSG1QKbmTolGUBv YAG8EbMxxm9q6t7xnPF85mF2eQ7A/J3ysJ7DsrrQQfuA7Q0rnXZDKm0V4hC8vtRh6ykrsV5bdRK3 4ZVw7kL7OdVaz4LAO9vXNwGYOCb6QxrGwCeShZj6NkGxpTLGDyqtjzo1LOK5Bmr8wuT5DUkzqLbU tq0AVybwAKgGK4n8oTEoWdvZNN1VdcPM526atsSrL7cEG4PSK1bM7NU6h5O3bfTYNWt0MRcQ9Vu3 XN0W9zZU336HsPZRn6oCt9133bymiK/hF+vTy26RMOFKwOBumMMV7PXwfZL0BHyh/L6wGeQlWGuP Sz4lX2uYeY4B9AVmAq46tEjDlHhcHrILEIm4kaYEsxKOQy6n24HtTpfbKrHBBwPIbLfZWJa5Cx0m WGpQAjPnzTbY/rOZ+YjNrCXTS+A7TFKAQ/IbPOgoVzKgOQlfRXKgrqj0ZqE6kzplfsdMwAAGXZen O3/8t3Rd0XAtMVPd1kytVzPdTILJ7sWwS6Ole/+b6R4uMGSqndK9PNBOYc7hOBBcgMpwEIBqEeDA oHs0koYG2K4RTdg+6iSkLDcJnoiLPIPnFVRwP4D3gRgveVj30LNOrdIWtXZ5F8+tzZTVep66V3H5 nQvZ6/OfZSeGljp1er9xje2WmlBNrHojuGrcV91FuQXlmacBXxvwvcJNsjpbHdGnq6ZWdTesN+8w XW1+1vQ6+sokn1fRXb9eznSYutFCE1ONGkzEG4lmyBE5zoSykVmRpZHPTV+YP89wxvqGBoNcEQrX ZurMFknS1GAIhR2NFcnkpPSMcQ1wcAw+fDU0gLO3AVy7DkMjyM8Gg1YxIO9nqJLoaHjOAFzVIFht KQMYxLxhlmGp4YDhkEFiAH1SUIEbRajAFUHPQb0oY+tEF+4wNKfZYaOpCMtSIgQPWCQVdwiOw+BI tDXKHRaDBR6quKq48QLnNM67CosOA4fg12fFGwHlUTgo2hxwAInqjkA/lDcBIcGaFo9ygNZ40co2 ZGmGriTlUlQ5hAWmC0pdwLBRAyRGl7V4MsNqsiozJuDQVD+shxCH4IYAz4AftUwmF/5ibwSsOWVr sP82qdZJOepqLG43TLZvIjU1zOnnw2qlLtrlntVVkwyXqbUdz3y4vEIoW+DRKUylM/iObqE6WBlZ EraZvOsHtzSbmc0Tz97s1+v4DZad9aEyv692xpf5T34hVHU8iNMbHSqdu9+8tSZWGazen3/5Jr/B 0vL7H74HO3FFW6cDMCmGN4LL3mRzEJlJ7iCwl/O+EFapmxbYu0pX2ftLz9glpaZKR4N5mmOpY3Hp 5Y4N/LrYE+FjMaW+nC5evC5F4VBFWgSlRcCLgB7ZoaVC3OJM2UvfxNiKfAPBN2KhkEaDOKfDYbNZ lYRhJVKJzuaI2Z28slKZVTJKkGMjkhtKdFg3ytQIKvyhbcB6gz02gD60j5LbBYVjwBmcFVgaIIFR pnKo9EMnHQoQNIVDsTQFQklFdcopeNNxp+Cc7WScJxk/bArXDr5PD/pRpIiNf9EHytUEHEGDMNEH gqqIAf900ufsuA3KK8eslZN+HCU9TlWGQ46yUgnq+8Z3CRbrMQcgA7UIhnQZYPLvj8BhJl/Rc9UL mgOc4YFDPLD237Bl2PqjUo4Ay8B+Min60kGzwWwBdbj9+bWNCrbGXBGIZkrcC9b/ribYnF9RxgVK /LakqxzzDXopix+ErVj9vw2vqzTr5P6giY81JlPl8/c+lv+klhybmImP/GONxyINtD6Vf/JGH3mS 7gigwqfPfL/gRSvBk/Dff/Tbcgb2CuKoCg5WtcGXdVPga6NpaDp8sXMJmgVfEcyB70vmwZcDC+A8 6UJojWGzvXiuVApfHKDOmTO6Z7fGutddtmrLJauumrvxsmWXz+4qn7512YZ1Kzq7ocP/A4E8dJsN ZW5kc3RyZWFtDWVuZG9iag04MSAwIG9iag08PC9TdGVtViA5NC9Gb250TmFtZS9QT1BYS1krVGlt ZXNOZXdSb21hblBTTVQvRm9udEZpbGUyIDgyIDAgUi9GbGFncyAzMi9NYXhXaWR0aCAyMDAwL0Rl c2NlbnQgLTIxNi9Gb250QkJveFstNTY4IC0zMDcgMjAwMCAxMDA2XS9Bc2NlbnQgODkxL0NhcEhl aWdodCA2NjIvWEhlaWdodCA0NDcvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwL0xl YWRpbmcgNDIvQXZnV2lkdGggNDAxL1N0ZW1IIDM2Pj4NZW5kb2JqDTgyIDAgb2JqDTw8L0xlbmd0 aCAzNDIwMC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSA0NjUxNj4+c3RyZWFtDQp4AdS8eXwU VdY/fO+t6j3dXd2d3ju9d6eTTtKdFRICqQBhC5ooCAkSCTsiSsImqAxxZVEH3HfAURQFhyYRDOgo +ujMOM484qPjqLOAM6i4MMMzwzg6kO7f91YHl5nn97yf9/P+9Xb1uXtV3brn3HPPOfdUrVqxeiEp IH1EIPL8K+f2EOUXmEoI3Tl/zapgPi/tJETzwaKexVfm867rCFHtX7xs3aJ8PoT8XbOXLJy7IJ8n 5xDXLUFBPk9rEEeXXLlqbT7vT+P6vmXL5w/XB79A+bYr564dvj/5HfLBq+ZeuTDf/sAmxGU9y1eu yueffQ9xpmfFwuH2tIMQcwuvU7F8C0JMuAXSE8lfSSN5hGgIIxJJkRlo80fxc6JCnter2NbThStn zTE3/l3r1ion/+hPRa/wxH9o1m46u2roNolocTGiU9rzCpynCWVbyEyJnF31z2NS/k685vxv4iEy XfhiQCgNNDXbhROkW/iU7BA+IscAIpFQIiHVBOhBOgdQ5Y4IHw60tFTJg4iTFUrcnyipOsQr+j2+ qp8IH7K9pJgEUHCs3+FVav7QP3bscKJuZD4xUFpedaxZL/yB/AXAhD8Ix0gif9ZAoqLqdLMRBVT4 ATFTSgJkp/B7kgEwIgsfDETjVTteEn6J+l8Ir5MFymmv9xstVbjgz4TniJUEhIPCgeGaAwMmSxVp XincjjE5gvAo4DjgNEAky4UnyQbAVsA+gEjMCAOAFKCNlwh7hD3o5y6cb0aYAiwHbAWIGMKnUX4F D4XdwlISxrm3CXcTO+JbhbuU+HHEHuR/hHI/4keR5/GO4fxDiHn9g8PlDyDvQP7+4fg+lHuRvxd5 Ht8znF8jrFbOWzUc7xRW9vsDUrMf9UFAGiAgdTdSd2Po7kaOIKTCjcIypQf7EVfhilfmY2BtfX8o ouBo/YDTXbUTQ7oeQ78eI7ceI7eeiGhz3fk21+XblAvXoc11aHMd2lyHUUkLK3G/lUAYQSgBggAB 474S487LMwiPAI4CBHITwm2AnTwnXI1xLEGvNgtL+xMBENvigXq5qul5YRGGWhYWDbiLqrZ+m9Pp OSEuGtCZhmMzb7tQabtwQFfASxcOeIryMVpd0WwS5pNrAYwUIowCagDjAaIwvz+aChwWLiRXaols CmxgG4QN4gaVmB5PrS8JVaQdMzBArEI5aUSDksCcRjqiW9ej69MJki6oS+tkXbtOtVzYIGwVhICQ EpqENmGOoBrMHenXNFQjkieqG6q3GXYaMoYjhqMGVUZ9RH1UfVx9Wq0KqtNqWd2u7lb3qPvU29Q7 1bpt6m0a1m3oMfQZBMkQNKQNsqHdoApo6M7mm4V5eEyCUAL0ALYBRIzxHJQHhcsAc4CNORi2y1BO EBLkJMBRpI8jViFnRjsz2plRakapGaUEIa9pB3QDegC8Vv1NzflzePvTvAZQjFoTrmQiDNcxoRwp wBTkjMgZkTOi1VF2Dj2UEAYB7QBBKTuOFKgG4fm69HB9N2I14fWnAUw5j9fJAIGdk+cWHymhmRK6 s4RuK6FyY1NzlRxGYLVa50TmxOYk5uwSl0eWx5Ynlu8S2yJtsbZE2y6xKdIUa0o07RJTkVQslUjt EgORQCyQCOwSt07dN/WlqW9OFedMXT51w1RhBFA30J9MVylxOMbjA/1uT9UIc/Motg+PMwfhDsAx gEACCFOAJsBygMj2IQywZ1D6DEqfIW2AOQAVzngG55sR8npex8t3AFRK6hhS7Hv1WAzZ3v6G6rbm KWC5cwA7AAKuvRfn71Va51P7lPIMwuNKeRtC3n4ngPdy7zfnCGBws3g/EAYATYA5gB6AirwpzMTi MJNfGWEA0APYBxCFWThmCjPZMzj2sr1CmWystAeIw4HVxmrRSs0SKwANGOluJbxfCTcrYZMSRmXT FOOXU4wvTjHeMsVYjARLkGaccLcShmRDs/HZZmNbs7Gk2YirOUmIGJldCdU8pJ8r4YVKWCYXhoxf h4x/Cxn/O2R8JGTsDRlHh/h5PsxdIytUQgMP6b1KOEUJ47IhYPxpwDgzYBwRMDYb6XaKPpCxSuhX Qi8P6V+fNY83E93z9K9kPK5H+xtLAoOMKBHN9Tc2BwZptr9xIqKh/sbtiP7Z33hX4AX6NVWWNPpl f/REoNlOz9DJIpY4+rfh+L/pZLIH+dOIFyN+gjTSGOLH+xuv5+0fw/kPIv8jEtby8x4l7cr5O+hk pfyR4fMe7i+bh7s+1F+2Dnd9kJRR3vq+/rITKL2rv2wzojv7y5Yh2tof4x1c2t9YGmi20MUkynjb +STGeE+mDt9xEq68DPmJ+ZNb+sv4WeP5DQbpuP5IJaJi3ssXaIS0K7cL9EeUhywiEaVzPhJROu0l MSU2UbPSeSMJK7G2P3I9rqJ+NnYi8I/G5/mDk79Tc//2wJ9ewPPNQPaPdHL/nsBbh/hw9QfeLBuk sYOB/4w8H3gtOkhn9AeOlA1qUfFS2SCjBwL7McgZtGX0YGBf2eLAMxGldlcEtUD1jsbywEORWYEH Ysj3B64ve4F3g1yJJ56B6s6yMYGpjXsCE2KDFNVyI24m6wMNkRWBehSPHKSTB/YEKqODvCtpXGPP wUAp7hiPKF25ZMRhVks0dLVcplmlmaeZoblIM0pTrSnXBDVFGp+mUGvVSlqTtkCr12q1aq2oZVqi LRzMHZeTXFwrVCtSmxpsmxJRSUtgjRQTUJHmGNUyzJ2MTWhlrdPG0oy1lbROH5sZkWwd1OQuzoxM tma07Zd27Kf0h53IZdimQUqmdwzSHC+62Zuxjus4RChN3Xy7l8fX3Xx7ZydtzRyZT1rnBTNfTsNz 6C+alVFFxrqIY02Tq8k6xlI/Yfz/EHQrhd3jk9/+XN8mkXIVZe5tndaRebqoM1PFE7miztbMxGnB 2R2HWC9b3jL+EOvhUWfHIXoN6225mJfTa8Z3ftOMhFkPmpFGHvFmAyTMm5EwHVCaTVWuBjINt4zf H0bAG71CJ/NGIJ9XlEaLlUag8V5+rXYeoRnzk6hyrSjz82agh/zFzN+9WAGhZuVi5gKiXMzHG+2P xXC/MgSdHftHxNBgf2yEUr3n2+qIUn2IdhLe4BCJ0U7lPlS5T/4SiXwbUMFwG6ZFm+8N4//XzMKx /y+uQAfm/m7B/JaFkZbuSMtCQHfm1jVLXJm+ecHg/gW/4xXBjBDvnjd/CY/nLsz8LrJwfGZBZHxw /1zlvH+pns+r50bG7yfzW6Z37J8vLxzfP1ee2xKZO75z4IkN41q/d6/N39xr3Ib/4V4b+MXG8Xs9 oZz3L/dq5dVP8Hu18nu18ns9IT+h3Kv14rG0tb1jv5aM7RwHBPJ4gBn0mA/d3lDnWIfUM0aZHKNC rh94D4sEy5Yh2ZkpiIzNGAF83pQ3lzfzKsxOXmVCsXm4yvWDUSHvYbp7uEpCsSUyliSJq+Xy8d/8 V65cuYrD6tVJhKtW80okMGlD01ozEy6a1ZFpzDS2ZOTu8Z2UY2318G9chyy91PhmI1veuKFxa+OO xn2NqtWrO1FsfSn8ZpjNCS8PbwhvDe8I7wurecXsjoNy447wX8LCalATXYVfC78Vbo0Yf55dtRqd WbmS4CYrAfnbJVcnx3U0h8l8SLsUknk5sQEigGrANICK/AfCtwF/AvwNIJIbEd4FeAwwwEuEcqG8 xXX5eH7HTlzxEHEJVQPp2qqRg4jnLsrH02bl45YL83Fjc5UL9f1N1fpmMwRvSg4j/AXgA8BngH8C VEKVUKVcHH3mv86VZGWSYrQIMqt4sDK5iiaRoHy4V61MJtGA51GAHMZWGV7kh3+ErlxNMBRACCI0 UspX8tNwD5w7/OMVYMWqHwKmkgDAB+3KS0juQ8AJwMnslNw51RUkkl2aOy7Y0PiZYSAkRu4lO0iU nKaV5BVyBJz8CYg67eRu2APeJPtgHFhH38BoRiBh7Aa/CIDvTyBOqiIPkPfJbLKCfESOQ2tuJX+g VlynhfRAa6zPfYqwlWzKHUIrPRlHfkwO02V0GuwK48gkVoaRiJGtuSPESRK5X+XeQ+4R8hGN5vaT SUh9TCyQzjeQO6BGLyW/yHErSZTMI0/S6+inkK26ya1ijbgldwUZRQ6QX9NWpC4g61Tv6Q5AOriD PEad9EjuWO4T8iLW0oW40g1kE3rcT46wCmGcaicJkjgZTS4kc1F7LXmf2milIOeKc2NzD6D0SfJX lmQ/FTToR5JMJnPI7eRRjMa75AREAQOtpY/QPTjeon9WcQtLK1lNriF96PkTOHcvOUQraSVzQj5k eMIScgnqtpJduP8AOUpbaSc9Ql8WdqnS2aZcYc6e+ySXI6WkAz3cQV7GPc7QNNrgDkJYWCX6xVWq qqHr8YQLyMPkKHkL/fgDxv3v5CtaiuND9gO2ITcztzv3EfqihewwklxEZpHlZA25mvwIWH2FvEr+ m55lOrR8U3xNdY3qdO5OjG2cjEXf29B6Gq59K7DUTwZxvIuntNAgnmIkvZBeTBfTrfReOkjfp+8z NQthqfxMyAhvCL8T61SqXAOu5OCaPKhkJlkCDPwAo30nnnc3eY28Tu00TsvxRO/i/C/ZKDYex2Ps TfYH4WZhq3hOdUv2ePbz7NncFtiexoPuOjCaT2MU/kId6EMJXUpX0j+h59vYs4JJkISIUCs0C9OF TmGTcLfwc+E/xRXiHvED1WTVXNUezdzsVdm3cq25mzAWFLqaH5RURmrICNDPIlDTFehfD44V5Dpy PdlCfgh6uZPshLw7SF4ir5Nfk9+TL4ABQkPo8+W4+5WgupvpD3E8QPfSl+lr9HX6If2SHyyMI8Hq WBMbxyawxexmHHezo+xddlLwCfOhf/fh2A5T0Pvg0qKYU1XhmKS6VfWk+g1NQjNJM0/7y3OnhkqH Oof+kCVZT/bS7L3Zl7Of5Gbk1qH/MVJOKtDTjejlA6DBXTieBiUeJD8lvyS/Ufr6V8qoChTvohFQ Qxmw1kQnQtSYTC+gF+G4BMdMOgvHXDqPLsGxgfbRG+iN9CZ6O71HOe7Hs+2iT9GDOJ6jh3H8mh6j H9PP6F8ZiJgJoOYYK2YpVo8nHccmsjZ2MY7FbDmOHraCrQGGnmQD7BB7V7AJMXDbuUKv8IDwY+EV 4R3ha5GJZWJKbBRniIvFG8U3xbfE98SzqoCqRbVEtV31itqrrlFfol6qvl+9T31SfU6j1rRDXL1O 844mp42BY/0Mz30AOP32l1K/SVeqCsW17BjmhUvoUW2kl2DE1Gy6sEz4ofBfqkX0tBCkH9AtwuXC FbnHhAnsK2E5ncFeomEhoGqAKec2kqN72IfsDPtEtNPp7FOaEO+gz7HlwjgGGwN46tuiXbxRdRLW gN+QBraeHmGvwXJ1Y+4npEG1nR5TbWdvkaB4nNnIMczqjew+nPSf7HJ2K+kQa1RnyeUY96dUazHe Y9gmWiq8I24nHwkR9jdoV/eCa/yKThGj7DJWT/eA4w5RPzlFe0kPvYfI9Hn6ezoImXi38CSdygqA rQwz0hEwtvxKCNF3BD3p5H2kcWan7ew0u0R4QX1UqIXac5T8F7mGCjQN2jn/y5KrMAPuZsXgaS3g Jm/TKuIi94Hfn8m+wDm26j3VraCzR4UycjFJky72BmnA3PgIRwe5BTa6w6DBTSTN7ifX5froAvD9 C8A/GYHeRlLUAG7pRN82YL1wsDB44Rzc+ivw/1+A67fSP5OraRAz6whJiLzmNrEFnKkb/PdWHAtI F3IPkzvVB1RvkzbqJEQMZreDyn9HLsOa8yfc3wML9R3gbI+KZeh1EJy5F2c8nJ1EZBy3kDcoI+vR 5zGY5+3iJHDee3NL8YSXY42aijXxdXJ57j4yDri7OHdj7lYyJ/dobjY03Gm53eC/a3L9pI5sVHWy GaqkWAMe+zp9FevRb+mt4NuTyAfgRzHqIp/h+DH6P0b1PNki/ga8syl3W+7XsLImYHl9AHxmCrjX leTPGLdJwhFSnb2Q7c9NEHqwQh0jF+WezAWonizJLQPnfYHs0qjAe/qIX7ULtHuruIil0d8S4qAp lM5W7SBEHnvJdLlpzOjGUQ31I0fU1dZUV1WmUxXlZcnSkkRxPBaNhEPBgL/I5/W4XU5Hoc1qkcwm Y4FBr9Nq1CpRgCpd1hKZ0B3MxLszYjwyaVI5z0fmomDudwq6M0EUTfh+m0yQnzcXVd9rKaPlon9p Kedbyt+0pFKwkTSWlwVbIsHMr8ZHgoN01kUdSN8+PtIZzJxS0hco6W1K2oh0KIQTgi2uJeODGdod bMlMWLNkS0v3+PIyut+gHxcZt1BfXkb26w1IGpDKOCM9+6lzDFUSzNnSsJ8RrRGPmPFExrdk3BGc issIsZa5CzLtF3W0jPeGQp3lZRk6bn5kXoZwqTmpNCHjlNtk1OMyGuU2wcszeBpya3B/2ZEttw1K ZF53smBBZMHc2R0ZYS6u0ZKxJHHf8RnnNSdc32ZxccjnG79b6xW2QEIM8sZbtmwMZnZe1PGdc70h foXOTlwjw2ITurdMwI1vA55aufqWYTd3dmTozbghNIyY8kz5p8urP7HupcGMLjI2smTL0m4gxrMl Qy5eF+r3eORDuePE0xLcMr0jEso0eSOdc8f79heSLRevG3DLQff3a8rL9kuW/LDuN5mHEwXG7yYW YsjzdUpKac5TrRd/M66U9zEyGUpDJjg/iJ50RPBMI3mwcCTZMn8khh+/ToqzMguAj8szunHdW6QG lEt4RJpRxaRIcMvfCfAfOfXF90vmDpeoY9LfCa/kVPINoWWwyA0TXSaZzJSWcgLRjANG0ccxSr62 vGzNIMtEeqQgImiPpB1jO7ezIYXBD4U4em8dlMk8ZDJ9F3Xk80Eyz9tP5BS0LNbNa46cr7Ffwmv6 ztd8c3p3BHT8LNZwQuwZbfybv1ly2FqWNGSo43+pXpivb50WaYUOFmzZ0j1Ms63Tv5fL1/MBxbih bjhF8ydiwDNiLKOOTY6A9C6GMocC/FWxCZGWy7snYaqhjxnbuA7By3ABnmJeQbkU6Hf2rPPX45mO An4tMaZW6H/BoEYLAlZKaHBCRuqelA879aHQ8PT6fzppMHean6VE3542/MyZhuTwU+WfMTPqe/nv da9gi9A6HdyJtU6ftWWL/nt1E8D3tmyZEAlO2NK9Ze5grm9eJChFthwSOoSOLT0t4Fh59A/mDt/q zUy4rROPsoQ2gMgZGbs/QjddtF+mm6bN6jgE41dw0/SOfkbZuO6xnXy82LjpHcP9VUYePeaYAMrV 9dTHTWQidCz2NJkOqED+KsTTEN+B8imA04AywDRAENABmAq4DnARqwfpXkbmqn5GJNUMEgZMQToi /omUiitJCOlJPI9rVgtFKPsTKdEUod3Pch/xOrTh50QQ96FuDMqsmtuJF+13A1qF28lkkeTOIp6A +41HPBXlbUiPBhhx/0ZWn5uPtAXp0ep6YkG6ANCC875GPB7tjbj3AtQXIs8AFtzHiNgLKMA1SwDj OKDtyzzGsEC8Roh6oqZ3Ig5CQ8mX8EHL/wQ+ePipIMVrEGuxs6wnBpyDvkEzxc4QJI5vf1ZiI4VY hR3QuVzEDWnBS3yoLlJ0kyD0RoL1OQJNkuu98eETixEnhtMlkAKS0Ba4zJ2CBFQJmaMaukMt5IIR 0KrqIVuMggwyGhJGE5Ehg4wdPvP/L9E4aFjA3v/S3QlK3SgyiobpAugEZ6DvXcA+FjpEWZVSDapX q09r/qn9iU6lX2M4bJxq0pleMe+RbrT0WR+xVdjeK5xvv8PxY2ejq9692av27vf91f/7QGXgltCN 4V2Rd2Kji8sTy0ufL5tW/uOKNyvFyr/WzKwzjGge+WT9Ow1fjL5wzLqmN5rnjbur5fjEpkmjJx2Z 9Pbk6OQfE0aBR5VPhW09UMIF+xl9nr3IqYK91E9U4iB78VmB6DU8cYASt1ategn1jAi0hOjoFfQy 4kpKXzYONV4onWm8YKiRNCEtnUNQmQ5ZQpYYAuoTybmgcOScrCJnMReP4PxY7oTwW1hOsN9NL5Nn a1Uaq0vltIpWk1NtMWskk9NvdKktBRrJZQzovWqLQSN59SodUVu0OqKR3EYXs9uEQqfJ4TQxe5FQ 6DJ6mN2r93n1QiElOmYXhUKi03u9g0KxrCO6QrhPmJxOnsM1C10uo93hcLs9HkoZL3QKhTZbUZHP J4rCcxqL1er3BwIqlZrXlWsks7mgwGDQQuozGY16vY44XS6vl+gli6Ww0N5k2uh8xrix29XjYq5B ZpSd+o1e3UYv3+vTqLFxCs42O9jxOB+s3sZGqVE6c+qEdOLLrhNDZ87wLB84Hn035HkJo3n+yDf8 l9KNqorkeunVjRUuHpn/5VeZpl1OW6S22haqDdmqBQ7V9gggJERsIcEWsoVWdu15viVHqO3SaZfS i+ZOm/P0oQm57Omuiy7NPjPnKjptUnaPj/7sYjqznf4sW8+hPfvUxfkUc9OZ4C7Ts1PYdbCT2UiD HLnX8qSF3VKw2cL09+ss5H5YgAjR63abwu1qqu4rnH4ZH4WuU0N8HEjTqaZTldCIaBe1x4vjrFYi I+xqNbMXOv2MXXffwm0P06ovr91+YcgzZX12eWzqojvolndoHc1dVTr+i+y9r727b8uTD6IPFejD DKUP9XK0RCzVTlIJuLkFnbBB0dPp0YH89rug7rPnUfH9TtAuW63D6bDaJaKprauz1tYUV7CK+xdu fTj75j+u3XFByN16nWpBaeuiO7NX/zr7iyy9KtbyOb3itV9ntjzBe3BVdg+9n/wcPHKaXNzJOp2v OgSds9t91C3oKNGIollrJQetcoFBbDDbA/Y+u2AfpKXYiTLPMTOz2/Uw6APzqOuCoa5TGJgT1npq sTrrORJprw1dQo/ikbBGHQnHa2vqqqsc9kL1VYt7dRqNIWYtrGxorRu7eGt2T1l4a7vNqCvUNVRX Tlg5Z/F+vipMo32sA3YzgTTJQabqK1pQt0EFfZb7agiESbQdst42upMepWoYpGoOYGWbPoujaqiL Iyp1CiHvStIWsoemMdXQWeaESk7JHbkTdDk0TANJyj4iqw2CrJMbanVyU+0cHd2h26djupsLll6j EP+KZJI/W2U6pvQ+/ySUpOTmiorm5leUsCIlY70jU3InhedUS7AWRcnh/rlaqDjqfpUKY6buNxo9 g9QsW3UeEpfjTI53x3fGj8fFuIUXm+bARLcBhsGdWOLcscPUjwcdHttTF0pdvV9ewDvBuzFunTyV RiPRcBT2N6j1TK2J+bxFXr9XUNvi5pgh7nI73UwdEi3zSEDtmUcLTUg5CpCK0uA86tUisEr2ecSt R8Btx4q9uRSJ0mRp6fW2GusI4MrpsBQyYK44PkJyOqqr6kbUWYDOPELZlNtWzep++LqHNr0975Xr r3y1pb63bpW/Ih2tL2kYXzuphm0/Sdsubt7xWnbfF9mD93z08j+yJ/ffM3fFXlp/8qGV6dDoadmH gYnTYONqjJiD3CcXyq5u107XcZdIXLKLrYESz0zNNtjdmsG5d2K9FpS0FukI0PgVnLEuh27cjPRf ZWzdmmHUpCqdtoAJMDH/A80ny1aTySxbatPmDeZt5p1m0ex2HmZRemJ4cJONF0jga5yZNTVaOPnW k7+fOkf/nkwqc7y3yxarthQ6HE57qHYMq+UDwAn6NJ0SsjXOzrLukQ69JuaJjRV/9ujZjStG+lks xooqr2G/u7s06A9waivDM+7BM/rpEvkGjctQ73T5Rte4ZARuHpj9DkeJplEzWfOURi0HLxVnaS91 znJdoV1lWWV92PCI6QHLXsNe0+uq150/d73vfN91PPi1+LXTbqdFolvltbsdbmeRS6NzGlyGohr3 RPdm59agxuVmzOlxF7jVRsHNVGoYA+yFGptoHEQ3dDq5sKCpT0d1g0K1XCCpPFvddId7n5u5DwvV GLjbBygr8A/S22UjUf+xzTbHtty2wSbaBqlGtsl4KA8JysG+oNAd3BlkQffz9GvMUyOV5cI5MAJu YFvZSzDrHmN/YVrmDhyGwfQbej7RmKforgvOdJ2SQNaNp4a6ehubhnr3q7kQ/dxWHX1J96aOka7e zuQJzlAUzFjr65mUb/LsevftbtR3mho3Sqr1r5pexTzvXdEFrgwiJkkqhGoJqa0BqtSaSF2e8cCM yDShqrq6EcKeOeeOQzkMbr9qwY54zP3mQ7t+n57yxNdj6LxlMyd4qCp7NkbH0vufuv6J1b2HfvrO tsWLf3Qge3qkVMl3naZhls8APqvo1ENEnzveX1Cv405UjQX1zboW/QRDa1h8U0dLSkaWyDXdNW/W HK/5h15DamizbkPkmoqno4eihyterzgWORb7bcVn4U9jBZO1JYP0toFEQiKD7MTA0TRNDwo1BwSV 5KCOQbrjQJGcTNUUwathQDKWJJ6nSyDc6tif4HcFHLBtCg6AyYFMAS0YpNtQXt5XzraV7yxn5Sg/ MEezAc8+yD6S9XIN3VlzpIbVwFI35jnZ9pKN2dzVnOGcPM9wTnB+03Wqqxf46eo9ATkJrCd5akXT qa5T1vpUngfVVaT8cb1ZVIdDkVA0FAuJalXMFI/rwVxSYvk86jcjFTIUz6N6XYU6PY8GjEWc20iN w9tbpdfjB4z1dq0gvcmkjaNJIVIHp1R1aHjJcGLyce7DlxI++SJ8HnLMapY07L/psZljD6/v67kz +/nm+amQ22NZ64yVLrov4gkk770w2LZj0vXdDy0Rp2y+Z2nbrLu3Vx68NnP97vHFRWVaVZPasH1Z W+vIokSzX3/ZTW2LNzzBeXgQs/UQsKuHXvEbOeEwUjNpMcpmQTbT0gJq14DhUkGnUlOxwGAkYoFR VBcYMat8slWjLdRotFpB1KgLsPdipMbn6cOQTQ10h2xUUbVOq1ZrVWJBgfg8nAIEoqWLZINOZxbo DmGfwIRB+g/ZRZuU6WWm3eBXx82CWS1rqMZt+s4c6m1UMNSICYTkxxC5SFNTfUoRtE5JQysaLfUW vhLXb6xIihCyeBJyFjjaCogtvSuoPWKJWEK1tBoRFQ4d3DX0Clt91a5slJ75YfZBuqhPuOHcbezR IZhmGekAve/HiLigG52TS1fr1uivNt2gez/2aQyCIl0vXCNe47jZKTZqE2qVEHEn3GohOEdLtaDX g8E4jcfNWJ5vH3ARFV8QB8xGbJxSGS44WA4NHlIqlzK5tLt0Z+nxUrHUfZiOIV5eRWySLWhL22Tb NttOm8bmLvl2WTwHkePE8LqokCeYCEiz69QKcAtFBhlmFAZsJnBGoaybZb6Yzlrk8/uY2hIzxmO6 CKhS8s4jIRNSUX18HvVZg/NIuACBsh/LF8ckCFUhU2o3CZrzvISvi5Yaa7SumqrthedJlDMc4d6b nnzsiui2O2795eLrfnnr3BfvpOavrhj6pXXihOrJMzdvWh+fqVoSM7b96Geb5x/PPH3b07MHaNFB OinbMTR+47TuD8emHr9/zz+DoIKp0Dl2YRfXQF4+BEfX4wM27xi4bcIdBwm3lqqEUt1YIhu7jTuN v6Cvs/foe+y4EUOKfUlilI0CU4kivKtkj8AKBYGJglElT6xV/ZGqEan/CC8ecIEHDu40UIO7QHWY nSQC+0QugHOPKIvt4k5RJb7APiYFw+IIF4Ix6pD3znCunZROJZsauTy/0bT+1fyAy7pVqlXqm1Q3 qUVl1BWuvAJcGTIYjdAQZEFN8X+y32Qbsa2RvbU3Pb26SDU1/s8Xxde8Fd0GrtVdB3rbAnpzQy+v ptfIhzshDFcHqkuLl1dfE+4z9BX0efq8N8T64luqn3Lt8jwZGyh41vNc/Pni1/SvGX5jdGiInqqN zKMrdhidnpgxZmqlt9EbjTebniKmUaSBwi2JTk7MoZcWz65eSpbSy9ni+NLiJdXX0uuK15RdV71V 3Krq0/Rpb7DcYN1auNVxv3iv9m7LvdaHHE/Enyl+pnpQPKj91PBZwaemT4s/rSrRGHXFDaSejqxS jdeSAk+xqASSU5H/1KpyLv/ZjEXNOvASHSifQxppCfNfIrVyLZNru2t31h6vFWsjL6BCwBwoxRzQ p52yc5tTcLprDtM/Y7/7vEh45hTnAKdOnMlLhXyNpFzuhnBYlUz5wxaHqLXHQqoIREBN0TxaVlg6 j1RYwYXDItiyn4uASUf5PJKyIPhWBkxyngyOTPBfgZn7jdCuAYVDdudUj7IYl+w5rXPKt6l5NMyh 6eZHu3751OM/X7YnUz/1g/0vL5uxjlauldcsWtRXW1k3rf32K5fdEJ/I9ty0c8ZNL/WvmLr9ik0X Lurd+sa6uStn7X932fq2y69e01azJJX9ZMKu7usfumbmpPql4EEXYSbsBk04STEtkKuvLX5f9Zvw +8XiEnGdar32Gt3VBWuN62xXB2/V3mjDTsfWEjZKqyp2hYpdKsEfE4lGdZjOJy4qP1vcDm4KziTr UrHlMUhrBGKOut+kAo+67VmnkxhdnAN5qBmO+5I1aBWsg3QhuFGJXNJXIsgl3SU7S46XiCXYF5VJ CM1k/Ut6pncnvreGQqjki+jQCa4mQ27PMyco0WDFCrYQ5/FV6o1qLQVxKeaLR+IBY2geKTJzUV2L VNDgh7xuQRDWxb7LkpJAFEdTl5PrfSOAF6AlL7TbC6HARyhHUB5Dyuq57Ibjb5U8smHrLxdd+9Mn r77zDz999EVWbR277oLOWzqb51T8wBdjq2l038LfP9d/61Nb9pz9Y3bd9UvZoRsunPvh2p3b3756 RhmwkIHetE3IgB85YQ8V3Nz9sMi4uG6beycUDploCsDQzbId6lTNNvtOO7O/QGNYN/4L+rSiQoNs z6sxUMvodxQq23fSNATFiitXZanmsTwWMnktq6J5yKYUVFSM5SvT3OwETRk06LFkOv29vPQJ8kTz F80CGIdPctt97e5LfGscGiqRxEnyWfPxGV+2iB3tT9ifcBydIQbbgxcFL57jEkMkSIMs2CYuIQvZ 4qKNRFwHT4CzzcJ+bfPYsdVjSdvFlWObGRENoqe0rbmaieO8ZFAYK+ukMXTMEjKOjkPuubHmCfCg 0PieF8bi/l5h4oGp19f5J8B6c5Fcp5lQUVOnv3ixOLKy8pIZhgmlTZ5ngt60V/YKXs+M+pHmyX2T 2eTdtoZgOB2Ww+1hMey+ZAZ8LAZCD1/mGqQjbk4mLwTXhZwM0flLJBQ6Sg3hdZgzQxjUoY+lj5qa Tkl/7xrq+kghrzyVgcik1zdKJqjB4AyjxreOGK1KT5w0YVLLJEE9qqGxganL4rqYPR6MWWLReAKL 4vjRk1eR1hGTi4g6JRYRbblhFXUEIPivHiCuIuiwq5+jPq/bI8V4mVxETMVoMalh3Co6ZeTUIqJK w+ysT2pWkcKQUznL7cvH1ogZ+QO0oMS8iioshy+uWBq43MKT3/6ghCr03YXfyJHQA6hwnsnAyMGw ySnC3mIVq4PEVs1ICLpwrWQl1VWiFeQ/PBvU+VjRZR3OERq+9AxzKqiymB6qvtXNvmRw8q/u3JV9 ++An2VWfvEF73qEa+tSqhlnZePatP2eX/PEr+tLZN+kFP37s3OapF1jv7h8/8aqfPLzy0nGdUuiV 1gt620dNLGvouy04crLwYrb3+NposOxOOql/Dw0/9PdszVcfZze9TMFLsn/O7v2QPvIV1cJhhO7J PnfouewDj09qHnnpwNINS++gS3qntbRcZWtb9dq2jqa2judm71gw9kJQOPYZVBlYHeElzlz7GVeP ZCsN+Jm/iECOIUUBCmmm8EXhj8QJ0AD0wh9lp5b5/IJZ63MUkUAPPDwYpVoz05JUE2dEvzr6q1SK k4l06tSfv6Cp/E9av/HVVyVAJadMrclsNkp6vy7QHlLbzTbJY/F4vT5XkToEZac/VsujgXRHjRIn K5S4vyRfHIzniz3+fLFTKe63K5F8n2SrMZoNuHi9eYp5gjTZ3xbqNM+ULins8C81L5aW+NdIfeJG 0xbzRmmjdbN/U+Ah80PSA5aH/IfMh6SfeA753zD/Qvp50S/8vzW/J31uPimd9H9t/kr6uuhrf5nO 3OplAZhPMEikyO/36Ux6r87hc3odWqbxau2WQq99rd8sBSW/zxe2SIWWHgvlm+SmQfa6bGH+Qsb8 gaJdBI4XfOAG6QG5QCuZBVhftVqd1gfXeVlnxjlsl0m2DLL0QJuf+gfZF7IpKJvaTadNgunJ4BVb FI7n9mDOujwS1muu6XJSR3gGBqqhxo2miqSKm0K7TDCGboQem3QR6RSVjvx7uFFa/2qjphF/rul2 fTNV6IquThpS6JqbKEDYI2g1zdsrFPObgQlPDf1tdnjUvOwll7irx9DfR+h79V3Thj69qD5x1cdf 0J++21YcSGliMbMrfZc4++z9my5SxWJiRahsDjWy6NDvuEwWxu7Vx5BE/dgTGcnWy+lZZJZ/M9nk 31z9gOeR4r2evcWfej4r/iRVMJJcU7yu+sGqB6p3RZ+ufs/zXvF7Cb3YMMg+GTAvrmvgROML1/BY /pPdWVMth8oQuP01VXIkgcBbVDM+Oj622fM+fTf6QfVHMY0YpTFjlSTY1V5Pod8RdSTs6YqqluiU mpm0wz2r+F5mkYjUcAmdFe1u6Gnoa9jZoPWkPVXtRJA0nqg/4U6Jaib4nf626k3RB6PvV2uCDXJD e8N8Nl/oVnWruzXd6TXqlZ6V3h7/qujK4msSN6lv8d7i31rd1/CL1Aepz6P/jLo7teaAVxcKSwGv IxSpjhIBjie1yUBUCJeMLKsWKsKJ2lqdoyThdDpYRYJTyjboPnyuNNQq0Vge9Q00Ndfw7MC4CUos F6J86hwf1fvTPua7REwGRpZV8uGRWmqtMmRwrD07xeOiIPJCvdFSQ0QaFCkE+7fkWJnaZmOXlBXA +IXQaEQYBi2bJXaJOciz5u31DS/Qt0iIzKUurMJYSJKwep0CBcHqkuzq5d6vlUL5p/C4R3SqE+wY du4zXSt4k2RyRV6AgRCDxSR1SjHGwCCTV7K4lQwLS3OqJpJw+anG43V7mVodj0Kwqo4nXPFqmtJU VtOIP14t1NDKaqHYW1JN06qKahIrClcTf5VQWw3TEBYAvgQodkh+V8U2AFWVrlixgqzo/UZAhWNQ F82LoupIqLa6Coyc2+RgFQjBeMBF1JiDy6J5+VRjyculiiSkEfpvnzC379hHQ33Vl8ScRcUXVLMp j8+/d/t1Q9fG5tTfedeFrxxe0L6q98CLM17ZOqbDy571j51988JDl8TqIiuEZT8IlcVc0eeuXvSo WaNpuuGCq3c7zi73Pra27c7pInajKKy/H6rM4NVRyuSxOn+KplhKSAXuNT/gf8z8mPWg+TmrQetH 76EyX2tf67hd2OJ4RLjXs1d4XtAVCCaRFU2CI6MqpZUsUcgYVHWAeSk9DGmj9WDwQVXCJ9BBduwA nEwkKg0KzQe2GncYmXFQSMmpQh3bi00DWiXt3WehAUuThVk8MghQ1xh0UbMrgG0ehTxck2ML5itq RLJrxQXcEvflil4IFL1gT0Ow+Jz5uOnUF2fAhCBjSK8r6A3aveoCGDnjhrgjpvbqykmBHYHWrSqn eqcRW9zfYC4vla7o7aK2iDLofJnmOBjhVIuRIFcerFFu5uGYGyG+FQiM+fjRjR+sX3Pq/pt+sS6w KHv6+ey+Q1sO0qaf3LW11Oot9BhUV2Sr3zy4OfvOscHsX7f17i48sPufh8+9Qac/P8lh86a5HBjB KrkO3MkBeVyQOw1eQ9Et0j3SryXVGmlN4UbpftsD9te9rxe9I2ldFmthkV/Q2OlGzyY/S2jVAS/k B03AawxFnCF3IGEyGZk7gRfFtL7GNivNKwFpq2xVWQdzfzjI55R1coTPxTFNtXKEBiO0J7Izcjwi REJOZTY6ldnoVIbbCamjQMJsVCuFag8/X709PHcYB3wuDoHgYYeGYSb5pYKUb6dcff3wFPN5/Ga7 FCuM+82+GdRjR1BkCcygXpt7xvnh52YKzJiu3urvT4wgpCIJBrVijDoBr4TpLFI9I+rw8RmQgGfr 6Jf3vpxd/dsNM07Squx/np61MjYitFJYtiFYFtuSffHt7EcvvjPPRyfAr9RNxxdxWi/FevAsRrya 1slNcu1i39W+h9JPufamn08fr9XOcPeoezQbtBt0feo+zVbtVp0uGvAWhcKxgDcZimhlPiDakMkU 0Hm1Gj6UIV6iCTEWUHs1PsnLaATyR1E12ZWsIOUSN2Oyt7FUlCVBULuKvCd9viKtbi/eUtrbxG2b 2GDVtGkEXOtjuV251pqKvWXJQHkKpy7z7A1CojkGaXtae20PFG2hlkgKqiQFK5KCKikciyqoiiqF UQVV0e01xw/RjYr6wtGk4ApzpuvUGWyFAl1d2GVSVvYvsKJjac8qSztYJXaUud1NOvUFkf6exHxS 4uF9hS5qCfEZAAOcYtQM8T2Gaj5PUAbjNZ8e33I2PpfA4+BxXLqquEYdi5lM1osvyb4rJUZ+vHJJ ekxzYvXZz9PpZNDpiU5Pi3Zzsb26KrFQxYZORipWZRPzfZFEtnlWsTOYGrM+uzfmlOT5Qu/1/kQs +5sr2u1mjtEQMMrfGCinpfsTqUHql0fEFtTpRJ0+kxLuTx5O/jT5vvB28lPxU/1Z8axe16PqUW8A jvtUfeqtwLFWo9eVwr5eAAN0XDZqvZqigNcZCquBVF5SovKqTcra6Q9446FIsiyh1xaIKgZUY/id eIsjThJSgiU4pmPF2Fl1OLXFycReUkJJSRrqdw+07m1qNV40btPQlxQ1/oBcQUwKJk0K0kwKJk1h f5GCySKlsEjBZNH2in+bdLCfrmiEQtWr6OnA3p+7gMU88oA7/DkKwd0U7A2dj2FIBYfD6kktHGVA YgWLRCyFTm4GxE71t9MvvzLZeD197B+XtBljMVrcMv4fRn2wLF05dDg9Pe4y6gNYRoX/NkY8LQuX Ammfty7P1rZNiWVnLA65ra5YrDJ4jbAsn86+O6cTLiqUTMJq8zRWmxraJU/XixMqmLvYk2CSS3Kz YJ1c1123Vtvj6nGvLd3m2ubOuDJuQ3lqjWGjQXDVVXja63rqbhOfEY/XiQXCLYYjdcIkLfDi+lvY yrEWqVHWnwFl/cFrbURolcdVPlgGF4KwOlEmmBJhHU0G/AVc+PArg+xXc84Gy5Ol3brNyszWNivj vHODNQcnCZHPSSsY6IlnFQY6yL6SDfrG9jg1xwNxBoHotAyPBXZJXOL18cm1CyA/w9SY5AwR8ywF SQWoUqYfbCp5i0qjdH6lGuaSNcGkRtLGEsUlxaXFgroAgog5ZBlFgwHJoknqy4kxgkAKwgqoK1aX U0PMVM5li2+V0NK8YSUJMaOLctGDL2TAYpCL2PmVzMINK7UhO9io2m5Rq/PLGiZuHfa3FWPLCPFT CCTT172YHdrYe+/f+lpvaw40X8yM7guLClce35y9+pcPzFjUf88bU9YtH2mzeQUscdN3XrT6V8/8 5ZXskXviMbppUVMoHq+JXZmdO6bh3E/+MfD4f1w+01Vij1QD83y1ewQztYVendcIn5so80EjscHc lwc4RmI1g7lzspUnaxTar1FQVGNDA9nGi200rOAurMyX8GDuJHYBgaKw0jDsaZagSRYBygApQAXc t/5IdIAmQCN0TMNoEo1WjGYVPj0jTSlFs/wVFMovvlACmsK4Jo/8CphLJn+fPFKZTnrl3p6JOyce nXh8omibuN0n17UjyUBxhlA4HPD6QuGagLciFG4JeMeEwizg1YcitoDXG4pg4SgPRWoD3tGhCEYg Eo16x4webTDoWUV5uc/n1VptYSaH6bEw5TaUnvDO8NHw8bA6PMiCskea2D3xyEQhOJFObImFa9ux K8dqtk+Y+ztX8gLpzAruBiT1rlCYgeIQNKylQVfLswL+JPynOBNQrnANb4SfJwPQwb9OfnD0/xs7 UChHbae72BrwgWQ6zcYrzBuMoCydHnohPS3uHtqiVFUOPT/MIlDDWjCIEOR+Q29akmcMTql5wbl7 vuUS9JHs/G9zwhXfacZ5RjWEpbWgnAB5WV4eUlbhkEI6ITlR6w7NtSyo0wa8LBR2BbzWUNgd8NJQ RBfwWkIRqwWMWotNZU49bi2fqm6RU507rOvR9mmPa4Wclqa17dpurTBHe0R7VCtoRd5Mq1CgdjD3 1bP8XCSychGnNe3cYE+oL3Q8JKRD7aHukHAkdDTEOFIuxFznUx+TvxezPi8gQShqUsxEGAT8Yv/O ZodnZH7c2dp/GToMqjKkse/xU85bz92tjJki1+Q+FCwYoQj5VB7VYqVzbHMK2QJnj/Pmgj3mIzGV 1UXTMTnGPNr8QGGNwxA5XD7J4YbHVLpQLmTthbRwUNAfcCeMuiLfYO6fynMjceZZPh48IYf40PnC Ol1aK2u3ando92lVL2mPaXMYNWWIMUyfyYXKMDl4W60ndgxS//Eo3uquHAgd/xHX5E50SV8qgwTp UeGMYIzYsYUng7JunZcdJY9XX+Ap8I2iBr3X4B6F/XHoW1xU5zvm8NM5z8sKwczOG5LznExRrsD+ fgnamxZ3jXt81WXL3KGyYHWxM+pNKeOpKlYGdOjyB168vaux0h0ovbRu7HRh+zdjWgLJ4jmMaZBk ZC80dRqEyVUOz8QLQ1ezLcEHgk8FDwULaHiQ/lCuNi2ou4TN9jNQnRAKO0Z4LaPD+oBXCkWCgSDc MGUYIz7xWfDdhAgTtGQvXcYG2atyyvE/id46nV7hanqFq+kVQtRvD83tGl5auNStjNsZvo/SeAoC wIkuLnLzmb4iiRXAOSyLfaNk2uMwRPKprUhrdeK9oVVnP66eEbMrwvSiZTODUkHVjfMf/sESerUm uy02MrhKuIIL0jFaKq87t3dawF5YsRpzERYV9V8xKmn6unzS7KImonWa3MaEucRcKqY11tF0dKrT tZwucV2ZWue6jz6YesP1gesk/dxlNLqgdqnTE9JCnasuPdElONLFrnhaULtUaadTSJIS5LDP5ax3 1bpr001VbVVL8HbRGtc696r0FrLZdXP6AXJf+inyRHpnVabql87XXUeqfgfHkqNVp5yfuT5zH6/6 kvzT+Y90DJ9YcE5IzaKdzhmppc617p+6Xku/63o3/ZHro7Qpbw8JBryeULgi4E0oHFsbiuQtJKGA txgaFQQGQguJy02o2wVHw9flMelUYdrlTKdc0JDRdzipuJ1Mp8VXbNLp4oQ2fSm4lDtVEQ4GQztD mRDnCsdD6tB2uYpWwfMRlzBK5qDZwm0blQq7AK/gPBwq1JddPAH6T2WBUMXcdt5Fke8L12/UDpvc tLC4cdvb8EcBOGcHr+nthWAH93bZm5LgIEPzgVTvclnqXZK1nmhd9c7B3NEDznpnurCemyu4+ADo pJhKIcop4/sSIBcVKP1mhn2vmgoThs54Y+3pbCINfazQ1AqfN/oFPUH7UjOhn8XaU0NH0jMjjqG/ i6vPrVkfKI3FaoIrhDWzEkXFsbO/FZXsuS3fVGw5eyu4WO6j3GeQDadir+xluXWLlVq3wmVUbqvd yqi1iNFiVm4baVtrux/+OTmmsYXDVuBMHwoDZ94QXoeDnStSyPEasVotlLGwNVxotYYxQ38km4v3 wqFDR5nXo7XqBAUfBdZpFktQSkuyJEjYn37WAuQgkWd4PKGozdL2EsWuBbW5hAb5h3GOl7ASWyFH qT0USofpkTDkEkUOUYRByCWnYfEC+wu7E3PB8hSBEIsCn7cc3YrGjFUC6Y8VJwiugUEfOwXHB45d AgG+XkGxhrsCkq4VeCk9obO6rSVws6i3tpEp1jlklnU5WWq9xvoQXnp8nh6wvkH/Sa1/YZTLgJ1w TaG9IIlDhOV2D/itTQzPMOAwNkGYPXkQRCX76nmyfzjyKrmD7nqsljz5nmy21lsdVvgu2QHueghh 7/Ub6nGZo/noqwOF9UyG4xkoif/OG8E4VZEuAUQ1bOAaXt8i/0plinLopT3CaE4x9D1OS9FzN3jj bSAsTkijRo8qGqWaek4jmM6TytnN4vhzPzmfE/a1lNl0sKRwrWIttIoC4iX75cr7rLs1T+mfksSr 6TrNRrpJI47TGhNEsCfUOlcj/5YUg5FVCAppQRZUwuQijl9PU22wSC5iRZZG/v0pZtYF4E852Tds duJWpwuk3uSXPPGtT2MV9XLfRU/cFjcVWMrhAuIqp4UapBwqpCS9sZy6GQKr1l5OnCKC7w5W8npM YKwsMG+EeDiijlteLIrjIl6BgzZ5CnsvN2avwevFJ7M3/u6lfxy8avMPrxx46evNV0H8Xp59J/tG dgnc1BrpuF/un7xxd/aF7LMDeEmTNtPZezZxKxM4tpjErArg2zVrD5EKPOpdDbWpitWuVd5VvusS PRX3+DTrXM9FDyd+6/2t74Oo2l0sVSTi9bH64lGJdMWs4suLeyr6Kgw/JdTjK/G1+n7j/q1XtTtB fxF93/lB9H1Yyj+Pqn1ypCihhaqsDYVpwKsJRcBo7aEIKQqWlRYlmiJtESibGnspbFR2ptXARdcj wd4te3o8Ks/kCo4CWKZIBZUrMhVsR8WRiqMVQkUZVdRkqiyFVBH7adhsUmbbsO6srI+m7eUVg/Tq gRBXlhVj8b9YqLou4BbjeN5ijOhUpyKZ5e3D3EGsnmvMecOwL1ri9LliiXiJE6bgqA9Bsbu0msa8 0GSGKR1Wq8nT18mSH+wnMkoM+4OjgMIAgYwCKYUAsdwdYQWUMUxHaNz/xmEV269i+oXwUqxYf/N7 3xr6uC9+Qc3Q81ifC70wdtH/Pvhf237788oVzbUXFy25b9JN06vb2bXZ1X0BrM8jA6uEZTzV2n/N E0dNE/X6R/s67mu1AfNc41oCzCdIDWNyf9TF5biYMpIbw9R6c/y1yGvlwuTok+XMFXBWLIrCfVoX i8fw/jrFO9HRa+m1bGVgZXBNeG1sC90YvL8c7/PHnou/UJ6L2tXBm+ht0ZuKH4zuoo+zJ6L7yl8q fy/9l/JcuRHv0lMPsyaA3cqGiob0oujlKX0p9vZ81B7wmkNhEkt4CSRRE2RQrj9FZFYWi0bDjBZC XI/uZUGmKS3ZpZjYnLzTMJO1a7o1wjbNTjgEEu9eX80gvUM2VyXwIgHDHhhs8VqrssPXkd+sa2mr JaF9IdaGxZiFDkh1VIbt4GidUFejVShKq4yDVqEobdhhVyjKrhTaFYqyb6+de4i6874roIxheV7q 4hpXUvn6RipPTYgUahrWv07BW8Ba37UilYR+1ogt51PYMVPeGqDWeg+oU9krSyoeoJVpFzYifOWV fnwtrTySqqaVfgQV4bJqEommg1XV2HIGPXHmCskXFmro9nypx5dvFBdOirWmv7A+geXrIPgxGDWS pw9I9WnJDNasMGXCl/lkMhSiXE4u/t9IUcP34ODgAPuQ4imjUS3By/y11UGjX/LFp9YqRKkIjfTP 7/1q62N7qKt7y/Jzo20+3Suv7bgRe1PXYM82u+b7pNn01Or1g/Hstbd0FLC76e4bNuzAJzwo6ct9 KKrAtUeymbLbek8ZPhdlZgZ8PE1MkBJVso22MZ2lYZBOkI/WjazzCF5xjmuOe45njletMqpMpPRI g7jKsMq4yrTG3OPvCfSketKbtbcYNho3mm4yb0zuFndXS1ZjtbHGWFtUXVRTVMs3N8rFoD8YKCkp x6biGNYkpt1pfzoA1+6a0bWTjJNKpxtmGGdKM0pmJLFLHWDe6kCtt266a7p7uqezanb17JrZtbPr Zo0wCQZDic3gLYkYgg2jStINK6wrbJuj92vuTz2Q3p06kni59KfJIw2nGwov1I704sN13n30TezL bqDDeyOysfbBSnjALw94/f7DRdgtkWvcDxbCnb2xwFRYUGBKFpSaxLhOieAZMwTJO1EpRBJ8z4TK /nANNov5Vh2NyFLK8pKFHbPQoGWf5ZhFwPbuxucCe/1JiftKo0FgRwV9qeIvFTmwVPjQyRVvIiOQ imBFGoxWrHiBToAn2ARlq417ynUle7HMrTjDXZxXDK2oTykvEzRxo/GwG5Cznu8Dm7gsSr6xZymp Lir1YhdG2YOpi6Y1tkTcUKarJiVmzkxtCDRpZPXlBdXEUFCWLJbAWs2mktKYFexVm1Jzms97Vyi8 NC9YgPpB+10QhHTzDYuMi6X5SbGrE264K5J4hV6RfgsMLnO9mDbXVwP4MttJFRMn9/eCUcMPGzwm gOIJD/dqS7Wf5cm8OB4ddhnLm8GEPTFr197ZSzYlx3z64q2tf3lhVE3gPzzuImw2ezoOLFt/x4iG 4uzjd009/syydSOdnpAeK3Fy487LNlw0prp1/aIr777owWM6VRO20t66847um2ZVLSrz/8eq26bf +XatO5DilD8Ga3JGWZP/W27AZy3YrKJZ/ivoFeyKoiv82lSoKdQWul91n3e36gmvhtEiP9ikFApD uzSHIhpXBG4VklkbGmRHZBssmkR2mpqsZizx7fiwBpwjWUL2aHUKn9MpLE2n8Dld2OkIJP18qTXx M4hf8s/x7/SL/sP4SqAj94Vs4FKsQ+F/Dlx9ILgASifX1s9g5A8RP7aFDbX8Av0Gcw0GOImXEPKq qIIZIhtqAeerPlaW2CGYP6j0Ot+V49pG3jKJrc9/4UPcLgm02MRHzXGDLbB4+kuQBFNDL3Ox8LE5 iZopmrikmpp9ZXq0YcTZM+dFQLHAZFs2G55vGFUrpMAf81Fl1mf1ZnWA5e2MzzqoX8J24x+fMwWY Q2PCAsKtfk3S0NGjR2iKu40UWKUQdWgN9U85qLKKuPIOIdW1eYeQspQSyzcGIzV/s54NnA4Jh52H XM97MqGvNaqn3Hs9L6gOqg9poL48qX5K87T9SYfqIc028zbrg45tIdXl9gXOVeI6fV9INcsx09ke Wqi+XKO6VNOpvVR/manTrpJD7fgC7kzVNLUqGKoRR9onkMkmVUxdokloE/aEQwXRIpSGseloSDXs sOojplBQ7/A4Sh2CQ2Pkj+g1qbG7oA2YYNhsbMKWwGuvvYZ9AGzaQLrxyoVERb0E23Fes0mLxgGn 3xsYzG2ULQ6NOqjVaLAKYjvHrlKruWqDV7T4CyQBM5ZXwjRq3VkndX6SdsiObY7TDtFxMm2X7e32 jP20XRW0d9t78J6VaB9knx8Mhu4NcT8SEE2XG/tNXcTFjWB8MnOvW84zELuUxP/ddQS+zxChvv1h PsO8naQruKKr07vgGy5b6+FdcPKgVK/V2uohLrx30FavT9h46Xv7zYqiy0/D1/jw1hvcqDTw5eUb V8WwHXHPLCdVHA7hoV+r+vGkWG1JtjiWFYsl9+QxrPSykRX4hJGcamhRFaimxoyhyoVnfyDeMasw EIGnia4iWrX03EeCZVV5Ua2BshinQG/uQ816UGC94M/T3kEdHVkSL7SA+rhChc/P+HRpr2iwMgO8 mkCGzvomhRC/IUW3Tm3U4FOGOo1en1bXa6wml62+AODFrBvQ6moQ9/EYBrk++SQSdbra1BRdp9ih e1KnjquT2jJDoiBhS3hKvKWJ4so6db2nJj1RPV7Tapjkna7u0HRoO/UdBR2ejvT0ysvVCzTLDEs8 S7xXVK8R16jXaNbo1xquLbjWs9a73rc2uDp1s3ibdotvU2pTenPlnZoHDHfZ7nI94Lnfe3fintTd 6d3ap3VPG5727PY+5Xu66MnUgGZA+5x+0PNs+mfpr7VfG84VfR2csiS1ML2kcrNOHOld5l8euKpc XKhZqF2iE1p1UwOTEq0psdM7M3VRWmjXtGtnGfAiAtzBDAafI1XqKwlUauoNumGqLyLWUQ3etM4n Giz5kfVatRoDNWjri7FxA9tJE9/IBOFz0ld86jnpl+l8Pi3MajC5w7dKize2vcTmKfTaEqkSb8Ja YPFai/1xb3F95Uhv/WCuZ8Br0AcHc8vlwrRWE8T7qGH48Hi9Hp/Pr9PrFcXf60OBL1Wk1Ya5ZSid qlRr8KrK67IvXYlspc1anEhAqSD4Hh6+S6nRjdqu3gUHmb5+uZb7ycC9RnGXiZena9KVfZXbKoW2 yjmV3ZU9SuZ45elKbeVJ7Se6iw3eAx7DYRaEc+8/ZYNc0F5wtEAoeLJh1CBbOpCfaNzB3S2dcEl4 y5ULp8khznrz8qgS5Wce93dXZt63Ce1wCZ+U+Lrkv3tw/XsJXhpu1OKAbYLP0fMzFD4uXDXCas0n aGEC76A0+XkQTCMIuKyGprzuhMnYSe14w0mZjsMzMr8loUxJGzZR88d3CofnaaRWs752rL8wmb0l Ac33V9HsleUFhS2j6Jeu2pFl1PBhIgjp3eZ220qYFB1ZU05FysqKHPHRmMHxmshNZ58X5p97RFz0 A2ccFvV0OPKDIQ3buOLSqrjNaNVijzpdUr1hKMA+vy7thDqrzOrd2aWsG3Kqhlwvu2T+iqlOEFVx gcE7IU6oVed0egSOUrlWiRp41CdHRtRyG0MPvp4l9gnbBLZToMJGlTpD8aWjbsaYWwvZDFbx/8Lb n1BZ8+Yhvp0DBF7YsnA8xyHMgvxNb4WF88HGHg7eCrWEWHd2Eh3M/oGGs0uxsfw1fyuxNXs5w6Yc +nmT/H8aexPwOKozXbhOVa/VW/W+d1erd/WmpVtSy7K7jHfZwgq2bAsjrIAJIZCxbMIaHGtCWBwy WJMdyEROJnueBGOMsUMISuIQsjh4MoQhuUPg5vcQCJh4uA4/E7D8v9+ploE8c/97ZXfV6erq6lq+ 851veb/3ZDTrfqs4aWU4U5M5B6iSEeQSkqcFgxCni8DaAROn0h5s0EpL4GSNqnHKOG00TBtnjOJ+ IzPe0QVzQkQ1uvX7rBup9o2MANEc06ufJs7sQoXOdOIdp8oR4lDdXpxmA6+1OM/VOM/fG69+Y369 aTuOuObcKbCS3w9ugsXSGl1TamqL53RayPSJY/6ouZq12Gzkr1IgLSvYwfh9WrN5POJYb4B2wfvf HyJzBY0zmp/cxF6+b2/TzNdmRARwZaoVXwFwK2Eolrvqds2Kg9q1eJyWbnxkP3LuKS1BO6HAaU+I hfjWEN8jpGQT5iGwW9SQuUX/mEBijQaU47WzNKY+VTqOfOFxvqk0N/dsqXRMeeo4JXqi2g5b7OO9 omdDH/OoyeZ06xvWw7LkKXl2C7t7bxfust3VMMU9gUGlNd0yWGPrjOtMK9QVHesGtdbeuEV2mlWh Yw1bK6+xrWms7V82uGbxZtuVttusH5M/ZnNtDNwaEJOtbS1x0gJyh6FqsVJ/BCrNLtjPzR22Nu0F WxOXhZjWYEOBvhBJaUzaJZWvrrcb7EMhCvEVbc31oW2hHSGpFtoDpNVHksjV4Iq7hrQhEZc9ReV4 lQbu2xFppeY22KpzFVaZzAq9Dru9XseNfwtPwDTW+wgD2zE8Uvyisylkk9np7EzWoGVPZ8XpLMsq tFP2EXEZRNOPfpJsorb4Si0RrTW7zZqzqcK7nzYD9shOmxkVOixbsuzveNgUnWFXiXDjJWQ8qGfA 2mwrNOAfUD925iyySad2tk7tIligu6n3npo+XByU7IiGjuvFC+26hVWNRbG00ds/0DcgorJNtqDk uEPtEE0NWxMRuLg3Jni8rqQjxjrSi4zNmDBgqausUbd5YkqMOTuwGDQNxci9wIlA3WGB/yhA5uDv XQyxeDgl8Ei2HGx5SNVNlASyWQ5140ohkc8fVPjqsLPZr+LaKQhrp9Xzms3WDKkotMULo/tpLWKD NWNr9uMlF2SsZaytWFvPR11JGukPIdfxLFRqOxHW16+77yZ/kHwevSCGErtIAlGoCWl/vx4MwHeg dbFJXPUPmb7F2z6cKP7ilc0bWtmcWMtlawdmb75wUcwjB12K3T809b7uQfa58vrlmwbWfeyD7vBH P7Cse/mNmzJ739fRUR6s9tQrm2aKyQtKt83/7NZFPrNjaOCzyz/FJobC5cnmaqrKO/cmKmKOGu8G 5i3Dfq33/AcS0EBnkNZFXzb67EKIh85DEOAXeAoSjbc4/II3qJ+jcQbZFOxvt4eCIIS3esnAcvs0 K3SFzy9Es1ZbahyGPiEuWs+WdKeV91Pk9JXH0Wlh9rdtihwOIeEQ+B59h76bMBpzqACBGjGNhUSS XjqdN3AWJvrxVx+mTXZ7LgstgKOi489R63j7946T6UF+xU1Kjn3FdNj0kPlPSYwYyxwTfWruOul6 w+3SHYavSd+2mFeZ2aDFl3cs9SZ8y0NB1LBFAwKckfNn0p0kbTwJvXy/UTK+bAcTfChjtyuOUceU Y8ZhmMbigANFzIpDdXShOec44TA70PsfHmo4JrM/WqvnH9AxePoBRsFZgGT5me5quYNNXjfOnfVC WJVs5pwqJVQWkUMxIRyy2WMWvEsaUioL26JA7puiKi+8IsEnuUdYCgIPGQfuBHY2gUmoDJYHmngp jzmPUnT3QnyTvDy26LZ7/+HXX77r26Nf3eRSQ7FOJ/NWej/Y3PpP/7S90SiIrx/9z38585npwUHp oS+sjijpqbOFs//e0/vEYwcejfowzq2EDA1j9Eixvxy0GNjC+CFG3gVZ5GOAKZB1Wc2TqSkEAXFL OMwkhXD/U4e8PnEMjZ8fphEl3i1BxUN9lyZax05xDMhxqid4wMMRk9d2VupCmp5e0LHZKMa8Gw0b 4KttNG+JbomZrzReb5wWplOHoj9RT6jPC/9htPaDvXJTaCy2LT0ZmoxdH9oV+7jnbu+Meyb0NQRL 708/CA7On5p/Gn7JcjL2J/UMC5nEYc9mz13Ju9Tp9Om02a2y74P0TMUrCYUB/h9SwF2Qi8nUdEoU Ugr8QQIfTKVmEOBcyDaeTjlS74s/hzDaTwNZqxmX9wxig7TSBjxNXKQt9cukna2377OL9prC89KT IBKdEQ4IcyAYtFKiWhS+dW3k1og4GmGzEYbKGVRHnTaBh1Qx6bQeRtOyjmVHxX/UI6OEwp3YtfPs zomTO7lYlUrI5u9EDGnnrpOedheTN8Qvj18blz4Vhz7eOY6+MTAwAGZWKgUjuBK3GQ8JSoi8nNNw 4oyK0kRocw66Eppx7gFFV3iMXLmdjPL9KKZG4cxCcR8MRpIsrsig26Th7DO3fuFFxg7d8d3u8qKE 25ZOL9m++D1f2nvZhf11dslDP2am555hzn0juVrOf30yMXzZl77y5rLqTbj65edOIip5N4IpFXFt W7ZyNY46KZqQxQYOluNI2sImqPEAV1gBG870DIwHyJPKUUoq3xtb39B4EEYNkcpSY98DFClOAzXe xZMeUl2KV7M6gW/yCfAszeUyiaOuuWrQXjooqQQD45gyR1qMbIwF9XWRB99CyZ0k0VdjU3GmxSeR xkracBhbgOuwAIBspjGcIaAZpjEVABcsRdJmqlqrFvk+/OLAX2qqVblWO17SlRuBoUqkLp6dmDiO ikB4rM+S9jwq1OCQrlpVr+EBaReglGaydovhFuPHDdO1+2tzNbNWm66JQi3Q6S+NGccsG0ufNYMs lqm1fnmVvEn+vOHrnftr5rna6ZKoqoKa+h6k3YZRcMWQul69VH2ffI16szorzKrfMh81P95py1m8 eftST8K73B/PB5bGEvHlSXzNZij7+V1Lllm5nJRsScGWsqOG9UrN458MTAfuD0hJxCzEwMvFURPO FTMj1Wn9MGqJl1WX7WnnZ1GmtmsCBi39wZol3gBSjwrXj8DCEr0GV5ORXMlgyWdzlqIqlAxYFMxZ lXUay1wx6pF6AfVfkHBKAVHQnkIQqDrnA7EHOPJ2ooc0oz4cB43phhtoywUZFn+6bHr4s8+/8eOb 1kNDRkoO5q64UoFoxTZ/umoaury2ZcXWA9dsvXLl4jd/8hO2auSb/8QV5ZvPfmlVzJ3e+TP2zPKp 5vr3P/Hzf4NEUz32BtQ/+gCN292W6IIlgPHOTgUXAvJoWLUxqP4uTWAqVIMooIwLxKjn5riupIbm pgw5iNqjWbeZsMsgZ8DH9G1qPEQ6FRRW557m30Dj5w9TbzB022wQIFKv0K9UU4o1EMgk1hiOa8eB sluQ5rh/WtgPdSTRKRBqhp+E/os65jpDIqxg7ocDZlBpTcJw3G82mD9p+LLhIIpN8FNmXBr1xBzJ t8+XTOA6qYmrhdjT1WLlBDwJS2cy8e4hvIQiM5zrxDGEwHv4ueJMSdyRodgWmghPCpO+pyVjWI3B TIs1A0ijI4aGApdlw3VLkoYIegtOjDrfvKGzWo+awtYt3ksD28COsjViBguDyQy2F6N/jWmv+AnT HfaPK7fF/1n8dugh71Pib12/U86I/0vyeibNk5YpXN1e6w/NT7hOmzHSmR0fEyUr9RMT+slwn3Wl uMq6PrlR3Gi9DPzFe717w/d4v2L9inzE8pD1gPxT8Y/i8/Yzss9ywgyn9YRZ3ElruneUSDsAB3y3 wSd0Bfx0BV7k+7f59/hn/c8hjueP/ivV6iDZ7+MxtoN6UE1bjZAb7vElUUYyYP6lJVCINl0BtiOw J7APkcgzPt80AepmLGIXEGLPWSQFUDFcieUAwHYmy7ecfoOwl+QKc9t4upxUeSYJTsWpOqXTTuak M7HiXjqXJZa1LRe4ACNnd5LZspN4I4AUQwYNzwgdFKpwF0AzZGvv8MPWhntANUAYejDEINiMIkwg npdtOWQSgAfZOc5da3xJt8iPCmb8mi3dtGuVpgMvoNfmDhYokEgr0hEHo/q7qP5Z+52sv5P1z6z8 nea0Nv1Iv4VVd9OBF491kJdw/m98fNxr0jMMwfYIBl0QQL07Ri8MX6bfse3b77j4tkrS//PPf/Xl /zx87+Nn72DfMCrhy/s23Cou+uWHPnT5jb69/5Ox377MzL/41uCWzID297CH1guCdLPxE0JJtLR7 d7bCx6uKRtZyhfvVUcTgnSZmcRaZhQYx5sG9/pOGWZ3Q9T20pZ1ON9HwBMSsJlsy2QQ4jAHtOsKi Bz0mqsM8NafMtY4jw6kPShiS5pRjyuP0DwYTrrXdkY+C5Yi+g3qgqBYvmjI4kqVICXzTGDNRD2Tc ruan8Yxm472Rb8dp/Y7b105npbwwBMHCLs3h549jBCI2qai25C71Hv89OWm5tNy+OnybdJvdeK+B 1Sp7UjTR16xl1vpF5YvuAxWrYoKe2ta5rSTGLM5DCcsnO9ihhPmIZNGS6cRs4jEUpboz2SArjcL5 7eosetwmFAUoEPAj7KIH98HhPSK+fpB1lo4wRXMUiszjciufdLlYhoT1wcnJOl8PDurrVktfZ7r5 WgvEUvUZJyMR3+accs45TzhNznD5e5JJMusW1ATFe0rwciG63LcdwuqFiZNUwoaA5hCIUVpn4dlC W/Lxx5PN+wI5VD9nA4WYkPdlYjzq9o78MIykdyRXqCIDzHTgP4Bx3qZD4NibDnh+/l4/+1osu2TD 2WeLhQvCBw9ueWjnVVsG64lg73AymatqsVekdWe/Nt1RzmQKyy8TL149tPcH1y2vDCQaqQ96vd1X Pn3BaoifsHh+pfQ/YJMvEtYI49LntI96AqOfy93TJ6EMZqt4fef1oAztNFVNF92lGlr967fu6L8u N7V1Hxgrbg1+LLSv8fElt67Yt/b29Z8JfiZ0z/ojhqPGQ8FDoZ/Vf7Z2buuJrc9vPb01GlH9vUrD 15fcavy6ZbivFRUCUl9qOCqEl73NFm31en1WC4IOHsDKf3/IgxEJjbkHAYujNQJIttZs9v7sY1kp e4R98aEtpWk4W9hVc9C+nlmABh5LSeQs0Hf4Gl9JYV8tNDPMhomBahh8Aa3hMnWdYQ6bZRbNu8PC 9oA9Bl4oYK8N0z28wr5bs4eH5VqYjYanwVL1qPhr8OpYpRFA0bs12WQOg92+XHaN/EDqwniXwLIp jEhdWlLpYju69nXNdkldIRpfu+w07HU1mlVpeiPbSNfmQN9G4+eHFPwi30K7oEHgM3SwjZh+jQEN MKcBrFjfV2DrC1OFucKJgqHgpD3xkY50Q+NVzUO2aeE6dWvXVm3rftxz41b6asxmr2917vvsSraS R3FWdqsB5gpMBZ6Esj9y7jXNTd8L2MkwCPBzRN7wUc17T4u1UB0yKomjEmY8USTQBOGWhuN1vsZR sT7D/XtqPEzXKF118dbvsRuFFJMf2Is4I4GEKeiD2A5vnCrtOqmUdurY4ZJe6LlTOcmLLaCR2oMC SAUITKycIiw2rIxdCn0ZQwVGiUNPpp5LiRgnkNmGUQYQx6Ens89lsWUXebPktkPjLBTQABGEYQT4 jJvXbh5ckWnE4sEQQ2Cgp7u3u94tmZbm1ueq2c7cpuzGGIstQl372saIKlzAWqqw2NiKCaOVkZhw UWmjypaHVsbYWH5zjG3aHB+MYvfoImFd97DK1g43+jRxmQo9vsQwFGMX1t4TEzYU36MKK4LLwBmK s9RDTDzOpAeb9Iw4fYI/Kv2gP1TQ0WC3kwebNLmqQEbBLkCxptMPAAOKXccXqFGCvOSD/HRTOt32 oXgYiEJEvB6VPHgqe6T6kH6eHWd6Gp2nzPM5+GCUVG+/w/vGxouP77918kclJ5jxJFfphoFjX12+ qpxMdcWmfrV4YscHvvDmD29ba3M3zNvqpSbzD29fXh9dd9mK3vk3al2D2x899O3e+r3/k11Y/NT4 ncc0o8kajMhG0+qp6cO+XNPnVs0GyWh1TF208/JPbu7pC4WyF1gvBytr+lLxjutv/uLmC3bdPHvx BW/9fe+WbFdmyZ7V9UDAgEEfbFiC9L/gzfWJ+9pjY3wAgx5wnrJb5gOhHMrQ+xBPeiMs+gaHu6Px vF5bEnJStDmEWp8/oVtCTHOpeiNfYSkQYoljKX6MVCVEx6gQap62ovE6D1mhofcxNF7RXPT1Cj9e hcELw6ygf8AMmH8QsngV8MoLdQy8rgaPYzX6hLw7XkYyrHUKqUL4gbxCBULZ9gd53Ek59ngPUjfk FcIvhINIw/CCNb2ljm5tGmvwJX4xX8dB6ZDuvMyHX5kPuTIfluV2pItvase+QgP9LMX3TPHNKb5n Cldzmkd+0cAUflA2aLz1MA3ilcpAf3vU5oN2uw0fskQJT7iRiI5Rv4IQR7XagNbZkAcmYTe7sq7c 9MDMgOHAwNzAiQGpZGKjA5MDU7RJG2CqJVRMII8KWsSOSjGRH+6QiwllOJ0qJnJHJKdWTTfy1aX1 RGM5U/N9oEzGVcKscrsVORzKWGdkdkBmLnlKnpWflA3I4T2qZStCKlNNVkYrk5WpimG6MlMRD1QY FW7OVU5UDJXJ/q/BO0SgGUqILEtYoLTGuEzaAtcCxLYeP6Obz1WFLxIzIo0UzcWM4RiS8RFznIbn dqSMB4apAo/iGG4aj/WQLOHy/SnU36G3AbPPrUEzdw2xtV1TSRsRS2MjOz669MKpqNcpd2nzS/xa jywll3d1f2DY31w5P7g47Qu5khF/zck8xrvPXnbzik2XaN+a//5mxNkymXxOuZAt/+yltfr6+dil 1WQm45UHNkmLde+R0KJDWJjRX2xCh9jOzBwVMhgI4mQiehxc3B0pHslIcUBhyhuSQCT4KtflaDzP BR+Np3lHQuNXh0nurQ70KV3jo/EHvhf1soXu9vRDtFdIpXBIcH1qR2oPhuGOHejDk6Cz5ZYs99qp N5o6TF5Yg09DqR+fUJ7VXUmIP+8Fx9EloDNL6AjsfE9wqLwPpPiSjnNo7VoEO6ixdKne0ML9/aYx jUJd+00i/aiA8EKH2UuX97oWo56EiuC0g/cHh0hi7+D9ga5M7w9ovM77A23h/SEUyqTf0Qd48zjO /dnjreMQJy43vCuEZzJsMjOVmcnsz5zOGNXMaEbUaJGhgbOnp87XA4P6Gllj/j6d5WutGo7U0UG8 wx2OYsKDbpEPL1UTqeX2sN07g0tpCqCHM3s98gwSgE0agw8u49lKzdVqSFfb7Y6wIxPSSk2cOLI4 fYP1mRAbDTFiWp4BvenpkDF0MH3wn3l3oNMmlloqdjqlm6lwx3BpepSE16FQj0ApCkYkCgu3A3WU h/Cel+t2qXBbroudixZ1dg4t+ki4e+n8smXVqNWciMQKTuYz3k0fDHV2LppPnVU3NSHIkaEx9t7P lNWwKzOFrMLl8yvZPuM+SG2RHWvreVvBy50gb5Ke35lDpKB5gwQZDV3w0HhG8+ryqcu2TD6TA977 PP8KGq9wWUXj37msovEMaJQgrEnBVMyTvNoL2ADzqRiI/gozj586TlE75enjuqKG7lsQzNLj8F0O fyHCTGFWojvd6m84Sgeh/rTSaGmm9A3nN+L7SyYVb6ZLkoItJ0pSxFLIq0vzicLyMF2SacwbsXaG o2rRbgbNphOZELDQm/HLrlkvA73RldpQp/6YAfWTqiXke/F8danloT/qxZDdTDI5ozKXyogN9bQq qSodHPHKv8BjxA7qwc7Sv6TomXNANSm/duGRnvQdOYOnD2ML41OrpUd6D5iORw9xeTu1axwEYkNt RkdPqU1Qy5WkEks4XfFszJWMsYQTWQUOVCUThkJlsGL+VmBgjCyksMjk0EvM23JTKA0NlSAe00/s 37qlOxWJut+bClUDb0vPPv5xZ2loXn3rfS+fvCCd7nGYN2c3/6P4ic+VUlyCGLHwG+zQe/3SY235 KUVgzqJQkC9V9HNxzM2XOgodW0gCArSEbfAilxFqaCX6Wi7Vl68mWds84BWFKRM3GKp8/K8GSB5h m+l2Ahq6nYDGqxhZ+Ufzem1xVWHupCEngxMQljp+CPJZeATWQk5oQPY8fdxa6OsXcmE8ZpymHSJ5 GIg/7Aei3D88IJvwhEqnSm0j4ixS1UhXARyjGw1kRpTmHofWJAgIyk30rkvD81FXM9kUPSaF4f+n rJ+RZ2wz9vtc97rv89ybnG0+KMvNcDOyTdnm3pa8Rtnh3pG8T7S+nDiVFKetf+98XHrc9ZL4kuuU +88eS8uNeU+TA2qrudK1S77OZamJnYqaVXO1JjIBitmvjLGLlI2qIa1sZptdLyh/UYxr3KuTP7L+ SP5/ZGPQGlCS8WRyhXiBy2Rzu7yOiD3uSjiTpg3SGLIx48pG90avKeyKxxPJDaKhnXio9WGkgiQz RZLzoBkSbgHV7IehAmVUOdjt+Om2dcODginc/Re4XYPGaa7H0fgr1+PVanOgrcdxv3i6j+yZ4xiA uEnD6cNxy8YUFxPdKGJWwslIIlyFqZLvkEVrQiZLJZ/uy9eWNhJ9y4WaYIPeyahJn8pENQnbsIuJ PgAzEH1Vk15myIsuWVFCcr8ggInsFW1dyP5LlA6bYNWEwyHZ1mWftoun7eyE/Xm7OGWfo5xOMDgL BEMkifohmDZCplYTqgrqKaiYwjhaZdPVGVCtTw40j7AbH0x9DUl2Ap4g7j1C/tOFyi6qRKMIGiJt C2YOQm7Uk8N09bDcSHDAtcMx7RzKRzVp1BCwQ6g9AugQd74E1kg5dsxsHsdwvGvXTkr57GqDhgDc 1WuUFHQbH/yVZAGVT3jFNQhewUXVRkCaNm20cjdd+goqm94hDzv3ACpGSVoXRJZDi9zksyDCroP8 zGYv92nIvoLiqOcRGtF5pigJvmBtkWG1/qVhuyWVY3df9MGlL798WUdXJrxkflkuWpj/Y7g6Ml9d mfbbXE414u90M8V491tTv1nusdt9cWQvxOqi387/24dTNaecyTC/N9jLrpw/MT4QYpmM2xZMvUe6 YHZV1J2egjWzGBaWC5rGz/5R1zRHhSDMC25f+ewm8LjxcYhxncG4zgA7MsxsMnzQ+BP3MNDQTSg0 nuYKA43fP8Sz48ZHoRwseJkxzSgq3r3n8+KEfH221EOORLvzk10On0HBuHTeVsp7uZXk8/GxBmkC AbMvc0OnHbPjgwidlG70oEHKi6fGdaPHbgcLO4/zwyUhw7/Fc0Zk5zw8E5wLngY3KB7fg62VdVpr g81FdRY86NjeNxpkWnA0OIna5ZngfuxothcT5uEOVkyY8umFRDlOyWySBZZx4Lf5YWitRRqL6jN2 Nmpnk/Yp+4x9v/203Wg/GHiH2aKb762h82zpgFTt5PEzbqe82zZZMLk/HK6vmm+1qhFnMhQpgELN ePebSzcNxLkdImn3raIkNeE/MYqYuhAF2yz9a3sUCY5zb3Ocx2CDbv5o3WPruhb0PRp/4o+Ptmgu esZdJb5Xqbt/5cJeaOh70RYtRXutXLpqKd9vKReUpVxQlq5DwaM4tm7he2jo4wsa+gHQ+KuGcQI7 yXSYdSX+9RL/eqkfjxTwbQwc/ZzQAu+f0jgmvD9GB8Z7OMH07X5kD2lJx+h382O4+THcsB9e1I+h dtE+eP8j/RhqJx0D73+n2egYlIHk79+CjOI4aiBc61mxmgwqddXGMY32qY2x9WM7xvaMSWObTKu6 Q9myDYAso47sAAEgZSVLx5WzGNLm5hYGNBK69tj2jmZb1CGPkHfKRZUQtSYv4XzQWhvC4XF0m9lo 3ji2yRzqXuXmZpNb5QlUtcSd4BLfVupfyt8t5e+WrsN1/YmPFKq6BffpDT6O8AZ1DTRe45/292/B M3iV9xc09B6Exhv803Xrxre0Ow7yGjhFWio4c/7CxWDM4b4D4lvKKWjUAw5MmfUYIBEvCivwquHV de7FhyIhlC2HKAeJv/GoFqubT4z/OSBNw+0cJ28bGcWZcTjVajGB8ua3DnX0FxPdaGi2jnXFxKrh DncxARZQ56F0qZgA/MtxKL20mFiJhrYkPZYfWboxMbbcUuwf0ZrFgkUwZ1dt2kwPJlu2yzazyWA0 r1qJ4qagPA7rE8RgqS6VTakHVBGJ2Ybm6i9WS5mBrn421X+gX+ynbYGRzUsz69YlR0ZHxOmRmRFR GFFGxBH068O+QH1kcsv4EfFijFl7wCy6nTOLUmxQx7RgCBs6C8Z37p4vQCcpkUuA4CHQxtEAtoAH XpgpAXe37bN3gDrJkU3nMvYUIF6uDmf2nT47sFyopZ2AF4Pxoo9c9v/GcW+PJQRDMJnNwbf1yALT GzK7b3v077Jge9nodk/l/b2bbvFfeffaNTtTAYfct3h+yLsoFZQN0fymxtXrRNE/uHK+e13TZkyV 1/c1NlTC3WvnF7V6ItzOzbuYryS+st2V69y+7ca1a8cGb5m/fpMagIMfVNLuUfbxqarWWG0rza/l Xj9GpYuwrVuLl/vn/Rf3RUFMsmiMXfq58oI9jBmqpP8XmqxXPK/JGlyTUSBaHOvmS6fFFUiTSqjS tnQ8U7RwldRm0OD6wBLg4bV2TQnHRSBurBu7aOgQTjRe1XLU3wNCnCuTOD9QnB8iXuTRtSI3nIsL BjIaZKKJY2joSg6Nv2oyHaUoxMQMpPYPmrWbe2bdPQ4iGyV6mA68EG/TrBlXpsccKesosVqNB9cU jhV7V4QNCWqSFAqucc1xjNTHu3Jd2qW1AA2Veoy+m7f5CXTrx3dlqMzQNGbhmsLCtYYlwOEXAb4p AEAJ4BkBQFrifM843xDnH8b5hdL3eYN+CI3XHqavFIuNeltd/B+DbbBNBxuItlka1P+7GqPg7p5q zDSMFQMjHu+pxjTeHWiYDjRONMQDDTaJDXMNKW4JFBMuPfBWLCYywx2WYsI5nI4XE2k98Nad71za leheHhPSPb38jmbSaZSNyMFAxjxjYQcszIUE8KzlSYvBQoE3kCnGM53J4ihYqcGONV2cKR4oSkJR QV09jeNWdPjiZF0PvvFe/n8XfPOEwpLJkA1LwRjD1CHGyEI3hmsJirkJ1ImBH4Nib7wbExgy+DeR N8TY3rmxHYwjDBtb+6VPrr1GDTht3RfML/JqvbJh6cgN19uc1BF9K7sRdYvp/fDUj9ZuGrpl/qbN yTCPubnWsxt27/zofHwiEEdPW7Wdbfzq6giPXEBpAw+JfuYS4qK9bTPEYAZSh7Jz1FDbp1MIDG2P ICV/htsL1NC8tNHAdzMEgZdWsrD5KEPKR8J2OOxtcIWVPqf9IvTlKMlUxODjEuezg7oAFhyGfSxx cNgB1DQYEnZ7koMk+FBE3QBjEf8RSsOu8Ez72dcDhwOYUtp6LP5bq8nzR5mttq4IbPbfxj5h3ev6 bdSc1HoaBg6OmE2yx/0/i4hakq2xLJyNBz83p5Vg/6+HKBrYCVqOGiYNU4YZwwGDyfAKEXS3NPss XJzzuADCBVNgtrT2QGHDWkyKevED9sSaB5KGNZgl8lFCQmPugTng5+ZoCFy25ftCROpBcZxP6nlJ eSn6jrcYHVAMzvPKSPb0sbgHM4KIIDaXs6ac2+VThTiLqCxgRStkRsvrUFQWlbDw24KqEDZiQRqC +yLUACqSAQkMWYPUAX+gua8TrzPdLN/svNlzY+C60HUxC2oX9apFa0xxN6N4AYVx+gGbnqihkBlP 1SLywanrwQtAGRcABsiHyYnCiY9cff2Te568+crdv9zQuPqC2Y++9yNXrZLu/+Id93/4remv3vWd j/zXDUtbX7zlifnf7//xmU9Mwuk491/zw9L3IGt5oSl2tGWtuIjj7XvkTrLAKB2AZcgbFlSp6OU6 2KtyuD3Mm7/yGAcab3G9i0YbhatKhZLH4DRFCDoAQmfNBvOjmnX2jWPWBK6FBa6FBQbphIZFPgMZ DSjct6MQwBEAlwvFCmV7/G1f5KjQc+6th0gQe2SSSSDqTGOyvGgQZ8fl1st1pBfnQmMAj169Croe 8vlV7FUwOfOgcHHiZGx0NnQC9KRbip6GoLoK/CKU5wnu0kO6Sao/Ii8iKE9TWaNsVfa6DbeX2aJy a9Ha8tbyB9wfKF9rucl9U/ljlq+aX7L8l9XRtWhL73j9mrpBW8RqFqlQ9HhhVoVv7/DCuMqnhXxq fT6BeSY9pYJkqKIUnc5ERIGD0xYOOXu6k/KMLE7K0/L9siS/rIo8hBdV1VHAO0WkpwnuqUM8janJ QQL0Evcf0cotYHkpF0ER2AW4WqkkOYkPVydQV2sNs8OSrefsua5sw9yjspoDi15rn8q6bVWVkoxt 0YWiJHYlhOHGx6Vsr58sHZJDPR2I0vG2ugzAElrQjUZdYcKdXpg2TWSR3Kp96z9+yc47p7413Ffo CTbXzqvh/rzXr6QToSyrW50f3LB9yXsu0bZ01TJSc9fTN733mo89deq+PX5XZf6lS3sTIB4K2Lq3 S5eNd4Wce+a/tSM9uOXC9x399c4LQx7KUyyfx9yjkOU4QodPtWU5koNIIPTm59RTfrjSibYv7SSf hCMznTpbBLdDsPV5rkvReIO7zk4jSTBcZ00xx02uhCedDZmK4x6b2anLDeIfsLzfdp7nuMTqQjMX 7SQVGu0kOYx2kgxGXJHEJkVCzQSZ3GooP1oRNRRVfKWwv2LoinSlWp0DpfWKFtFS6ztXl7a4RiPj idHUxUCr7FAui1yW2tF5i7IzsiexM7WndFvkH0pfcH028oXEZ1Of7/xi6RuBr0W+HftO6WjgBxDb 35VeKb1Z6lQr12avLezzfs77Od9cxbwBjHmA/CTM+bYHHQ25EkkpHSkyuqx0FjNwYaZFTLCYTDop clzDPJEzTJwEoc/9TGIWugr2cq5bQamn+Jj/Sf+fMZkeRwL4l5UXsJNUK47yDMqNUX/iuJVTrbMk j0SqwWO+oUzBG8wEc4BLerHIBtIqy/sIQkmyp6evqZp7ANgs6E9CsCwMzVzW2uhJwvwGAfBtJ8k4 4LdPujrUOzzf4x2I+0Jb71xz278w34+bk7nBxq357a2p/f987aJLpPvffN+Wnlg2q9iaMH2vWf/a L15iWVWNZc7W2HcxXv/gh0fnQDTHM8biw5CsAnuoLVeFTq4jTcmgO8+N03woydqu/Ds9XyQGdLsW Dd0iReNVHSGR5I55kpuw2Ao/izRtEnHJUCBMwdwQuEn+oDnX53fk9+SlfMEcsgMg1DpOHu4p+Le4 se8O2FKWq22JLqR703S4HL67w7oH3DU4QMiEM+WK0s09WDd+m9S4aQyNP3EnlBocb5VMdhbfNiYB 60LY5ng7ukkJW9Q0wX1z9Yg9Lk3UXB81mLVOtq2TJUnLcX/x9nQeiYpcIr9ckG2dbp+qMENomhJO CsKu45j+0AyPcJuJIclmqiY7WafgRhIiqbJpdUYVBVWBhzgHEL1RnSxScJKoCBZ8vF3Al3PJArLj 1AREi9fEtYG5JGTIHqAIBqWFZNzxUn/KEJDX1Tby/jbgt+7am/pX1zPpzX6Pv9LldVywZL60siMs G0FpmszLzC/d/6tfLSvn+1b4ipfOr1mXh/GWCXB/6vL9i2NkwEFetp87Kf4G8tJtqLflJd/L5aUX 9TzimMh4rpTxXClzgX4qj3pScSyfQjhTVz9onNF6SB5c3WZL3pUyeEpGdpORXYMavGyNMdZpDt+Q YJeDrz+rRtgkKHPEiAeYWqBUYQPVsMZqApHZFhl+sPuOP3VceUofSc+H9XpSrrzF0BlIeKpGsbPb rB8m7FlrZFcbP2wUjdlO8/IE2574ECBxWY+N0Rm+pkFhmsZcrt6eiAUzssKLyQMtaBrL53t7uLQA c6Cvj8GGmgC+d2IC8d6JlnKMM9HipEh0itZyuCx6PFXN1iyjninkG7dfnLtP+XTGKJtR3FSc7J3q ne41uXqPMFW7A+ryF45fOI9ljmX/Lf105rflFwwvpF/IvFS2eVrlifLfVXaX97F94j5p2j+NWZWm Y3sr+6oO4g+RQUpuisnlJzp+lrbEpIDPg9kkwsVo+R7rPfJ96qfSn8rYPCVHoTxcXt+7rffG4o3l 253fSN/f+6L0QsxetHQnhEfFBEuyGiLxR1jpoPAoiIUimrszlAg/Gk1EkhGmRFQ8APow/CgycBGt w+NBXthmcOX5yphgPxWqtc5uEPDgpkY+Eg6HqIDDF6jRjRV/6WHMQ1CkPxPSTPJptimaN20Kcz1K wFr2aeDEDVeTQJOVZ/NsMj+Vn85Lar4rL+a/x1TM4Kc+oGNj0TmIpYMjE84SCvZcCijYZg3lZgfP MTQJJ3sSn8PkoXztyXfQd8AqleGnZRw2n8NhWyDzGNfZPBCiJyb1BT4PNPWEyqGqanXUQSjDdXqs UEyqittkTroRODEVLTF0YcCgzAVjjDg8uGIn34tYO940v6687n6zANYOlHwQZccWLTzLZsVZadZ2 r2PGPxOZic7E7un4XHq2Yod5jKALrwzZotlq6VrmrvJ9mfvKxolxKi92F9Rw01oAXZkmN0W8qDr+ oNyEYzOnheVmFZvK/IVqSAX0Z06VFjAhgejlq3AzA6MAsGYEMGhlxwqFJ+V2pf1BUPXQsVC0z0Az IOJVVj30ndOAImA3V1NSHPgdBx3gtOZx4Hcc2AcvsO7Ri7sE3Bn47xa4N1Szh3EuzeEenKKkjc6k KBIRlGAA5Dw8wG3wGa2C9L5fnEnlbrhk5SY1ue2Tv3j0uo3XpPxBRyoV++JlKza/d/73lcp9H+4b 6XUrHrt0//wTn/rAcGWgUKyuuvzLu+9JyBG26hN3v6e54tKZwebmnZ8Pupwh6DDfuf8Uhww/BHvZ 2bYOy8ZBxIvyFOSbxTGbnQdg7H4vM3p508sHMu8CWgqNM9w5QOO0Dpvy2ixlV8CH6R6iBwVAKVrH z2L6llPH2jHaZxeq8N4OvoaDCCohDMKXxMe00MazfZFHU/FE9EYYDc1He0yh9t8VZf6rfGwNCEzp 5zSIIn7bFmVG7hwYeTDFyEdBI06Q8qvIoeNM+fiHhp7hw6zUsbfHvxKvA2idPTExMacAUjJBaBL6 w2NF7YsDJ7DU3tzGtoliK36P+57wY/7HAkfCL4bNs3G2N4Iiq/WObfZtjr+EEInwh/KgjPSHwhGJ 0cIX3c8kf1f7bKUusF6Z7A066cCTgN+TjXWFL/pLwUZ5vzJYRu3VWvwAinowV4LBYMz4Rr1sGtM9 Y6rBA9457wnv816TdzL2baAmddcAngH9m8BUmAgUY94WzJJwErAlvMNHJxmGT4FbZzonONn8uzgm CZNWw/AiMevlFleOsMOYexTzsww//XRvIbXEnU9PL69u6fzH/msrwaLhh/P/uvLsd8eXFAuXXd67 7XLx/anAVatzV9DIKCK2cVb6tJAVu9pSFcjzGCIUGxnqzKYW2hmBtj2kJtoZgZM6JkON8B0jHp59 AC2hDs5DQ/dF0TjDYUOezILr6QxlTTbVGTLFy06UgqAPP0TQDIssAJNxHH6SbsJj+iB6mDrPM6+s etvp1Dab9ZIFySLbVFvICXg4jqof0ta2iQETgWXMhYqpEZiBFEshwYrINDxGPBZLTuWSp4JinNzR HM72NS57aOgoIWrwuL/Hg2kZ9YQZj/tjQRF/HvYvzVFwogUh5Mg52INwkKNag+XJq1DzND4cyBvq tv7koLo6uVo1Rize9eR5ptYnsvm0Jc+WmhOW5aotG8fklis0r4x6KQxJdIucsk222VK8XMopgJrA xabYLJiqDJi0AxA5TziC+O0o5rIUp7E44JVI6NS22EHocj/SC6jO22kAycEPgPRR/hhhdy6I8PTP I+V0CEg05nLHXJGYoLijShz11Dq5LyJ05Hvq1n9PP9VFLcghYHFm8Ano0gn7P9+QLkdNVDLvnH+1 cv0tK0Z2lmP9q9nS8Vbpg2ubF0ufPvubWV4N9aPpC8Y/Mc3uWdoTZdmz902P9q0TzRf2g7IFGTvI 6CnIqCr+UJfRw1arEPGY+NxUbtjlKl4iQBTAbaOu8ZVXWsiBc9KgNsKgOyRjNgirtSOF79l8PPjr 85rc3P9ze0wi34L+rfKGSsc5Xnr7P45GD/7Z44hI0GO1ejbIW0Jbw5imjgg3GyATndPe62/4wr5I 2tohp9yqJxNSw2pk0NqUB5Fyb4QHI8OWNdbl8orQivCayFWWL1jusf5T5N7obMc3hW9Yvmr9cvjL IGj5AYqCDsuHQw+Hvxd5JDrX8ZvQ6/LroTcjlVkrWIwJYzZZ5+tSt75OFPU1avz49nxeX6fT+trt 5mtNC8fqro5bMPPiLnHKeIv698bb3Ps6rIOWulxHRefjprnUMxHznfLe0B1hqd+zOiR6Q76EV4iq CcEjuxPoBbeDoiUSVkPhcJdV9oGpJRqJZKwWtCxmE2YDtcAk83pgNgmmSNiGDBCGp20y6DUzwHMe lp+SjfJuKwo2rtQUzVTbbzlq+RUoqXdbw9dFiBhBFay4PpenbqXrBAid1gd7GrR62N4QrHNwl46w xw4rHWwaZK7tvWh92OWtp0ixhoEjJ7Z1UhuRs6EXwlCroTORU7TeFYKhhUyTLuukXcHkysER/388 RxhRCGhBB6Q/Lvo6v9FDsgrOFCivFx/G2pqBvQxnAVYKgmDPa7K3aVFBCIQXH5I4eoqqi4iul2DZ Xi8PxXC6f9T3c9Yj1Bjl3ez+WL7o/83TQYsN9HGlui8dm3+kOH80UEi6e6RPZ3NqumveJDoG4k6r y4bptNyJlW+9Khn7aorVgt7iOHfSeAi9pSwdb/eWXCrhdoplCvI5BWsuZDEUskmTy0Ri3gK9PiJS oNlaYDfS+wxoODF6LietGIrR0sKX8JOgPhFxoGUoZzUIBX7wm1DXKVwHGgnbdahnsOlHL5crqVS1 Ql0HupJ+qzUByqtnJ/iPUVyR8rr4Qw13FY9Ri7UagTwcTHc2r1a3Va+yTlVfyr5UeCP7RsFOOxz0 Nvh+T0ST9VS1WtzeFw+DST6tVA1yLp4r55q5seDXg18PfT1nsWX7M/359cI6NmJeY1mVWZkfKYwU 7zRPK9Puf8jeWbizOF29V/k07Zx9RDmaPVp4rPpE9onCb7O/LZyoJgUjZlr2G4LWrDlvLZiKjeAy ZZl71HiReVPoouJe2z7lztDe8N70ndk7c9PV4B3W24N35CSHdZzdoNzgNqBPoHwnm5WZGb1CCboT ippOJVShWE4ILtmZcCXDiQTc+tsfJODgkXO7NS2UzYDhy2I1Z4oFX7FYgDRk810Wqw8TfsE6Cfsz ctYny1nMUNAVCvtCoXAxlw7DWUf/k/EcHmGvoBMl2CsPJpnLTe8UwQnbBKOgosCBVwWRNmLWeOyC Thp6hH1AyGKm6K9proKGk0X1kE19y3WFDJ/qgUNzwhXF9BEUy/hBWT0aZvvD7NHwk+HnoPU+mamh e0cfVl1ZcJEwXryDapHsI0wB4M2PHm7X5Nq2HNNy0zQDB3vlkHV3vmb5Hrq5BcafjAATmy6cLmBG Foz9+GphPyZOvVKLjhbZNM3JohRVzMpyoDhXPFE0Fycr562mU6gX2RmOnDqL+Wkndrb7NjZFsAHD W+hkBKYUvaizU1en+fEwwpGJpXd9bmChjS0kgufZzoj/0wIYFCdf4o2FLf/XnEvEuMQVBjIKehoL 6FqiWnooR3Tf5JhQwRKs2ecPxont+/zKR+9OHww2cS9PH/Tzdw/4ddVBPUTXHLyew+uFltCBU5DQ tiJpv2dpibiacnkHm8YwfOwn9VA+MMQOrU6gvvSHvnyTpTYX539V/I/5v2TnfxcfGII+MSRiyfLZ /2TfuWMo6ER9uoRstM9/9jX2Zp/qTWAWW8dVb70srjn7sCSu6XWQzRhF3vmP0DAD0mttm9Gek0P1 nKEi4FA16JlDFa8iDqBxWKgk3LqiQTKByPz4Qs8p0FB6h2eFzPY59jn3ue/I3VF/2vZ08Hf53/Va XVVkdmwZO2CIthd6zLHBquviPkO1ZWwpLfdArlVo1rsG19jWK+vdKxNrcusKa+va4Kbwpuzo4HXm PbY9yh73nsCe4GfMs8qs++uhR3IJp9GluNyuclJJupPlolwM1gZlzO1nvbhvdHABi5jBed8ErCNd yPVgIq3m6iHZIFTpGhLVeLxZrQ5S6RFXaEB5tOhKuEab05d0TV/OoW8inpWv1xsyUDS9MD/M5nCu 3qj3NrKefYEa4EkNmKUBe3x3eBQRI8wXnN4D7uV9aZYOZwFj7K28Vizme0dxt3c3WMNoNGfDZnOm kfU1Gll7IJ/v6rX7envtgNCFrPZgbz4btg3UciFZstfNDRdql5J4ErUqPQYM4G43jcpVAwolK4lE XMZESise2hFggSoK7JwPqmEGS2YOTmFDCx8IPx8+HTbQBhqNw4+IfZjdw8yuPNio5qEPHsTMXL2P iD9EFdygOPJg6jgvA8OkVYiAlsBJitmr2n1vYmG0pYJ9JELQ/zjPIXdsqOuBnJSznFFHowYDYeDu WugVTJVA9/gkv9EeVFVOYIvC3yq3vIKW2aIMOQFvVIZ2HztGq2OWY2asLNiKsAfKrDjZyQJ00YY+ JRNC8Y2HrSgJR5QB7ReJcR35vBc1a8zdciAh1cIA/uKDeENrzQv2TSPlNM1Ei9ZHrUHcE8y01yoC 9ogjnD7samZVFw34zxx0UaHx81j1YHXYgQ8cfAtFJ3KISuRQb5zFC98jjnYyEhC/4Cu3bjJEHU0F N8CNVxChDAXkwJg7FCESPxG7k1YABINWsMXmsIKnfVrz+pt9Fn+zgCkDini5LYEmDKbntWigWdTc ePmbPfTCLwfp1/Giry+AMkm3vPvvbyMiukONffgH3IBpc7UGKZl03n4BhDNA04TqKaY8qSb+ntzS fqqdjrL7i6m0LbB07eqOHOvrznSP7T65cXVzfrQCyPztn1peqcz/JhPNXTz33eH3LIZiigVDPUrH +99/ecQfh1oKdez6+vyRm7qlTMbnDAYnjh3b6g7lxUzG6IvfcO6ta/rRV+yocD0DzdRzPncK67TU KQk35lk+Do8B9gvIh0gxuXmTSB8Pi7wpUrOHN3vQ1J0JILJfwb9W7ThFbt/pUySsJSHuc4s3Y+oI ATXUpvTN9Bsunw8Zinrvgo6AJ3gMfiHZPDw90N11QAEa7FHQUL4hhM+dFiJIKMsK0t8EAfu2lSoC naXPFEVvvRrY3ner8TaTaLUaPZawJWIt+SI5a8aTAbvFAOvzNKKrPO+3vl++Kvy+yOXR95dvtNwk 3xS+IfKh6I3lvfLe8OeFz1s/F/ls6RHhRP0/TGnYJKVSubNTZtxSD5N5X+5pm/c5ixqORLo6ZR92 KJdK3LAvdeIrnRGrQbaUsQ7D0rCk2yZ+HlKkOXG2+Vq6GXfVASHDpN0WLbpPZs/JpylZOiX/GcnS 3S3reus2q2TdDcfWqcVLT6OawaXOIk+xb1uZ1cqtslgO99a/SbAxTly3a+TkxM6TZzFhJCzvs22o 2MjZkyV9RKcHwUduTLjB7XdSHxi4yUf735IjYu6u9uDMdpIVjxH1vzfFuS3eTmQhSaGH8/qJkRT/ 7Ozb/kol9dxxt9nSUWKd2ULIGp6/q+/+9yxa19+VahbkxKrM0vmHXamwEuyFDOfj+RXzPeyvxYLH asMMbYZQytl66+9uu3N5ubM34FoyPis+mKym7Yod0ovZbKRrIL1+9k2t5rEYQoZZw6xj1vlNwxGD eTbIHMHrHN19owJSkH4QbQedXtelhotczxlOuMxtT7fApGBAcolOox0pgw8b2ahxElmDLrtpuYt9 yMW2uXa4RFeXKCPWBCXJF7ht+M8zNXBthdcVZak/QWGtjNZjNB6SEzYDJkzMSAafJBkkm2hwMbsz 6KBfMYwi+9HlABRmG+L6wMbLrkfEJYITdF9LtLLEqrO4rOqog3U5NFBhSY5ILdgKrgey2F4FCzGm NQoHgl/ShxBg3EfOnKRJQzF7AxhpEQinGe6psp4WC+eIU6UmfLc7dh8Ltec+bK/GSfUjSIb4BIyu o4Lz3AnNCi0vdWHBASwONFwavcsECKv+74cDTUPBR81nwM1umAJj7ZFzM4fBoBHyU/PFw340Xbz5 DrZarjOhEccZZvFhmIoQHly6P+VnKSoP7Jcusb31DOgfn3rvkDdqKJgk4ey97MKr1gYVGwvP/zEj dYbTPcPz2beeSpfVKylXvky6UtoAXsiAUBE+qhXARWAIBbPRZKHD4rYVtI7DQbdmOwzghiChgCDi 4vx9VB7fqbmig/sRxv+xy5l0TmOCaNpmNQzej1BruIrpFj/0YGqjzl7Jp3kHD+nZiXanaqGOgGzl d4gA3V/cRv/52uHziTqEt7P//Wa2css62epwlD3FxcP9y665Tdx6BRJrdls5UFw8MnDBB243Xl2s bl+Udjhdi8tdKz40tv07udzgJUtiTqeyqNS9etfYVd8Rzp1buAtMElai1uefBVwzUa2KAhM7pSJ8 6AmyP38oXcFew72KCOu1uDUM08aoWH3CYYfmk2K4OcZBVzAZnCb8Out8UAlHY99HFjMl/Jot1qkx R85isnudvBNqpS37ZLh7aZbrBYQEr2fqhw7g2IpXr8xGbHanzRNxF5YkOweXXT2+SLqitriRa4B+ 2WwdqvTEcjs3Xv9ejZ7m/DFpg/CEEEQFyV3a4i9Ev1D9Zu1I7YnaSzXTzc7rgh933hY0hMIx4F4M rpSl0x463KllbMJhj2a3dbdig6MV5qokgUKQKvwR78fY8mPDoMufBIOzBGbGzgdd4a7udz5cuqjX J4g3jiYxPIn/9Ch5t24/U9B9Ikz8rsvTr85k/N9sv/aKlmxzyIFAoHNopP+Cq+9gl28ekVGKHAi6 8aj7ll9z2/yxzubEYjxIi2Wo1LV61+arvpvprFyxKO10WCxLSl0rr8PDJgnnf+dSwna99TfLVXgv ISBhA0GmC46rW/AKPsGP/hAUwnjSUcxTHxfSAhgs4WLmMV9GUejEjOFl9JcaaBm6wVPaKzSEPqGf DFOwt2vCcmEF5GiVsBp8F8PCWmGdMCJcCCaWUeE9wkXCBmGjMCZsEjYLW4Rx4WJhq3AJ6HEPCQ8J Dws/wdmAqxwv+jMh8S+Mrh/dsna8tPGqD15x7YVX3HDRjg++9+9GN4xsFIT/D7JSlhkNZW5kc3Ry ZWFtDWVuZG9iag03IDAgb2JqDVsvSUNDQmFzZWQgNTMgMCBSXQ1lbmRvYmoNOSAwIG9iag1bL0lD Q0Jhc2VkIDUxIDAgUl0NZW5kb2JqDTUxIDAgb2JqDTw8L0xlbmd0aCAyNjEyL0ZpbHRlci9GbGF0 ZURlY29kZS9OIDMvQWx0ZXJuYXRlL0RldmljZVJHQj4+c3RyZWFtDQp4AZ2Wd1RT2RaHz703vdAS IiAl9Bp6CSDSO0gVBFGJSYBQAoaEJnZEBUYUESlWZFTAAUeHImNFFAuDgmLXCfIQUMbBUURF5d2M awnvrTXz3pr9x1nf2ee319ln733XugBQ/IIEwnRYAYA0oVgU7uvBXBITy8T3AhgQAQ5YAcDhZmYE R/hEAtT8vT2ZmahIxrP27i6AZLvbLL9QJnPW/3+RIjdDJAYACkXVNjx+JhflApRTs8UZMv8EyvSV KTKGMTIWoQmirCLjxK9s9qfmK7vJmJcm5KEaWc4ZvDSejLtQ3pol4aOMBKFcmCXgZ6N8B2W9VEma AOX3KNPT+JxMADAUmV/M5yahbIkyRRQZ7onyAgAIlMQ5vHIOi/k5aJ4AeKZn5IoEiUliphHXmGnl 6Mhm+vGzU/liMSuUw03hiHhMz/S0DI4wF4Cvb5ZFASVZbZloke2tHO3tWdbmaPm/2d8eflP9Pch6 +1XxJuzPnkGMnlnfbOysL70WAPYkWpsds76VVQC0bQZA5eGsT+8gAPIFALTenPMehmxeksTiDCcL i+zsbHMBn2suK+g3+5+Cb8q/hjn3mcvu+1Y7phc/gSNJFTNlReWmp6ZLRMzMDA6Xz2T99xD/48A5 ac3Jwyycn8AX8YXoVVHolAmEiWi7hTyBWJAuZAqEf9Xhfxg2JwcZfp1rFGh1XwB9hTlQuEkHyG89 AEMjAyRuP3oCfetbEDEKyL68aK2Rr3OPMnr+5/ofC1yKbuFMQSJT5vYMj2RyJaIsGaPfhGzBAhKQ B3SgCjSBLjACLGANHIAzcAPeIACEgEgQA5YDLkgCaUAEskE+2AAKQTHYAXaDanAA1IF60AROgjZw BlwEV8ANcAsMgEdACobBSzAB3oFpCILwEBWiQaqQFqQPmULWEBtaCHlDQVA4FAPFQ4mQEJJA+dAm qBgqg6qhQ1A99CN0GroIXYP6oAfQIDQG/QF9hBGYAtNhDdgAtoDZsDscCEfCy+BEeBWcBxfA2+FK uBY+DrfCF+Eb8AAshV/CkwhAyAgD0UZYCBvxREKQWCQBESFrkSKkAqlFmpAOpBu5jUiRceQDBoeh YZgYFsYZ44dZjOFiVmHWYkow1ZhjmFZMF+Y2ZhAzgfmCpWLVsaZYJ6w/dgk2EZuNLcRWYI9gW7CX sQPYYew7HA7HwBniHHB+uBhcMm41rgS3D9eMu4Drww3hJvF4vCreFO+CD8Fz8GJ8Ib4Kfxx/Ht+P H8a/J5AJWgRrgg8hliAkbCRUEBoI5wj9hBHCNFGBqE90IoYQecRcYimxjthBvEkcJk6TFEmGJBdS JCmZtIFUSWoiXSY9Jr0hk8k6ZEdyGFlAXk+uJJ8gXyUPkj9QlCgmFE9KHEVC2U45SrlAeUB5Q6VS Dahu1FiqmLqdWk+9RH1KfS9HkzOX85fjya2Tq5FrleuXeyVPlNeXd5dfLp8nXyF/Sv6m/LgCUcFA wVOBo7BWoUbhtMI9hUlFmqKVYohimmKJYoPiNcVRJbySgZK3Ek+pQOmw0iWlIRpC06V50ri0TbQ6 2mXaMB1HN6T705PpxfQf6L30CWUlZVvlKOUc5Rrls8pSBsIwYPgzUhmljJOMu4yP8zTmuc/jz9s2 r2le/7wplfkqbip8lSKVZpUBlY+qTFVv1RTVnaptqk/UMGomamFq2Wr71S6rjc+nz3eez51fNP/k /IfqsLqJerj6avXD6j3qkxqaGr4aGRpVGpc0xjUZmm6ayZrlmuc0x7RoWgu1BFrlWue1XjCVme7M VGYls4s5oa2u7act0T6k3as9rWOos1hno06zzhNdki5bN0G3XLdTd0JPSy9YL1+vUe+hPlGfrZ+k v0e/W3/KwNAg2mCLQZvBqKGKob9hnmGj4WMjqpGr0SqjWqM7xjhjtnGK8T7jWyawiZ1JkkmNyU1T 2NTeVGC6z7TPDGvmaCY0qzW7x6Kw3FlZrEbWoDnDPMh8o3mb+SsLPYtYi50W3RZfLO0sUy3rLB9Z KVkFWG206rD6w9rEmmtdY33HhmrjY7POpt3mta2pLd92v+19O5pdsN0Wu067z/YO9iL7JvsxBz2H eIe9DvfYdHYou4R91RHr6OG4zvGM4wcneyex00mn351ZzinODc6jCwwX8BfULRhy0XHhuBxykS5k LoxfeHCh1FXbleNa6/rMTdeN53bEbcTd2D3Z/bj7Kw9LD5FHi8eUp5PnGs8LXoiXr1eRV6+3kvdi 72rvpz46Pok+jT4Tvna+q30v+GH9Av12+t3z1/Dn+tf7TwQ4BKwJ6AqkBEYEVgc+CzIJEgV1BMPB AcG7gh8v0l8kXNQWAkL8Q3aFPAk1DF0V+nMYLiw0rCbsebhVeH54dwQtYkVEQ8S7SI/I0shHi40W SxZ3RslHxUXVR01Fe0WXRUuXWCxZs+RGjFqMIKY9Fh8bFXskdnKp99LdS4fj7OIK4+4uM1yWs+za crXlqcvPrpBfwVlxKh4bHx3fEP+JE8Kp5Uyu9F+5d+UE15O7h/uS58Yr543xXfhl/JEEl4SyhNFE l8RdiWNJrkkVSeMCT0G14HWyX/KB5KmUkJSjKTOp0anNaYS0+LTTQiVhirArXTM9J70vwzSjMEO6 ymnV7lUTokDRkUwoc1lmu5iO/kz1SIwkmyWDWQuzarLeZ0dln8pRzBHm9OSa5G7LHcnzyft+NWY1 d3Vnvnb+hvzBNe5rDq2F1q5c27lOd13BuuH1vuuPbSBtSNnwy0bLjWUb326K3tRRoFGwvmBos+/m xkK5QlHhvS3OWw5sxWwVbO3dZrOtatuXIl7R9WLL4oriTyXckuvfWX1X+d3M9oTtvaX2pft34HYI d9zd6brzWJliWV7Z0K7gXa3lzPKi8re7V+y+VmFbcWAPaY9kj7QyqLK9Sq9qR9Wn6qTqgRqPmua9 6nu37Z3ax9vXv99tf9MBjQPFBz4eFBy8f8j3UGutQW3FYdzhrMPP66Lqur9nf19/RO1I8ZHPR4VH pcfCj3XVO9TXN6g3lDbCjZLGseNxx2/94PVDexOr6VAzo7n4BDghOfHix/gf754MPNl5in2q6Sf9 n/a20FqKWqHW3NaJtqQ2aXtMe9/pgNOdHc4dLT+b/3z0jPaZmrPKZ0vPkc4VnJs5n3d+8kLGhfGL iReHOld0Prq05NKdrrCu3suBl69e8blyqdu9+/xVl6tnrjldO32dfb3thv2N1h67npZf7H5p6bXv bb3pcLP9luOtjr4Ffef6Xfsv3va6feWO/50bA4sG+u4uvnv/Xtw96X3e/dEHqQ9eP8x6OP1o/WPs 46InCk8qnqo/rf3V+Ndmqb307KDXYM+ziGePhrhDL/+V+a9PwwXPqc8rRrRG6ketR8+M+YzderH0 xfDLjJfT44W/Kf6295XRq59+d/u9Z2LJxPBr0euZP0reqL45+tb2bedk6OTTd2nvpqeK3qu+P/aB /aH7Y/THkensT/hPlZ+NP3d8CfzyeCZtZubf94Tz+w1lbmRzdHJlYW0NZW5kb2JqDTUzIDAgb2Jq DTw8L0xlbmd0aCAxMDg4L0ZpbHRlci9GbGF0ZURlY29kZS9OIDEvQWx0ZXJuYXRlL0RldmljZUdy YXk+PnN0cmVhbQ0KeAGFVU1sG1UQHmfXDqrCigO0VSuVJ/5aRWm0CRQSKqCunTppItfND5BSFW3X z/HWm91ld+02UU+5kBNUAiGuIIR6A4GoWn7U5tJeiqhUBVTIBalIrQAJAao4AOKb9dpZh0PWevb3 5s3Mm/lmxkvUfdHwPLtLEM07oV+YzM6+PHtMdN+gLtKoh/AYZuBlS6UJxo7rSP7tfO59SymW3NzL vjrPNt2lyzIwoXUFyy0H5jxRSifK9JmeHxJ1H4d86HToMX4b+MHa9GQO+DywFtsC0kMF6UjfMkXB NxZEyXcrlp2MdbNz9rHpM2/XOVZ+dmH1BLWpcfz2IuYzVX90EvhZ4PdNY2QKuA94zQsPshw6XffV azPZprxrsOIfmonlJxar0y8BPwCdZSscmwbuB37XOVk8Eutfrbnj7Gc75L+bQe4Y8GNEypaqHOPa COD+ssyPACMGpVitj7J/+FGWg8YUyxlfWKzmisC4S7l9yjhcAt4K/KfvTvJdjxCpW6Rd4LvgX+3z whLLh4BLjl3ku5CLuiyDKMc9wJ+E1enRWP/70J9mW/bzb8U6NAYMHtLCs6Meehp4wq9PcmxPAC8Z /kgBGH7S56Uzw7wxvlE28sztU8B/0YspgyS5dBLfJjn0D/INyKJGhDzycVbB3qYCNBwsn6zU/VSD TFDyvGVnURUnIewcrAYZVIqsml4ElbETNMd+cBMj9nsn2psbdHPQcWgRPkR8/91Yz1W3qbr6JNZ+ dUJ9Th1Sh0moL6gH1OfVPKTD6v7IxoftAryu58E33oXXpqfXqJ6M59yO+h7Pe+eNJf9Vy/zmzd86 LN123HOIq7lrcwL23CRHyK0W6/8UsyGTfF07++X2RIRiVb14/GbPtbN0JFmLqDrljbVI307fSa/i +1Z6Lekj/UN6DZ9blEW97IjZeWTHHMqI6wJ4MJBxgIjqqCtHv7cjxxXYhdCx6UecuZFVgAr8Dcta xFSy5ome6MiXc2cfHRlXnHM7PO/Eh8yrfL14r0hLffrH+i/6B/p3+q/6qv4e0M8d0bT6pNUlUfcp bymfKV8pl5TPlesklCvKinJZuap8pHyB3aeQriiX4IV1Wz3X7LF274CzZheacX8xD9yxQcQcazNv LG1FcApn65lL5Lbxhs5+bt+lHdR2ao9qee1h7XFtQuvV9mkHtG3aINaANqrtxsnOdt/YcTV5tpI9 a9FsxGazkhxVFfz6iNLAZz0unlOLZhC3RacjBoKoDg5m4P/TynOFuUi9gt611F3qgDoWz1FW3YdJ Gu+YqSGetMxIJp/Jksj0ZoYzA5nDjBF9c8pEZjdOh/E90s6IWTGTOh15yYQec9pke31e+F+Je4m9 NIBt7GQoz+CdRZRzvQXfmquGYlDXnxFZvCKlGHPM/j5h2LaIjgLhy0D6DVnuJ37/sh3RH0ej92pq 63Wz7jeaMkqlvib6DyJqiOoNZW5kc3RyZWFtDWVuZG9iag0zMyAwIG9iag08PC9SZWN0WzUzNy40 NjkgMzU4IDU2Ni40NTUgMzYzXS9TdWJ0eXBlL0xpbmsvQSA4MCAwIFIvQm9yZGVyWzAgMCAwXS9U eXBlL0Fubm90Pj4NZW5kb2JqDTM0IDAgb2JqDTw8L1JlY3RbNTM3LjQ2OSAzNjMgNTY2LjQ1NSAz NzNdL1N1YnR5cGUvTGluay9BIDc5IDAgUi9Cb3JkZXJbMCAwIDBdL1R5cGUvQW5ub3Q+Pg1lbmRv YmoNMzUgMCBvYmoNPDwvUmVjdFszNiAzNDMgMTEyLjk5MiAzNDhdL1N1YnR5cGUvTGluay9BIDc4 IDAgUi9Cb3JkZXJbMCAwIDBdL1R5cGUvQW5ub3Q+Pg1lbmRvYmoNMzYgMCBvYmoNPDwvUmVjdFsz NiAzNDggMTEyLjk5MiAzNThdL1N1YnR5cGUvTGluay9BIDc2IDAgUi9Cb3JkZXJbMCAwIDBdL1R5 cGUvQW5ub3Q+Pg1lbmRvYmoNMzcgMCBvYmoNPDwvUmVjdFs0MzQuMzkyIDMxMyA1NTkgMzE4XS9T dWJ0eXBlL0xpbmsvQSA3NSAwIFIvQm9yZGVyWzAgMCAwXS9UeXBlL0Fubm90Pj4NZW5kb2JqDTM4 IDAgb2JqDTw8L1JlY3RbNDM0LjM5MiAzMTggNTU5IDMyOF0vU3VidHlwZS9MaW5rL0EgNzMgMCBS L0JvcmRlclswIDAgMF0vVHlwZS9Bbm5vdD4+DWVuZG9iag0zOSAwIG9iag08PC9SZWN0WzMxNS45 NDkgMjUzIDQzNy45MjQgMjU4XS9TdWJ0eXBlL0xpbmsvQSA3MiAwIFIvQm9yZGVyWzAgMCAwXS9U eXBlL0Fubm90Pj4NZW5kb2JqDTQwIDAgb2JqDTw8L1JlY3RbMzE1Ljk0OSAyNTggNDM3LjkyNCAy NjhdL1N1YnR5cGUvTGluay9BIDcwIDAgUi9Cb3JkZXJbMCAwIDBdL1R5cGUvQW5ub3Q+Pg1lbmRv YmoNNDEgMCBvYmoNPDwvUmVjdFsyMzMuMjUgMjIzIDM1NS4yMjUgMjI4XS9TdWJ0eXBlL0xpbmsv QSA2OSAwIFIvQm9yZGVyWzAgMCAwXS9UeXBlL0Fubm90Pj4NZW5kb2JqDTQyIDAgb2JqDTw8L1Jl Y3RbMjMzLjI1IDIyOCAzNTUuMjI1IDIzOF0vU3VidHlwZS9MaW5rL0EgNjcgMCBSL0JvcmRlclsw IDAgMF0vVHlwZS9Bbm5vdD4+DWVuZG9iag00NCAwIG9iag08PC9SZWN0WzQzMC4zOTUgMTY1LjM1 OSA1MzYuMzczIDE3OS4wXS9TdWJ0eXBlL0xpbmsvQSA2NCAwIFIvQm9yZGVyWzAgMCAwXS9UeXBl L0Fubm90Pj4NZW5kb2JqDTQ1IDAgb2JqDTw8L1JlY3RbMzU5LjkzIDE1MSA0ODIuNTkgMTU2XS9T dWJ0eXBlL0xpbmsvQSA2MyAwIFIvQm9yZGVyWzAgMCAwXS9UeXBlL0Fubm90Pj4NZW5kb2JqDTQ2 IDAgb2JqDTw8L1JlY3RbMzU5LjkzIDE1NiA0ODIuNTkgMTY1XS9TdWJ0eXBlL0xpbmsvQSA2MSAw IFIvQm9yZGVyWzAgMCAwXS9UeXBlL0Fubm90Pj4NZW5kb2JqDTQ3IDAgb2JqDTw8L1JlY3RbNDM2 LjkzNCAxMzcgNTQwLjM2OSAxNDJdL1N1YnR5cGUvTGluay9BIDYwIDAgUi9Cb3JkZXJbMCAwIDBd L1R5cGUvQW5ub3Q+Pg1lbmRvYmoNNDggMCBvYmoNPDwvUmVjdFs0MzYuOTM0IDE0MiA1NDAuMzY5 IDE1MV0vU3VidHlwZS9MaW5rL0EgNTkgMCBSL0JvcmRlclswIDAgMF0vVHlwZS9Bbm5vdD4+DWVu ZG9iag00OSAwIG9iag08PC9SZWN0WzM2IDExOCAxMDAuOTggMTIzXS9TdWJ0eXBlL0xpbmsvQSA1 OCAwIFIvQm9yZGVyWzAgMCAwXS9UeXBlL0Fubm90Pj4NZW5kb2JqDTUwIDAgb2JqDTw8L1JlY3Rb MzYgMTIzIDEwMC45OCAxMzddL1N1YnR5cGUvTGluay9BIDU2IDAgUi9Cb3JkZXJbMCAwIDBdL1R5 cGUvQW5ub3Q+Pg1lbmRvYmoNMTE1IDAgb2JqDTw8L0NyZWF0aW9uRGF0ZShEOjIwMTMwMTIzMTAz MDI5LTA3JzAwJykvUmVjdFs5MS41NzYzIDYxMC4yMyAxNzcuMDY4IDY5My4wMjRdL05NKDY0M2Jk N2E4LTIxN2EtMDY0NS1hNGMzLTE0NjNhYThmZjMwMikvU3VidHlwZS9TdGFtcC9DWzEuMCAwLjAg MC4wXS9GIDQvTShEOjIwMTMwMTIzMTAzMjU3LTA3JzAwJykvTmFtZS8jMjNYS0VUVXZwbUtCeFF1 dElMTjV3N1FDL1AgMiAwIFIvVChyb2dlcikvU3ViaihXaXJlbGVzc01BTiBsb2dvKS9UeXBlL0Fu bm90L1BvcHVwIDEyMyAwIFIvQVA8PC9OIDEyMiAwIFI+Pj4+DWVuZG9iag0xMjMgMCBvYmoNPDwv UmVjdFs2MTIuMCA1NjMuMzYxIDc5Mi4wIDY4My4zNjFdL1N1YnR5cGUvUG9wdXAvUGFyZW50IDEx NSAwIFIvRiAyOC9PcGVuIGZhbHNlL1R5cGUvQW5ub3Q+Pg1lbmRvYmoNMTIyIDAgb2JqDTw8L1N1 YnR5cGUvRm9ybS9MZW5ndGggMzYwOC9GaWx0ZXJbL0ZsYXRlRGVjb2RlXS9OYW1lL0ZSTS9NYXRy aXhbMS4wIDAuMCAwLjAgMS4wIC0xNS4wNTgzIC02NjAuNDY0XS9SZXNvdXJjZXM8PC9Db2xvclNw YWNlPDwvQ1MwIDExNiAwIFI+Pi9Gb250PDwvVDFfMCAxMTggMCBSPj4vUHJvY1NldFsvUERGL1Rl eHRdL0V4dEdTdGF0ZTw8L0dTMCAxMjEgMCBSPj4+Pi9UeXBlL1hPYmplY3QvQkJveFsxNS4wNTgz IDY2MC40NjQgMTQwLjUxOCA3ODEuOTY0XS9Gb3JtVHlwZSAxPj5zdHJlYW0NCkiJxFfLjiS5DbzX V+QPlFaUqNfZB58NH/wBDXvnMLPAev8fcEQwsyq77V10zWyVMcB0slIpicEgGfz18iv+2Zbxz7Zr 7T2tbL0N22rLKRcvOfv29g1rfr789Ne/5+3n3y51Wlp9q5aT+2alJe/4Y6lt//7n5V+Xv31yz9in xUa27+Q1tiqVm/1j++W2leecSra12txqz2lZxnPjTj/9BTd7+40LUy0F//fi2/bb2y+3S3OPb5er p9YnHr9erh27zc0sDVwN9kjTR7yyggv1/bmlVutWcho+9UN8cfohJ6u2ddiN9ky+yul9TQu3udsl len35bisn17XZDbvZtYt/nRQP4GYZ4ejZeOOva2tpgZ8gOByBZrve/etDq5DTNLoZbtaTbOP5zLB epoGJvCTYfhk5dzrY0ywVCpDjHD4qBvCsHDtwyppDlDrcti4WMtzp01t//1DTRUYKbp9zo9mSXA8 TG5XUl2EKvW69qU43/Lx3dsFVPdy2yWs/Dw63JDFz6NVoIkUa6l0X2v5Q8Di+Gl0Z5TOVUOOOhbj xNwO4+0SmOwmEAEUMOoiWsO0sNrQQpkOMBzO70s9eeWeM5sMoGzJZj2Mt8sR0rCZho3/11p2A7HJ PCAspG3XqeTFQlKiTsCJsT/zHm1/BuEr1+MeegRSROkiA24iaJbyoP95Ctq3y5dLgNFTR+yFU/Pd wk0LXESl6fUwPGUUFXlBswLvud0MOQHKzAFD3L9RhlZAhy2y78+x99slLHAWuQq86n6D893e/j/l psyUcXqU9rKXE9XBJ1eTOpCjParJs0m/PYn2/ke093XmPawz8WGemN9OzO+/w3w7Ud/ecd8eIX/7 cfLPHyN/Wa9h/41p3tKacy2EizQfA6yDYw/2LWt73zIcARi60VgN4gUhZyzIrkY4fLkUCnpLvTca NetKWuIDeBLGqenACgJEEsYziRhQhzUrD2xQAE11iCqIzw3lU1eYSImRDKzB9RoK6YS06Yex0lzR YGkZ6a0LdQN/HHtBUwKtm0EWLpT33aTKwDsSmLFuKOAw+uCekFCIFWKC5UychUDDWpU51pk+MCjR QAc7DLJj8iZh7tkLB5Vhu2FtaiHNBRy5rk0mh6NlorkvZtOYQwmRAfpIY1WitUwEs/0Z2qkUraIF TzMvNz0yJj+Vhs2Rs5b59fNpaO9pWD5HQzvRsJ1o2N7RsH2OhuXHaTg/S0P/IxrOMw3rn01D/xQN Tyx8R8IXc7Djro6RLpfvHuY2/J0YSnpwq6slNWsxc5Vmd1MO3tbKyjGqDcTh9Hif0jBitPJuakP5 Jvh50Ka39Ty1zfdDHM1XCPZJgi8Jlu/FkelXNIf0gM5snCxOfUIISYSZKAeCuZ2HVGTbPHvfWzt5 /4XhGUNJ07HbN6I5jOp3mKYk5Mgcd/Pd6meitzq/Bgnt+9GDADLlsmVxLWzBtABTPz/e6RRg3m3e W0Wge73bt/dRxj6YL+BXnTOVbGoVi8IJs2F+DCC6pEJmGnzBLUhgl7ZgX0bJYjlH8XaV+I7aPYYE 3sK2TTLtGnWZlco54uHbRvU8TfMe1TO03dR8N3yFcswuwYuQqqCDSlLdzy5tdS1kEE4FHG7qK8zP hzCDgCYb0GKKKjJxssVGuCCqosUJM6sBFFEzoobEKqh7RpdUwdiHsms+WNymgIbgaO5srvoem64a vZKqm00c+UCra1CxOp+NmSvXGz5GkyoIcgPPyqOY1c72P6oGAeFUmNhgicsP72IQuwD7vbEhZg4W 0ENwHE25a6ha3dVeyxRUQwKFyADjpXGNjZ342gzclgk3jJKa34ZL39T+dNwqqvUC14hbZfbggvWx 2RUbV2HFdifFLW3GFkAdxtSTm9uFQk58mZohnRnVINPQTIFAo9H6PrbxMNiCHvk+hfKYsqprl1LH rryWYKMsufI2ukFp/nwhjGwZOVhH9BY2Gt+DHu/rLGyN1YmusDpV0gF+libZmAktQGBLgFoRXjOL XRMFTOgFIF5FvBpZ7EvbzOBcCSFbi8faxU8p4ucBXtaaZ2M3wHOn8lDC4tyc7bHGwEQRdNEHVOVR qE7ZZdL57pF6U/QoQ6wbWUncXcRaQ1RiOjelcxQ8TgXkF+GsktWaW1gU1RhE+1ojZ6N21KcDN7GT DRGN7aE3TF+8/oPtIXzhSJEoX8gEExMsiy7rGMFKkCmrOWYUR3UCUTEfzOJKINxFrREfsMewt3iP FuHqOxasm42BKlmkw4Gm5c+Gbg3ctUmJOArdggZ6VInowm6MvJodaVBEgGmhHsLBsQRUjcLlQ0CN rqJmJFnZ51ByEaKFSNV425mCo+3buSTOntispCgEWt5bqKL1CtgWmys0dfXO8ovmWh+dEShMhV05 esI1hBzdrMrNkHLEwKVLRvRPnBtiTqyy7RBzBBYspZgToFMdmWJO8ZBElJijlmMjZ9Q6TnyFjPM5 wBCIOYigWjX2PSxJrqHjpKGUomyc15By19By10PMbcLNiqBSiWMZlJy7Us9JyNxKF2glPXcNQRd6 jnsZxU/ouZBzRciHmHuNlkNnaBwZuJNN1tuH9S/j36Ov1RDxUxNBKdEYGl3xvea36Lymkk89Rzkn klLPue4elRDJzM5BGuH+oeai3RxajlJuCyEXOu41Mg5CZKGFLpQnNH3QhM/2KGSHEmlynkouhJxU Q9kOISdJ4aJTtFzyhyqONcxohIqLo5rgDglHBcdnCjjqtyldQ/kW6u2mP16g3aB86+g7y4y1Y632 mHYTZGUL7UadMH0L7XYN8XZoNxa6tYV0u4Z2C+lG5RaACQnXi6oc9MX6NcWtAogPyRaKLQTbXey+ QLBhxBrL1TSZllAQUGwPdgHmhFKChYeiVYqNFQ1N71BsnJbIG5usO2VE0hGB7kQxxBpTdWwh1ajU yCsKNeo0ImPH7Loi86HMePpeFJ4u08AmBH+g/CMly0IDhcBtD6ckdRplmio1dVrINKq0yUI9W0ya VTW8cXCtqlnU1dJnwaG3S8izUGdso20LbRbS7Hpos5BmLHZSZTlk4vO1GYQSQo1JFKWDIsMmchPX e1hkrC302TVLrAYBKAe2XZxRmxGiqoLk1IMSZtRldTtk2Xah8BBISkrb20kz7VNCrsRgVk3pnzWX tVAy9vyE7C11gxSjwEADMKgLsu2EGBvV6NKqUEj/A7GBjamWHK2ubF8vOLkRO3Rdh1noPV43kG7B Xmqae7p+xdeZqHSVvK/a8uszC9BC5MAKJDb9LRwea33I3+vZ4YrbXuVxOGy0P7p8vfs8aNLnFT63 F/h8jvFcLG1q8o/H+GOI30X4Q4Dfx/eF4e19MKZytXNCm98V3o/R/RDcj7E93N1j+6rQFuw0EVrw ClrhVvw+FDxiH8PP7wgQYyujQlOnyGgLu4F+YCvkGk2eECqlE5E2NSUNuAoUVtnnS8gJQG8Sdouz JwAs5WYVNQ4tlY1GY0qOQvXWVEfz8aDGxHoc5j5IxCe7cey3m3EYUht9K65hmv6OG+LybeHyPUtb AezwKp4Ph8MKLFCJmwBnKf4C2HC+4a5qFl78sGFNKF2r2LvfLFyvtVAkskG/rF6pLzktLbobDxS8 HGCP38+ffNjv3WH7V3GP2wXjtuiJuL8u2/AQJmuRwXOJGT0D07ZiRjFKhJCZ/AL4iSDxlyeTimFh cR6xOh7/w37V87YVw8D9/Yo3toNdSdTn2qBjCxT2WKBbhyJdU+Tf946UbD+lQ43USYcOAXTOk0hR 5PE4jjFkBmyDGR7+/OWmtk7CPCI6aGVw6xl1kb23ukCd8cNaByg8vo8xgJS1Ja99y+9yONNtg9hC wrAtBsZxhsyS7ZnSzvWHzNBsBnWkbEyLZoKC6OSeQeixoAJWtz15zVzz6TWDjp783NbjpF6dZqVv UfvDrVuKlMhBEmIYZS4Raj2jgWP7la/pKIBRPUXJJnJAlX1yZ8RpwetdI6vZ4P2AGbMGWxifPNYN LpxboYEpAuCqs2kkNhtQBo0oBTTVzw2XBZDMsUMkDoBGzQgtHeY9g7ezfEBjKfrcvKcBo9vWxv/M dla6e6RjVLIot5q0ceEpI2DJzTJVOnhYqIkHooHAwk2lr/E4wXKAiBMWbxR5EQ+SvZFE/YOnjdD4 VBcscSkkfScc8ZiyOOV2CYndoXqoyNZte84/1+SjI3MnKLJ7PnZhOeG5ajEco7JFUrHFW5UZuhcQ F4lJgFIL9Tkk6mvr4iJwEiqgyw4gknwnUULPPNN0Dy4MsuRYesmjJcWzFgjoLQAZth+XDlGGsVmY vHEUs5USxXjKan1wliV+Z1K0KRQITnBR2bJm7b0SvZVkppP4yOl/Q1axkdF3GeWxppMCIuhQtNlB dEvp64TSNq7Xdtg5OSS/4fqKJG7G9RKlw87g0C5VB0mSSd2L3mRnJFMQYB0eDUirA2St3tOHqBK7 ZXannqDX6G1hZWOI58bgdaxtzZa4RDRKUBahVrL4mKPD/+toAcxe0boRjBIsKT2Z1Fv0puzUz3tG SkVGoNs3UNbIzrvDnJ2Hu0/0N6w/17h+XKdM9Z4PI72wdgFkiMHh/Pv45X45vAbTQeh76EVpTntC QE/CORhKUA83pToR2MhGdWocIW/XkYBDurQineogeiZYAIOG/bzSq7Ft2bczzHRKqzwiqSc4Tkmo sDihYdq+3CIEprWzjQ16Cb6FzKm+ORDu/1DfurXBjWKE8Y+G+gm8DG6a0GVwZUKvHOrLk3bTUe+P m3AHzykr1W203x39Vx50/LZA2QZnB+sSeYRuAVWLOSVAAzu81PHH8uZLSO7t8fvy4Yhbrfj7vPwS YACRmmFPDWVuZHN0cmVhbQ1lbmRvYmoNMTIxIDAgb2JqDTw8L09QTSAxL09QIGZhbHNlL0JHMi9E ZWZhdWx0L29wIGZhbHNlL1R5cGUvRXh0R1N0YXRlL1NBIGZhbHNlL1VDUjIvRGVmYXVsdC9TTSAw LjAyMDAwNDM+Pg1lbmRvYmoNMTE4IDAgb2JqDTw8L1N1YnR5cGUvVHlwZTEvRm9udERlc2NyaXB0 b3IgMTE5IDAgUi9MYXN0Q2hhciAxNjgvV2lkdGhzWzczN10vQmFzZUZvbnQvSExDQU9IK0FyaWFs LUJvbGRNVC9GaXJzdENoYXIgMTY4L0VuY29kaW5nL01hY1JvbWFuRW5jb2RpbmcvVHlwZS9Gb250 Pj4NZW5kb2JqDTExOSAwIG9iag08PC9TdGVtViAxMzcvRm9udE5hbWUvSExDQU9IK0FyaWFsLUJv bGRNVC9Gb250RmlsZTMgMTIwIDAgUi9GbGFncyAyNjIxNzYvRGVzY2VudCAtMjA3L0ZvbnRCQm94 Wy0xNjcgLTI1MCAxMDA2IDkzOV0vQXNjZW50IDc0My9YSGVpZ2h0IDUyOS9DYXBIZWlnaHQgNzQz L1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgMC9TdGVtSCAxMDkvQ2hhclNldCgvc3Bh Y2UvcmVnaXN0ZXJlZCk+Pg1lbmRvYmoNMTIwIDAgb2JqDTw8L1N1YnR5cGUvVHlwZTFDL0xlbmd0 aCA0ODYvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJYmRgYWJgZGQU8fBxdvT30HYsykzM 0XXKz0nxDQGJq/6QZvwhwvJDhkfst/Xvvl9Nv+xZJ8oyMKw15ft+gP/7UcEdPxqEGJgYGa88cM4v qCzKTM8oUdBI1lQwtLQ01AGRxmDSDEyag0kLMGmp4JiSn5SqEFxZXJKaW6zgmZecX1SQX5RYkpqi p6DgmJOjEAQyrVghKLU4tagMKAp2nEJmsUKiQklRYkpqbmJRtkJ+mkJIRqqCb35efkllQaqCM9SU zPw8PYWi1PRMoPFFqSkKmXkKJUB1ocEKAUAr8koUEvNSFELgxvinpWUmp4IFU3OKU8szgJr0UEID CBgZljIwMzKy8G39vorv+6rubsbvXt3MfD9Ly69+n33qO8OpT1cZW69+F7/93eDhd42rzN+jv+uJ 3v5uvoBt85JW/V3ya7xY37PF3M44Xj8vbaZkL/udaUsPb5daU7s2f4HcopyS7t9q0tZst31E17Bd PNAdFhLR7Syfxfb0+zLR71bfpX5L/bYCQhgt/V0KKGr1HUzLX2X5nfzbBhhFyb+TvwPp78lAaP0d TAN5QHF5vqIlPxOm/06b/t2lm+37x4l/Ts5g//5xyp8z0zi/M3J9l+X+zjidh+e77CQe3h4ePoAA AwDDcdrVCg1lbmRzdHJlYW0NZW5kb2JqDTExNiAwIG9iag1bL0lDQ0Jhc2VkIDExNyAwIFJdDWVu ZG9iag0xMTcgMCBvYmoNPDwvTGVuZ3RoIDI1NzUvRmlsdGVyL0ZsYXRlRGVjb2RlL04gMy9BbHRl cm5hdGUvRGV2aWNlUkdCPj5zdHJlYW0NCkiJnJZ5VFN3Fsd/b8mekJWww2MNW4CwBpA1bGGRHQRR CEkIARJCSNgFQUQFFEVEhKqVMtZtdEZPRZ0urmOtDtZ96tID9TDq6Di0FteOnRc4R51OZ6bT7x/v 9zn3d+/v3d+9953zAKAnpaq11TALAI3WoM9KjMUWFRRipAkAAwogAhEAMnmtLi07IQfgksZLsFrc CfyLnl4HkGm9IkzKwDDw/4kt1+kNAEAZOAcolLVynDtxrqo36Ez2GZx5pZUmhlET6/EEcbY0sWqe ved85jnaxAqNVoGzKWedQqMw8WmcV9cZlTgjqTh31amV9ThfxdmlyqhR4/zcFKtRymoBQOkmu0Ep L8fZD2e6PidLgvMCAMh01Ttc+g4blA0G06Uk1bpGvVpVbsDc5R6YKDRUjCUp66uUBoMwQyavlOkV mKRao5NpGwGYv/OcOKbaYniRg0WhwcFCfx/RO4X6r5u/UKbeztOTzLmeQfwLb20/51c9CoB4Fq/N +re20i0AjK8EwPLmW5vL+wAw8b4dvvjOffimeSk3GHRhvr719fU+aqXcx1TQN/qfDr9A77zPx3Tc m/JgccoymbHKgJnqJq+uqjbqsVqdTK7EhD8d4l8d+PN5eGcpy5R6pRaPyMOnTK1V4e3WKtQGdbUW U2v/UxN/ZdhPND/XuLhjrwGv2AewLvIA8rcLAOXSAFK0Dd+B3vQtlZIHMvA13+He/NzPCfr3U+E+ 06NWrZqLk2TlYHKjvm5+z/RZAgKgAibgAStgD5yBOxACfxACwkE0iAfJIB3kgAKwFMhBOdAAPagH LaAddIEesB5sAsNgOxgDu8F+cBCMg4/BCfBHcB58Ca6BW2ASTIOHYAY8Ba8gCCJBDIgLWUEOkCvk BflDYigSiodSoSyoACqBVJAWMkIt0AqoB+qHhqEd0G7o99BR6AR0DroEfQVNQQ+g76CXMALTYR5s B7vBvrAYjoFT4Bx4CayCa+AmuBNeBw/Bo/A++DB8Aj4PX4Mn4YfwLAIQGsJHHBEhIkYkSDpSiJQh eqQV6UYGkVFkP3IMOYtcQSaRR8gLlIhyUQwVouFoEpqLytEatBXtRYfRXehh9DR6BZ1CZ9DXBAbB luBFCCNICYsIKkI9oYswSNhJ+IhwhnCNME14SiQS+UQBMYSYRCwgVhCbib3ErcQDxOPES8S7xFkS iWRF8iJFkNJJMpKB1EXaQtpH+ox0mTRNek6mkR3I/uQEciFZS+4gD5L3kD8lXybfI7+isCiulDBK OkVBaaT0UcYoxygXKdOUV1Q2VUCNoOZQK6jt1CHqfuoZ6m3qExqN5kQLpWXS1LTltCHa72if06Zo L+gcuiddQi+iG+nr6B/Sj9O/oj9hMBhujGhGIcPAWMfYzTjF+Jrx3Ixr5mMmNVOYtZmNmB02u2z2 mElhujJjmEuZTcxB5iHmReYjFoXlxpKwZKxW1gjrKOsGa5bNZYvY6WwNu5e9h32OfZ9D4rhx4jkK TifnA84pzl0uwnXmSrhy7gruGPcMd5pH5Al4Ul4Fr4f3W94Eb8acYx5onmfeYD5i/on5JB/hu/Gl /Cp+H/8g/zr/pYWdRYyF0mKNxX6LyxbPLG0soy2Vlt2WByyvWb60wqzirSqtNliNW92xRq09rTOt 6623WZ+xfmTDswm3kdt02xy0uWkL23raZtk2235ge8F21s7eLtFOZ7fF7pTdI3u+fbR9hf2A/af2 Dxy4DpEOaocBh88c/oqZYzFYFTaEncZmHG0dkxyNjjscJxxfOQmccp06nA443XGmOoudy5wHnE86 z7g4uKS5tLjsdbnpSnEVu5a7bnY96/rMTeCW77bKbdztvsBSIBU0CfYKbrsz3KPca9xH3a96ED3E HpUeWz2+9IQ9gzzLPUc8L3rBXsFeaq+tXpe8Cd6h3lrvUe8bQrowRlgn3Cuc8uH7pPp0+Iz7PPZ1 8S303eB71ve1X5Bfld+Y3y0RR5Qs6hAdE33n7+kv9x/xvxrACEgIaAs4EvBtoFegMnBb4J+DuEFp QauCTgb9IzgkWB+8P/hBiEtISch7ITfEPHGGuFf8eSghNDa0LfTj0BdhwWGGsINhfw8XhleG7wm/ v0CwQLlgbMHdCKcIWcSOiMlILLIk8v3IySjHKFnUaNQ30c7Riuid0fdiPGIqYvbFPI71i9XHfhT7 TBImWSY5HofEJcZ1x03Ec+Jz44fjv05wSlAl7E2YSQxKbE48nkRISknakHRDaieVS3dLZ5JDkpcl n06hp2SnDKd8k+qZqk89lganJadtTLu90HWhduF4OkiXpm9Mv5MhyKjJ+EMmMTMjcyTzL1mirJas s9nc7OLsPdlPc2Jz+nJu5brnGnNP5jHzivJ25z3Lj8vvz59c5Lto2aLzBdYF6oIjhaTCvMKdhbOL 4xdvWjxdFFTUVXR9iWBJw5JzS62XVi39pJhZLCs+VEIoyS/ZU/KDLF02KpstlZa+Vzojl8g3yx8q ohUDigfKCGW/8l5ZRFl/2X1VhGqj6kF5VPlg+SO1RD2s/rYiqWJ7xbPK9MoPK3+syq86oCFrSjRH tRxtpfZ0tX11Q/UlnZeuSzdZE1azqWZGn6LfWQvVLqk9YuDhP1MXjO7Glcapusi6kbrn9Xn1hxrY DdqGC42ejWsa7zUlNP2mGW2WN59scWxpb5laFrNsRyvUWtp6ss25rbNtenni8l3t1PbK9j91+HX0 d3y/In/FsU67zuWdd1cmrtzbZdal77qxKnzV9tXoavXqiTUBa7ased2t6P6ix69nsOeHXnnvF2tF a4fW/riubN1EX3DftvXE9dr11zdEbdjVz+5v6r+7MW3j4QFsoHvg+03Fm84NBg5u30zdbNw8OZT6 TwCkAVv+mLiZJJmQmfyaaJrVm0Kbr5wcnImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowaj dqPmpFakx6U4pammGqaLpv2nbqfgqFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AA sHWw6rFgsdayS7LCszizrrQltJy1E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9 j74KvoS+/796v/XAcMDswWfB48JfwtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2 y7bMNcy1zTXNtc42zrbPN8+40DnQutE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ 8dp22vvbgNwF3IrdEN2W3hzeot8p36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui8 6Ubp0Opb6uXrcOv77IbtEe2c7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4 qPk4+cf6V/rn+3f8B/yY/Sn9uv5L/tz/bf//AgwA94Tz+woNZW5kc3RyZWFtDWVuZG9iag01NiAw IG9iag08PC9VUkkgNTcgMCBSL1MvVVJJL1R5cGUvQWN0aW9uPj4NZW5kb2JqDTU3IDAgb2JqDSho dHRwOi8vaWVlZTgwMi5vcmcvMTYvY2FsZW5kYXIuaHRtbCkNZW5kb2JqDTU4IDAgb2JqDTw8L1VS SSA1NyAwIFIvUy9VUkkvVHlwZS9BY3Rpb24+Pg1lbmRvYmoNNTkgMCBvYmoNPDwvVVJJIDU3IDAg Ui9TL1VSSS9UeXBlL0FjdGlvbj4+DWVuZG9iag02MCAwIG9iag08PC9VUkkgNTcgMCBSL1MvVVJJ L1R5cGUvQWN0aW9uPj4NZW5kb2JqDTYxIDAgb2JqDTw8L1VSSSA2MiAwIFIvUy9VUkkvVHlwZS9B Y3Rpb24+Pg1lbmRvYmoNNjIgMCBvYmoNKGh0dHA6Ly9pZWVlODAyLm9yZy8xNi9tZWV0aW5ncy9t dGc4NCkNZW5kb2JqDTYzIDAgb2JqDTw8L1VSSSA2MiAwIFIvUy9VUkkvVHlwZS9BY3Rpb24+Pg1l bmRvYmoNNjQgMCBvYmoNPDwvVVJJKGh0dHA6Ly9kb2Mud2lyZWxlc3NtYW4ub3JnLzE2LTEzLTAw MTgpL1MvVVJJL1R5cGUvQWN0aW9uPj4NZW5kb2JqDTY3IDAgb2JqDTw8L1VSSSA2OCAwIFIvUy9V UkkvVHlwZS9BY3Rpb24+Pg1lbmRvYmoNNjggMCBvYmoNKGh0dHA6Ly9kb2Mud2lyZWxlc3NtYW4u b3JnLzE2LTEyLTA2ODItMDEpDWVuZG9iag02OSAwIG9iag08PC9VUkkgNjggMCBSL1MvVVJJL1R5 cGUvQWN0aW9uPj4NZW5kb2JqDTcwIDAgb2JqDTw8L1VSSSA3MSAwIFIvUy9VUkkvVHlwZS9BY3Rp b24+Pg1lbmRvYmoNNzEgMCBvYmoNKGh0dHA6Ly9kb2Mud2lyZWxlc3NtYW4ub3JnLzE2LTEyLTA3 MDMtMDApDWVuZG9iag03MiAwIG9iag08PC9VUkkgNzEgMCBSL1MvVVJJL1R5cGUvQWN0aW9uPj4N ZW5kb2JqDTczIDAgb2JqDTw8L1VSSSA3NCAwIFIvUy9VUkkvVHlwZS9BY3Rpb24+Pg1lbmRvYmoN NzQgMCBvYmoNKGh0dHA6Ly9kb2Mud2lyZWxlc3NtYW4ub3JnLzE2LTEyLTA2ODItMDEpDWVuZG9i ag03NSAwIG9iag08PC9VUkkgNzQgMCBSL1MvVVJJL1R5cGUvQWN0aW9uPj4NZW5kb2JqDTc2IDAg b2JqDTw8L1VSSSA3NyAwIFIvUy9VUkkvVHlwZS9BY3Rpb24+Pg1lbmRvYmoNNzcgMCBvYmoNKGh0 dHA6Ly9kb2Mud2lyZWxlc3NtYW4ub3JnLzE2LTEyLTA2ODApDWVuZG9iag03OCAwIG9iag08PC9V UkkgNzcgMCBSL1MvVVJJL1R5cGUvQWN0aW9uPj4NZW5kb2JqDTc5IDAgb2JqDTw8L1VSSSA3NyAw IFIvUy9VUkkvVHlwZS9BY3Rpb24+Pg1lbmRvYmoNODAgMCBvYmoNPDwvVVJJIDc3IDAgUi9TL1VS SS9UeXBlL0FjdGlvbj4+DWVuZG9iag0xMjcgMCBvYmoNPDwvQ3JlYXRpb25EYXRlKEQ6MjAxMzAx MjMxNzMwMTJaKS9TdWJqZWN0KElFRUUgODAyLjE2LTEzLTAwNDEtMDAtV0dMUykvQXV0aG9yKFJv Z2VyIE1hcmtzKS9DcmVhdG9yKFBhZ2VzKS9Qcm9kdWNlcihNYWMgT1MgWCAxMC43LjUgUXVhcnR6 IFBERkNvbnRleHQpL01vZERhdGUoRDoyMDEzMDEyMzEwMzUyOC0wNycwMCcpL1RpdGxlKFJlcG9y dCBmb2xsb3dpbmcgU2Vzc2lvbiAjODM6IFByb2dyZXNzIG9uIElFRUUgUHJvamVjdCBQODAyLjE2 LjMgQXJjaGl0ZWN0dXJlIGFuZCBQcml2YWN5KT4+DWVuZG9iag14cmVmDTAgMTI5DTAwMDAwMDAw MDEgNjU1MzUgZg0KMDAwMDAwMDAwNSAwMDAwMSBmDQowMDAwMDA0MjQ2IDAwMDAwIG4NCjAwMDAw MDQxMjMgMDAwMDAgbg0KMDAwMDAwNDUwOSAwMDAwMCBuDQowMDAwMDAwMDEzIDAwMDAxIGYNCjAw MDAwMDg4MjggMDAwMDAgbg0KMDAwMDA5NzMxMCAwMDAwMCBuDQowMDAwMDEwMDQ1IDAwMDAwIG4N CjAwMDAwOTczNDQgMDAwMDAgbg0KMDAwMDAxMDc5NSAwMDAwMCBuDQowMDAwMDA4OTg4IDAwMDAw IG4NCjAwMDAwMDk2NTQgMDAwMDAgbg0KMDAwMDAwMDAxNCAwMDAwMCBmDQowMDAwMDAwMDE1IDAw MDAwIGYNCjAwMDAwMDAwMTYgMDAwMDAgZg0KMDAwMDAwMDAxNyAwMDAwMCBmDQowMDAwMDAwMDE4 IDAwMDAwIGYNCjAwMDAwMDAwMTkgMDAwMDAgZg0KMDAwMDAwMDAyMCAwMDAwMCBmDQowMDAwMDAw MDIxIDAwMDAwIGYNCjAwMDAwMDAwMjIgMDAwMDAgZg0KMDAwMDAwMDAyMyAwMDAwMCBmDQowMDAw MDAwMDI0IDAwMDAwIGYNCjAwMDAwMDAwMjUgMDAwMDAgZg0KMDAwMDAwMDAyNiAwMDAwMCBmDQow MDAwMDAwMDI3IDAwMDAwIGYNCjAwMDAwMDAwMjggMDAwMDAgZg0KMDAwMDAwMDAyOSAwMDAwMCBm DQowMDAwMDAwMDQzIDAwMDAwIGYNCjAwMDAwMTA2MzggMDAwMDAgbg0KMDAwMDAxMDQ4NiAwMDAw MCBuDQowMDAwMDA0MzU2IDAwMDAwIG4NCjAwMDAxMDEyNjcgMDAwMDAgbg0KMDAwMDEwMTM2NSAw MDAwMCBuDQowMDAwMTAxNDYzIDAwMDAwIG4NCjAwMDAxMDE1NTYgMDAwMDAgbg0KMDAwMDEwMTY0 OSAwMDAwMCBuDQowMDAwMTAxNzQzIDAwMDAwIG4NCjAwMDAxMDE4MzcgMDAwMDAgbg0KMDAwMDEw MTkzNSAwMDAwMCBuDQowMDAwMTAyMDMzIDAwMDAwIG4NCjAwMDAxMDIxMzAgMDAwMDAgbg0KMDAw MDAwMDA1MiAwMDAwMSBmDQowMDAwMTAyMjI3IDAwMDAwIG4NCjAwMDAxMDIzMzEgMDAwMDAgbg0K MDAwMDEwMjQyNyAwMDAwMCBuDQowMDAwMTAyNTIzIDAwMDAwIG4NCjAwMDAxMDI2MjEgMDAwMDAg bg0KMDAwMDEwMjcxOSAwMDAwMCBuDQowMDAwMTAyODExIDAwMDAwIG4NCjAwMDAwOTczNzggMDAw MDAgbg0KMDAwMDAwMDA1NCAwMDAwMSBmDQowMDAwMTAwMDg0IDAwMDAwIG4NCjAwMDAwMDAwNjUg MDAwMDEgZg0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMTExMDMyIDAwMDAwIG4NCjAwMDAxMTEw ODIgMDAwMDAgbg0KMDAwMDExMTEzNiAwMDAwMCBuDQowMDAwMTExMTg2IDAwMDAwIG4NCjAwMDAx MTEyMzYgMDAwMDAgbg0KMDAwMDExMTI4NiAwMDAwMCBuDQowMDAwMTExMzM2IDAwMDAwIG4NCjAw MDAxMTEzOTEgMDAwMDAgbg0KMDAwMDExMTQ0MSAwMDAwMCBuDQowMDAwMDAwMDY2IDAwMDAxIGYN CjAwMDAwMDAwODMgMDAwMDEgZg0KMDAwMDExMTUyMyAwMDAwMCBuDQowMDAwMTExNTczIDAwMDAw IG4NCjAwMDAxMTE2MzIgMDAwMDAgbg0KMDAwMDExMTY4MiAwMDAwMCBuDQowMDAwMTExNzMyIDAw MDAwIG4NCjAwMDAxMTE3OTEgMDAwMDAgbg0KMDAwMDExMTg0MSAwMDAwMCBuDQowMDAwMTExODkx IDAwMDAwIG4NCjAwMDAxMTE5NTAgMDAwMDAgbg0KMDAwMDExMjAwMCAwMDAwMCBuDQowMDAwMTEy MDUwIDAwMDAwIG4NCjAwMDAxMTIxMDYgMDAwMDAgbg0KMDAwMDExMjE1NiAwMDAwMCBuDQowMDAw MTEyMjA2IDAwMDAwIG4NCjAwMDAwNjI3NzQgMDAwMDAgbg0KMDAwMDA2MzAyNSAwMDAwMCBuDQow MDAwMDAwMDg2IDAwMDAxIGYNCjAwMDAwMTExOTQgMDAwMDAgbg0KMDAwMDAxMTQ0MiAwMDAwMCBu DQowMDAwMDAwMDg5IDAwMDAxIGYNCjAwMDAwMzM4ODMgMDAwMDAgbg0KMDAwMDAzNDEwNSAwMDAw MCBuDQowMDAwMDAwMDkyIDAwMDAxIGYNCjAwMDAwMzAxOTUgMDAwMDAgbg0KMDAwMDAzMDQxNiAw MDAwMCBuDQowMDAwMDAwMDk0IDAwMDAxIGYNCjAwMDAwMzA3MTQgMDAwMDAgbg0KMDAwMDAwMDA5 NyAwMDAwMSBmDQowMDAwMDQ5NTAzIDAwMDAwIG4NCjAwMDAwNDk3NjIgMDAwMDAgbg0KMDAwMDAw MDEwMCAwMDAwMSBmDQowMDAwMDI1Mzk1IDAwMDAwIG4NCjAwMDAwMjU2MzYgMDAwMDAgbg0KMDAw MDAwMDEwMSAwMDAwMSBmDQowMDAwMDAwMTAyIDAwMDAxIGYNCjAwMDAwMDAxMDMgMDAwMDEgZg0K MDAwMDAwMDEwNCAwMDAwMSBmDQowMDAwMDAwMTA1IDAwMDAxIGYNCjAwMDAwMDAxMDYgMDAwMDEg Zg0KMDAwMDAwMDEwNyAwMDAwMSBmDQowMDAwMDAwMTA4IDAwMDAxIGYNCjAwMDAwMDAxMDkgMDAw MDEgZg0KMDAwMDAwMDExMCAwMDAwMSBmDQowMDAwMDAwMTExIDAwMDAxIGYNCjAwMDAwMDAxMTIg MDAwMDEgZg0KMDAwMDAwMDExMyAwMDAwMSBmDQowMDAwMDAwMTE0IDAwMDAxIGYNCjAwMDAwMDAx MjUgMDAwMDEgZg0KMDAwMDEwMjkwMyAwMDAwMCBuDQowMDAwMTA4MzI1IDAwMDAwIG4NCjAwMDAx MDgzNjIgMDAwMDAgbg0KMDAwMDEwNzM0OSAwMDAwMCBuDQowMDAwMTA3NTEyIDAwMDAwIG4NCjAw MDAxMDc3NTQgMDAwMDAgbg0KMDAwMDEwNzI0MSAwMDAwMCBuDQowMDAwMTAzMzI2IDAwMDAwIG4N CjAwMDAxMDMyMTQgMDAwMDAgbg0KMDAwMDAwMDE2MiAwMDAwMCBuDQowMDAwMDAwMTI2IDAwMDAx IGYNCjAwMDAwMDAwMDAgMDAwMDEgZg0KMDAwMDExMjI1NiAwMDAwMCBuDQowMDAwMDA0MTk2IDAw MDAwIG4NCnRyYWlsZXINPDwvU2l6ZSAxMjkvUm9vdCA1NSAwIFIvSW5mbyAxMjcgMCBSL0lEWzw2 QTM2NjE4NzA2OEZFMDlBNkFERjYyNzNFNEY2RjM4Qz48QTcxNDM4MjM0MkFFNDI0MTkxQzY3RDAy NjY1QkM3QUE+XT4+DXN0YXJ0eHJlZg0xMTI1NTYNJSVFT0YN --Apple-Mail=_1A7FA3F8-9044-4B78-8D27-619EA8C6E699 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii --Apple-Mail=_1A7FA3F8-9044-4B78-8D27-619EA8C6E699-- --Apple-Mail=_E0C99E61-5EBB-4A37-A73F-10115EDCCE35-- From acmorton@att.com Thu Jan 24 16:09:02 2013 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 AA5BA21F853A for ; Thu, 24 Jan 2013 16:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0ChVK96GD40 for ; Thu, 24 Jan 2013 16:09:00 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 5F90721F84F3 for ; Thu, 24 Jan 2013 16:08:46 -0800 (PST) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 0DF3D120855; Thu, 24 Jan 2013 19:10:01 -0500 (EST) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id 1C1CCE36DE; Thu, 24 Jan 2013 19:03:25 -0500 (EST) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Thu, 24 Jan 2013 19:08:45 -0500 From: "MORTON JR., ALFRED (AL)" To: "trevor.burbridge@bt.com" , "aservin@lacnic.net" , "lmap@ietf.org" Date: Thu, 24 Jan 2013 19:08:39 -0500 Thread-Topic: [lmap] Proposed LMAP Charter Thread-Index: Ac36IKlZjVzdY+/yT3KDVqJ7MOmnnAABtunQAAIgPbAAANCAUAAWnr9w Message-ID: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <49B53DD1-B801-4412-B503-0825F646816F@isoc.org> In-Reply-To: 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 Cc: "philip.eardley@bt.com" , "mlinsner@cisco.com" , "ford@isoc.org" , "trammell@tik.ee.ethz.ch" Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jan 2013 00:09:02 -0000 I agree with option b) below, given those three as choices. I wasn't thinking of cross MA or full-study statistics as part of LMAP, or any standards-setting effort for that matter. Analysis is partly art. While the key IPPM metrics mandate the collection and storage of singletons= , their value is sometimes very limited (the loss ratio is zero, no need to s= ee the arrival status of each packet) and has storage implications in large sc= ale. It has made sense in some circumstances to store singletons (e.g., diagnost= ics),=20 but not forever. Al > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > trevor.burbridge@bt.com > Sent: Thursday, January 24, 2013 8:27 AM > To: MORTON JR., ALFRED (AL); aservin@lacnic.net; lmap@ietf.org > Cc: philip.eardley@bt.com; mlinsner@cisco.com; ford@isoc.org; > trammell@tik.ee.ethz.ch > Subject: Re: [lmap] Proposed LMAP Charter >=20 > I was thinking really of statistics produced across a set of MAs - this > could not be done on the MA and is beyond the scope of the LMAP > measurement control and collection. >=20 > Statistics for a single MA, I guess could be just another test that the > probe could operate. One more question for this group would then be if > this statistic just looks the same as a singleton measurement to the LMAP > framework, or whether LMAP contains support for constructing statistics i= n > different ways from singleton metrics. Obviously the former simplifies ou= r > work considerably but means different statistics have to be coded as a > single test and may not be able to operate in conjunction with other > statistics based upon the same singleton test. The other problem is that > streams or statistics will overlap - contention of tests needs to be done > on the singleton level. >=20 > Options: > a) only allow singleton measures - streams and statistics are constructed > after collection. Obviously not good if the singleton test is a ping ever= y > second. > b) allow streams and statistics to be coded as tests but only allow > scheduling/contention to be managed at the test level within LMAP. If > streams/statistics overlap they may affect each other. Contention > management for sub-test elements (e.g. singleton ping tests within an > average latency stream) would be coded into the test. > c) allow streams and statistics to be constructed on the MA but manage > contention at the singleton level. In effect same as (a) but with > processing capabilities on the MA. Could get very complicated. >=20 > I guess I would advocate (b). >=20 > Trevor. >=20 > >-----Original Message----- > >From: MORTON JR., ALFRED (AL) [mailto:acmorton@att.com] > >Sent: 24 January 2013 12:54 > >To: Burbridge,T,Trevor,TUB8 R; aservin@lacnic.net; lmap@ietf.org > >Cc: Eardley,PL,Philip,TUB8 R; mlinsner@cisco.com; ford@isoc.org; > >trammell@tik.ee.ethz.ch > >Subject: RE: [lmap] Proposed LMAP Charter > > > >Hi Trevor, > > > >You are right that post-singleton measurement processing is part of > >IPPM's work (singletons, samples, statistics). But LMAP could easily > >use what has been specified in IPPM RFCs to specify some form of > >results format. So I tend to agree with Arturo. > > > >For me, the simplest LMAP framework is the one which ensures > >the same measurements are performed according to the same sampling plan > >(schedule) and reported the same way by each organization in their > network. > >Thus, there is freedom to choose the best implementation within a > >network. > > > >regards, > >Al > > > > > >> -----Original Message----- > >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf > >Of > >> trevor.burbridge@bt.com > >> Sent: Thursday, January 24, 2013 6:46 AM > >> To: aservin@lacnic.net; lmap@ietf.org > >> Cc: philip.eardley@bt.com; mlinsner@cisco.com; ford@isoc.org; > >> trammell@tik.ee.ethz.ch > >> Subject: Re: [lmap] Proposed LMAP Charter > >> > >> > >> I would argue that the scope of LMAP is to define the overall > measurement > >> framework. If this framework is used to run the same (IPPM defined) > tests > >> then it will yield comparable results. > >> > >> How to process these results into equivalent statistics is post- > >> measurement and beyond the scope of LMAP (and would probably fall in > >the > >> remit of IPPM in any case). Similar argument for data sharing - data > can > >> be anonymised/aggregated (if necessary) and shared after collection. > >> > >> Trevor. > >> > >> >-----Original Message----- > >> >From: Arturo Servin [mailto:aservin@lacnic.net] > >> >Sent: 24 January 2013 10:51 > >> >To: lmap@ietf.org > >> >Cc: Matthew Ford; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R= ; > >> >mlinsner@cisco.com; Brian Trammell > >> >Subject: Re: [lmap] Proposed LMAP Charter > >> > > >> >Hi al, > >> > > >> > I was going to ask something similar. > >> > > >> > For example, we have a project where we have done some > >> >measurements but those are confined to a specific region of the world= . > It > >> >would be interesting to share that data among other organizations > doing > >> the > >> >same but today we can't because there is not a standard (that I asume > we > >> >are intent to produce) and because privacy implications (that I am no= t > >> sure > >> >that we are addressing in the chapter). > >> > > >> > So, is a WG goal to address the problem of sharing and anomyzing > >> >data (or address any privacy concern)? > >> > > >> >Regards, > >> >as > >> > > >> >On 23 Jan 2013, at 10:15, Brian Trammell wrote: > >> > > >> >> hi Mat, Phil, all, > >> >> > >> >> I agree as well, though other comments on finer points may follow. > One > >> >inline below. > >> >> > >> >> On 23 Jan 2013, at 13:07 , Matthew Ford wrote: > >> >> > >> >>> Phil, > >> >>> > >> >>> Nice post, which I think I completely agree with. > >> >>> > >> >>> On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: > >> >>> > >> >>>> * We assume that Measurement Agent, tests Controller and > >> results > >> >Collector are all under control of same organisation (eg Samknows, > FCC, > >> BT). > >> >Reason: Inter-organisation interactions (for example to share results= ) > is > >> >better handled by business-level negotiation than a control protocol. > >> >>> > >> >>> I think we also need an assumption that nothing will preclude > having > >> >collectors, for example, be under control of third-parties. I think i= t > is > >> worth > >> >explicitly stating that, unless there is disagreement on this point? > >> >> > >> >> +1 on this point. I'd suggest that we leave the component > >> >ownership/control issues completely aside; i.e., we don't necessarily > >> want to > >> >preclude organization(s) from agreeing to use a measurement > >> infrastructure > >> >in place (which uses this control protocol) for sharing of > intermediate > >> or final > >> >measurement results (in support of an existing business-level > agreement). > >> >> > >> >> What's _really_ important about this assumption is that it makes th= e > >> >problems of inter-domain measurement control and exchange explicitly > >out > >> >of scope for the charter, and simplifies issues of trust among the > >> >components. I think it should probably be explicitly phrased as an > issue > >> of > >> >scope rather than an assumption about deployment. > >> >> > >> >> Cheers, > >> >> > >> >> Brian > >> >> > >> >> > >> >> _______________________________________________ > >> >> 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 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From julm+lmap@autogeree.net Fri Jan 25 03:10:06 2013 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 AC83C21F8803 for ; Fri, 25 Jan 2013 03:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIIsbXHO6-Cf for ; Fri, 25 Jan 2013 03:10:05 -0800 (PST) Received: from chomsky.autogeree.net (chomsky.autogeree.net [91.216.110.36]) by ietfa.amsl.com (Postfix) with ESMTP id 5274621F8639 for ; Fri, 25 Jan 2013 03:10:04 -0800 (PST) Received: by localhost.local (localhost.local, from userid 1000) id 24F0A20ABE; Fri, 25 Jan 2013 12:09:55 +0100 (CET) Date: Fri, 25 Jan 2013 12:09:55 +0100 From: Julien Moutinho To: lmap@ietf.org Message-ID: <20130125110955.GA17360@localhost> References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <20130124102626.GA7215@localhost> <9510D26531EF184D9017DF24659BB87F340D7963AE@EMV65-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F340D7963AE@EMV65-UKRD.domain1.systemhost.net> X-Operating-System: 3.2.0-4-amd64 x86_64 GNU/Linux OpenPGP: preference=signencrypt; id=F2E027182397AC0775714F2AD15AF7F467E8299B; url="http://autogeree.net/~julm/pub.gpg" User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jan 2013 11:10:06 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Phil! some comments of mine inlined. Le mer. 23 janv. 2013 =C3=A0 09:54:39 +0000, philip.eardley@bt.com a =C3=A9= crit : > The LMAP WG makes the following architectural assumptions - in order to > make rapid progress with an acceptable loss of generality:- > > * We assume that Measurement Agent, tests Controller and > results Collector are all under control of same organisation (eg > Samknows, FCC, BT). Reason: Inter-organisation interactions (for > example to share results) is better handled by business-level > negotiation than a control protocol. agreed for an initial scope. though, what is the precise meaning of "control" here? because shouldn't the MA be "under control" of anyone but the owner of the system it runs on? which for instance would mean free/open source software, and being able to precisely see and filter what is sent to whom and when. [phil] "under control" - I'd say this is the party who owns /manages the MA. For a hardware device this is "the owner of the system it runs on" - for a software MA then it's the owner of the app (not necessarily the owner of the system it runs on). the Controller instructs the MA what test server(s) to use and what Collectors to send results to. [julm] what I just think is that there should be an MA-local policy configuration that is authoritative over test configurations sent by Controllers, and whoever on the system happens to be able to edit this MA-local policy is said the owner of the MA, so that it is not necessarily the same owner than the Controller's or Collector's. I agree to left it aside for an initial scope. > * We assume no negotiation is needed between Controller and MA. > The Controller already knows the characteristics of the MA, for > instance via TR069 for Broadband Forum devices. The Controller simply > instructs (securely) the MA "Measure this"; the MA replies "OK /error". agreed for an initial scope, but I think there should eventually be a more complex MA<>Controller negotiation, for instance to synchronise several MA, a Controller could tell each MA to recontact it in a given amount of time, until it has accumulated a given number of MA to trigger the probing. [phil] please can you explain a bit more, I don't follow. [julm] for instance in the context of simple-loss tomography we want each MA within a set large enough, to send one ping to a common Test server, all at the same time. I have been suggested that one way to coordinate the MA could be to have the Controller accumulating MA by telling them to recontact it later or just keep waiting on that established connexion, and once it considers the set of MA large enough, to tell each MA to send the ping. There certainly are several algorithms/methods to reach certain kinds of temporal synchronisation amongst MA, and maybe this is a property useful in enough uses cases so that a variety of them could be considered in LMAP. I agree to left it aside for an initial scope. also, some characteristics may be volatile, like the geolocation, and may be used by the Controller to filter its MA, therefore I think a mechanism to keep track of the MA's characteristics should be part of this negotiation; be it via TR-069 if it is flexible and supported enough or else. [phil] i agree that it will learn these characteristics via TR-069 or something else outside lmap. i think the implication for lmap is that no negotiation is needed in lmap. [phil] let me see if i get your scenario. we have mobiles with MA functionality. the Controller wants tests to be run by mobiles in Cambridge. from an lmap point of view, i think the Controller would liaise with the mobile operator's location database to select mobiles that are near Cambridge, and then send an instruction to those mobiles "for the next hour, if you're in cambridge then run this test". an hour later it would re-check the location DB to re-tweak the set of mobiles and re-send the instruction. i dont think this needs lmap negotiation. [julm] what I simply think is that there should be a way for the Controller to probe the MA's capabilities to select the MA it wants to use before sending it a test configuration. When speaking about geolocation I was referring to probe the embedded GPS or the GSM tower identifier; not contacting an operator's location database. Maybe the tracking of capabilities could rather be a feedback from the Collector to the Controller. but I don't know/haven't thought about it more at this point. > * We assume the raw measurement results are reported; filtering > /averaging of measuremnts by the MA is not in the initial scope, except > as defined by IPPM as part of the metric definition. what is the need for this assumption? I think the MA should just be able to perform computation when the concept of the probing allows it, for instance for certain kinds of local anomalies detection having the MA doing some computation is cheap on the MA and saves a lot of computer resources when data mining the Collector. [phil] the reason for the assumption is to simplify the definition of lmap's Reporting data model. reporting the raw measurements would, i think, be the most usual case. I agree that there'll be some cases where the MA wants to do some averaging (or other data manipulation) rather than leaving all data manipulation to the Collector - but I think it is Ok to leave this out of the initial scope. [julm] agreed for an initial scope. > * We assume that data privacy issues are out of scope although > security is considered. The MA, Controller and Collector are all under > control of the same organisation. IPPM considers the implications of > any passive measurement tests that it defines. what is the need for this frightening assumption? does it just mean that privacy concerns must be specified within IPPM RFC? [phil] sorry, didn't phrase this bullet very well. We meant: as a consequence of the previous assumptions, therefore data privacy can be excluded from the scope (because MA, controller and collector are under control of the same organisation). of course the Collector may send some anonymised version of the collected data to other parties - this would clearly have privacy implications. but this is out of scope -- the range of things that the Collected data could be used for are large - for instance how could the operator use it for their network mgt? this requires interaction with the OSS, and i think this is out of scope of lmap. Basic rule of thumb therefore is that lmap avoids thinking about "how to use the collected measurements" - its scope is "how to control and collect the measurements" [julm] well, my concern here is not on how to use the collected measurement= s, but rather on how to give the user running a MA a language to express a policy specifying what they allow their MA to do, which for instance could express things like: - allow to receive configurations from such Controller; - allow to send samples to such Collector; - allow such category of probes to run during such time periods/system parameters/network parameters; - allow such category of probes to use such system devices/system ressources/network interfaces. > The LMAP WG standardises the following items: > > 1. The data model that defines the test schedule, which includes: > a. The IPPM metric to be tested and values for its parameters. > {Question: is the restriction to IPPM OK? Ie non-IPPM tests are out of = scope} what is the need for this assumption? I think metrics should be easily extensible according to a common schema (for instance specifying a hierarchical namespace for probes gathering them by ///..). [phil] thanks - interested to hear people's views about this [julm] and this hierarchy could be replicated in the test configuration and report sample models. looking forward to the discussion, julm --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQJNBAEBCgA3BQJRAmf2MBSAAAAAABUAEnBrYS1hZGRyZXNzQGdudXBnLm9yZ2p1 bG1AYXV0b2dlcmVlLm5ldAAKCRBeJxnPcP6KniLED/0dj9SkjimMFYogb8HapG8S uLSNQ0294HvfSZIC/r0j0RxLKr6mYtxrlODM0xiIfSIeAS/vvmc2i1yv+74GjcaU 6e0r/e2gy1brg9L9SIVcwTil533EtA/luD+VMUoBALrMVbkq3i7oBMMwB6kLZ85m XHC3Hlckw7wD2tRYjGbrokqBfgwpICXIKPoVIVt2X6GwiSmAjqDTPaiTh7vss8Hj ANyYptWBD+gHFpfKLLtrsZJHp+/VbGno07lwb4XyChWj3o+RC/OSTreVVsGSYSiV Lw4v3lOYYcZhAPtTZn21r4HOEWaRm2KvQ5TgFAKawMrACQdEt8yWHyUlzS31Cbqk F8DJYXAhT+hwTqyQrs6e7TsnDGLQacKChzOO6SoJnjZRjlVEv4+WECA0nAfhUD2h /58yIvaFRNcuGcFk1s9nIpksmT51sKeOnFF/l3q5BnQvmAPYi7A/PowfPsjFaLN/ Q6ZlZkgznudVI2UTFRv5OODpv1kj1rYEBv6AXjRCiQWcsKbPotRWsxRuDwtfdfAn b6LAaPYRJijiXmw3hWJUK1crvkqp+LIGOcLkHjCQyt8HWtKJULEiHKIRhX+/a688 zz/McoOXao8SJAZhfe1u2txMG34zqWiEgVH/naMXcEGH9mlNEdMAnPClXBl3ha6n idAvRIF9Fzmxx8jD+uOhaA== =87Gg -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From jamesmilleresquire@gmail.com Fri Jan 25 08:30:25 2013 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 ACBB621F88AE for ; Fri, 25 Jan 2013 08:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae0P50+rsfzG for ; Fri, 25 Jan 2013 08:30:24 -0800 (PST) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8F34C21F8887 for ; Fri, 25 Jan 2013 08:30:24 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id fr13so396611vbb.16 for ; Fri, 25 Jan 2013 08:30:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ylYYtUFul7Y5oRmRN2rIQsD1EURAsW9+rPio0RBlDcE=; b=veffrVJNu206Z6SIOaAQD84QDhjPpEDg5BD6XAzTme9CHY+EPcLOdOPwvwcxuV/QHU Ih3p4152lMSDNhO/m/LrfFsZ/mhcHRH8qUC9HJnfqkDwMUoqpI3YM90fGVD8JHsjkQAo 3N78mVgUMNdHsnwM3O6Ozjz9WwBMT7uWsURT18Giemy9fivWbHwhxOzotpf/CF5iL9iz ugPna5gN5dTeivkh2vq8ZDU+PD1mlQrcFMoQn4UhOrouZGX1/3GURfeUnUQKGgbKZNws vT03tyGK1cbCECEi0a3n1kWjSKcDnmuzAKdum76WMwfrL/Hu/Hy67PdxgxNp5WD3zBqD bvow== X-Received: by 10.52.70.205 with SMTP id o13mr5762247vdu.75.1359131423951; Fri, 25 Jan 2013 08:30:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.13.70 with HTTP; Fri, 25 Jan 2013 08:29:53 -0800 (PST) In-Reply-To: References: From: James Miller Date: Fri, 25 Jan 2013 11:29:53 -0500 Message-ID: To: Marc Linsner Content-Type: multipart/alternative; boundary=20cf307f32b0ba4b1404d41f71c1 Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Use Case draft X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jan 2013 16:30:25 -0000 --20cf307f32b0ba4b1404d41f71c1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks again Marc for all your contributions to the effort. I would perhaps add in the use cases the regulator as another stakeholder. If this text is helpful please feel free to use: Regulators in jurisdictions around the world are responding to consumers' adoption of broadband technology solution for traditional telecommunications and media services by reviewing the historical approaches to regulating these industries and services and in some cases modifying existing approaches or developing new solutions. Some jurisdictions have responded to a perceived need for greater information about broadband performance in the development of regulatory policies and approaches for broadband technologies by developing large-scale measurement programs. Programs such as the U.S. Federal Communications Commission's Measuring Broadband America, U.K. Ofcom's UK Broadband Speeds reports and a growing list of others programs employ a diverse set of operational and technical approaches to gathering data in scientifically and statistical robust ways to perform analysis and reporting on diverse aspects of broadband performance. While each jurisdiction responds to distinct consumer, industry, and regulatory concerns, much commonality exists in the need to produce datasets that are able to compare multiple broadband providers, diverse technical solutions, geographic and regional distributions, and marketed and provisioned levels and combinations of broadband services. Regulators role in the development and enforcement of broadband policies also require that the measurement approaches meet a high level of verifiability, accuracy and fairness to support valid and meaningful comparisons of broadband performance. LMAP standards could answer regulators shared needs by providing scalable, cost-effective, scientifically robust solutions to the measurement and collection of broadband performance information. http://tools.ietf.org/html/draft-linsner-lmap-use-cases-00 The opinions expressed are those of the author and do not necessarily represent the views of the Federal Communications Commission or the United States Government; The Maureen and Mike Mansfield Foundation; or any Japanese Ministry or the Government of Japan. On Fri, Dec 21, 2012 at 12:32 PM, Marc Linsner wrote: > In an effort to move things forward, I submitted this draft to dissect th= e > use cases away from both the requirements and architecture discussions. > The goal is to have a discussion and come to consensus on the use cases = to > be considered if/when the LMAP work moves forward. Hopefully, breaking > topics into smaller more portable documents will allow the topics to move > forward at different speeds. > > Admittedly, this draft is far from complete, but I made an attempt to > capture (at least in part) the conversation around use cases from the lis= t. > > Fire away=85.. > > -Marc- > > > A new version of I-D, draft-linsner-lmap-use-cases-00.txt > has been successfully submitted by Marc Linsner and posted to the > IETF repository. > > Filename: draft-linsner-lmap-use-cases > Revision: 00 > Title: Large-Scale Broadband Measurement Use Cases > Creation date: 2012-12-21 > WG ID: Individual Submission > Number of pages: 5 > URL: > http://www.ietf.org/internet-drafts/draft-linsner-lmap-use-cases-00.txt > Status: > http://datatracker.ietf.org/doc/draft-linsner-lmap-use-cases > Htmlized: > http://tools.ietf.org/html/draft-linsner-lmap-use-cases-00 > > > Abstract: > Measuring broadband performance on a large scale is important for > network diagnostics by providers and users, as well for as public > policy. To conduct such measurements, user networks gather data, > either on their own initiative or instructed by a measurement > controller, and then upload the measurement results to a designated > measurement server. Understanding the various scenarios and users of > measuring broadband performance is essential to development of the > system requirements. The details of the measurement metrics > themselves are beyond the scope of this document. > > > > > > > The IETF Secretariat > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > --20cf307f32b0ba4b1404d41f71c1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks again Marc for all your contributions to the effort.

<= div>I would perhaps add in the use cases the regulator as another stakehold= er. =A0If this text is helpful please feel free to use:

Regulators in jurisdictions a= round the world are responding to consumers' adoption of broadband tech= nology solution for traditional telecommunications and media services by re= viewing the historical approaches to regulating these industries and servic= es and in some cases modifying existing approaches or developing new soluti= ons. Some jurisdictions have responded to a perceived need for greater info= rmation about broadband performance in the development of regulatory polici= es and approaches for broadband technologies by developing large-scale meas= urement programs. Programs such as the U.S. Federal Communications Commissi= on's Measuring Broadband America, U.K. Ofcom's UK Broadband Speeds = reports and a growing list of others programs employ a diverse set of opera= tional and technical approaches to gathering data in scientifically and sta= tistical robust ways to perform analysis and reporting on diverse aspects o= f broadband performance. While each jurisdiction responds to distinct consu= mer, industry, and regulatory concerns, much commonality exists in the need= to produce datasets that are able to compare multiple broadband providers,= diverse technical solutions, geographic and regional distributions, and ma= rketed and provisioned levels and combinations of broadband services. Regul= ators role in the development and enforcement of broadband policies also re= quire that the measurement approaches meet a high level of verifiability, a= ccuracy and fairness to support valid and meaningful comparisons of broadba= nd performance. LMAP standards could answer regulators shared needs by prov= iding scalable, cost-effective, scientifically robust solutions to the meas= urement and collection of broadband performance information.

http://tools.ietf.org/html/draft-linsner-lmap-use-cases-00<= /a>

The opinions expressed are those of the autho= r and do not necessarily represent the views of the Federal Communications = Commission or the=A0United States Government; The Maureen and Mike Mansfiel= d Foundation; or any Japanese Ministry or the Government of Japan.=A0

On Fri, Dec 21, 2012 at 12:32 PM, Marc Linsn= er <mlinsner@cisco.com> wrote:
In an effort to move things forward, I submitted this draft to = dissect the use cases away from both the requirements and architecture disc= ussions. =A0The goal is to have a discussion and come to consensus on the u= se cases to be considered if/when the LMAP work moves forward. =A0Hopefully= , breaking topics into smaller more portable documents will allow the topic= s to move forward at different speeds.

Admittedly, this draft is far from complete, but I made= an attempt to capture (at least in part) the conversation around use cases= from the list.

Fire away=85..

-Marc-


A new version of I-D, draft-linsner-lmap-use-= cases-00.txt
has = been successfully submitted by Marc Linsner and posted to the
IETF repository.
=

Filename: =A0draft-linsner-lmap-use-cases
Revision: =A000
Title: <= span style=3D"white-space:pre-wrap"> =A0Large-Scale Broadband Measur= ement Use Cases
Creation date: =A02012-12-21
WG ID: =A0Individual Submis= sion
Number of pages: 5


Abstract:
=A0=A0 Measuring broadband performance on a large scale is important for
=A0=A0 network diag= nostics by providers and users, as well for as public
=A0=A0 policy.=A0=A0To conduct such measurements, user networks gather data= ,
=A0=A0 either o= n their own initiative or instructed by a measurement
=A0=A0 controller, and then upload the measurement results to a designated<= /div>
=A0=A0 measuremen= t server.=A0=A0Understanding the various scenarios and users of
=A0=A0 measuring broadband performance is essential to development of the
=A0=A0 system requ= irements.=A0=A0The details of the measurement metrics
=A0=A0 themselves are beyond the scope of this document.


=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0


The IETF Secretariat


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


--20cf307f32b0ba4b1404d41f71c1-- From Michael.K.Bugenhagen@centurylink.com Fri Jan 25 09:10:44 2013 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 4B48521F8460 for ; Fri, 25 Jan 2013 09:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLpTwy09ve3o for ; Fri, 25 Jan 2013 09:10:43 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id B385821F84D7 for ; Fri, 25 Jan 2013 09:10:43 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r0PHAdN4003016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jan 2013 10:10:40 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 6F68B1E005A; Fri, 25 Jan 2013 11:10:34 -0600 (CST) Received: from sudnp797.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 3AC3F1E0049; Fri, 25 Jan 2013 11:10:34 -0600 (CST) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r0PHAX2O021679; Fri, 25 Jan 2013 10:10:33 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r0PHAX4r021674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 10:10:33 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([2002:9775:ce1b::9775:ce1b]) with mapi id 14.02.0318.001; Fri, 25 Jan 2013 11:10:33 -0600 From: "Bugenhagen, Michael K" To: "'trevor.burbridge@bt.com'" , "ford@isoc.org" , "philip.eardley@bt.com" Thread-Topic: [lmap] Proposed LMAP Charter Thread-Index: AQHN9b4JTFTNyLguM0iYwcPeFnywgZhXGGqAgAAlJoCAAE6aAIACxU0g Date: Fri, 25 Jan 2013 17:10:32 +0000 Message-ID: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <49B53DD1-B801-4412-B503-0825F646816F@isoc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mlinsner@cisco.com" , "lmap@ietf.org" Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jan 2013 17:10:44 -0000 Trevor, Just observing something here -- Given there is no standard definition = of what "3rd party" is, and the definition varies depending on if we discus= s business roles, vs. vendor roles, vs. operator the undefined use of "3rd = party" without some contextual qualifier is pretty dangerous in terms of ca= using confusion. So if the words "3rd party" is used anywhere it really has to be accompan= ied by some type of category or qualifier. Regards, Mike=20 -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of tre= vor.burbridge@bt.com Sent: Wednesday, January 23, 2013 10:49 AM To: ford@isoc.org; philip.eardley@bt.com Cc: mlinsner@cisco.com; lmap@ietf.org Subject: Re: [lmap] Proposed LMAP Charter Our position is that nothing should preclude 3rd parties operating separate= components of the measurement architecture. Of course data protection woul= d have to be considered/observed but we will not need anything explicit in = the technical work of LMAP to do so. What we want to avoid explicitly is two or more controllers connecting to a= single Measurement Agent and having to manage such conflicts. There might,= however, be two or more controllers for disjoint subsets of measurement ag= ents (e.g. one for mobile devices and one for home gateways). There of cour= se will be multiple test servers (to test multiple network paths) and could= also be multiple collectors (where a MA replicates or partitions its resul= ts). Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England = no: 1800000=20 >-----Original Message----- >From: Matthew Ford [mailto:ford@isoc.org] >Sent: 23 January 2013 12:08 >To: Eardley,PL,Philip,TUB8 R >Cc: mlinsner@cisco.com; lmap@ietf.org; Burbridge,T,Trevor,TUB8 R >Subject: Re: [lmap] Proposed LMAP Charter > >Phil, > >Nice post, which I think I completely agree with. > >On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: > >> * We assume that Measurement Agent, tests Controller and results >Collector are all under control of same organisation (eg Samknows, FCC, BT= ). >Reason: Inter-organisation interactions (for example to share results)=20 >is better handled by business-level negotiation than a control protocol. > >I think we also need an assumption that nothing will preclude having=20 >collectors, for example, be under control of third-parties. I think it=20 >is worth explicitly stating that, unless there is disagreement on this poi= nt? > >Mat > _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From mlinsner@cisco.com Fri Jan 25 09:56:03 2013 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 E37D421F8457 for ; Fri, 25 Jan 2013 09:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.001 X-Spam-Level: X-Spam-Status: No, score=-9.001 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQCk+b+Qz1E6 for ; Fri, 25 Jan 2013 09:56:03 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEC721F8200 for ; Fri, 25 Jan 2013 09:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3809; q=dns/txt; s=iport; t=1359136563; x=1360346163; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=s/q0E83WMFUtcHUdOM4FBUMj9SlGO0vxgmcJsuK8meE=; b=WGI++uQYF47u/6aN/gug46JFg71DS4Trnhf8/APF/j7hP0sIW1M26UJ9 IduIOwX0qtjtw60k4jLo+rhKVJp2CPHOMdLiZoDzqbO52hisK0daSIqzb +dV8OuA9XDM01Y1EhfZ8x9R1i3Sc0XQZJ29rIxkf4b+m3T8ghO1awXgpc U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAMDFAlGtJV2b/2dsb2JhbABFgzi7GxZzgh4BAQEEAQEBNwIBMQsMAgUIEQECAQEBAScdER8DBggGAQ0FiA8MvkYEBI0ADoQtA4hhjSyFa4pdgxWBUQ X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208";a="168175765" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 25 Jan 2013 17:56:02 +0000 Received: from [10.82.238.244] (rtp-vpn5-1774.cisco.com [10.82.238.244]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0PHtpRJ001463; Fri, 25 Jan 2013 17:55:59 GMT User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 25 Jan 2013 12:55:46 -0500 From: Marc Linsner To: "Bugenhagen, Michael K" , "'trevor.burbridge@bt.com'" , "ford@isoc.org" , "philip.eardley@bt.com" Message-ID: Thread-Topic: [lmap] Proposed LMAP Charter In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "lmap@ietf.org" Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jan 2013 17:56:04 -0000 Mike, How about 'different administrative domain'? -Marc- -----Original Message----- From: "Bugenhagen, Michael K" Date: Friday, January 25, 2013 12:10 PM To: "'trevor.burbridge@bt.com'" , "ford@isoc.org" , "philip.eardley@bt.com" Cc: Marc Linsner , "lmap@ietf.org" Subject: RE: [lmap] Proposed LMAP Charter >Trevor, > > Just observing something here -- Given there is no standard >definition of what "3rd party" is, and the definition varies depending on >if we discuss business roles, vs. vendor roles, vs. operator the >undefined use of "3rd party" without some contextual qualifier is pretty >dangerous in terms of causing confusion. > > So if the words "3rd party" is used anywhere it really has to be >accompanied by some type of category or qualifier. > >Regards, >Mike > > > > >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >trevor.burbridge@bt.com >Sent: Wednesday, January 23, 2013 10:49 AM >To: ford@isoc.org; philip.eardley@bt.com >Cc: mlinsner@cisco.com; lmap@ietf.org >Subject: Re: [lmap] Proposed LMAP Charter > >Our position is that nothing should preclude 3rd parties operating >separate components of the measurement architecture. Of course data >protection would have to be considered/observed but we will not need >anything explicit in the technical work of LMAP to do so. > >What we want to avoid explicitly is two or more controllers connecting to >a single Measurement Agent and having to manage such conflicts. There >might, however, be two or more controllers for disjoint subsets of >measurement agents (e.g. one for mobile devices and one for home >gateways). There of course will be multiple test servers (to test >multiple network paths) and could also be multiple collectors (where a MA >replicates or partitions its results). > > >Trevor. > >Trevor Burbridge >Network Infrastructure & Innovation | BT Innovate & Design >Tel: 01473 645115 >Fax: 01473 640929 > >This email contains BT information, which may be privileged or >confidential. It's meant only for the individual(s) or entity named >above. If you're not the intended recipient, note that disclosing, >copying, distributing or using this information is prohibited. If you've >received this email in error, please let me know immediately on the email >address above. Thank you. >We monitor our email system, and may record your emails. >British Telecommunications plc >Registered office: 81 Newgate Street London EC1A 7AJ Registered in >England no: 1800000 > > >>-----Original Message----- >>From: Matthew Ford [mailto:ford@isoc.org] >>Sent: 23 January 2013 12:08 >>To: Eardley,PL,Philip,TUB8 R >>Cc: mlinsner@cisco.com; lmap@ietf.org; Burbridge,T,Trevor,TUB8 R >>Subject: Re: [lmap] Proposed LMAP Charter >> >>Phil, >> >>Nice post, which I think I completely agree with. >> >>On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: >> >>> * We assume that Measurement Agent, tests Controller and >>>results >>Collector are all under control of same organisation (eg Samknows, FCC, >>BT). >>Reason: Inter-organisation interactions (for example to share results) >>is better handled by business-level negotiation than a control protocol. >> >>I think we also need an assumption that nothing will preclude having >>collectors, for example, be under control of third-parties. I think it >>is worth explicitly stating that, unless there is disagreement on this >>point? >> >>Mat >> > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From jamesmilleresquire@gmail.com Fri Jan 25 10:29:17 2013 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 B673721F844F for ; Fri, 25 Jan 2013 10:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHYp-mKEj0Lt for ; Fri, 25 Jan 2013 10:29:16 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id EDA0F21F8445 for ; Fri, 25 Jan 2013 10:29:15 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id p1so508581vcq.30 for ; Fri, 25 Jan 2013 10:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=eD+WNKnIihvFNf1tmVy6lnspBLPL99JXxqR0WT5H25M=; b=QgLiKlMshl8F81c7dqR4iUIzgyzwxNU5ouXGK06nlKCkOje4SNrLDiXe5mjhdrdXad pIQygaUotrOIPK8AxVGixf7LtJJyL2Obt+iX8BESkL9dG83jyZ/NNa+2IznAqc5KYZdm 5zyMr9Dn8Ohmasbc2QC7G+x0ezXXaMDpMpGmTx1QDJQVn0ElmcNFX6JbMUgjIN3QbAA6 jOuL0U/NZGy0tldnpSjr8funo271vV4Qjd2QJx9+2Vnu154NPgxj7C4BA6+6vKpPHpJg eGWf9NwznqvUrEYXnESXhO2tqb1/S3urfPkS9gMlLq1rpXKGhU1saePLFFw8HXQWUeid Zm/A== X-Received: by 10.52.176.6 with SMTP id ce6mr6181699vdc.57.1359138555097; Fri, 25 Jan 2013 10:29:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.13.70 with HTTP; Fri, 25 Jan 2013 10:28:45 -0800 (PST) In-Reply-To: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <49B53DD1-B801-4412-B503-0825F646816F@isoc.org> From: James Miller Date: Fri, 25 Jan 2013 13:28:45 -0500 Message-ID: To: "MORTON JR., ALFRED (AL)" Content-Type: multipart/alternative; boundary=bcaec51a80cac6f24704d4211ab5 Cc: "ford@isoc.org" , "lmap@ietf.org" , "mlinsner@cisco.com" , "aservin@lacnic.net" , "trevor.burbridge@bt.com" , "philip.eardley@bt.com" , "trammell@tik.ee.ethz.ch" Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jan 2013 18:29:17 -0000 --bcaec51a80cac6f24704d4211ab5 Content-Type: text/plain; charset=ISO-8859-1 I'm not sure I fully understand the difference of the three options, but b) looks good from my perspective. I think Al's point from a few days ago is important to remember. A key point from my perspective is that the value of the collected results may be measured in the public policy context based on the quality of the sample plan, ability of the managers to monitor anomalies in the environments and interpret the results appropriately, and the post-collection statistics work on the results. The protocols should be able to accept other layers of management for selection of MA's and execution of pre-defined test schedules, and the ability to transfer results in a way that supports post-processing. Also wanted to tag again that the b) should be able to absorb security features imposed to support differing privacy policies for collected results being securely transferred to select entities for post-collection data processing. The opinions expressed are those of the author and do not necessarily represent the views of the Federal Communications Commission or the United States Government; The Maureen and Mike Mansfield Foundation; or any Japanese Ministry or the Government of Japan. >For me, the simplest LMAP framework is the one which ensures > >the same measurements are performed according to the same sampling plan > >(schedule) and reported the same way by each organization in their > network. > >Thus, there is freedom to choose the best implementation within a > >network. On Thu, Jan 24, 2013 at 7:08 PM, MORTON JR., ALFRED (AL) wrote: > I agree with option b) below, given those three as choices. > > I wasn't thinking of cross MA or full-study statistics as part of LMAP, > or any standards-setting effort for that matter. Analysis is partly art. > > While the key IPPM metrics mandate the collection and storage of > singletons, > their value is sometimes very limited (the loss ratio is zero, no need to > see > the arrival status of each packet) and has storage implications in large > scale. > It has made sense in some circumstances to store singletons (e.g., > diagnostics), > but not forever. > > Al > > > -----Original Message----- > > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > > trevor.burbridge@bt.com > > Sent: Thursday, January 24, 2013 8:27 AM > > To: MORTON JR., ALFRED (AL); aservin@lacnic.net; lmap@ietf.org > > Cc: philip.eardley@bt.com; mlinsner@cisco.com; ford@isoc.org; > > trammell@tik.ee.ethz.ch > > Subject: Re: [lmap] Proposed LMAP Charter > > > > I was thinking really of statistics produced across a set of MAs - this > > could not be done on the MA and is beyond the scope of the LMAP > > measurement control and collection. > > > > Statistics for a single MA, I guess could be just another test that the > > probe could operate. One more question for this group would then be if > > this statistic just looks the same as a singleton measurement to the LMAP > > framework, or whether LMAP contains support for constructing statistics > in > > different ways from singleton metrics. Obviously the former simplifies > our > > work considerably but means different statistics have to be coded as a > > single test and may not be able to operate in conjunction with other > > statistics based upon the same singleton test. The other problem is that > > streams or statistics will overlap - contention of tests needs to be done > > on the singleton level. > > > > Options: > > a) only allow singleton measures - streams and statistics are constructed > > after collection. Obviously not good if the singleton test is a ping > every > > second. > > b) allow streams and statistics to be coded as tests but only allow > > scheduling/contention to be managed at the test level within LMAP. If > > streams/statistics overlap they may affect each other. Contention > > management for sub-test elements (e.g. singleton ping tests within an > > average latency stream) would be coded into the test. > > c) allow streams and statistics to be constructed on the MA but manage > > contention at the singleton level. In effect same as (a) but with > > processing capabilities on the MA. Could get very complicated. > > > > I guess I would advocate (b). > > > > Trevor. > > > > >-----Original Message----- > > >From: MORTON JR., ALFRED (AL) [mailto:acmorton@att.com] > > >Sent: 24 January 2013 12:54 > > >To: Burbridge,T,Trevor,TUB8 R; aservin@lacnic.net; lmap@ietf.org > > >Cc: Eardley,PL,Philip,TUB8 R; mlinsner@cisco.com; ford@isoc.org; > > >trammell@tik.ee.ethz.ch > > >Subject: RE: [lmap] Proposed LMAP Charter > > > > > >Hi Trevor, > > > > > >You are right that post-singleton measurement processing is part of > > >IPPM's work (singletons, samples, statistics). But LMAP could easily > > >use what has been specified in IPPM RFCs to specify some form of > > >results format. So I tend to agree with Arturo. > > > > > >For me, the simplest LMAP framework is the one which ensures > > >the same measurements are performed according to the same sampling plan > > >(schedule) and reported the same way by each organization in their > > network. > > >Thus, there is freedom to choose the best implementation within a > > >network. > > > > > >regards, > > >Al > > > > > > > > >> -----Original Message----- > > >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf > > >Of > > >> trevor.burbridge@bt.com > > >> Sent: Thursday, January 24, 2013 6:46 AM > > >> To: aservin@lacnic.net; lmap@ietf.org > > >> Cc: philip.eardley@bt.com; mlinsner@cisco.com; ford@isoc.org; > > >> trammell@tik.ee.ethz.ch > > >> Subject: Re: [lmap] Proposed LMAP Charter > > >> > > >> > > >> I would argue that the scope of LMAP is to define the overall > > measurement > > >> framework. If this framework is used to run the same (IPPM defined) > > tests > > >> then it will yield comparable results. > > >> > > >> How to process these results into equivalent statistics is post- > > >> measurement and beyond the scope of LMAP (and would probably fall in > > >the > > >> remit of IPPM in any case). Similar argument for data sharing - data > > can > > >> be anonymised/aggregated (if necessary) and shared after collection. > > >> > > >> Trevor. > > >> > > >> >-----Original Message----- > > >> >From: Arturo Servin [mailto:aservin@lacnic.net] > > >> >Sent: 24 January 2013 10:51 > > >> >To: lmap@ietf.org > > >> >Cc: Matthew Ford; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 > R; > > >> >mlinsner@cisco.com; Brian Trammell > > >> >Subject: Re: [lmap] Proposed LMAP Charter > > >> > > > >> >Hi al, > > >> > > > >> > I was going to ask something similar. > > >> > > > >> > For example, we have a project where we have done some > > >> >measurements but those are confined to a specific region of the > world. > > It > > >> >would be interesting to share that data among other organizations > > doing > > >> the > > >> >same but today we can't because there is not a standard (that I asume > > we > > >> >are intent to produce) and because privacy implications (that I am > not > > >> sure > > >> >that we are addressing in the chapter). > > >> > > > >> > So, is a WG goal to address the problem of sharing and anomyzing > > >> >data (or address any privacy concern)? > > >> > > > >> >Regards, > > >> >as > > >> > > > >> >On 23 Jan 2013, at 10:15, Brian Trammell wrote: > > >> > > > >> >> hi Mat, Phil, all, > > >> >> > > >> >> I agree as well, though other comments on finer points may follow. > > One > > >> >inline below. > > >> >> > > >> >> On 23 Jan 2013, at 13:07 , Matthew Ford wrote: > > >> >> > > >> >>> Phil, > > >> >>> > > >> >>> Nice post, which I think I completely agree with. > > >> >>> > > >> >>> On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: > > >> >>> > > >> >>>> * We assume that Measurement Agent, tests Controller and > > >> results > > >> >Collector are all under control of same organisation (eg Samknows, > > FCC, > > >> BT). > > >> >Reason: Inter-organisation interactions (for example to share > results) > > is > > >> >better handled by business-level negotiation than a control protocol. > > >> >>> > > >> >>> I think we also need an assumption that nothing will preclude > > having > > >> >collectors, for example, be under control of third-parties. I think > it > > is > > >> worth > > >> >explicitly stating that, unless there is disagreement on this point? > > >> >> > > >> >> +1 on this point. I'd suggest that we leave the component > > >> >ownership/control issues completely aside; i.e., we don't necessarily > > >> want to > > >> >preclude organization(s) from agreeing to use a measurement > > >> infrastructure > > >> >in place (which uses this control protocol) for sharing of > > intermediate > > >> or final > > >> >measurement results (in support of an existing business-level > > agreement). > > >> >> > > >> >> What's _really_ important about this assumption is that it makes > the > > >> >problems of inter-domain measurement control and exchange explicitly > > >out > > >> >of scope for the charter, and simplifies issues of trust among the > > >> >components. I think it should probably be explicitly phrased as an > > issue > > >> of > > >> >scope rather than an assumption about deployment. > > >> >> > > >> >> Cheers, > > >> >> > > >> >> Brian > > >> >> > > >> >> > > >> >> _______________________________________________ > > >> >> 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 > > _______________________________________________ > > 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 > --bcaec51a80cac6f24704d4211ab5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm not sure I fully understand the difference of the three options, bu= t b) looks good from my perspective. =A0

I think Al'= s point from a few days ago is important to remember. =A0A key point from m= y perspective is that the value of the collected results may be measured in= the public policy context based on the quality of the sample plan, ability= of the managers to monitor=A0anomalies=A0in the environments and interpret= the results appropriately, and the post-collection statistics work on the = results. =A0The protocols should be able to accept other layers of manageme= nt for selection of MA's and execution of pre-defined test schedules, a= nd the ability to transfer results in a way that supports post-processing.<= div>
Also wanted to tag again that the b) should be able to absor= b security features imposed to support differing privacy policies for colle= cted results being securely=A0transferred=A0to select entities for post-col= lection data processing.

The opinions exp= ressed are those of the author and do not necessarily represent the views o= f the Federal Communications Commission or the=A0United States Government; = The Maureen and Mike Mansfield Foundation; or any Japanese Ministry or the = Government of Japan.=A0

>For me, the simplest LMAP framework is = the one which ensures
> >the same measurements are performed accor= ding to the same sampling plan
> >(schedule) and reported the same= way by each organization in their
> network.
> >Thus, there is freedom to choose the best impleme= ntation within a
> >network.

On = Thu, Jan 24, 2013 at 7:08 PM, MORTON JR., ALFRED (AL) &l= t;acmorton@att.com> wrote:
I agree with option b) below, given those th= ree as choices.

I wasn't thinking of cross MA or full-study statistics as part of LMAP,=
or any standards-setting effort for that matter. Analysis is partly art.
While the key IPPM metrics mandate the collection and storage of singletons= ,
their value is sometimes very limited (the loss ratio is zero, no need to s= ee
the arrival status of each packet) and has storage implications in large sc= ale.
It has made sense in some circumstances to store singletons (e.g., diagnost= ics),
but not forever.

Al

> -----Original Message-----
> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of
> trevor.burbridge@bt.com=
> Sent: Thursday, January = 24, 2013 8:27 AM
> To: MORTON JR., ALFRED (AL); ase= rvin@lacnic.net; lmap@ietf.org
> Cc: philip.eardley@bt.com= ; mlinsner@cisco.com; ford@isoc.org;
> trammell@tik.ee.ethz.ch=
> Subject: Re: [lmap] Proposed LMAP Charter
>
> I was thinking really of statistics produced across a set of MAs - thi= s
> could not be done on the MA and is beyond the scope of the LMAP
> measurement control and collection.
>
> Statistics for a single MA, I guess could be just another test that th= e
> probe could operate. One more question for this group would then be if=
> this statistic just looks the same as a singleton measurement to the L= MAP
> framework, or whether LMAP contains support for constructing statistic= s in
> different ways from singleton metrics. Obviously the former simplifies= our
> work considerably but means different statistics have to be coded as a=
> single test and may not be able to operate in conjunction with other > statistics based upon the same singleton test. The other problem is th= at
> streams or statistics will overlap - contention of tests needs to be d= one
> on the singleton level.
>
> Options:
> a) only allow singleton measures - streams and statistics are construc= ted
> after collection. Obviously not good if the singleton test is a ping e= very
> second.
> b) allow streams and statistics to be coded as tests but only allow > scheduling/contention to be managed at the test level within LMAP. If<= br> > streams/statistics overlap they may affect each other. Contention
> management for sub-test elements (e.g. singleton ping tests within an<= br> > average latency stream) would be coded into the test.
> c) allow streams and statistics to be constructed on the MA but manage=
> contention at the singleton level. In effect same as (a) but with
> processing capabilities on the MA. Could get very complicated.
>
> I guess I would advocate (b).
>
> Trevor.
>
> >-----Original Message-----
> >From: MORTON JR., ALFRED (AL) [mailto:acmorton@att.com]
> >Sent: 24 January 2013 12:54
> >To: Burbridge,T,Trevor,TUB8 R; aservin@lacnic.net; lmap@ietf.org
> >Cc: Eardley,PL,Philip,TUB8 R; mlinsner@cisco.com; ford@isoc.org;
> >trammell@tik.ee.ethz.ch=
> >Subject: RE: [lmap] Proposed LMAP Charter
> >
> >Hi Trevor,
> >
> >You are right that post-singleton measurement processing is part o= f
> >IPPM's work (singletons, samples, statistics). But LMAP could = easily
> >use what has been specified in IPPM RFCs to specify some form of > >results format. So I tend to agree with Arturo.
> >
> >For me, the simplest LMAP framework is the one which ensures
> >the same measurements are performed according to the same sampling= plan
> >(schedule) and reported the same way by each organization in their=
> network.
> >Thus, there is freedom to choose the best implementation within a<= br> > >network.
> >
> >regards,
> >Al
> >
> >
> >> -----Original Message-----
> >> From: lmap-bounces@i= etf.org [mailto:lmap-bounces@i= etf.org] On Behalf
> >Of
> >> trevor.burbridge@b= t.com
> >> Sent: Thursday, January 24, 2013 6:46 AM
> >> To: aservin@lacnic.net<= /a>; lmap@ietf.org
> >> Cc: philip.eardley@b= t.com; mlinsner@cisco.com; ford@isoc.org;
> >> trammell@tik.ee.et= hz.ch
> >> Subject: Re: [lmap] Proposed LMAP Charter
> >>
> >>
> >> I would argue that the scope of LMAP is to define the overall=
> measurement
> >> framework. If this framework is used to run the same (IPPM de= fined)
> tests
> >> then it will yield comparable results.
> >>
> >> How to process these results into equivalent statistics is po= st-
> >> measurement and beyond the scope of LMAP (and would probably = fall in
> >the
> >> remit of IPPM in any case). Similar argument for data sharing= - data
> can
> >> be anonymised/aggregated (if necessary) and shared after coll= ection.
> >>
> >> Trevor.
> >>
> >> >-----Original Message-----
> >> >From: Arturo Servin [mailto:aservin@lacnic.net]
> >> >Sent: 24 January 2013 10:51
> >> >To: lmap@ietf.org > >> >Cc: Matthew Ford; Eardley,PL,Philip,TUB8 R; Burbridge,T,T= revor,TUB8 R;
> >> >mlinsner@cisco.com<= /a>; Brian Trammell
> >> >Subject: Re: [lmap] Proposed LMAP Charter
> >> >
> >> >Hi al,
> >> >
> >> > =A0I was going to ask something similar.
> >> >
> >> > =A0For example, we have a project where we have done som= e
> >> >measurements but those are confined to a specific region = of the world.
> It
> >> >would be interesting to share that data among other organ= izations
> doing
> >> the
> >> >same but today we can't because there is not a standa= rd (that I asume
> we
> >> >are intent to produce) and because privacy implications (= that I am not
> >> sure
> >> >that we are addressing in the chapter).
> >> >
> >> > =A0So, is a WG goal to address the problem of sharing an= d anomyzing
> >> >data (or address any privacy concern)?
> >> >
> >> >Regards,
> >> >as
> >> >
> >> >On 23 Jan 2013, at 10:15, Brian Trammell wrote:
> >> >
> >> >> hi Mat, Phil, all,
> >> >>
> >> >> I agree as well, though other comments on finer poin= ts may follow.
> One
> >> >inline below.
> >> >>
> >> >> On 23 Jan 2013, at 13:07 , Matthew Ford wrote:
> >> >>
> >> >>> Phil,
> >> >>>
> >> >>> Nice post, which I think I completely agree with= .
> >> >>>
> >> >>> On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote:
> >> >>>
> >> >>>> * =A0 =A0 =A0 =A0 We assume that Measurement= Agent, tests Controller and
> >> results
> >> >Collector are all under control of same organisation (eg = Samknows,
> FCC,
> >> BT).
> >> >Reason: Inter-organisation interactions (for example to s= hare results)
> is
> >> >better handled by business-level negotiation than a contr= ol protocol.
> >> >>>
> >> >>> I think we also need an assumption that nothing = will preclude
> having
> >> >collectors, for example, be under control of third-partie= s. I think it
> is
> >> worth
> >> >explicitly stating that, unless there is disagreement on = this point?
> >> >>
> >> >> +1 on this point. I'd suggest that we leave the = component
> >> >ownership/control issues completely aside; i.e., we don&#= 39;t necessarily
> >> want to
> >> >preclude organization(s) from agreeing to use a measureme= nt
> >> infrastructure
> >> >in place (which uses this control protocol) for sharing o= f
> intermediate
> >> or final
> >> >measurement results (in support of an existing business-l= evel
> agreement).
> >> >>
> >> >> What's _really_ important about this assumption = is that it makes the
> >> >problems of inter-domain measurement control and exchange= explicitly
> >out
> >> >of scope for the charter, and simplifies issues of trust = among the
> >> >components. I think it should probably be explicitly phra= sed as an
> issue
> >> of
> >> >scope rather than an assumption about deployment.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Brian
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> 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
> _______________________________________________
> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap
_______________________________________________
lmap mailing list
lmap@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lmap

--bcaec51a80cac6f24704d4211ab5-- From jamesmilleresquire@gmail.com Fri Jan 25 10:40:30 2013 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 B7C5A21F8528 for ; Fri, 25 Jan 2013 10:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeGYKbOaUeoP for ; Fri, 25 Jan 2013 10:40:29 -0800 (PST) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7B17021F8BAB for ; Fri, 25 Jan 2013 10:40:29 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id c13so347771vea.33 for ; Fri, 25 Jan 2013 10:40:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=zpCDjqX2oxX/7siEaQs3ZWjbLsTETvEJkMM4+NgpdHw=; b=sacwztImn3vuXgWjFnstA2TY5Fp0dELQ1jp3T6nvjD5uNgty3rM4YKhXvOiMYy+DLp jK7gCBsW6ZVwkjQjiY2rV8Iw8FeHqZBVUDh8+wgzGxkYuJ/Qp3dJ4YT8X30n6S/F/2ey golv1wCB7TIeKXrhiDKtAQjyeGR03viQe7RCHfyR5B+VuKy0wi8CtIg3YfwrV4wPIiMd aqhIY1HNJPGR+JQl3teH1QAiQINYFLV4w+cVSq8t0Tbz8j1xhF463uIYL1nKCY2/TKTO nVusk4T8TXaLr6IXM52ImkPfgA2Ah5GEAZw8MMRdMeiuvqtu/c6qTQFiIsc0fMmXtPmz V7kQ== X-Received: by 10.220.239.143 with SMTP id kw15mr6905341vcb.62.1359139228903; Fri, 25 Jan 2013 10:40:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.13.70 with HTTP; Fri, 25 Jan 2013 10:39:58 -0800 (PST) In-Reply-To: References: From: James Miller Date: Fri, 25 Jan 2013 13:39:58 -0500 Message-ID: To: Marc Linsner Content-Type: multipart/alternative; boundary=14dae9ccd4eef0698304d421423d Cc: "trevor.burbridge@bt.com" , "philip.eardley@bt.com" , "Bugenhagen, Michael K" , "ford@isoc.org" , "lmap@ietf.org" Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jan 2013 18:40:30 -0000 --14dae9ccd4eef0698304d421423d Content-Type: text/plain; charset=ISO-8859-1 I think the third-party point was introduced from Matt Ford and +1'd but I am having trouble seeing where there was an edit to your original charter text. Where would this go? Below is placeholder sentence.. To conduct service measurements, user networks gather data, either on their own initiative or instructed by a measurement controller, and then upload the measurement results to a designated measurement server. [ These functions in some cases may be executed by different entities that may or may not share clearly defined organizational or legal relationships. ] I think the sentence should cover the many of the architectural use cases we have in the field today such as: 1) Contractual relationships between arms-length parties, e.g. Carriers and Solutions providers, Regulators and Solutions providers, 2) Relationships based on shared interests lacking legal privitiy and legal obligations, e.g. Regulators and loose collaborative groups, Carriers and research entities without contractual agreements. One thing I'd considered early was including these and other features at the data schema level to help people evaluate the results of LMAP projects. For example, results of a roughly coded research project without administrative support and scrutiny might be used in different ways than a contracted solution with clearly defined and legally enforceable service obligations. Maybe not crucial for the charter text but I do think the data schemas should include description of the kinds of administrative and operational features implementable with the protocols. On Fri, Jan 25, 2013 at 12:55 PM, Marc Linsner wrote: > Mike, > > How about 'different administrative domain'? > > -Marc- > > -----Original Message----- > From: "Bugenhagen, Michael K" > Date: Friday, January 25, 2013 12:10 PM > To: "'trevor.burbridge@bt.com'" , "ford@isoc.org" > , "philip.eardley@bt.com" > Cc: Marc Linsner , "lmap@ietf.org" > Subject: RE: [lmap] Proposed LMAP Charter > > >Trevor, > > > > Just observing something here -- Given there is no standard > >definition of what "3rd party" is, and the definition varies depending on > >if we discuss business roles, vs. vendor roles, vs. operator the > >undefined use of "3rd party" without some contextual qualifier is pretty > >dangerous in terms of causing confusion. > > > > So if the words "3rd party" is used anywhere it really has to be > >accompanied by some type of category or qualifier. > > > >Regards, > >Mike > > > > > > > > > >-----Original Message----- > >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > >trevor.burbridge@bt.com > >Sent: Wednesday, January 23, 2013 10:49 AM > >To: ford@isoc.org; philip.eardley@bt.com > >Cc: mlinsner@cisco.com; lmap@ietf.org > >Subject: Re: [lmap] Proposed LMAP Charter > > > >Our position is that nothing should preclude 3rd parties operating > >separate components of the measurement architecture. Of course data > >protection would have to be considered/observed but we will not need > >anything explicit in the technical work of LMAP to do so. > > > >What we want to avoid explicitly is two or more controllers connecting to > >a single Measurement Agent and having to manage such conflicts. There > >might, however, be two or more controllers for disjoint subsets of > >measurement agents (e.g. one for mobile devices and one for home > >gateways). There of course will be multiple test servers (to test > >multiple network paths) and could also be multiple collectors (where a MA > >replicates or partitions its results). > > > > > >Trevor. > > > >Trevor Burbridge > >Network Infrastructure & Innovation | BT Innovate & Design > >Tel: 01473 645115 > >Fax: 01473 640929 > > > >This email contains BT information, which may be privileged or > >confidential. It's meant only for the individual(s) or entity named > >above. If you're not the intended recipient, note that disclosing, > >copying, distributing or using this information is prohibited. If you've > >received this email in error, please let me know immediately on the email > >address above. Thank you. > >We monitor our email system, and may record your emails. > >British Telecommunications plc > >Registered office: 81 Newgate Street London EC1A 7AJ Registered in > >England no: 1800000 > > > > > >>-----Original Message----- > >>From: Matthew Ford [mailto:ford@isoc.org] > >>Sent: 23 January 2013 12:08 > >>To: Eardley,PL,Philip,TUB8 R > >>Cc: mlinsner@cisco.com; lmap@ietf.org; Burbridge,T,Trevor,TUB8 R > >>Subject: Re: [lmap] Proposed LMAP Charter > >> > >>Phil, > >> > >>Nice post, which I think I completely agree with. > >> > >>On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: > >> > >>> * We assume that Measurement Agent, tests Controller and > >>>results > >>Collector are all under control of same organisation (eg Samknows, FCC, > >>BT). > >>Reason: Inter-organisation interactions (for example to share results) > >>is better handled by business-level negotiation than a control protocol. > >> > >>I think we also need an assumption that nothing will preclude having > >>collectors, for example, be under control of third-parties. I think it > >>is worth explicitly stating that, unless there is disagreement on this > >>point? > >> > >>Mat > >> > > > >_______________________________________________ > >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 > --14dae9ccd4eef0698304d421423d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think the third-party point was introduced from Matt Ford and +1'd bu= t I am having trouble seeing where there was an edit to your original chart= er text.

Where would this go? =A0Below is placeholder se= ntence..

To conduct service meas= urements, user networks gather data, either on their own initiative or inst= ructed by a measurement controller, and then upload the measurement results= to a designated measurement server.=A0
[ These functions = in some cases may be executed by different entities that may or may not sha= re clearly defined organizational or legal relationships. ]=A0
=

<= font color=3D"#222222" face=3D"Calibri" size=3D"3">I think the sentence sho= uld cover the many of the=A0architectural=A0use cases we have in the field = today such as:

<= div>1)=A0Contractual=A0= relationships between arms-length parties, e.g. Carriers and Solutions prov= iders, Regulators and=A0Solutions providers,=A0
2) Relationships b= ased on shared interests lacking legal privitiy and legal obligations, e.g.= Regulators and loose collaborative groups, Carriers and research=A0entitie= s=A0without=A0contractual agreements.

<= div>One thing I'd c= onsidered early was including these and other features at the data schema l= evel to help people evaluate the results of LMAP projects. =A0For example, = results of a roughly coded research project without administrative support = and scrutiny might be used in different ways than a contracted solution wit= h clearly defined and legally enforceable service obligations.

<= div>Maybe not crucial f= or the charter text but I do think the data schemas should include descript= ion of the kinds of administrative and operational features implementable w= ith the protocols.

On Fri, Jan 25, 2013 at 12:55 PM, Mar= c Linsner <mlinsner@cisco.com> wrote:
Mike,

How about 'different administrative domain'?

-Marc-

-----Original Message-----
From: "Bugenhagen, Michael K" <Michael.K.Bugenhagen@centurylink.com>
Date: Friday, January 25, 2013 12:10 PM
To: "'trevor.burbridge@= bt.com'" <trevor= .burbridge@bt.com>, "ford@isoc= .org"
<ford@isoc.org>, "philip.eardley@bt.com" <philip.eardley@bt.com>
Cc: Marc Linsner <mlinsner@cisco.c= om>, "lmap@ietf.org" = <lmap@ietf.org>
Subject: RE: [lmap] Proposed LMAP Charter

>Trevor,
>
> =A0 =A0Just observing something here -- Given there is no standard
>definition of what "3rd party" is, and the definition varies = depending on
>if we discuss business roles, vs. vendor roles, vs. operator the
>undefined use of "3rd party" without some contextual qualifie= r is pretty
>dangerous in terms of causing confusion.
>
> =A0So if the words "3rd party" is used anywhere it really ha= s to be
>accompanied by some type of category or qualifier.
>
>Regards,
>Mike
>
>
>
>
>-----Original Message-----
>From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of
>trevor.burbridge@bt.com<= br> >Sent: Wednesday, January 23, 2013 10:49 AM
>To: ford@isoc.org; philip.eardley@bt.com
>Cc: mlinsner@cisco.com; lmap@ietf.org
>Subject: Re: [lmap] Proposed LMAP Charter
>
>Our position is that nothing should preclude 3rd parties operating
>separate components of the measurement architecture. Of course data
>protection would have to be considered/observed but we will not need >anything explicit in the technical work of LMAP to do so.
>
>What we want to avoid explicitly is two or more controllers connecting = to
>a single Measurement Agent and having to manage such conflicts. There >might, however, be two or more controllers for disjoint subsets of
>measurement agents (e.g. one for mobile devices and one for home
>gateways). There of course will be multiple test servers (to test
>multiple network paths) and could also be multiple collectors (where a = MA
>replicates or partitions its results).
>
>
>Trevor.
>
>Trevor Burbridge
>Network Infrastructure & Innovation | BT Innovate & Design
>Tel: 01473 645115
>Fax: 01473 640929
>
>This email contains BT information, which may be privileged or
>confidential. It's meant only for the individual(s) or entity named=
>above. If you're not the intended recipient, note that disclosing,<= br> >copying, distributing or using this information is prohibited. If you&#= 39;ve
>received this email in error, please let me know immediately on the ema= il
>address above. Thank you.
>We monitor our email system, and may record your emails.
>British Telecommunications plc
>Registered office: 81 Newgate Street London EC1A 7AJ Registered in
>England no: 1800000
>
>
>>-----Original Message-----
>>From: Matthew Ford [mailto:ford@is= oc.org]
>>Sent: 23 January 2013 12:08
>>To: Eardley,PL,Philip,TUB8 R
>>Cc: mlinsner@cisco.com; <= a href=3D"mailto:lmap@ietf.org">lmap@ietf.org; Burbridge,T,Trevor,TUB8 = R
>>Subject: Re: [lmap] Proposed LMAP Charter
>>
>>Phil,
>>
>>Nice post, which I think I completely agree with.
>>
>>On 23 Jan 2013, at 09:54, = philip.eardley@bt.com wrote:
>>
>>> * =A0 =A0 =A0 =A0 We assume that Measurement Agent, tests Cont= roller and
>>>results
>>Collector are all under control of same organisation (eg Samknows, = FCC,
>>BT).
>>Reason: Inter-organisation interactions (for example to share resul= ts)
>>is better handled by business-level negotiation than a control prot= ocol.
>>
>>I think we also need an assumption that nothing will preclude havin= g
>>collectors, for example, be under control of third-parties. I think= it
>>is worth explicitly stating that, unless there is disagreement on t= his
>>point?
>>
>>Mat
>>
>
>_______________________________________________
>lmap mailing list
>lmap@ietf.org
>https://www.ietf.org/mailman/listinfo/lmap


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

--14dae9ccd4eef0698304d421423d-- From Michael.K.Bugenhagen@centurylink.com Fri Jan 25 11:02:44 2013 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 E8B4521F8A80 for ; Fri, 25 Jan 2013 11:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFC5F4HDRWLY for ; Fri, 25 Jan 2013 11:02:44 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 2B87521F888B for ; Fri, 25 Jan 2013 11:02:44 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r0PJ2e7k021895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jan 2013 12:02:41 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 57E711E0062; Fri, 25 Jan 2013 12:02:35 -0700 (MST) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 3F44B1E0053; Fri, 25 Jan 2013 12:02:35 -0700 (MST) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r0PJ2YDx013723; Fri, 25 Jan 2013 12:02:34 -0700 (MST) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.qintra.com [151.117.206.28]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r0PJ2YOJ013696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 12:02:34 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.02.0318.001; Fri, 25 Jan 2013 13:02:33 -0600 From: "Bugenhagen, Michael K" To: "'Marc Linsner'" , "'trevor.burbridge@bt.com'" , "ford@isoc.org" , "philip.eardley@bt.com" Thread-Topic: [lmap] Proposed LMAP Charter Thread-Index: AQHN9b4JTFTNyLguM0iYwcPeFnywgZhXGGqAgAAlJoCAAE6aAIACxU0ggAByCQD//6BK0A== Date: Fri, 25 Jan 2013 19:02:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "lmap@ietf.org" Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jan 2013 19:02:45 -0000 Marc, A suggestion on an language for "3rd party" is to use the Agency distinctio= n-=20 Personally I think a more appropriate term that reflects an privacy rela= tionship between the customers (and their private identification / informat= ion) is the word "non-affiliated agency" vs. "3rd party". The reasoning here - When an operator "outsources" testing to a "3rd party" they are an agent= of the operator and have the same responsibilities of the operator. When a non-operator affiliated agent is doing testing - they have the respo= nsibility of maintaining the relationship with the customer in terms of pri= vacy. So non-operator affiliated agency would be an more accurate term in = my opinion, and it reflects more closely the role of customer privacy than = simply stating 3rd party....=20 =20 Another dimension that some standards bodies will observer ---=20 a) Independent certified lab vs. affiliated - Is the agency affiliated with another organization or fully an Certified= Independent lab - this is an international standard ... =09 b) Test results qualifiers That dimensionally relate to the Tester agent be= ing able to validate information with a Operator - Non-Validated tests =3D the tester doesn't know / can't guarantee (So you h= ave validated and non-validated results) 1) Provisioned speed tier 2) What the "sold speed" of the operator is - and these can and do change 3) That the customer actually put the device on the line they said they ar= e on (not a relatives line) 4) That they are on the correct operator Regards=20 -Mike =20 =20 -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: Friday, January 25, 2013 11:56 AM To: Bugenhagen, Michael K; 'trevor.burbridge@bt.com'; ford@isoc.org; philip= .eardley@bt.com Cc: lmap@ietf.org Subject: Re: [lmap] Proposed LMAP Charter Mike, How about 'different administrative domain'? -Marc- -----Original Message----- From: "Bugenhagen, Michael K" Date: Friday, January 25, 2013 12:10 PM To: "'trevor.burbridge@bt.com'" , "ford@isoc.org" , "philip.eardley@bt.com" Cc: Marc Linsner , "lmap@ietf.org" Subject: RE: [lmap] Proposed LMAP Charter >Trevor, > > Just observing something here -- Given there is no standard=20 >definition of what "3rd party" is, and the definition varies depending=20 >on if we discuss business roles, vs. vendor roles, vs. operator the=20 >undefined use of "3rd party" without some contextual qualifier is=20 >pretty dangerous in terms of causing confusion. > > So if the words "3rd party" is used anywhere it really has to be=20 >accompanied by some type of category or qualifier. > >Regards, >Mike > > > > >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of=20 >trevor.burbridge@bt.com >Sent: Wednesday, January 23, 2013 10:49 AM >To: ford@isoc.org; philip.eardley@bt.com >Cc: mlinsner@cisco.com; lmap@ietf.org >Subject: Re: [lmap] Proposed LMAP Charter > >Our position is that nothing should preclude 3rd parties operating=20 >separate components of the measurement architecture. Of course data=20 >protection would have to be considered/observed but we will not need=20 >anything explicit in the technical work of LMAP to do so. > >What we want to avoid explicitly is two or more controllers connecting=20 >to a single Measurement Agent and having to manage such conflicts.=20 >There might, however, be two or more controllers for disjoint subsets=20 >of measurement agents (e.g. one for mobile devices and one for home=20 >gateways). There of course will be multiple test servers (to test=20 >multiple network paths) and could also be multiple collectors (where a=20 >MA replicates or partitions its results). > > >Trevor. > >Trevor Burbridge >Network Infrastructure & Innovation | BT Innovate & Design >Tel: 01473 645115 >Fax: 01473 640929 > >This email contains BT information, which may be privileged or=20 >confidential. It's meant only for the individual(s) or entity named=20 >above. If you're not the intended recipient, note that disclosing,=20 >copying, distributing or using this information is prohibited. If=20 >you've received this email in error, please let me know immediately on=20 >the email address above. Thank you. >We monitor our email system, and may record your emails. >British Telecommunications plc >Registered office: 81 Newgate Street London EC1A 7AJ Registered in=20 >England no: 1800000 > > >>-----Original Message----- >>From: Matthew Ford [mailto:ford@isoc.org] >>Sent: 23 January 2013 12:08 >>To: Eardley,PL,Philip,TUB8 R >>Cc: mlinsner@cisco.com; lmap@ietf.org; Burbridge,T,Trevor,TUB8 R >>Subject: Re: [lmap] Proposed LMAP Charter >> >>Phil, >> >>Nice post, which I think I completely agree with. >> >>On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: >> >>> * We assume that Measurement Agent, tests Controller and >>>results >>Collector are all under control of same organisation (eg Samknows,=20 >>FCC, BT). >>Reason: Inter-organisation interactions (for example to share results)=20 >>is better handled by business-level negotiation than a control protocol. >> >>I think we also need an assumption that nothing will preclude having=20 >>collectors, for example, be under control of third-parties. I think it=20 >>is worth explicitly stating that, unless there is disagreement on this=20 >>point? >> >>Mat >> > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From jamesmilleresquire@gmail.com Fri Jan 25 11:15:45 2013 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 0F3ED21F87D5 for ; Fri, 25 Jan 2013 11:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjX8Dqck79Sh for ; Fri, 25 Jan 2013 11:15:44 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4119021F8788 for ; Fri, 25 Jan 2013 11:15:44 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so528162vbb.17 for ; Fri, 25 Jan 2013 11:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=09Car5K0Sb0K+x1QQFt0qx4224rkymW/J2HjxKCc0v8=; b=vVLeliaLjekDO/BFY2+F7LAKB6/O04Rx8dyyd0JQW/EZXpqNJvOs5hejnsz+SCoHgB bu7BJqZ3ZYEe1y/JvL/Gep27vPiDwNUXWv8Nv7DOwI6R6N4eL6AxxhTg88nS78c6iYiR 44wcD39hfz4EPBHg8xm+ghVAfT5FR5jXpyoQtYyj6mRFSZuF9UXrU6yddYq75CU09uiz 0JfZKZJBrDEnEpTgt77usST6cvEgdbH0lqz6rS7SBPa1gay3RneVnxs5x8CaEU+iAK2Q sg+hiNZG2PgTmraXvvzTfS+gZVgLnP4kBBaGaOb4wLPB70tdXsG+6cHY3Wgw1Y/8jSH2 Uaww== X-Received: by 10.52.70.205 with SMTP id o13mr6287955vdu.75.1359141343632; Fri, 25 Jan 2013 11:15:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.13.70 with HTTP; Fri, 25 Jan 2013 11:15:12 -0800 (PST) In-Reply-To: References: From: James Miller Date: Fri, 25 Jan 2013 14:15:12 -0500 Message-ID: To: "Bugenhagen, Michael K" Content-Type: multipart/alternative; boundary=20cf307f32b0fc9e1f04d421c03c Cc: Marc Linsner , "philip.eardley@bt.com" , "trevor.burbridge@bt.com" , "ford@isoc.org" , "lmap@ietf.org" Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jan 2013 19:15:45 -0000 --20cf307f32b0fc9e1f04d421c03c Content-Type: text/plain; charset=ISO-8859-1 Mike, I'd comment that "agent" would be preferable to "agency" in your text. On Fri, Jan 25, 2013 at 2:02 PM, Bugenhagen, Michael K < Michael.K.Bugenhagen@centurylink.com> wrote: > uage for "3rd party" is to use the Agent Also use of agency alone to describe the scope of possible relationships is incomplete. Pasting back a post w/ edits that I think I missed you, my text is broader. The relationships must include both agency or contractual (legal agency) and non-contractual (extra-legal) relationships. For example, M-Lab does not appear to be a 501(c)(3) non-profit but is a "collaborative effort" with a steering committee that may not satisfy an agency or contractural definition in how they support current LMAP efforts. I think replacing "agency" below would be fine but note that agency is a different area of law from contract and so a more appropriate term that captures the points is probably "legal". They taught me in law school that agency law has been largely subsumed by contract law, but the main point is there are legally enforceable obligations in some cases.. and in others not. [ These functions in some cases may be executed by different entities that may or may not share clearly defined organizational or legal relationships. ] I think the sentence should cover the many of the architectural use cases we have in the field today such as: 1) Contractual or other legal relationships between arms-length parties, e.g. Carriers and Solutions providers, Regulators and Solutions providers, 2) Relationships based on shared interests lacking legal privity and legal obligations, e.g. Regulators and loose collaborative groups, Carriers and research entities without contractual agreements. --20cf307f32b0fc9e1f04d421c03c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mike,

I'd comment that "agent" would be pr= eferable=A0to "agency" in your text.

On Fri, Jan 25, 2013 at 2:02 PM, Bugenhagen, Michae= l K <Michael.K.Bugenhagen@centurylink.com> wrote:
uage for "3rd party" is to use the= Agent

Also use of agency alone to describe the scope= of possible relationships is incomplete. =A0Pasting back a post w/ edits t= hat I think I missed you, my text is broader. =A0The relationships must inc= lude both agency or contractual=A0(legal agency) and non-contractual (extra= -legal) relationships. =A0For example, M-Lab does not appear to be a 501(c)= (3) non-profit but is a "collaborative effort" with a steering co= mmittee that may not satisfy an agency or contractural definition in how th= ey support current LMAP efforts.

I think replacing "agency" below would be fin= e but note that agency is a different area of law from contract and so a mo= re appropriate term that captures the points is probably "legal".= =A0They taught me in law school that agency law has been largely subsumed = by contract law, but the main point is there are legally enforceable obliga= tions in some cases.. and in others not.

<= font color=3D"#222222" face=3D"Calibri" size=3D"3">[ These functions in som= e cases may be executed by different entities that may or may not share cle= arly defined organizational or legal relationships. ]=A0

I think the sentence sh= ould cover the many of the=A0architectural=A0use cases we have in the field= today such as:

1)=A0Contractual or other legal relationships betw= een arms-length parties, e.g. Carriers and Solutions providers, Regulators = and=A0Solutions= providers,=A0
2) Relationships based on shared interests l= acking legal privity and legal obligations, e.g. Regulators and loose colla= borative groups, Carriers and research=A0entities=A0without=A0contractual a= greements.

--20cf307f32b0fc9e1f04d421c03c-- From julm+lmap@autogeree.net Sat Jan 26 01:26:24 2013 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 3C36C21F8825 for ; Sat, 26 Jan 2013 01:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.593 X-Spam-Level: X-Spam-Status: No, score=-1.593 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_00=-2.599, FAKE_REPLY_C=2.012] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skx4++DcXGil for ; Sat, 26 Jan 2013 01:26:23 -0800 (PST) Received: from chomsky.autogeree.net (chomsky.autogeree.net [91.216.110.36]) by ietfa.amsl.com (Postfix) with ESMTP id B1C7021F8820 for ; Sat, 26 Jan 2013 01:26:23 -0800 (PST) Received: by localhost.local (localhost.local, from userid 1000) id DD89120CEE; Sat, 26 Jan 2013 10:26:13 +0100 (CET) Date: Sat, 26 Jan 2013 10:26:13 +0100 From: Julien Moutinho To: lmap@ietf.org Message-ID: <20130126092613.GB14283@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: <20130125110955.GA17360@localhost> X-Operating-System: 3.2.0-4-amd64 x86_64 GNU/Linux OpenPGP: preference=signencrypt; id=F2E027182397AC0775714F2AD15AF7F467E8299B; url="http://autogeree.net/~julm/pub.gpg" User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jan 2013 09:26:24 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > b. Test schedule: when the test should be done and how often > > repeated ('once an hour at xx.03'). A test may also be a one-off, done > > immediately on demand. > I think that a variety of common temporal series should be considered > (like, raw-list, periodic, exponential-based, gamma-based, uniform-random= -based, ..); > for instance some tomography probes require these kind of distributions. > I think metrics should be easily extensible according to a common schema > (for instance specifying a hierarchical namespace for probes > gathering them by ///..). >=20 > [phil] thanks - interested to hear people's views about this >=20 > [julm] and this hierarchy could be replicated > in the test configuration and report sample models. [julm] so I see that you all have started to work on this registry and its organisation : http://www.ietf.org/mail-archive/web/ippm/current/msg03034.html it's very welcome :) --K8nIJk4ghYZn606h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQJNBAEBCgA3BQJRA6ExMBSAAAAAABUAEnBrYS1hZGRyZXNzQGdudXBnLm9yZ2p1 bG1AYXV0b2dlcmVlLm5ldAAKCRBeJxnPcP6KnlePD/9rAtvfQCegZ6SJQw1sRdxo NFULljePcg0O4NTyC/8cX6jxhJJeN7sSAdRW6af6r+2+vFeUVuucqTobe6V/Y0Mv Kl/9++VJ+GjA8eWttRC64beD78CD+/K+KMtcoIgg0BGIb/H+YKZ27lERPJJwGqQH m6YyXhdsWQG6Dz3wC5UYNQPdafgJTlhGEP73vM/TR7VTnkpiR7dB1Le8oHCTWUz6 v2wvaazWXuxizs5ONJjo1QiMKcxyxDq3m+2GRKyrF6+ebfKPBRhnIrSlGkJlH+ay qJ8s4YB2QmQanXt/MTdksnRnJcg2J01lWgYKSgPK1edEHeatdPJAx/DNE0F3BRUD jCKsnWpfjK62XIWi0o1np6edJliTqTwdrKaO3Se4oprbeArQbGAqic6672ahi1Gt 73qd9pYqUTH1A2pDT9h1IV5qxv++KwnaRXEQnTcQYHiRk7HRRYRGGO1sV9l7SDvq AVglvD2+vUil44hqR6ntJ08x5LztUmxm4v7A6NccfZvt9HOH9jsz+WZRRYrDLH/5 uhAgDT8VdE+gt5nCninTFbc2ibXqqPW+PAj/6MQL2Q078zl4218yk/f5DTNwR8X/ Kf7v40nZBhF9rQuPTN2GEtBCHAdw8B8tid/jihIE3LOPk3SnhXOhXYxCgM7iW+7v kVU0Qa1Q08dy9KE54RFpmA== =+tff -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- From acmorton@att.com Sat Jan 26 07:48:51 2013 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 A986521F84ED for ; Sat, 26 Jan 2013 07:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNL4GU1o8tUB for ; Sat, 26 Jan 2013 07:48:51 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1183E21F84C5 for ; Sat, 26 Jan 2013 07:48:51 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id EB3EC12058E; Sat, 26 Jan 2013 10:50:08 -0500 (EST) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-blue.research.att.com (Postfix) with ESMTP id 1B50AF00E9; Sat, 26 Jan 2013 10:48:50 -0500 (EST) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Sat, 26 Jan 2013 10:48:50 -0500 From: "MORTON JR., ALFRED (AL)" To: Julien Moutinho , "lmap@ietf.org" Date: Sat, 26 Jan 2013 10:48:47 -0500 Thread-Topic: [lmap] Proposed LMAP Charter Thread-Index: Ac37pz/bgbqpjnnUT22x7Nrlfypa4gANEFdw Message-ID: References: <20130125110955.GA17360@localhost> <20130126092613.GB14283@localhost> In-Reply-To: <20130126092613.GB14283@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jan 2013 15:48:51 -0000 SGkgSnVsaWVuLCBwbGVhc2Ugc2VlIHJlcGx5IGJlbG93Og0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGxtYXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmxtYXAtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IEp1bGllbiBNb3V0aW5obw0KPiBTZW50OiBT YXR1cmRheSwgSmFudWFyeSAyNiwgMjAxMyA0OjI2IEFNDQo+IFRvOiBsbWFwQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbbG1hcF0gUHJvcG9zZWQgTE1BUCBDaGFydGVyDQo+IA0KPiA+ID4gICBi LiAgICAgIFRlc3Qgc2NoZWR1bGU6IHdoZW4gdGhlIHRlc3Qgc2hvdWxkIGJlIGRvbmUgYW5kIGhv dyBvZnRlbg0KPiA+ID4gICByZXBlYXRlZCAoJ29uY2UgYW4gaG91ciBhdCB4eC4wMycpLiBBIHRl c3QgbWF5IGFsc28gYmUgYSBvbmUtb2ZmLA0KPiBkb25lDQo+ID4gPiAgIGltbWVkaWF0ZWx5IG9u IGRlbWFuZC4NCj4gPiBJIHRoaW5rIHRoYXQgYSB2YXJpZXR5IG9mIGNvbW1vbiB0ZW1wb3JhbCBz ZXJpZXMgc2hvdWxkIGJlIGNvbnNpZGVyZWQNCj4gPiAobGlrZSwgcmF3LWxpc3QsIHBlcmlvZGlj LCBleHBvbmVudGlhbC1iYXNlZCwgZ2FtbWEtYmFzZWQsIHVuaWZvcm0tDQo+IHJhbmRvbS1iYXNl ZCwgLi4pOw0KPiA+IGZvciBpbnN0YW5jZSBzb21lIHRvbW9ncmFwaHkgcHJvYmVzIHJlcXVpcmUg dGhlc2Uga2luZCBvZiBkaXN0cmlidXRpb25zLg0KPiANCj4gPiBJIHRoaW5rIG1ldHJpY3Mgc2hv dWxkIGJlIGVhc2lseSBleHRlbnNpYmxlIGFjY29yZGluZyB0byBhIGNvbW1vbiBzY2hlbWENCj4g PiAoZm9yIGluc3RhbmNlIHNwZWNpZnlpbmcgYSBoaWVyYXJjaGljYWwgbmFtZXNwYWNlIGZvciBw cm9iZXMNCj4gPiBnYXRoZXJpbmcgdGhlbSBieSA8a2luZCBvZiBtZXRyaWM+LzxraW5kIG9mIHBy b3RvY29sPi88a2luZCBvZg0KPiB1bmRlcmx5aW5nIHNvZnR3YXJlPi8uLikuDQo+ID4NCj4gPiBb cGhpbF0gdGhhbmtzIC0gaW50ZXJlc3RlZCB0byBoZWFyIHBlb3BsZSdzIHZpZXdzIGFib3V0IHRo aXMNCj4gPg0KPiA+IFtqdWxtXSBhbmQgdGhpcyBoaWVyYXJjaHkgY291bGQgYmUgcmVwbGljYXRl ZA0KPiA+IGluIHRoZSB0ZXN0IGNvbmZpZ3VyYXRpb24gYW5kIHJlcG9ydCBzYW1wbGUgbW9kZWxz Lg0KPiANCj4gW2p1bG1dIHNvIEkgc2VlIHRoYXQgeW91IGFsbCBoYXZlIHN0YXJ0ZWQgdG8gd29y aw0KPiBvbiB0aGlzIHJlZ2lzdHJ5IGFuZCBpdHMgb3JnYW5pc2F0aW9uIDoNCj4gCWh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pcHBtL2N1cnJlbnQvbXNnMDMwMzQuaHRtbA0K PiANCj4gaXQncyB2ZXJ5IHdlbGNvbWUgOikNCg0KR2xhZCB0byBoZWFyIGl0LCBhbmQgaWYgeW91 IHRha2UgYSBsb29rIGF0IHRoZSBkcmFmdHMsIHBsZWFzZSBwcm92aWRlIGNvbW1lbnRzDQpvbiB0 aGUgaXBwbS1saXN0LiBXZSBuZWVkIG1vcmUgb3BpbmlvbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGJl dHdlZW4NCnRoZSB0d28gYWx0ZXJuYXRpdmVzLCBoaWVyYXJjaGljYWwgYW5kIGluZGVwZW5kZW50 IHJlZ2lzdHJpZXMsIA0KYXMgTWFyY2VsbyBkZXNjcmliZWQgdGhlbS4gVGhpcyBpcyBhIGNyaXRp Y2FsIGJ1dCBub3QgdmVyeSBleGNpdGluZw0KdG9waWMsIHNvIGV2ZW4gYW4gZXhwcmVzc2lvbiBv ZiBzdXBwb3J0IGZvciB0aGUgd29yayB3b3VsZCBiZSB1c2VmdWwhDQoNCnRoYW5rcyBhbmQgcmVn YXJkcywNCkFsIA0K From Michael.K.Bugenhagen@centurylink.com Sun Jan 27 11:29:30 2013 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 52D4B21F84E9 for ; Sun, 27 Jan 2013 11:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.899, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mhYf2M0XoDH for ; Sun, 27 Jan 2013 11:29:29 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 946C521F871F for ; Sun, 27 Jan 2013 11:29:29 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r0RJTOJ9001917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jan 2013 13:29:25 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id BB93A1E0069; Sun, 27 Jan 2013 13:29:15 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 6FBBC1E004D; Sun, 27 Jan 2013 13:29:15 -0600 (CST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r0RJS3Rc003510; Sun, 27 Jan 2013 13:28:03 -0600 (CST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r0RJS363003507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Jan 2013 13:28:03 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([2002:9775:ce1b::9775:ce1b]) with mapi id 14.02.0318.001; Sun, 27 Jan 2013 13:28:03 -0600 From: "Bugenhagen, Michael K" To: James Miller Thread-Topic: [lmap] Proposed LMAP Charter Thread-Index: AQHN9b4JTFTNyLguM0iYwcPeFnywgZhXGGqAgAAlJoCAAE6aAIACxU0ggAByCQD//6BK0IAAdecAgALDqjg= Date: Sun, 27 Jan 2013 19:28:01 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_AC7890BAE1A24748AA98F1F0963EA09Acenturylinkcom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Marc Linsner , "trevor.burbridge@bt.com" , "philip.eardley@bt.com" , "ford@isoc.org" , "lmap@ietf.org" Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jan 2013 19:29:30 -0000 --_000_AC7890BAE1A24748AA98F1F0963EA09Acenturylinkcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, Unfortunately the word "agent" is already in use in different forums as = the "probe" or test client, agency however hadn't been used that I know of= . I was thinking "agent" as we'll but them realized the two definitions f= or the same word should not be used for different meanings in the same docu= ment. Those were my thoughts anyway. Regards Mike Sent from my iPhone On Jan 25, 2013, at 1:15 PM, "James Miller" > wrote: Mike, I'd comment that "agent" would be preferable to "agency" in your text. On Fri, Jan 25, 2013 at 2:02 PM, Bugenhagen, Michael K > wrote: uage for "3rd party" is to use the Agent Also use of agency alone to describe the scope of possible relationships is= incomplete. Pasting back a post w/ edits that I think I missed you, my te= xt is broader. The relationships must include both agency or contractual (= legal agency) and non-contractual (extra-legal) relationships. For example= , M-Lab does not appear to be a 501(c)(3) non-profit but is a "collaborativ= e effort" with a steering committee that may not satisfy an agency or contr= actural definition in how they support current LMAP efforts. I think replacing "agency" below would be fine but note that agency is a di= fferent area of law from contract and so a more appropriate term that captu= res the points is probably "legal". They taught me in law school that agen= cy law has been largely subsumed by contract law, but the main point is the= re are legally enforceable obligations in some cases.. and in others not. [ These functions in some cases may be executed by different entities that = may or may not share clearly defined organizational or legal relationships.= ] I think the sentence should cover the many of the architectural use cases w= e have in the field today such as: 1) Contractual or other legal relationships between arms-length parties, e.= g. Carriers and Solutions providers, Regulators and Solutions providers, 2) Relationships based on shared interests lacking legal privity and legal = obligations, e.g. Regulators and loose collaborative groups, Carriers and r= esearch entities without contractual agreements. _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap --_000_AC7890BAE1A24748AA98F1F0963EA09Acenturylinkcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
James,

   Unfortunately the word "agent" is already in us= e in different forums as the "probe" or test client,  agency= however hadn't been used that I know of.   I was thinking "agent= " as we'll but them realized the two definitions for the same word sho= uld not be used for different meanings in the same document.  Those were my t= houghts anyway.

Regards
Mike


Sent from my iPhone

On Jan 25, 2013, at 1:15 PM, "James Miller" <jamesmilleresquire@gmail.com> wrote:<= br>
Mike,

I'd comment that "agent" would be preferable to "a= gency" in your text.

On Fri, Jan 25, 2013 at 2:02 PM, Bugenhagen, Mic= hael K <Michael.K.Bugenhagen@centurylink.com> wrote:
uage for "3rd party" is to use the Agent

Also use of agency alone to describe the scope of possible relationships is= incomplete.  Pasting back a post w/ edits that I think I missed you, = my text is broader.  The relationships must include both agency or con= tractual (legal agency) and non-contractual (extra-legal) relationships.  For example, M-Lab does not appear to b= e a 501(c)(3) non-profit but is a "collaborative effort" with a s= teering committee that may not satisfy an agency or contractural definition= in how they support current LMAP efforts.

I think replacing "agency" below would be fine but note that= agency is a different area of law from contract and so a more appropriate = term that captures the points is probably "legal".  They tau= ght me in law school that agency law has been largely subsumed by contract law, but the main point is there are legally enforceable oblig= ations in some cases.. and in others not.

[ These functions in so= me cases may be executed by different entities that may or may not share cl= early defined organizational or legal relationships. ] 

I think the sentence sh= ould cover the many of the architectural use cases we have in the= field today such as:

1) Contractual or = other legal relationships between arms-length parties, e.g. Carriers and So= lutions providers, Regulators and Solutions providers, 
2) Relationships based = on shared interests lacking legal privity and legal obligations, e.g. Regul= ators and loose collaborative groups, Carriers and research entities&n= bsp;without contractual agreements.

_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ie= tf.org/mailman/listinfo/lmap
--_000_AC7890BAE1A24748AA98F1F0963EA09Acenturylinkcom_-- From trammell@tik.ee.ethz.ch Mon Jan 28 03:13:45 2013 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 3163921F843B for ; Mon, 28 Jan 2013 03:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ4sPLMZpE-I for ; Mon, 28 Jan 2013 03:13:44 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9008621F8971 for ; Mon, 28 Jan 2013 03:13:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 66459D9323; Mon, 28 Jan 2013 12:13:42 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xgbeNJDbDWl5; Mon, 28 Jan 2013 12:13:41 +0100 (MET) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 417B9D930B; Mon, 28 Jan 2013 12:13:41 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: Date: Mon, 28 Jan 2013 12:13:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2494CA1D-ADF5-4568-A5DF-01FAAA54CAC2@tik.ee.ethz.ch> References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <49B53DD1-B801-4412-B503-0825F646816F@isoc.org> To: lmap@ietf.org X-Mailer: Apple Mail (2.1499) Cc: "MORTON JR., ALFRED \(AL\)" , ford@isoc.org, aservin@lacnic.net, mlinsner@cisco.com, trevor.burbridge@bt.com, "philip.eardley@bt.com EARDLEY" Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jan 2013 11:13:45 -0000 Greetings, all, I'm behind the curve a bit on this thread, so I thought I'd sum up from = my point of view... Please note I'm not wearing my IPPM co-chair hat = here; comments on what belongs where below are personal opinion only.=20 Executive summary: I broadly agree with Phil and Trevor's proposal. There seem to be a few areas of work to build something like the union = of the visions of LMAP I've seen on this list; in determining how to = charter a WG, the question for each of these is does it already have a = home in another WG (here I'm thinking IPPM), does it fit into a charter = simple enough to make LMAP likely to complete its initial milestones in = a timely fashion, or should it be declared out of scope?=20 (1) A common definition of singleton metrics to be produced by a single = measurement agents. In my opinion, this is key to ensuring = interoperability, and is pretty clearly in the scope of IPPM; new = development required by LMAP should probably be done by IPPM. As you = pointed out, there are two variants of a new registry of these under = consideration in IPPM, as well: draft-bagnulo-ippm-new-registry and = draft-bagnulo-ippm-new-registry-independent. I repeat your call for = those interested in LMAP to have a look at these and provide comments to = the IPPM list. (2) A common definition of sampling/statistics over singleton metrics to = be produced by a single measurement agent. This is also pretty clearly = in the scope of IPPM. (3) A common definition of statistics over singleton metrics to be = produced by multiple measurement agents. Some specific cases, especially = as regards the derivation of whole-path metrics from subpath metrics or = whole-interval metrics from sub-interval metrics, have already been = covered by IPPM (RFC 5835 defines a Framework for Metric Composition, = and RFC 6049, Spatial Composition of Metrics). As for other statistics, = IPPM could provide a home for this work, depending on how close to the = assumptions of RFC 5835 those statistics hold. (4) A set of reference sample plans referencing these metrics and = statistics in (1)-(3); this provides the basis for comparison among = multiple tests run by different test providers.=20 (5) A definition of a control protocol for setting up measurements at = measurement agents, with standard representations for the sampling plans = in (4), based on metrics and statistics in (1)-(3). Key for = interoperability in a multi-vendor environment (as you're likely to have = with measurement agents on user end systems or CPE), and more so in a = multi-measurement-operator environment (even if this group decides it's = out of scope). Such work also implies the definition of a reference = architecture so everyone can be sure what the terminology referenced by = the protocol means. This seems to be the focus of much of the energy in = LMAP to date, and probably makes sense to put this central in the = charter of a new working group should one be formed. This is broadly in = line with the charter proposal under discussion, so, so far, so good. (6) A definition (or selection) of a data export protocol for moving = measurements from agents to collectors. If the data export protocol is = part of the measurement specification the controller gives to the agent, = this is perhaps less crucial (though then you do need to make sure your = agent and collector protocols match at deployment time). Otherwise, this = must be defined along with (5), or you have no common representation for = interoperability between collectors and agents. (7) Cross-domain reporting of results in (6) above. This adds = anonymization/pseudonymization for privacy preservation and = authorization to receive reports to the issues that must be addressed.=20= (8) Cross-domain control of measurement agents to support (7) above. As = above, plus you have a whole host of new AAA problems to solve, too.=20 (9) Best practices in the management of relationships among the entities = managing each piece of an LMAP infrastructure. This touches on the legal = conversation on this subject, which is somewhat outside of my area of = expertise, but an applicability statement is probably a good starting = point here. (10) Definition of best practices for data processing and archiving = (e.g., outliner removal from statistics, specification of metadata, = etc). There is some work in this area under consideration for IPPM = (draft-mathis-ippm-data-curation), but no plan as yet to address this = point comprehensively.=20 I'm not sure where the line between IPPM and not-IPPM should be for = composition of metrics across multiple measurement agents as in (3). I'm = inclined to say that operation on IPPM metrics that doesn't fit into = anything that we need that's not covered in existing IPPM frameworks = should probably be done as new work in IPPM. Similarly, (10) gets into = the management of the data at the semantic level; as such, it's kind of = tied to the definitions of the metrics (1) - (3). I'm inclined to say = this is IPPM work, but maybe that's only because there's already a draft = on the subject up for consideration in IPPM. Recommendations for sample plans (4) should follow from the LMAP use = cases, and as such are the first thing "up the stack" that, in my mind, = is not clearly IPPM work. Definitions are only necessary to provided a = basis for comparison of tests from multiple providers, but would be = useful as recommendations in any case. I think focusing on (4), then, plus the control protocol (5), and = determining to what extent we can reuse/extend existing protocols for = data export (6) is probably a good starting point for an LMAP charter. = Cross-domain issues (7) and (8) are of interest to some potential users = of the control protocol (myself included), but are probably best = considered after the core is done. Work on (9) might be necessary in any = case other than single-owner, single-operator infrastructures (i.e., = even if you don't need interdomain control you may need to think about = who's responsible for what in order to ensure the protocol supports the = ownership structures you require), so that should probably appear in an = applicability statement, as well.=20 Best regards, Brian On 24 Jan 2013, at 13:53 , MORTON JR., ALFRED (AL) wrote: > Hi Trevor, >=20 > You are right that post-singleton measurement processing is part of > IPPM's work (singletons, samples, statistics). But LMAP could easily=20= > use what has been specified in IPPM RFCs to specify some form of > results format. So I tend to agree with Arturo. >=20 > For me, the simplest LMAP framework is the one which ensures > the same measurements are performed according to the same sampling = plan > (schedule) and reported the same way by each organization in their = network. > Thus, there is freedom to choose the best implementation within a > network. >=20 > regards, > Al >=20 >=20 >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf = Of >> trevor.burbridge@bt.com >> Sent: Thursday, January 24, 2013 6:46 AM >> To: aservin@lacnic.net; lmap@ietf.org >> Cc: philip.eardley@bt.com; mlinsner@cisco.com; ford@isoc.org; >> trammell@tik.ee.ethz.ch >> Subject: Re: [lmap] Proposed LMAP Charter >>=20 >>=20 >> I would argue that the scope of LMAP is to define the overall = measurement >> framework. If this framework is used to run the same (IPPM defined) = tests >> then it will yield comparable results. >>=20 >> How to process these results into equivalent statistics is post- >> measurement and beyond the scope of LMAP (and would probably fall in = the >> remit of IPPM in any case). Similar argument for data sharing - data = can >> be anonymised/aggregated (if necessary) and shared after collection. >>=20 >> Trevor. >>=20 >>> -----Original Message----- >>> From: Arturo Servin [mailto:aservin@lacnic.net] >>> Sent: 24 January 2013 10:51 >>> To: lmap@ietf.org >>> Cc: Matthew Ford; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 = R; >>> mlinsner@cisco.com; Brian Trammell >>> Subject: Re: [lmap] Proposed LMAP Charter >>>=20 >>> Hi al, >>>=20 >>> I was going to ask something similar. >>>=20 >>> For example, we have a project where we have done some >>> measurements but those are confined to a specific region of the = world. It >>> would be interesting to share that data among other organizations = doing >> the >>> same but today we can't because there is not a standard (that I = asume we >>> are intent to produce) and because privacy implications (that I am = not >> sure >>> that we are addressing in the chapter). >>>=20 >>> So, is a WG goal to address the problem of sharing and anomyzing >>> data (or address any privacy concern)? >>>=20 >>> Regards, >>> as >>>=20 >>> On 23 Jan 2013, at 10:15, Brian Trammell wrote: >>>=20 >>>> hi Mat, Phil, all, >>>>=20 >>>> I agree as well, though other comments on finer points may follow. = One >>> inline below. >>>>=20 >>>> On 23 Jan 2013, at 13:07 , Matthew Ford wrote: >>>>=20 >>>>> Phil, >>>>>=20 >>>>> Nice post, which I think I completely agree with. >>>>>=20 >>>>> On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: >>>>>=20 >>>>>> * We assume that Measurement Agent, tests Controller and >> results >>> Collector are all under control of same organisation (eg Samknows, = FCC, >> BT). >>> Reason: Inter-organisation interactions (for example to share = results) is >>> better handled by business-level negotiation than a control = protocol. >>>>>=20 >>>>> I think we also need an assumption that nothing will preclude = having >>> collectors, for example, be under control of third-parties. I think = it is >> worth >>> explicitly stating that, unless there is disagreement on this point? >>>>=20 >>>> +1 on this point. I'd suggest that we leave the component >>> ownership/control issues completely aside; i.e., we don't = necessarily >> want to >>> preclude organization(s) from agreeing to use a measurement >> infrastructure >>> in place (which uses this control protocol) for sharing of = intermediate >> or final >>> measurement results (in support of an existing business-level = agreement). >>>>=20 >>>> What's _really_ important about this assumption is that it makes = the >>> problems of inter-domain measurement control and exchange explicitly = out >>> of scope for the charter, and simplifies issues of trust among the >>> components. I think it should probably be explicitly phrased as an = issue >> of >>> scope rather than an assumption about deployment. >>>>=20 >>>> Cheers, >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> lmap mailing list >>>> lmap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lmap >>=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 sharam.hakimi@exfo.com Mon Jan 28 06:21:32 2013 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 802F421F884B for ; Mon, 28 Jan 2013 06:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PekwrFnwjfZs for ; Mon, 28 Jan 2013 06:21:31 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id E932821F88FD for ; Mon, 28 Jan 2013 06:21:27 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 09:21:25 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 09:21:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jan 2013 09:22:00 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA022C2EDB@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] Proposed LMAP Charter Thread-Index: AQHN9b4JTFTNyLguM0iYwcPeFnywgZhXGGqAgAAlJoCAAE6aAIACxU0ggAByCQD//6BK0IAEcT/Q References: From: "Sharam Hakimi" To: "Bugenhagen, Michael K" , "Marc Linsner" , , , X-OriginalArrivalTime: 28 Jan 2013 14:21:26.0114 (UTC) FILETIME=[C1A65C20:01CDFD62] Cc: lmap@ietf.org Subject: Re: [lmap] Proposed LMAP Charter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jan 2013 14:21:32 -0000 Mike, I agree with the notion that a third party has different meaning in different situations as you have described. I think that the language should be that the architecture shall not prevent multiple test devices that perform the same test on the defined network, subnet, etc.=20 I do not believe that going down the path of having multiple controlling agents controlling the same device is not a good idea in the same operator's network and certainly not acceptable especially when that device is owned and maintained by someone else. The current proposed architecture does not prevent multiple test agents/devices, each controlled by its deployer, to perform the same test (that provides information from the users/customers point of view) at the same test points and I think that provides enough flexibility to arrive at the required/needed information. Sharam -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, Michael K Sent: Friday, January 25, 2013 2:03 PM To: 'Marc Linsner'; 'trevor.burbridge@bt.com'; ford@isoc.org; philip.eardley@bt.com Cc: lmap@ietf.org Subject: Re: [lmap] Proposed LMAP Charter Marc, A suggestion on an language for "3rd party" is to use the Agency distinction-=20 Personally I think a more appropriate term that reflects an privacy relationship between the customers (and their private identification / information) is the word "non-affiliated agency" vs. "3rd party". The reasoning here - When an operator "outsources" testing to a "3rd party" they are an agent of the operator and have the same responsibilities of the operator. When a non-operator affiliated agent is doing testing - they have the responsibility of maintaining the relationship with the customer in terms of privacy. So non-operator affiliated agency would be an more accurate term in my opinion, and it reflects more closely the role of customer privacy than simply stating 3rd party....=20 =20 Another dimension that some standards bodies will observer ---=20 a) Independent certified lab vs. affiliated - Is the agency affiliated with another organization or fully an Certified Independent lab - this is an international standard ... =09 b) Test results qualifiers That dimensionally relate to the Tester agent being able to validate information with a Operator - Non-Validated tests =3D the tester doesn't know / can't guarantee (So = you have validated and non-validated results) 1) Provisioned speed tier 2) What the "sold speed" of the operator is - and these can and do change 3) That the customer actually put the device on the line they said they are on (not a relatives line) 4) That they are on the correct operator Regards=20 -Mike =20 =20 -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: Friday, January 25, 2013 11:56 AM To: Bugenhagen, Michael K; 'trevor.burbridge@bt.com'; ford@isoc.org; philip.eardley@bt.com Cc: lmap@ietf.org Subject: Re: [lmap] Proposed LMAP Charter Mike, How about 'different administrative domain'? -Marc- -----Original Message----- From: "Bugenhagen, Michael K" Date: Friday, January 25, 2013 12:10 PM To: "'trevor.burbridge@bt.com'" , "ford@isoc.org" , "philip.eardley@bt.com" Cc: Marc Linsner , "lmap@ietf.org" Subject: RE: [lmap] Proposed LMAP Charter >Trevor, > > Just observing something here -- Given there is no standard=20 >definition of what "3rd party" is, and the definition varies depending=20 >on if we discuss business roles, vs. vendor roles, vs. operator the=20 >undefined use of "3rd party" without some contextual qualifier is=20 >pretty dangerous in terms of causing confusion. > > So if the words "3rd party" is used anywhere it really has to be=20 >accompanied by some type of category or qualifier. > >Regards, >Mike > > > > >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >trevor.burbridge@bt.com >Sent: Wednesday, January 23, 2013 10:49 AM >To: ford@isoc.org; philip.eardley@bt.com >Cc: mlinsner@cisco.com; lmap@ietf.org >Subject: Re: [lmap] Proposed LMAP Charter > >Our position is that nothing should preclude 3rd parties operating=20 >separate components of the measurement architecture. Of course data=20 >protection would have to be considered/observed but we will not need=20 >anything explicit in the technical work of LMAP to do so. > >What we want to avoid explicitly is two or more controllers connecting=20 >to a single Measurement Agent and having to manage such conflicts.=20 >There might, however, be two or more controllers for disjoint subsets=20 >of measurement agents (e.g. one for mobile devices and one for home=20 >gateways). There of course will be multiple test servers (to test=20 >multiple network paths) and could also be multiple collectors (where a=20 >MA replicates or partitions its results). > > >Trevor. > >Trevor Burbridge >Network Infrastructure & Innovation | BT Innovate & Design >Tel: 01473 645115 >Fax: 01473 640929 > >This email contains BT information, which may be privileged or=20 >confidential. It's meant only for the individual(s) or entity named=20 >above. If you're not the intended recipient, note that disclosing,=20 >copying, distributing or using this information is prohibited. If=20 >you've received this email in error, please let me know immediately on=20 >the email address above. Thank you. >We monitor our email system, and may record your emails. >British Telecommunications plc >Registered office: 81 Newgate Street London EC1A 7AJ Registered in=20 >England no: 1800000 > > >>-----Original Message----- >>From: Matthew Ford [mailto:ford@isoc.org] >>Sent: 23 January 2013 12:08 >>To: Eardley,PL,Philip,TUB8 R >>Cc: mlinsner@cisco.com; lmap@ietf.org; Burbridge,T,Trevor,TUB8 R >>Subject: Re: [lmap] Proposed LMAP Charter >> >>Phil, >> >>Nice post, which I think I completely agree with. >> >>On 23 Jan 2013, at 09:54, philip.eardley@bt.com wrote: >> >>> * We assume that Measurement Agent, tests Controller and >>>results >>Collector are all under control of same organisation (eg Samknows,=20 >>FCC, BT). >>Reason: Inter-organisation interactions (for example to share results) >>is better handled by business-level negotiation than a control protocol. >> >>I think we also need an assumption that nothing will preclude having=20 >>collectors, for example, be under control of third-parties. I think it >>is worth explicitly stating that, unless there is disagreement on this >>point? >> >>Mat >> > >_______________________________________________ >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 mirja.kuehlewind@ikr.uni-stuttgart.de Mon Jan 28 09:06:04 2013 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 2187E21F8A6F for ; Mon, 28 Jan 2013 09:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in4K0uxLtndU for ; Mon, 28 Jan 2013 09:06:03 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7643821F8A68 for ; Mon, 28 Jan 2013 09:06:02 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id CBBE7633B1; Mon, 28 Jan 2013 18:06:00 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id BDA7F59A8A; Mon, 28 Jan 2013 18:06:00 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: lmap@ietf.org Date: Mon, 28 Jan 2013 18:05:59 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: philip.eardley@bt.com, trevor.burbridge@bt.com Subject: [lmap] measurement traffic load [was: Re: Proposed LMAP Charter] X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jan 2013 17:06:04 -0000 Hi everybody, thanks Phil for this really good proposal. I agreed that it is import to sc= ope=20 down the initial work to a well defined scenario and focus on basic protoco= l=20 functionality. Regarding the text below and also following the discussion on data processi= ng,=20 I would like to add one comment and maybe can some feedback from people how= =20 already have experience with large scale measurements: =46or me the proposal seem to produce a huge amount of data. We envision a = MA in=20 basically every home network, there are frequent test scheduled by one or=20 more 'parties' and there is all the raw data which needs to be transmitted = to=20 the collector. Thinking about this I afraid that most of our future Interne= t=20 traffic will be the measurement (and collection) traffic itself. Maybe this= =20 issue is out of scope for the actual work group focus, but I guess it's wor= th=20 think about this when defining the architecture/scenarios and protocols. Mirja On Wednesday 23 January 2013 10:54:39 philip.eardley@bt.com wrote: > Thanks Marc. We're very interested in discussing a potential charter. > One thing we think is worth trying to do is to simplify the proposed work > as much as possible, as the potential scope is big. Of course this could = be > done entirely as part of the WG's work, but doing this beforehand would > enable a more rapid start. Below is our attempt to suggest some simplifyi= ng > assumptions. Each of the simplifying assumptions has some penalty, so it > would be great to hear whether people think they're reasonable, or > over-restrict the use case that you have in mind. If it's helpful we could > write up the architectural assumptions in an I-D - co-authors very welcom= e. > So a key question is whether the prospective WG should start with a phase > of reaching consensus on architecture and choosing starting protocols, or > whether we can reach enough consensus before the next IETF to move straig= ht > to standards work. I'm not sure that we can decide this right now, as it > depends on how the discussion goes over the next month or so. There are > some work items below that might apply in the latter case. -- > Measuring broadband service on a large scale is important for network > diagnostics by providers and users, as well for public policy. {Comment: > operators may want measurement to help network planning and network mgt > like fault identification; not sure whether this needs explicitly noting.= }=20 > To conduct service measurements, Measurement Agents (MAs) on user networks > gather data, either on their own initiative or instructed by a Controller, > and then upload the measurement results to a designated Collector. > Currently measurement platforms contain up to a few thousand MAs. However, > the vision is that MAs could potentially be embedded in every home hub, > cable modem, enterprise edge router, set top box, smartphone and so on. > Standards will help this capability be more pervasive, manageable and > directly comparable. RFCs from the IPPM WG define how to measure metrics - > requests to define new tests should be handled by IPPM. These tests > effectively define the communications between a MA and Test Server. > {Comment: there are likely new metrics that need to be defined (eg latency > under load) or tests under new conditions (eg current test for speed may > not scale well to high line speeds).} . In a few cases the IPPM definition > may need to be extended to move results data from the Test Server to the = MA > for later reporting. The LMAP WG makes the following architectural > assumptions - in order to make rapid progress with an acceptable loss of > generality:- > > * We assume that Measurement Agent, tests Controller and results > Collector are all under control of same organisation (eg Samknows, FCC, > BT). Reason: Inter-organisation interactions (for example to share result= s) > is better handled by business-level negotiation than a control protocol. > > * We assume the MA initiates a measurement. Reasons: having the > test schedule on MA avoids it having to check frequently with the > Controller; it is easier if the MA is behind a NAT; and the MA knows > whether the user is active and therefore whether to run test or delay it. > > * We assume measurement results are sent from MA, and not from te= st > server. Reason-1: It is easier to secure the MA to Collector communicatio= n. > One implication is that for an upload test measured by the test server, t= he > result is reported back to the MA which reports it in turn. Reason-2: Test > servers may be controlled by a third party ('load time for IETF home > page'). > > * We assume no negotiation is needed between Controller and MA. T= he > Controller already knows the characteristics of the MA, for instance via > TR069 for Broadband Forum devices. The Controller simply instructs > (securely) the MA "Measure this"; the MA replies "OK /error". > > * Similarly we assume no negotiation is needed between the MA and > Collector. The protocol simply delivers (securely) the measurement results > from the MA to the Collector, and returns an ack or error code. > > * We assume each MA is controlled by only one Controller. Reason: > to avoid different Controllers giving the MA conflicting schedules. Note:= a > measurement platform may have several Controllers, with each Controller > controlling a subset of the MAs, for example one controlling wireline MAs > and one mobile MAs. > > * We assume the raw measurement results are reported; filtering > /averaging of measuremnts by the MA is not in the initial scope, except as > defined by IPPM as part of the metric definition. > > * We assume that uploading a new test capability to the MA is out > of scope. This can be done as a firmware upgrade for home hub, or new app > for PC, etc. > > * We assume as out of scope a network parameter server (which > stores nominal values such as the contractual data rate). The functional > role of the Network Paraemeter Server may be fulfilled by existing OSS > (such as network or home gateway management systems). Interfaces to the N= PS > are pre-measurement (used by the Controller to decide which tests to > schedule) or post-measurement (used to analyse the measurement data). > > * We assume data filtering is out of the initial scope. Filtering > includes: removal of outlier measurements, archiving (curating) data for > scientific research, and so on. There are certainly some aspects where be= st > practice would be useful but data filtering is not a first priority. > > * We assume that data privacy issues are out of scope although > security is considered. The MA, Controller and Collector are all under > control of the same organisation. IPPM considers the implications of any > passive measurement tests that it defines. The LMAP WG standardises the > following items: > > 1. The data model that defines the test schedule, which includes: > > a. The IPPM metric to be tested and values for its parameters. > {Question: is the restriction to IPPM OK? Ie non-IPPM tests are out of > scope} > > b. Test schedule: when the test should be done and how often repeated > ('once an hour at xx.03'). A test may also be a one-off, done immediately > on demand. > > c. Output parameters: some IPPM metrics may define a choice of > outputs > > d. Test Server: which server or servers should be used for the test > > e. Environmental conditions: such as 'no user traffic' which means a > particular instance of the test is delayed or abandoned. > > f. (perhaps) Metadata: such as a mobile's location when the test > should be made, the line's nominal rate etc. There may be privacy > implications for the scenario where the measurement plaform is not > controlled by the operator; the initial scope will exclude this scenario. > > g. (perhaps) Metadat to report: for example, the MA may be able to > measure Layer 1 o 2 charcteristics such as DSL sync speed and interleavin= g; > the actual test is out of scope. As for the previous bullet, there may be > privacy implications for the general scenario, which we exclude from the > initial scope. > > h. (perhaps) Priority: the Controller decides which tests are done > when. However a test might get delayed until it overlaps with another > scheduled test - which should be done (or done first)? Or should it simply > be abandoned? > > 2. The data model that defines how an MA should report test results. > This may be combined with (1) above or specified as a separate reporting > schedule. This includes: > > a. Where to report results to (one or more Collectors) > > b. How often to report results for the different tests > > c. What to do when Collector is not available (fail-over, try again) > > 3. The data model that defines the report, which includes: > > a. The metric that was measured > > b. The time of the test > > c. Whether the test is scheduled, one-off triggered by the > Controller, or user-initiated > > d. The measurement result - usually several results are batched > together; the result of a one-off test may be wanted immediately > > e. (perhaps) Metadata, such as the mobile's location > > f. Comment: it would make sense to use the same language as for 1, > for instance XML, YANG... > > 4. The application level protocol for the (secure) delivery of the > test and reporting schedule (#1, #2) > > a. A simple instruction - response protocol, with error codes defined > > b. LMAP could specify how it operates over one existing protocol (RE= ST > style HTTP(s), Netconf...) > > 5. The application level protocol for the (secure) delivery of the > report (#3) > > a. Same comments as for #4 > > 6. A document explaining the simplifying architectural assumptions in > more detail. This document could also define some terminology and explain > the use cases. Looking forward to the discussion, > Best wishes, > Trevor and Phil > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Marc Linsner Sent: 18 January 2013 20:48 > To: lmap@ietf.org > Subject: [lmap] Proposed LMAP Charter > > Let's discuss possible charter language for the proposed LMAP work. At > this point, IMO, we should propose a charter for the work that could eith= er > be added to an existing WG's charter, or standalone as a WG charter.=20 > That's an AD decision. A follow-on discussion to this would obviously be > the output documents and milestones. > > Here is a strawman to start with - > > " > Measuring broadband service on a large scale is important for network > diagnostics by providers and users, as well for public policy. To conduct > service measurements, user networks gather data, either on their own > initiative or instructed by a measurement controller, and then upload the > measurement results to a designated measurement server. There is a need to > standardize a logical architecture and describe key requirements for > protocols to connect the components. A large-scale measurement system > needs to support residential and small-enterprise networks, using either > wired or wireless networks. The architecture needs to consider the > management of the active and passive measurements. > > The LMAP work will include describing various use cases considered to be > Large Scale Performance Measurement systems, define the requirements of t= he > management of these systems, and finally define the management > communication architecture and protocols. > > This work will also include discussions about the privacy and security > concerns and will address them within its documents. " > > Fire away! > > -Marc Linsner- =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From philip.eardley@bt.com Mon Jan 28 09:16:15 2013 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 6B81921F87FE for ; Mon, 28 Jan 2013 09:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUt2u-ZD-AAq for ; Mon, 28 Jan 2013 09:16:14 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id BD4B821F862E for ; Mon, 28 Jan 2013 09:16:13 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 28 Jan 2013 17:16:11 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.36]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Mon, 28 Jan 2013 17:16:11 +0000 From: To: , Date: Mon, 28 Jan 2013 17:16:10 +0000 Thread-Topic: measurement traffic load [was: Re: Proposed LMAP Charter] Thread-Index: Ac39ecCbkKMDkIGHRgKLi9WxF60I4QAADdZw Message-ID: <9510D26531EF184D9017DF24659BB87F3419D404C3@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: trevor.burbridge@bt.com Subject: Re: [lmap] measurement traffic load [was: Re: Proposed LMAP Charter] X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jan 2013 17:16:15 -0000 This is a good point. Most usually the Controller will select a subset of the Measurement Agents,= and instruct them to collect measurements according to some schedule ('mea= sure download speed once an hour'). The other MAs won't be making measureme= nts - otherwise as you say the internet will be dominated by measurement tr= affic! This is fine where the operator or regulator is interested in averag= es-across-lines (eg to compare one ISP against another) Because (hopefully) all home hubs etc include MA functionality, if a custom= er reports problems, then the Controller can tell the relevant MA to run so= me specific tests. This is the new bit that would be great. Also, think the default case is to report the raw measurement. But eg some = IPPM metrics define a "statistic" as well as a "singleton" measurement resu= lt - so that might be reported instead.=20 phil=20 -----Original Message----- From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de]=20 Sent: 28 January 2013 17:06 To: lmap@ietf.org Cc: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R Subject: measurement traffic load [was: Re: Proposed LMAP Charter] Hi everybody, thanks Phil for this really good proposal. I agreed that it is import to sc= ope down the initial work to a well defined scenario and focus on basic pro= tocol functionality. Regarding the text below and also following the discussion on data processi= ng, I would like to add one comment and maybe can some feedback from people= how already have experience with large scale measurements: For me the proposal seem to produce a huge amount of data. We envision a MA= in basically every home network, there are frequent test scheduled by one = or more 'parties' and there is all the raw data which needs to be transmitt= ed to the collector. Thinking about this I afraid that most of our future I= nternet traffic will be the measurement (and collection) traffic itself. Ma= ybe this issue is out of scope for the actual work group focus, but I guess= it's worth think about this when defining the architecture/scenarios and p= rotocols. Mirja On Wednesday 23 January 2013 10:54:39 philip.eardley@bt.com wrote: > Thanks Marc. We're very interested in discussing a potential charter. > One thing we think is worth trying to do is to simplify the proposed work > as much as possible, as the potential scope is big. Of course this could = be > done entirely as part of the WG's work, but doing this beforehand would > enable a more rapid start. Below is our attempt to suggest some simplifyi= ng > assumptions. Each of the simplifying assumptions has some penalty, so it > would be great to hear whether people think they're reasonable, or > over-restrict the use case that you have in mind. If it's helpful we coul= d > write up the architectural assumptions in an I-D - co-authors very welcom= e. > So a key question is whether the prospective WG should start with a phase > of reaching consensus on architecture and choosing starting protocols, or > whether we can reach enough consensus before the next IETF to move straig= ht > to standards work. I'm not sure that we can decide this right now, as it > depends on how the discussion goes over the next month or so. There are > some work items below that might apply in the latter case. -- > Measuring broadband service on a large scale is important for network > diagnostics by providers and users, as well for public policy. {Comment: > operators may want measurement to help network planning and network mgt > like fault identification; not sure whether this needs explicitly noting.= }=20 > To conduct service measurements, Measurement Agents (MAs) on user network= s > gather data, either on their own initiative or instructed by a Controller= , > and then upload the measurement results to a designated Collector. > Currently measurement platforms contain up to a few thousand MAs. However= , > the vision is that MAs could potentially be embedded in every home hub, > cable modem, enterprise edge router, set top box, smartphone and so on. > Standards will help this capability be more pervasive, manageable and > directly comparable. RFCs from the IPPM WG define how to measure metrics = - > requests to define new tests should be handled by IPPM. These tests > effectively define the communications between a MA and Test Server. > {Comment: there are likely new metrics that need to be defined (eg latenc= y > under load) or tests under new conditions (eg current test for speed may > not scale well to high line speeds).} . In a few cases the IPPM definitio= n > may need to be extended to move results data from the Test Server to the = MA > for later reporting. The LMAP WG makes the following architectural > assumptions - in order to make rapid progress with an acceptable loss of > generality:- > > * We assume that Measurement Agent, tests Controller and results > Collector are all under control of same organisation (eg Samknows, FCC, > BT). Reason: Inter-organisation interactions (for example to share result= s) > is better handled by business-level negotiation than a control protocol. > > * We assume the MA initiates a measurement. Reasons: having the > test schedule on MA avoids it having to check frequently with the > Controller; it is easier if the MA is behind a NAT; and the MA knows > whether the user is active and therefore whether to run test or delay it. > > * We assume measurement results are sent from MA, and not from te= st > server. Reason-1: It is easier to secure the MA to Collector communicatio= n. > One implication is that for an upload test measured by the test server, t= he > result is reported back to the MA which reports it in turn. Reason-2: Tes= t > servers may be controlled by a third party ('load time for IETF home > page'). > > * We assume no negotiation is needed between Controller and MA. T= he > Controller already knows the characteristics of the MA, for instance via > TR069 for Broadband Forum devices. The Controller simply instructs > (securely) the MA "Measure this"; the MA replies "OK /error". > > * Similarly we assume no negotiation is needed between the MA and > Collector. The protocol simply delivers (securely) the measurement result= s > from the MA to the Collector, and returns an ack or error code. > > * We assume each MA is controlled by only one Controller. Reason: > to avoid different Controllers giving the MA conflicting schedules. Note:= a > measurement platform may have several Controllers, with each Controller > controlling a subset of the MAs, for example one controlling wireline MAs > and one mobile MAs. > > * We assume the raw measurement results are reported; filtering > /averaging of measuremnts by the MA is not in the initial scope, except a= s > defined by IPPM as part of the metric definition. > > * We assume that uploading a new test capability to the MA is out > of scope. This can be done as a firmware upgrade for home hub, or new app > for PC, etc. > > * We assume as out of scope a network parameter server (which > stores nominal values such as the contractual data rate). The functional > role of the Network Paraemeter Server may be fulfilled by existing OSS > (such as network or home gateway management systems). Interfaces to the N= PS > are pre-measurement (used by the Controller to decide which tests to > schedule) or post-measurement (used to analyse the measurement data). > > * We assume data filtering is out of the initial scope. Filtering > includes: removal of outlier measurements, archiving (curating) data for > scientific research, and so on. There are certainly some aspects where be= st > practice would be useful but data filtering is not a first priority. > > * We assume that data privacy issues are out of scope although > security is considered. The MA, Controller and Collector are all under > control of the same organisation. IPPM considers the implications of any > passive measurement tests that it defines. The LMAP WG standardises the > following items: > > 1. The data model that defines the test schedule, which includes: > > a. The IPPM metric to be tested and values for its parameters. > {Question: is the restriction to IPPM OK? Ie non-IPPM tests are out of > scope} > > b. Test schedule: when the test should be done and how often repeate= d > ('once an hour at xx.03'). A test may also be a one-off, done immediately > on demand. > > c. Output parameters: some IPPM metrics may define a choice of > outputs > > d. Test Server: which server or servers should be used for the test > > e. Environmental conditions: such as 'no user traffic' which means a > particular instance of the test is delayed or abandoned. > > f. (perhaps) Metadata: such as a mobile's location when the test > should be made, the line's nominal rate etc. There may be privacy > implications for the scenario where the measurement plaform is not > controlled by the operator; the initial scope will exclude this scenario. > > g. (perhaps) Metadat to report: for example, the MA may be able to > measure Layer 1 o 2 charcteristics such as DSL sync speed and interleavin= g; > the actual test is out of scope. As for the previous bullet, there may be > privacy implications for the general scenario, which we exclude from the > initial scope. > > h. (perhaps) Priority: the Controller decides which tests are done > when. However a test might get delayed until it overlaps with another > scheduled test - which should be done (or done first)? Or should it simpl= y > be abandoned? > > 2. The data model that defines how an MA should report test results= . > This may be combined with (1) above or specified as a separate reporting > schedule. This includes: > > a. Where to report results to (one or more Collectors) > > b. How often to report results for the different tests > > c. What to do when Collector is not available (fail-over, try again= ) > > 3. The data model that defines the report, which includes: > > a. The metric that was measured > > b. The time of the test > > c. Whether the test is scheduled, one-off triggered by the > Controller, or user-initiated > > d. The measurement result - usually several results are batched > together; the result of a one-off test may be wanted immediately > > e. (perhaps) Metadata, such as the mobile's location > > f. Comment: it would make sense to use the same language as for 1, > for instance XML, YANG... > > 4. The application level protocol for the (secure) delivery of the > test and reporting schedule (#1, #2) > > a. A simple instruction - response protocol, with error codes define= d > > b. LMAP could specify how it operates over one existing protocol (RE= ST > style HTTP(s), Netconf...) > > 5. The application level protocol for the (secure) delivery of the > report (#3) > > a. Same comments as for #4 > > 6. A document explaining the simplifying architectural assumptions i= n > more detail. This document could also define some terminology and explain > the use cases. Looking forward to the discussion, > Best wishes, > Trevor and Phil > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Marc Linsner Sent: 18 January 2013 20:48 > To: lmap@ietf.org > Subject: [lmap] Proposed LMAP Charter > > Let's discuss possible charter language for the proposed LMAP work. At > this point, IMO, we should propose a charter for the work that could eith= er > be added to an existing WG's charter, or standalone as a WG charter.=20 > That's an AD decision. A follow-on discussion to this would obviously be > the output documents and milestones. > > Here is a strawman to start with - > > " > Measuring broadband service on a large scale is important for network > diagnostics by providers and users, as well for public policy. To conduc= t > service measurements, user networks gather data, either on their own > initiative or instructed by a measurement controller, and then upload the > measurement results to a designated measurement server. There is a need t= o > standardize a logical architecture and describe key requirements for > protocols to connect the components. A large-scale measurement system > needs to support residential and small-enterprise networks, using either > wired or wireless networks. The architecture needs to consider the > management of the active and passive measurements. > > The LMAP work will include describing various use cases considered to be > Large Scale Performance Measurement systems, define the requirements of t= he > management of these systems, and finally define the management > communication architecture and protocols. > > This work will also include discussions about the privacy and security > concerns and will address them within its documents. " > > Fire away! > > -Marc Linsner- --=20 ------------------------------------------------------------------- Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de ------------------------------------------------------------------- From acmorton@att.com Mon Jan 28 09:24:11 2013 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 E8BB721F86CE for ; Mon, 28 Jan 2013 09:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkaNncvT7Z3T for ; Mon, 28 Jan 2013 09:24:11 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id F2C0A21F85FC for ; Mon, 28 Jan 2013 09:24:10 -0800 (PST) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 2E360120289; Mon, 28 Jan 2013 12:25:34 -0500 (EST) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id 75DEDE36F1; Mon, 28 Jan 2013 12:18:39 -0500 (EST) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Mon, 28 Jan 2013 12:24:09 -0500 From: "MORTON JR., ALFRED (AL)" To: Mirja Kuehlewind , "lmap@ietf.org" Date: Mon, 28 Jan 2013 12:24:02 -0500 Thread-Topic: [lmap] measurement traffic load [was: Re: Proposed LMAP Charter] Thread-Index: Ac39ecxWfjuYNriURAiyrbUxfqKqCQAAP3Zg Message-ID: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> 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 Cc: "philip.eardley@bt.com" , "trevor.burbridge@bt.com" Subject: Re: [lmap] measurement traffic load [was: Re: Proposed LMAP Charter] X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jan 2013 17:24:12 -0000 Hi Mirja, see below: > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Mirja Kuehlewind > Sent: Monday, January 28, 2013 12:06 PM > To: lmap@ietf.org > Cc: philip.eardley@bt.com; trevor.burbridge@bt.com > Subject: [lmap] measurement traffic load [was: Re: Proposed LMAP Charter] >=20 ... > Regarding the text below and also following the discussion on data > processing, > I would like to add one comment and maybe can some feedback from people h= ow > already have experience with large scale measurements: >=20 > For me the proposal seem to produce a huge amount of data. We envision a = MA in > basically every home network, there are frequent test scheduled by one or > more 'parties' and there is all the raw data which needs to be transmitte= d to > the collector. Thinking about this I afraid that most of our future Inter= net > traffic will be the measurement (and collection) traffic itself. Maybe th= is > issue is out of scope for the actual work group focus, but I guess it's w= orth > think about this when defining the architecture/scenarios and protocols. >=20 > Mirja >=20 This is a good point to raise again - it's something we briefly discussed l= ast=20 November and I doubt the traffic implications have escaped the mind of oper= ators. The authors of the IPPM Framework were on top of this issue for measurement traffic, but the same goes for the results as you said. At 06:01 PM 11/14/2012, Al Morton wrote: It is an important tenet of the IPPM framework RFC 2330, sec6.2: ... Finally, some measurement methodologies may be 'conservative' in the sense that the act of measurement does not modify, or only slightly modifies, the value of the performance metric the methodology attempts to measure. {Comment: for example, in a wide-area high-speed network under modest load, a test using several small 'ping' packets to measure delay would likely not interfere (much) with the delay properties of that network as observed by others. The corresponding statement about tests using a large flow to measure flow capacity would likely fail.} There are many reasons to prefer a "conservative" methodology, especially if a reasonable projection or model based on fundamental metrics is possible/available. regards, Al From trammell@tik.ee.ethz.ch Mon Jan 28 09:35:43 2013 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 D948021F8A08 for ; Mon, 28 Jan 2013 09:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji2VLlXGglXi for ; Mon, 28 Jan 2013 09:35:43 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id F19DA21F8999 for ; Mon, 28 Jan 2013 09:35:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DED12D9307; Mon, 28 Jan 2013 18:35:41 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hEMQG22K2MRq; Mon, 28 Jan 2013 18:35:41 +0100 (MET) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8022AD9304; Mon, 28 Jan 2013 18:35:41 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: Date: Mon, 28 Jan 2013 18:35:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1D90733F-85E8-4F96-AFA8-9501F1FAD628@tik.ee.ethz.ch> References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> To: "MORTON JR., ALFRED (AL)" X-Mailer: Apple Mail (2.1499) Cc: "philip.eardley@bt.com" , Mirja Kuehlewind , "trevor.burbridge@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] measurement traffic load [was: Re: Proposed LMAP Charter] X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jan 2013 17:35:44 -0000 Hi, all, On Jan 28, 2013, at 6:24 PM, "MORTON JR., ALFRED (AL)" = wrote: > Hi Mirja, see below: >=20 >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf = Of >> Mirja Kuehlewind >> Sent: Monday, January 28, 2013 12:06 PM >> To: lmap@ietf.org >> Cc: philip.eardley@bt.com; trevor.burbridge@bt.com >> Subject: [lmap] measurement traffic load [was: Re: Proposed LMAP = Charter] >>=20 > ... >> Regarding the text below and also following the discussion on data >> processing, >> I would like to add one comment and maybe can some feedback from = people how >> already have experience with large scale measurements: >>=20 >> For me the proposal seem to produce a huge amount of data. We = envision a MA in >> basically every home network, there are frequent test scheduled by = one or >> more 'parties' and there is all the raw data which needs to be = transmitted to >> the collector. Thinking about this I afraid that most of our future = Internet >> traffic will be the measurement (and collection) traffic itself. = Maybe this >> issue is out of scope for the actual work group focus, but I guess = it's worth >> think about this when defining the architecture/scenarios and = protocols. >>=20 >> Mirja >>=20 >=20 > This is a good point to raise again - it's something we briefly = discussed last=20 > November and I doubt the traffic implications have escaped the mind of = operators. > The authors of the IPPM Framework were on top of this issue for = measurement > traffic, but the same goes for the results as you said. >=20 > At 06:01 PM 11/14/2012, Al Morton wrote: > It is an important tenet of the IPPM framework RFC 2330, sec6.2: > ... > Finally, some measurement methodologies may be 'conservative' in the > sense that the act of measurement does not modify, or only slightly > modifies, the value of the performance metric the methodology > attempts to measure. {Comment: for example, in a wide-area = high-speed > network under modest load, a test using several small 'ping' packets > to measure delay would likely not interfere (much) with the delay > properties of that network as observed by others. The corresponding > statement about tests using a large flow to measure flow capacity > would likely fail.} >=20 >=20 > There are many reasons to prefer a "conservative" methodology, > especially if a reasonable projection or model based on fundamental > metrics is possible/available. Good point. However, scaling up and out might make the distance between = "doesn't affect the measurement" and "doesn't affect the Internet" wider = than we think about in the core network measurement case. Tens of = thousands of MAs on tens of thousands of home routers looking at tens of = thousands of links means that even very conservative measurements, in = aggregate, can lead both to significant test and reporting traffic.=20 If the definition of recommended / defined test plans falls into the = LMAP charter, then a requirement of those test plans should definitely = include bounds on measurement and reporting traffic. And I think issues = like this point to it being a good idea to define test plans, separate = from the singleton and metrics they're based on. Best regards, Brian= From dengguangqing@cnnic.cn Mon Jan 28 17:40:21 2013 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 E43D721E8064 for ; Mon, 28 Jan 2013 17:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.153 X-Spam-Level: X-Spam-Status: No, score=0.153 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dp6HOVMpa+oJ for ; Mon, 28 Jan 2013 17:40:19 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id EEDB621E805A for ; Mon, 28 Jan 2013 17:40:15 -0800 (PST) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO user-think) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 29 Jan 2013 09:40:08 +0800 Date: Tue, 29 Jan 2013 09:40:07 +0800 From: "Guangqing Deng" To: "lmap@ietf.org" References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de>, <9510D26531EF184D9017DF24659BB87F3419D404C3@EMV65-UKRD.domain1.systemhost.net> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201301290940068432111@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart248048343073_=----" Subject: Re: [lmap] measurement traffic load [was: Re: Proposed LMAP Charter] X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jan 2013 01:40:22 -0000 This is a multi-part message in MIME format. ------=_001_NextPart248048343073_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBNaXJqYSdzIHBvaW50LiBVc3VhbGx5LCB0aGUgYm90dGxlbmVjayBsaW5rcyBp biBpbnRlcm5ldCBhcmUgdGhvc2UgY3Jvc3MtSVNQIGxpbmtzLiBJZiB0aGUgY29sbGVjdG9yIGFu ZCB0aGUgTUEgYXJlIGluIGRpZmZlcmVudCBJU1BzLCB0aGUgbWVhc3VyZW1lbnQgdHJhZmZpYyBm cm9tIE1BcyB0byBjb2xsZWN0b3JzIHdpbGwgYnJpbmcgaHVnZSBwcmVzc3VyZSB0byB0aGUgYWxy ZWFkeSBidXN5IGNyb3NzLUlTUCBsaW5rcy4gU28gaG93IHRvIHJlZHVjZSB0aGUgY3Jvc3MtSVNQ IG1lYXN1cmVtZW50IHRyYWZmaWMgd2hpbGUgbm90IHJlZHVjaW5nIHRoZSBtZWFzdXJlbWVudCBh Y2N1cmFjeSBtYXkgYmUgYSBjaGFsbGVuZ2luZyBwcm9ibGVtIHRoYXQgbmVlZHMgbW9yZSBjb25z aWRlcmF0aW9uLiANCg0KDQoNCg0KR3VhbmdxaW5nIERlbmcNCkNOTklDIA0KDQpGcm9tOiBwaGls aXAuZWFyZGxleUBidC5jb20NCkRhdGU6IDIwMTMtMDEtMjkgMDE6MTYNClRvOiBtaXJqYS5rdWVo bGV3aW5kQGlrci51bmktc3R1dHRnYXJ0LmRlOyBsbWFwQGlldGYub3JnDQpDQzogdHJldm9yLmJ1 cmJyaWRnZQ0KU3ViamVjdDogUmU6IFtsbWFwXSBtZWFzdXJlbWVudCB0cmFmZmljIGxvYWQgW3dh czogUmU6IFByb3Bvc2VkIExNQVAgQ2hhcnRlcl0NClRoaXMgaXMgYSBnb29kIHBvaW50Lg0KTW9z dCB1c3VhbGx5IHRoZSBDb250cm9sbGVyIHdpbGwgc2VsZWN0IGEgc3Vic2V0IG9mIHRoZSBNZWFz dXJlbWVudCBBZ2VudHMsIGFuZCBpbnN0cnVjdCB0aGVtIHRvIGNvbGxlY3QgbWVhc3VyZW1lbnRz IGFjY29yZGluZyB0byBzb21lIHNjaGVkdWxlICgnbWVhc3VyZSBkb3dubG9hZCBzcGVlZCBvbmNl IGFuIGhvdXInKS4gVGhlIG90aGVyIE1BcyB3b24ndCBiZSBtYWtpbmcgbWVhc3VyZW1lbnRzIC0g b3RoZXJ3aXNlIGFzIHlvdSBzYXkgdGhlIGludGVybmV0IHdpbGwgYmUgZG9taW5hdGVkIGJ5IG1l YXN1cmVtZW50IHRyYWZmaWMhIFRoaXMgaXMgZmluZSB3aGVyZSB0aGUgb3BlcmF0b3Igb3IgcmVn dWxhdG9yIGlzIGludGVyZXN0ZWQgaW4gYXZlcmFnZXMtYWNyb3NzLWxpbmVzIChlZyB0byBjb21w YXJlIG9uZSBJU1AgYWdhaW5zdCBhbm90aGVyKQ0KDQpCZWNhdXNlIChob3BlZnVsbHkpIGFsbCBo b21lIGh1YnMgZXRjIGluY2x1ZGUgTUEgZnVuY3Rpb25hbGl0eSwgaWYgYSBjdXN0b21lciByZXBv cnRzIHByb2JsZW1zLCB0aGVuIHRoZSBDb250cm9sbGVyIGNhbiB0ZWxsIHRoZSByZWxldmFudCBN QSB0byBydW4gc29tZSBzcGVjaWZpYyB0ZXN0cy4gVGhpcyBpcyB0aGUgbmV3IGJpdCB0aGF0IHdv dWxkIGJlIGdyZWF0Lg0KDQpBbHNvLCB0aGluayB0aGUgZGVmYXVsdCBjYXNlIGlzIHRvIHJlcG9y dCB0aGUgcmF3IG1lYXN1cmVtZW50LiBCdXQgZWcgc29tZSBJUFBNIG1ldHJpY3MgZGVmaW5lIGEg InN0YXRpc3RpYyIgYXMgd2VsbCBhcyBhICJzaW5nbGV0b24iIG1lYXN1cmVtZW50IHJlc3VsdCAt IHNvIHRoYXQgbWlnaHQgYmUgcmVwb3J0ZWQgaW5zdGVhZC4gDQoNCnBoaWwgDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pcmphIEt1ZWhsZXdpbmQgW21haWx0bzptaXJq YS5rdWVobGV3aW5kQGlrci51bmktc3R1dHRnYXJ0LmRlXSANClNlbnQ6IDI4IEphbnVhcnkgMjAx MyAxNzowNg0KVG86IGxtYXBAaWV0Zi5vcmcNCkNjOiBFYXJkbGV5LFBMLFBoaWxpcCxUVUI4IFI7 IEJ1cmJyaWRnZSxULFRyZXZvcixUVUI4IFINClN1YmplY3Q6IG1lYXN1cmVtZW50IHRyYWZmaWMg bG9hZCBbd2FzOiBSZTogUHJvcG9zZWQgTE1BUCBDaGFydGVyXQ0KDQpIaSBldmVyeWJvZHksDQoN CnRoYW5rcyBQaGlsIGZvciB0aGlzIHJlYWxseSBnb29kIHByb3Bvc2FsLiBJIGFncmVlZCB0aGF0 IGl0IGlzIGltcG9ydCB0byBzY29wZSBkb3duIHRoZSBpbml0aWFsIHdvcmsgdG8gYSB3ZWxsIGRl ZmluZWQgc2NlbmFyaW8gYW5kIGZvY3VzIG9uIGJhc2ljIHByb3RvY29sIGZ1bmN0aW9uYWxpdHku DQoNClJlZ2FyZGluZyB0aGUgdGV4dCBiZWxvdyBhbmQgYWxzbyBmb2xsb3dpbmcgdGhlIGRpc2N1 c3Npb24gb24gZGF0YSBwcm9jZXNzaW5nLCBJIHdvdWxkIGxpa2UgdG8gYWRkIG9uZSBjb21tZW50 IGFuZCBtYXliZSBjYW4gc29tZSBmZWVkYmFjayBmcm9tIHBlb3BsZSBob3cgYWxyZWFkeSBoYXZl IGV4cGVyaWVuY2Ugd2l0aCBsYXJnZSBzY2FsZSBtZWFzdXJlbWVudHM6DQoNCkZvciBtZSB0aGUg cHJvcG9zYWwgc2VlbSB0byBwcm9kdWNlIGEgaHVnZSBhbW91bnQgb2YgZGF0YS4gV2UgZW52aXNp b24gYSBNQSBpbiBiYXNpY2FsbHkgZXZlcnkgaG9tZSBuZXR3b3JrLCB0aGVyZSBhcmUgZnJlcXVl bnQgdGVzdCBzY2hlZHVsZWQgYnkgb25lIG9yIG1vcmUgJ3BhcnRpZXMnIGFuZCB0aGVyZSBpcyBh bGwgdGhlIHJhdyBkYXRhIHdoaWNoIG5lZWRzIHRvIGJlIHRyYW5zbWl0dGVkIHRvIHRoZSBjb2xs ZWN0b3IuIFRoaW5raW5nIGFib3V0IHRoaXMgSSBhZnJhaWQgdGhhdCBtb3N0IG9mIG91ciBmdXR1 cmUgSW50ZXJuZXQgdHJhZmZpYyB3aWxsIGJlIHRoZSBtZWFzdXJlbWVudCAoYW5kIGNvbGxlY3Rp b24pIHRyYWZmaWMgaXRzZWxmLiBNYXliZSB0aGlzIGlzc3VlIGlzIG91dCBvZiBzY29wZSBmb3Ig dGhlIGFjdHVhbCB3b3JrIGdyb3VwIGZvY3VzLCBidXQgSSBndWVzcyBpdCdzIHdvcnRoIHRoaW5r IGFib3V0IHRoaXMgd2hlbiBkZWZpbmluZyB0aGUgYXJjaGl0ZWN0dXJlL3NjZW5hcmlvcyBhbmQg cHJvdG9jb2xzLg0KDQpNaXJqYQ0KDQoNCk9uIFdlZG5lc2RheSAyMyBKYW51YXJ5IDIwMTMgMTA6 NTQ6MzkgcGhpbGlwLmVhcmRsZXlAYnQuY29tIHdyb3RlOg0KPiBUaGFua3MgTWFyYy4gV2UncmUg dmVyeSBpbnRlcmVzdGVkIGluIGRpc2N1c3NpbmcgYSBwb3RlbnRpYWwgY2hhcnRlci4NCj4gT25l IHRoaW5nIHdlIHRoaW5rIGlzIHdvcnRoIHRyeWluZyB0byBkbyBpcyB0byBzaW1wbGlmeSB0aGUg cHJvcG9zZWQgd29yaw0KPiBhcyBtdWNoIGFzIHBvc3NpYmxlLCBhcyB0aGUgcG90ZW50aWFsIHNj b3BlIGlzIGJpZy4gT2YgY291cnNlIHRoaXMgY291bGQgYmUNCj4gZG9uZSBlbnRpcmVseSBhcyBw YXJ0IG9mIHRoZSBXRydzIHdvcmssIGJ1dCBkb2luZyB0aGlzIGJlZm9yZWhhbmQgd291bGQNCj4g ZW5hYmxlIGEgbW9yZSByYXBpZCBzdGFydC4gQmVsb3cgaXMgb3VyIGF0dGVtcHQgdG8gc3VnZ2Vz dCBzb21lIHNpbXBsaWZ5aW5nDQo+IGFzc3VtcHRpb25zLiBFYWNoIG9mIHRoZSBzaW1wbGlmeWlu ZyBhc3N1bXB0aW9ucyAgaGFzIHNvbWUgcGVuYWx0eSwgc28gaXQNCj4gd291bGQgYmUgZ3JlYXQg dG8gaGVhciB3aGV0aGVyIHBlb3BsZSB0aGluayB0aGV5J3JlIHJlYXNvbmFibGUsIG9yDQo+IG92 ZXItcmVzdHJpY3QgdGhlIHVzZSBjYXNlIHRoYXQgeW91IGhhdmUgaW4gbWluZC4gSWYgaXQncyBo ZWxwZnVsIHdlIGNvdWxkDQo+IHdyaXRlIHVwIHRoZSBhcmNoaXRlY3R1cmFsIGFzc3VtcHRpb25z IGluIGFuIEktRCAtIGNvLWF1dGhvcnMgdmVyeSB3ZWxjb21lLg0KPiBTbyBhIGtleSBxdWVzdGlv biBpcyB3aGV0aGVyIHRoZSBwcm9zcGVjdGl2ZSBXRyBzaG91bGQgc3RhcnQgd2l0aCBhIHBoYXNl DQo+IG9mIHJlYWNoaW5nIGNvbnNlbnN1cyBvbiBhcmNoaXRlY3R1cmUgYW5kIGNob29zaW5nIHN0 YXJ0aW5nIHByb3RvY29scywgb3INCj4gd2hldGhlciB3ZSBjYW4gcmVhY2ggZW5vdWdoIGNvbnNl bnN1cyBiZWZvcmUgdGhlIG5leHQgSUVURiB0byBtb3ZlIHN0cmFpZ2h0DQo+IHRvIHN0YW5kYXJk cyB3b3JrLiBJJ20gbm90IHN1cmUgdGhhdCB3ZSBjYW4gZGVjaWRlIHRoaXMgcmlnaHQgbm93LCBh cyBpdA0KPiBkZXBlbmRzIG9uIGhvdyB0aGUgZGlzY3Vzc2lvbiBnb2VzIG92ZXIgdGhlIG5leHQg bW9udGggb3Igc28uIFRoZXJlIGFyZQ0KPiBzb21lIHdvcmsgaXRlbXMgYmVsb3cgdGhhdCBtaWdo dCBhcHBseSBpbiB0aGUgbGF0dGVyIGNhc2UuIC0tDQo+IE1lYXN1cmluZyBicm9hZGJhbmQgc2Vy dmljZSBvbiBhIGxhcmdlIHNjYWxlIGlzIGltcG9ydGFudCBmb3IgbmV0d29yaw0KPiBkaWFnbm9z dGljcyBieSBwcm92aWRlcnMgYW5kIHVzZXJzLCBhcyB3ZWxsIGZvciBwdWJsaWMgcG9saWN5LiAg e0NvbW1lbnQ6DQo+IG9wZXJhdG9ycyBtYXkgd2FudCBtZWFzdXJlbWVudCB0byBoZWxwIG5ldHdv cmsgcGxhbm5pbmcgYW5kIG5ldHdvcmsgbWd0DQo+IGxpa2UgZmF1bHQgaWRlbnRpZmljYXRpb247 IG5vdCBzdXJlIHdoZXRoZXIgdGhpcyBuZWVkcyBleHBsaWNpdGx5IG5vdGluZy59IA0KPiBUbyBj b25kdWN0IHNlcnZpY2UgbWVhc3VyZW1lbnRzLCBNZWFzdXJlbWVudCBBZ2VudHMgKE1Bcykgb24g dXNlciBuZXR3b3Jrcw0KPiBnYXRoZXIgZGF0YSwgZWl0aGVyIG9uIHRoZWlyIG93biBpbml0aWF0 aXZlIG9yIGluc3RydWN0ZWQgYnkgYSBDb250cm9sbGVyLA0KPiBhbmQgdGhlbiB1cGxvYWQgdGhl IG1lYXN1cmVtZW50IHJlc3VsdHMgdG8gYSBkZXNpZ25hdGVkIENvbGxlY3Rvci4NCj4gQ3VycmVu dGx5IG1lYXN1cmVtZW50IHBsYXRmb3JtcyBjb250YWluIHVwIHRvIGEgZmV3IHRob3VzYW5kIE1B cy4gSG93ZXZlciwNCj4gdGhlIHZpc2lvbiBpcyB0aGF0IE1BcyBjb3VsZCBwb3RlbnRpYWxseSBi ZSBlbWJlZGRlZCBpbiBldmVyeSBob21lIGh1YiwNCj4gY2FibGUgbW9kZW0sIGVudGVycHJpc2Ug ZWRnZSByb3V0ZXIsIHNldCB0b3AgYm94LCBzbWFydHBob25lIGFuZCBzbyBvbi4NCj4gU3RhbmRh cmRzIHdpbGwgaGVscCB0aGlzIGNhcGFiaWxpdHkgYmUgbW9yZSBwZXJ2YXNpdmUsIG1hbmFnZWFi bGUgYW5kDQo+IGRpcmVjdGx5IGNvbXBhcmFibGUuIFJGQ3MgZnJvbSB0aGUgSVBQTSBXRyBkZWZp bmUgaG93IHRvIG1lYXN1cmUgbWV0cmljcyAtDQo+IHJlcXVlc3RzIHRvIGRlZmluZSBuZXcgdGVz dHMgc2hvdWxkIGJlIGhhbmRsZWQgYnkgSVBQTS4gVGhlc2UgdGVzdHMNCj4gZWZmZWN0aXZlbHkg ZGVmaW5lIHRoZSBjb21tdW5pY2F0aW9ucyBiZXR3ZWVuIGEgTUEgYW5kIFRlc3QgU2VydmVyLg0K PiB7Q29tbWVudDogdGhlcmUgYXJlIGxpa2VseSBuZXcgbWV0cmljcyB0aGF0IG5lZWQgdG8gYmUg ZGVmaW5lZCAoZWcgbGF0ZW5jeQ0KPiB1bmRlciBsb2FkKSBvciB0ZXN0cyB1bmRlciBuZXcgY29u ZGl0aW9ucyAoZWcgY3VycmVudCB0ZXN0IGZvciBzcGVlZCBtYXkNCj4gbm90IHNjYWxlIHdlbGwg dG8gaGlnaCBsaW5lIHNwZWVkcykufSAuIEluIGEgZmV3IGNhc2VzIHRoZSBJUFBNIGRlZmluaXRp b24NCj4gbWF5IG5lZWQgdG8gYmUgZXh0ZW5kZWQgdG8gbW92ZSByZXN1bHRzIGRhdGEgZnJvbSB0 aGUgVGVzdCBTZXJ2ZXIgdG8gdGhlIE1BDQo+IGZvciBsYXRlciByZXBvcnRpbmcuIFRoZSBMTUFQ IFdHIG1ha2VzIHRoZSBmb2xsb3dpbmcgYXJjaGl0ZWN0dXJhbA0KPiBhc3N1bXB0aW9ucyAtIGlu IG9yZGVyIHRvIG1ha2UgcmFwaWQgcHJvZ3Jlc3Mgd2l0aCBhbiBhY2NlcHRhYmxlIGxvc3Mgb2YN Cj4gZ2VuZXJhbGl0eTotDQo+DQo+ICogICAgICAgICBXZSBhc3N1bWUgdGhhdCBNZWFzdXJlbWVu dCBBZ2VudCwgdGVzdHMgQ29udHJvbGxlciBhbmQgcmVzdWx0cw0KPiBDb2xsZWN0b3IgYXJlIGFs bCB1bmRlciBjb250cm9sIG9mIHNhbWUgb3JnYW5pc2F0aW9uIChlZyBTYW1rbm93cywgRkNDLA0K PiBCVCkuIFJlYXNvbjogSW50ZXItb3JnYW5pc2F0aW9uIGludGVyYWN0aW9ucyAoZm9yIGV4YW1w bGUgdG8gc2hhcmUgcmVzdWx0cykNCj4gaXMgYmV0dGVyIGhhbmRsZWQgYnkgYnVzaW5lc3MtbGV2 ZWwgbmVnb3RpYXRpb24gdGhhbiBhIGNvbnRyb2wgcHJvdG9jb2wuDQo+DQo+ICogICAgICAgICBX ZSBhc3N1bWUgdGhlIE1BIGluaXRpYXRlcyBhIG1lYXN1cmVtZW50LiBSZWFzb25zOiBoYXZpbmcg dGhlDQo+IHRlc3Qgc2NoZWR1bGUgb24gTUEgYXZvaWRzIGl0IGhhdmluZyB0byBjaGVjayBmcmVx dWVudGx5IHdpdGggdGhlDQo+IENvbnRyb2xsZXI7IGl0IGlzIGVhc2llciBpZiB0aGUgTUEgaXMg YmVoaW5kIGEgTkFUOyBhbmQgdGhlIE1BIGtub3dzDQo+IHdoZXRoZXIgdGhlIHVzZXIgaXMgYWN0 aXZlIGFuZCB0aGVyZWZvcmUgd2hldGhlciB0byBydW4gdGVzdCBvciBkZWxheSBpdC4NCj4NCj4g KiAgICAgICAgIFdlIGFzc3VtZSBtZWFzdXJlbWVudCByZXN1bHRzIGFyZSBzZW50IGZyb20gTUEs IGFuZCBub3QgZnJvbSB0ZXN0DQo+IHNlcnZlci4gUmVhc29uLTE6IEl0IGlzIGVhc2llciB0byBz ZWN1cmUgdGhlIE1BIHRvIENvbGxlY3RvciBjb21tdW5pY2F0aW9uLg0KPiBPbmUgaW1wbGljYXRp b24gaXMgdGhhdCBmb3IgYW4gdXBsb2FkIHRlc3QgbWVhc3VyZWQgYnkgdGhlIHRlc3Qgc2VydmVy LCB0aGUNCj4gcmVzdWx0IGlzIHJlcG9ydGVkIGJhY2sgdG8gdGhlIE1BIHdoaWNoIHJlcG9ydHMg aXQgaW4gdHVybi4gUmVhc29uLTI6IFRlc3QNCj4gc2VydmVycyBtYXkgYmUgY29udHJvbGxlZCBi eSBhIHRoaXJkIHBhcnR5ICgnbG9hZCB0aW1lIGZvciBJRVRGIGhvbWUNCj4gcGFnZScpLg0KPg0K PiAqICAgICAgICAgV2UgYXNzdW1lIG5vIG5lZ290aWF0aW9uIGlzIG5lZWRlZCBiZXR3ZWVuIENv bnRyb2xsZXIgYW5kIE1BLiBUaGUNCj4gQ29udHJvbGxlciBhbHJlYWR5IGtub3dzIHRoZSBjaGFy YWN0ZXJpc3RpY3Mgb2YgdGhlIE1BLCBmb3IgaW5zdGFuY2UgdmlhDQo+IFRSMDY5IGZvciBCcm9h ZGJhbmQgRm9ydW0gZGV2aWNlcy4gVGhlIENvbnRyb2xsZXIgc2ltcGx5IGluc3RydWN0cw0KPiAo c2VjdXJlbHkpIHRoZSBNQSAiTWVhc3VyZSB0aGlzIjsgdGhlIE1BIHJlcGxpZXMgIk9LIC9lcnJv ciIuDQo+DQo+ICogICAgICAgICBTaW1pbGFybHkgd2UgYXNzdW1lIG5vIG5lZ290aWF0aW9uIGlz IG5lZWRlZCBiZXR3ZWVuIHRoZSBNQSBhbmQNCj4gQ29sbGVjdG9yLiBUaGUgcHJvdG9jb2wgc2lt cGx5IGRlbGl2ZXJzIChzZWN1cmVseSkgdGhlIG1lYXN1cmVtZW50IHJlc3VsdHMNCj4gZnJvbSB0 aGUgTUEgdG8gdGhlIENvbGxlY3RvciwgYW5kIHJldHVybnMgYW4gYWNrIG9yIGVycm9yIGNvZGUu DQo+DQo+ICogICAgICAgICBXZSBhc3N1bWUgZWFjaCBNQSBpcyBjb250cm9sbGVkIGJ5IG9ubHkg b25lIENvbnRyb2xsZXIuIFJlYXNvbjoNCj4gdG8gYXZvaWQgZGlmZmVyZW50IENvbnRyb2xsZXJz IGdpdmluZyB0aGUgTUEgY29uZmxpY3Rpbmcgc2NoZWR1bGVzLiBOb3RlOiBhDQo+IG1lYXN1cmVt ZW50IHBsYXRmb3JtIG1heSBoYXZlIHNldmVyYWwgQ29udHJvbGxlcnMsIHdpdGggZWFjaCBDb250 cm9sbGVyDQo+IGNvbnRyb2xsaW5nIGEgc3Vic2V0IG9mIHRoZSBNQXMsIGZvciBleGFtcGxlIG9u ZSBjb250cm9sbGluZyB3aXJlbGluZSBNQXMNCj4gYW5kIG9uZSBtb2JpbGUgTUFzLg0KPg0KPiAq ICAgICAgICAgV2UgYXNzdW1lIHRoZSByYXcgbWVhc3VyZW1lbnQgcmVzdWx0cyBhcmUgcmVwb3J0 ZWQ7IGZpbHRlcmluZw0KPiAvYXZlcmFnaW5nIG9mIG1lYXN1cmVtbnRzIGJ5IHRoZSBNQSBpcyBu b3QgaW4gdGhlIGluaXRpYWwgc2NvcGUsIGV4Y2VwdCBhcw0KPiBkZWZpbmVkIGJ5IElQUE0gYXMg cGFydCBvZiB0aGUgbWV0cmljIGRlZmluaXRpb24uDQo+DQo+ICogICAgICAgICBXZSBhc3N1bWUg dGhhdCB1cGxvYWRpbmcgYSBuZXcgdGVzdCBjYXBhYmlsaXR5IHRvIHRoZSBNQSBpcyBvdXQNCj4g b2Ygc2NvcGUuIFRoaXMgY2FuIGJlIGRvbmUgYXMgYSBmaXJtd2FyZSB1cGdyYWRlIGZvciBob21l IGh1Yiwgb3IgbmV3IGFwcA0KPiBmb3IgUEMsIGV0Yy4NCj4NCj4gKiAgICAgICAgIFdlIGFzc3Vt ZSBhcyBvdXQgb2Ygc2NvcGUgYSBuZXR3b3JrIHBhcmFtZXRlciBzZXJ2ZXIgKHdoaWNoDQo+IHN0 b3JlcyBub21pbmFsIHZhbHVlcyBzdWNoIGFzIHRoZSBjb250cmFjdHVhbCBkYXRhIHJhdGUpLiBU aGUgZnVuY3Rpb25hbA0KPiByb2xlIG9mIHRoZSBOZXR3b3JrIFBhcmFlbWV0ZXIgU2VydmVyIG1h eSBiZSBmdWxmaWxsZWQgYnkgZXhpc3RpbmcgT1NTDQo+IChzdWNoIGFzIG5ldHdvcmsgb3IgaG9t ZSBnYXRld2F5IG1hbmFnZW1lbnQgc3lzdGVtcykuIEludGVyZmFjZXMgdG8gdGhlIE5QUw0KPiBh cmUgcHJlLW1lYXN1cmVtZW50ICh1c2VkIGJ5IHRoZSBDb250cm9sbGVyIHRvIGRlY2lkZSB3aGlj aCB0ZXN0cyB0bw0KPiBzY2hlZHVsZSkgb3IgcG9zdC1tZWFzdXJlbWVudCAodXNlZCB0byBhbmFs eXNlIHRoZSBtZWFzdXJlbWVudCBkYXRhKS4NCj4NCj4gKiAgICAgICAgIFdlIGFzc3VtZSBkYXRh IGZpbHRlcmluZyBpcyBvdXQgb2YgdGhlIGluaXRpYWwgc2NvcGUuIEZpbHRlcmluZw0KPiBpbmNs dWRlczogcmVtb3ZhbCBvZiBvdXRsaWVyIG1lYXN1cmVtZW50cywgYXJjaGl2aW5nIChjdXJhdGlu ZykgZGF0YSBmb3INCj4gc2NpZW50aWZpYyByZXNlYXJjaCwgYW5kIHNvIG9uLiBUaGVyZSBhcmUg Y2VydGFpbmx5IHNvbWUgYXNwZWN0cyB3aGVyZSBiZXN0DQo+IHByYWN0aWNlIHdvdWxkIGJlIHVz ZWZ1bCBidXQgZGF0YSBmaWx0ZXJpbmcgaXMgbm90IGEgZmlyc3QgcHJpb3JpdHkuDQo+DQo+ICog ICAgICAgICBXZSBhc3N1bWUgdGhhdCBkYXRhIHByaXZhY3kgaXNzdWVzIGFyZSBvdXQgb2Ygc2Nv cGUgYWx0aG91Z2gNCj4gc2VjdXJpdHkgaXMgY29uc2lkZXJlZC4gVGhlIE1BLCBDb250cm9sbGVy IGFuZCBDb2xsZWN0b3IgYXJlIGFsbCB1bmRlcg0KPiBjb250cm9sIG9mIHRoZSBzYW1lIG9yZ2Fu aXNhdGlvbi4gSVBQTSBjb25zaWRlcnMgdGhlIGltcGxpY2F0aW9ucyBvZiBhbnkNCj4gcGFzc2l2 ZSBtZWFzdXJlbWVudCB0ZXN0cyB0aGF0IGl0IGRlZmluZXMuIFRoZSBMTUFQIFdHIHN0YW5kYXJk aXNlcyB0aGUNCj4gZm9sbG93aW5nIGl0ZW1zOg0KPg0KPiAxLiAgICAgIFRoZSBkYXRhIG1vZGVs IHRoYXQgZGVmaW5lcyB0aGUgdGVzdCBzY2hlZHVsZSwgd2hpY2ggaW5jbHVkZXM6DQo+DQo+IGEu ICAgICAgVGhlIElQUE0gbWV0cmljIHRvIGJlIHRlc3RlZCBhbmQgdmFsdWVzIGZvciBpdHMgcGFy YW1ldGVycy4NCj4ge1F1ZXN0aW9uOiBpcyB0aGUgcmVzdHJpY3Rpb24gdG8gSVBQTSBPSz8gSWUg bm9uLUlQUE0gdGVzdHMgYXJlIG91dCBvZg0KPiBzY29wZX0NCj4NCj4gYi4gICAgICBUZXN0IHNj aGVkdWxlOiB3aGVuIHRoZSB0ZXN0IHNob3VsZCBiZSBkb25lIGFuZCBob3cgb2Z0ZW4gcmVwZWF0 ZWQNCj4gKCdvbmNlIGFuIGhvdXIgYXQgeHguMDMnKS4gQSB0ZXN0IG1heSBhbHNvIGJlIGEgb25l LW9mZiwgZG9uZSBpbW1lZGlhdGVseQ0KPiBvbiBkZW1hbmQuDQo+DQo+IGMuICAgICAgIE91dHB1 dCBwYXJhbWV0ZXJzOiBzb21lIElQUE0gbWV0cmljcyBtYXkgZGVmaW5lIGEgY2hvaWNlIG9mDQo+ IG91dHB1dHMNCj4NCj4gZC4gICAgICBUZXN0IFNlcnZlcjogd2hpY2ggc2VydmVyIG9yIHNlcnZl cnMgc2hvdWxkIGJlIHVzZWQgZm9yIHRoZSB0ZXN0DQo+DQo+IGUuICAgICAgRW52aXJvbm1lbnRh bCBjb25kaXRpb25zOiBzdWNoIGFzICdubyB1c2VyIHRyYWZmaWMnIHdoaWNoIG1lYW5zIGENCj4g cGFydGljdWxhciBpbnN0YW5jZSBvZiB0aGUgdGVzdCBpcyBkZWxheWVkIG9yIGFiYW5kb25lZC4N Cj4NCj4gZi4gICAgICAgIChwZXJoYXBzKSBNZXRhZGF0YTogc3VjaCBhcyBhIG1vYmlsZSdzIGxv Y2F0aW9uIHdoZW4gdGhlIHRlc3QNCj4gc2hvdWxkIGJlIG1hZGUsIHRoZSBsaW5lJ3Mgbm9taW5h bCByYXRlIGV0Yy4gVGhlcmUgbWF5IGJlIHByaXZhY3kNCj4gaW1wbGljYXRpb25zIGZvciB0aGUg c2NlbmFyaW8gd2hlcmUgdGhlIG1lYXN1cmVtZW50IHBsYWZvcm0gaXMgbm90DQo+IGNvbnRyb2xs ZWQgYnkgdGhlIG9wZXJhdG9yOyB0aGUgaW5pdGlhbCBzY29wZSB3aWxsIGV4Y2x1ZGUgdGhpcyBz Y2VuYXJpby4NCj4NCj4gZy4gICAgICAocGVyaGFwcykgTWV0YWRhdCB0byByZXBvcnQ6IGZvciBl eGFtcGxlLCB0aGUgTUEgbWF5IGJlIGFibGUgdG8NCj4gbWVhc3VyZSBMYXllciAxIG8gMiBjaGFy Y3RlcmlzdGljcyBzdWNoIGFzIERTTCBzeW5jIHNwZWVkIGFuZCBpbnRlcmxlYXZpbmc7DQo+IHRo ZSBhY3R1YWwgdGVzdCBpcyBvdXQgb2Ygc2NvcGUuIEFzIGZvciB0aGUgcHJldmlvdXMgYnVsbGV0 LCB0aGVyZSBtYXkgYmUNCj4gcHJpdmFjeSBpbXBsaWNhdGlvbnMgZm9yIHRoZSBnZW5lcmFsIHNj ZW5hcmlvLCB3aGljaCB3ZSBleGNsdWRlIGZyb20gdGhlDQo+IGluaXRpYWwgc2NvcGUuDQo+DQo+ IGguICAgICAgKHBlcmhhcHMpIFByaW9yaXR5OiB0aGUgQ29udHJvbGxlciBkZWNpZGVzIHdoaWNo IHRlc3RzIGFyZSBkb25lDQo+IHdoZW4uIEhvd2V2ZXIgYSB0ZXN0IG1pZ2h0IGdldCBkZWxheWVk IHVudGlsIGl0IG92ZXJsYXBzIHdpdGggYW5vdGhlcg0KPiBzY2hlZHVsZWQgdGVzdCAtIHdoaWNo IHNob3VsZCBiZSBkb25lIChvciBkb25lIGZpcnN0KT8gT3Igc2hvdWxkIGl0IHNpbXBseQ0KPiBi ZSBhYmFuZG9uZWQ/DQo+DQo+IDIuICAgICAgIFRoZSBkYXRhIG1vZGVsIHRoYXQgZGVmaW5lcyBo b3cgYW4gTUEgc2hvdWxkIHJlcG9ydCB0ZXN0IHJlc3VsdHMuDQo+IFRoaXMgbWF5IGJlIGNvbWJp bmVkIHdpdGggKDEpIGFib3ZlIG9yIHNwZWNpZmllZCBhcyBhIHNlcGFyYXRlIHJlcG9ydGluZw0K PiBzY2hlZHVsZS4gVGhpcyBpbmNsdWRlczoNCj4NCj4gYS4gICAgICAgV2hlcmUgdG8gcmVwb3J0 IHJlc3VsdHMgdG8gKG9uZSBvciBtb3JlIENvbGxlY3RvcnMpDQo+DQo+IGIuICAgICAgSG93IG9m dGVuIHRvIHJlcG9ydCByZXN1bHRzIGZvciB0aGUgZGlmZmVyZW50IHRlc3RzDQo+DQo+IGMuICAg ICAgIFdoYXQgdG8gZG8gd2hlbiBDb2xsZWN0b3IgaXMgbm90IGF2YWlsYWJsZSAoZmFpbC1vdmVy LCB0cnkgYWdhaW4pDQo+DQo+IDMuICAgICAgVGhlIGRhdGEgbW9kZWwgdGhhdCBkZWZpbmVzIHRo ZSByZXBvcnQsIHdoaWNoIGluY2x1ZGVzOg0KPg0KPiBhLiAgICAgIFRoZSBtZXRyaWMgdGhhdCB3 YXMgbWVhc3VyZWQNCj4NCj4gYi4gICAgICBUaGUgdGltZSBvZiB0aGUgdGVzdA0KPg0KPiBjLiAg ICAgICBXaGV0aGVyIHRoZSB0ZXN0IGlzIHNjaGVkdWxlZCwgb25lLW9mZiB0cmlnZ2VyZWQgYnkg dGhlDQo+IENvbnRyb2xsZXIsIG9yIHVzZXItaW5pdGlhdGVkDQo+DQo+IGQuICAgICAgVGhlIG1l YXN1cmVtZW50IHJlc3VsdCAtIHVzdWFsbHkgc2V2ZXJhbCByZXN1bHRzIGFyZSBiYXRjaGVkDQo+ IHRvZ2V0aGVyOyB0aGUgcmVzdWx0IG9mIGEgb25lLW9mZiB0ZXN0IG1heSBiZSB3YW50ZWQgaW1t ZWRpYXRlbHkNCj4NCj4gZS4gICAgICAocGVyaGFwcykgTWV0YWRhdGEsIHN1Y2ggYXMgdGhlIG1v YmlsZSdzIGxvY2F0aW9uDQo+DQo+IGYuICAgICAgICBDb21tZW50OiBpdCB3b3VsZCBtYWtlIHNl bnNlIHRvIHVzZSB0aGUgc2FtZSBsYW5ndWFnZSBhcyBmb3IgMSwNCj4gZm9yIGluc3RhbmNlIFhN TCwgWUFORy4uLg0KPg0KPiA0LiAgICAgIFRoZSBhcHBsaWNhdGlvbiBsZXZlbCBwcm90b2NvbCBm b3IgdGhlIChzZWN1cmUpIGRlbGl2ZXJ5IG9mIHRoZQ0KPiB0ZXN0IGFuZCByZXBvcnRpbmcgc2No ZWR1bGUgKCMxLCAjMikNCj4NCj4gYS4gICAgICBBIHNpbXBsZSBpbnN0cnVjdGlvbiAtIHJlc3Bv bnNlIHByb3RvY29sLCB3aXRoIGVycm9yIGNvZGVzIGRlZmluZWQNCj4NCj4gYi4gICAgICBMTUFQ IGNvdWxkIHNwZWNpZnkgaG93IGl0IG9wZXJhdGVzIG92ZXIgb25lIGV4aXN0aW5nIHByb3RvY29s IChSRVNUDQo+IHN0eWxlIEhUVFAocyksIE5ldGNvbmYuLi4pDQo+DQo+IDUuICAgICAgVGhlIGFw cGxpY2F0aW9uIGxldmVsIHByb3RvY29sIGZvciB0aGUgKHNlY3VyZSkgZGVsaXZlcnkgb2YgdGhl DQo+IHJlcG9ydCAoIzMpDQo+DQo+IGEuICAgICAgU2FtZSBjb21tZW50cyBhcyBmb3IgIzQNCj4N Cj4gNi4gICAgICBBIGRvY3VtZW50IGV4cGxhaW5pbmcgdGhlIHNpbXBsaWZ5aW5nIGFyY2hpdGVj dHVyYWwgYXNzdW1wdGlvbnMgaW4NCj4gbW9yZSBkZXRhaWwuIFRoaXMgZG9jdW1lbnQgY291bGQg YWxzbyBkZWZpbmUgc29tZSB0ZXJtaW5vbG9neSBhbmQgZXhwbGFpbg0KPiB0aGUgdXNlIGNhc2Vz LiBMb29raW5nIGZvcndhcmQgdG8gdGhlIGRpc2N1c3Npb24sDQo+IEJlc3Qgd2lzaGVzLA0KPiBU cmV2b3IgYW5kIFBoaWwNCj4gRnJvbTogbG1hcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bG1h cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gTWFyYyBMaW5zbmVyIFNlbnQ6IDE4 IEphbnVhcnkgMjAxMyAyMDo0OA0KPiBUbzogbG1hcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbbG1h cF0gUHJvcG9zZWQgTE1BUCBDaGFydGVyDQo+DQo+IExldCdzIGRpc2N1c3MgcG9zc2libGUgY2hh cnRlciBsYW5ndWFnZSBmb3IgdGhlIHByb3Bvc2VkIExNQVAgd29yay4gIEF0DQo+IHRoaXMgcG9p bnQsIElNTywgd2Ugc2hvdWxkIHByb3Bvc2UgYSBjaGFydGVyIGZvciB0aGUgd29yayB0aGF0IGNv dWxkIGVpdGhlcg0KPiBiZSBhZGRlZCB0byBhbiBleGlzdGluZyBXRydzIGNoYXJ0ZXIsIG9yIHN0 YW5kYWxvbmUgYXMgYSBXRyBjaGFydGVyLiANCj4gVGhhdCdzIGFuIEFEIGRlY2lzaW9uLiAgQSBm b2xsb3ctb24gZGlzY3Vzc2lvbiB0byB0aGlzIHdvdWxkIG9idmlvdXNseSBiZQ0KPiB0aGUgb3V0 cHV0IGRvY3VtZW50cyBhbmQgbWlsZXN0b25lcy4NCj4NCj4gSGVyZSBpcyBhIHN0cmF3bWFuIHRv IHN0YXJ0IHdpdGggLQ0KPg0KPiAiDQo+IE1lYXN1cmluZyBicm9hZGJhbmQgc2VydmljZSBvbiBh IGxhcmdlIHNjYWxlIGlzIGltcG9ydGFudCBmb3IgbmV0d29yaw0KPiBkaWFnbm9zdGljcyBieSBw cm92aWRlcnMgYW5kIHVzZXJzLCBhcyB3ZWxsIGZvciBwdWJsaWMgcG9saWN5LiAgVG8gY29uZHVj dA0KPiBzZXJ2aWNlIG1lYXN1cmVtZW50cywgdXNlciBuZXR3b3JrcyBnYXRoZXIgZGF0YSwgZWl0 aGVyIG9uIHRoZWlyIG93bg0KPiBpbml0aWF0aXZlIG9yIGluc3RydWN0ZWQgYnkgYSBtZWFzdXJl bWVudCBjb250cm9sbGVyLCBhbmQgdGhlbiB1cGxvYWQgdGhlDQo+IG1lYXN1cmVtZW50IHJlc3Vs dHMgdG8gYSBkZXNpZ25hdGVkIG1lYXN1cmVtZW50IHNlcnZlci4gVGhlcmUgaXMgYSBuZWVkIHRv DQo+IHN0YW5kYXJkaXplIGEgbG9naWNhbCBhcmNoaXRlY3R1cmUgYW5kIGRlc2NyaWJlIGtleSBy ZXF1aXJlbWVudHMgZm9yDQo+IHByb3RvY29scyB0byBjb25uZWN0IHRoZSBjb21wb25lbnRzLiAg QSBsYXJnZS1zY2FsZSBtZWFzdXJlbWVudCBzeXN0ZW0NCj4gbmVlZHMgdG8gc3VwcG9ydCByZXNp ZGVudGlhbCBhbmQgc21hbGwtZW50ZXJwcmlzZSBuZXR3b3JrcywgdXNpbmcgZWl0aGVyDQo+IHdp cmVkIG9yIHdpcmVsZXNzIG5ldHdvcmtzLiBUaGUgYXJjaGl0ZWN0dXJlIG5lZWRzIHRvIGNvbnNp ZGVyIHRoZQ0KPiBtYW5hZ2VtZW50IG9mIHRoZSBhY3RpdmUgYW5kIHBhc3NpdmUgbWVhc3VyZW1l bnRzLg0KPg0KPiBUaGUgTE1BUCB3b3JrIHdpbGwgaW5jbHVkZSBkZXNjcmliaW5nIHZhcmlvdXMg dXNlIGNhc2VzIGNvbnNpZGVyZWQgdG8gYmUNCj4gTGFyZ2UgU2NhbGUgUGVyZm9ybWFuY2UgTWVh c3VyZW1lbnQgc3lzdGVtcywgZGVmaW5lIHRoZSByZXF1aXJlbWVudHMgb2YgdGhlDQo+IG1hbmFn ZW1lbnQgb2YgdGhlc2Ugc3lzdGVtcywgYW5kIGZpbmFsbHkgZGVmaW5lIHRoZSBtYW5hZ2VtZW50 DQo+IGNvbW11bmljYXRpb24gYXJjaGl0ZWN0dXJlIGFuZCBwcm90b2NvbHMuDQo+DQo+IFRoaXMg d29yayB3aWxsIGFsc28gaW5jbHVkZSBkaXNjdXNzaW9ucyBhYm91dCB0aGUgcHJpdmFjeSBhbmQg c2VjdXJpdHkNCj4gY29uY2VybnMgYW5kIHdpbGwgYWRkcmVzcyB0aGVtIHdpdGhpbiBpdHMgZG9j dW1lbnRzLiAiDQo+DQo+IEZpcmUgYXdheSENCj4NCj4gLU1hcmMgTGluc25lci0NCg0KDQoNCi0t IA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KRGlwbC4tSW5nLiBNaXJqYSBLw7xobGV3aW5kDQpJbnN0aXR1dGUgb2Yg Q29tbXVuaWNhdGlvbiBOZXR3b3JrcyBhbmQgQ29tcHV0ZXIgRW5naW5lZXJpbmcgKElLUikNClVu aXZlcnNpdHkgb2YgU3R1dHRnYXJ0LCBHZXJtYW55DQpQZmFmZmVud2FsZHJpbmcgNDcsIEQtNzA1 NjkgU3R1dHRnYXJ0DQoNCnRlbDogKzQ5KDApNzExLzY4NS02Nzk3Mw0KZW1haWw6IG1pcmphLmt1 ZWhsZXdpbmRAaWtyLnVuaS1zdHV0dGdhcnQuZGUNCndlYjogd3d3Lmlrci51bmktc3R1dHRnYXJ0 LmRlDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KbG1hcCBtYWlsaW5nIGxpc3QNCmxtYXBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1hcA== ------=_001_NextPart248048343073_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Thanks for Mirja's point. Usually, the = bottleneck links in internet are those cross= -ISP links. If the collector and the MA=  are in different ISPs, the measurement = ;traffic from MAs to collectors will bring&n= bsp;huge pressure to the already busy cross-= ISP links. So how to reduce the cross-I= SP measurement traffic while not reducing th= e measurement accuracy may be a challenging&= nbsp;problem that needs more consideration.=20
 
Guangqing=20 Deng
CNNIC 
 
From: philip.eardley@bt.com
Date: 2013-01-29 01:16
To: mirja.kuehlewind@ikr= .uni-stuttgart.de;=20 lmap@ietf.org
CC: trevor.burbridge
Subject: Re: [lmap] measurement traffic load [was: Re: Pr= oposed=20 LMAP Charter]
This is a good point.
Most usually the Controller will select = ;a subset of the Measurement Agents, and&nbs= p;instruct them to collect measurements according=  to some schedule ('measure download speed&n= bsp;once an hour'). The other MAs won't = ;be making measurements - otherwise as you&n= bsp;say the internet will be dominated by&nb= sp;measurement traffic! This is fine where t= he operator or regulator is interested in&nb= sp;averages-across-lines (eg to compare one ISP&n= bsp;against another)
 
Because (hopefully) all home hubs etc i= nclude MA functionality, if a customer repor= ts problems, then the Controller can tell&nb= sp;the relevant MA to run some specific = ;tests. This is the new bit that would&= nbsp;be great.
 
Also, think the default case is to = ;report the raw measurement. But eg some&nbs= p;IPPM metrics define a "statistic" as well&= nbsp;as a "singleton" measurement result - s= o that might be reported instead. 
 
phil 
 
 
-----Original Message-----
From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.un= i-stuttgart.de] 
Sent: 28 January 2013 17:06
To: lmap@ietf.org
Cc: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8&= nbsp;R
Subject: measurement traffic load [was: Re:&= nbsp;Proposed LMAP Charter]
 
Hi everybody,
 
thanks Phil for this really good propos= al. I agreed that it is import to = scope down the initial work to a well&n= bsp;defined scenario and focus on basic prot= ocol functionality.
 
Regarding the text below and also follo= wing the discussion on data processing, I&nb= sp;would like to add one comment and ma= ybe can some feedback from people how a= lready have experience with large scale meas= urements:
 
For me the proposal seem to produce&nbs= p;a huge amount of data. We envision a&= nbsp;MA in basically every home network, the= re are frequent test scheduled by one o= r more 'parties' and there is all the&n= bsp;raw data which needs to be transmitted&n= bsp;to the collector. Thinking about this I&= nbsp;afraid that most of our future Internet=  traffic will be the measurement (and c= ollection) traffic itself. Maybe this issue = is out of scope for the actual work&nbs= p;group focus, but I guess it's worth t= hink about this when defining the architectu= re/scenarios and protocols.
 
Mirja
 
 
On Wednesday 23 January 2013 10:54:39 p= hilip.eardley@bt.com wrote:
> Thanks Marc. We're very interested = ;in discussing a potential charter.
> One thing we think is worth t= rying to do is to simplify the proposed=  work
> as much as possible, as the p= otential scope is big. Of course this c= ould be
> done entirely as part of the = WG's work, but doing this beforehand would
> enable a more rapid start. Below&n= bsp;is our attempt to suggest some simplifyi= ng
> assumptions. Each of the simplifying&nb= sp;assumptions  has some penalty, so it
> would be great to hear whether&nbs= p;people think they're reasonable, or
> over-restrict the use case that yo= u have in mind. If it's helpful we = ;could
> write up the architectural assumptions&= nbsp;in an I-D - co-authors very welcome.
> So a key question is whether = the prospective WG should start with a = phase
> of reaching consensus on architecture&n= bsp;and choosing starting protocols, or
> whether we can reach enough consen= sus before the next IETF to move straig= ht
> to standards work. I'm not sure&nb= sp;that we can decide this right now, a= s it
> depends on how the discussion goes=  over the next month or so. There = are
> some work items below that might&n= bsp;apply in the latter case. --
> Measuring broadband service on a l= arge scale is important for network
> diagnostics by providers and users,&nbs= p;as well for public policy.  {Comment:
> operators may want measurement to = help network planning and network mgt
> like fault identification; not sure&nbs= p;whether this needs explicitly noting.} 
> To conduct service measurements, Measur= ement Agents (MAs) on user networks
> gather data, either on their own&n= bsp;initiative or instructed by a Controller,
> and then upload the measurement re= sults to a designated Collector.
> Currently measurement platforms contain = ;up to a few thousand MAs. However,
> the vision is that MAs could = potentially be embedded in every home hub,
> cable modem, enterprise edge router,&nb= sp;set top box, smartphone and so on.
> Standards will help this capability&nbs= p;be more pervasive, manageable and
> directly comparable. RFCs from the = ;IPPM WG define how to measure metrics = -
> requests to define new tests shoul= d be handled by IPPM. These tests
> effectively define the communications b= etween a MA and Test Server.
> {Comment: there are likely new met= rics that need to be defined (eg latenc= y
> under load) or tests under new&nbs= p;conditions (eg current test for speed may<= /DIV>
> not scale well to high line s= peeds).} . In a few cases the IPPM = ;definition
> may need to be extended to mo= ve results data from the Test Server to=  the MA
> for later reporting. The LMAP WG&n= bsp;makes the following architectural
> assumptions - in order to make&nbs= p;rapid progress with an acceptable loss of<= /DIV>
> generality:-
>
> *         We&n= bsp;assume that Measurement Agent, tests Controll= er and results
> Collector are all under control of=  same organisation (eg Samknows, FCC,
> BT). Reason: Inter-organisation interactions=  (for example to share results)
> is better handled by business-level&nbs= p;negotiation than a control protocol.
>
> *         We&n= bsp;assume the MA initiates a measurement. R= easons: having the
> test schedule on MA avoids it = ;having to check frequently with the
> Controller; it is easier if the&nb= sp;MA is behind a NAT; and the MA = knows
> whether the user is active and&nbs= p;therefore whether to run test or delay&nbs= p;it.
>
> *         We&n= bsp;assume measurement results are sent from = ;MA, and not from test
> server. Reason-1: It is easier to&= nbsp;secure the MA to Collector communication.
> One implication is that for an&nbs= p;upload test measured by the test server,&n= bsp;the
> result is reported back to the&nbs= p;MA which reports it in turn. Reason-2:&nbs= p;Test
> servers may be controlled by a&nbs= p;third party ('load time for IETF home
> page').
>
> *         We&n= bsp;assume no negotiation is needed between = Controller and MA. The
> Controller already knows the characteri= stics of the MA, for instance via
> TR069 for Broadband Forum devices. = ;The Controller simply instructs
> (securely) the MA "Measure this"; = the MA replies "OK /error".
>
> *         Simi= larly we assume no negotiation is needed&nbs= p;between the MA and
> Collector. The protocol simply delivers=  (securely) the measurement results
> from the MA to the Collector, = ;and returns an ack or error code.
>
> *         We&n= bsp;assume each MA is controlled by only&nbs= p;one Controller. Reason:
> to avoid different Controllers giving&n= bsp;the MA conflicting schedules. Note: a
> measurement platform may have several&n= bsp;Controllers, with each Controller
> controlling a subset of the MAs,&n= bsp;for example one controlling wireline MAs
> and one mobile MAs.
>
> *         We&n= bsp;assume the raw measurement results are r= eported; filtering
> /averaging of measuremnts by the M= A is not in the initial scope, except&n= bsp;as
> defined by IPPM as part of th= e metric definition.
>
> *         We&n= bsp;assume that uploading a new test capabil= ity to the MA is out
> of scope. This can be done as=  a firmware upgrade for home hub, or&nb= sp;new app
> for PC, etc.
>
> *         We&n= bsp;assume as out of scope a network pa= rameter server (which
> stores nominal values such as the&= nbsp;contractual data rate). The functional
> role of the Network Paraemeter Ser= ver may be fulfilled by existing OSS
> (such as network or home gateway&n= bsp;management systems). Interfaces to the NPS
> are pre-measurement (used by the C= ontroller to decide which tests to
> schedule) or post-measurement (used to&= nbsp;analyse the measurement data).
>
> *         We&n= bsp;assume data filtering is out of the = ;initial scope. Filtering
> includes: removal of outlier measuremen= ts, archiving (curating) data for
> scientific research, and so on. Th= ere are certainly some aspects where best
> practice would be useful but data&= nbsp;filtering is not a first priority.
>
> *         We&n= bsp;assume that data privacy issues are out&= nbsp;of scope although
> security is considered. The MA, Co= ntroller and Collector are all under
> control of the same organisation. = IPPM considers the implications of any
> passive measurement tests that it = defines. The LMAP WG standardises the
> following items:
>
> 1.      The data mo= del that defines the test schedule, which&nb= sp;includes:
>
> a.      The IPPM me= tric to be tested and values for its&nb= sp;parameters.
> {Question: is the restriction to I= PPM OK? Ie non-IPPM tests are out of
> scope}
>
> b.      Test schedule:&n= bsp;when the test should be done and ho= w often repeated
> ('once an hour at xx.03'). A = test may also be a one-off, done immedi= ately
> on demand.
>
> c.       Output par= ameters: some IPPM metrics may define a = ;choice of
> outputs
>
> d.      Test Server:&nbs= p;which server or servers should be used&nbs= p;for the test
>
> e.      Environmental co= nditions: such as 'no user traffic' which&nb= sp;means a
> particular instance of the test is=  delayed or abandoned.
>
> f.        (perhaps)=  Metadata: such as a mobile's location = when the test
> should be made, the line's nominal=  rate etc. There may be privacy
> implications for the scenario where&nbs= p;the measurement plaform is not
> controlled by the operator; the in= itial scope will exclude this scenario.
>
> g.      (perhaps) Metada= t to report: for example, the MA may&nb= sp;be able to
> measure Layer 1 o 2 charcteristics=  such as DSL sync speed and interleavin= g;
> the actual test is out of sco= pe. As for the previous bullet, there m= ay be
> privacy implications for the general&nb= sp;scenario, which we exclude from the
> initial scope.
>
> h.      (perhaps) Priori= ty: the Controller decides which tests are&n= bsp;done
> when. However a test might get&nbs= p;delayed until it overlaps with another
> scheduled test - which should be&n= bsp;done (or done first)? Or should it = simply
> be abandoned?
>
> 2.       The data&n= bsp;model that defines how an MA should = ;report test results.
> This may be combined with (1) = ;above or specified as a separate reporting<= /DIV>
> schedule. This includes:
>
> a.       Where to&n= bsp;report results to (one or more Collector= s)
>
> b.      How often t= o report results for the different tests
>
> c.       What to&nb= sp;do when Collector is not available (fail-= over, try again)
>
> 3.      The data mo= del that defines the report, which includes:=
>
> a.      The metric = that was measured
>
> b.      The time of=  the test
>
> c.       Whether th= e test is scheduled, one-off triggered by&nb= sp;the
> Controller, or user-initiated
>
> d.      The measurement&= nbsp;result - usually several results are ba= tched
> together; the result of a one-off&= nbsp;test may be wanted immediately
>
> e.      (perhaps) Metada= ta, such as the mobile's location
>
> f.        Comment:&= nbsp;it would make sense to use the sam= e language as for 1,
> for instance XML, YANG...
>
> 4.      The application&= nbsp;level protocol for the (secure) delivery&nbs= p;of the
> test and reporting schedule (#1, #= 2)
>
> a.      A simple in= struction - response protocol, with error co= des defined
>
> b.      LMAP could = specify how it operates over one existing&nb= sp;protocol (REST
> style HTTP(s), Netconf...)
>
> 5.      The application&= nbsp;level protocol for the (secure) delivery&nbs= p;of the
> report (#3)
>
> a.      Same comments&nb= sp;as for #4
>
> 6.      A document = explaining the simplifying architectural assumptions&n= bsp;in
> more detail. This document could a= lso define some terminology and explain
> the use cases. Looking forward to&= nbsp;the discussion,
> Best wishes,
> Trevor and Phil
> From: lmap-bounces@ietf.org [mailto:lmap-bounces@= ietf.org] On Behalf Of
> Marc Linsner Sent: 18 January 2013=  20:48
> To: lmap@ietf.org
> Subject: [lmap] Proposed LMAP Charter
>
> Let's discuss possible charter language=  for the proposed LMAP work.  At
> this point, IMO, we should propose=  a charter for the work that could = ;either
> be added to an existing WG's = charter, or standalone as a WG charter. = ;
> That's an AD decision.  A fol= low-on discussion to this would obviously be=
> the output documents and milestones.
>
> Here is a strawman to start w= ith -
>
> "
> Measuring broadband service on a l= arge scale is important for network
> diagnostics by providers and users,&nbs= p;as well for public policy.  To conduc= t
> service measurements, user networks gat= her data, either on their own
> initiative or instructed by a meas= urement controller, and then upload the
> measurement results to a designated&nbs= p;measurement server. There is a need to
> standardize a logical architecture and&= nbsp;describe key requirements for
> protocols to connect the components.&nb= sp; A large-scale measurement system
> needs to support residential and s= mall-enterprise networks, using either
> wired or wireless networks. The ar= chitecture needs to consider the
> management of the active and passi= ve measurements.
>
> The LMAP work will include describ= ing various use cases considered to be
> Large Scale Performance Measurement sys= tems, define the requirements of the
> management of these systems, and f= inally define the management
> communication architecture and protocols.
>
> This work will also include discus= sions about the privacy and security
> concerns and will address them wit= hin its documents. "
>
> Fire away!
>
> -Marc Linsner-
 
 
 
-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja K=C3=BChlewind
Institute of Communication Networks and Comp= uter Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart
 
tel: +49(0)711/685-67973
email: mirja.kuehlewind@ikr.uni-stuttgart.de
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------
_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap
------=_001_NextPart248048343073_=------ From mlinsner@cisco.com Wed Jan 30 06:21:36 2013 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 1B96921F8B3F for ; Wed, 30 Jan 2013 06:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.135 X-Spam-Level: X-Spam-Status: No, score=-9.135 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwUQLg5hkEWY for ; Wed, 30 Jan 2013 06:21:35 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8096621F8B36 for ; Wed, 30 Jan 2013 06:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1084; q=dns/txt; s=iport; t=1359555695; x=1360765295; h=date:subject:from:to:message-id:mime-version; bh=i+XPbOF70Ha3hF4TYp6fazop7zsAGlbkOHCMrJH51f8=; b=FtQ5/J7fCIaJVz/qtZj7eFC92/7kdlkWdNTRZxYw2FDwt1LJhkowBRli OAQqFahODo4KTPWWPoaSC5SQ+gYDJI62qORBqJla8MgcrRgxfPMRfzLBC waYGh0HtMi7R8pK95QkYmUH/RzMELXHK0jB52cmEwNOyhdSO4nlR+JD+g o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkIAAgsCVGtJXG+/2dsb2JhbABFgkmDN4FirhMLB4gmZxZzghUQPU8LAQKBHYgkDKAdoS2NYYMpA4hhjSyBHIRSil2DFQ X-IronPort-AV: E=Sophos;i="4.84,569,1355097600"; d="scan'208,217";a="170480499" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jan 2013 14:21:28 +0000 Received: from [10.116.195.114] (rtp-mlinsner-8711.cisco.com [10.116.195.114]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0UELQqt025989 for ; Wed, 30 Jan 2013 14:21:27 GMT User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Wed, 30 Jan 2013 09:21:25 -0500 From: Marc Linsner To: Message-ID: Thread-Topic: BOF Request Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3442382487_258568" Subject: [lmap] BOF Request X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2013 14:21:36 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3442382487_258568 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit We submitted a request for a session at Orlando. The AD telechat is tomorrow. http://trac.tools.ietf.org/bof/trac/wiki#OperationsandManagement -Marc- --B_3442382487_258568 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
We submitted a request for a= session at Orlando.  The AD telechat is tomorrow.

=
http://trac.tools.ietf.org/bof/trac/wiki#OperationsandManagement

-Marc-
--B_3442382487_258568-- From dromasca@avaya.com Wed Jan 30 06:31:20 2013 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 E278021F8B65 for ; Wed, 30 Jan 2013 06:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.925 X-Spam-Level: X-Spam-Status: No, score=-102.925 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Br6g-l4-FNWz for ; Wed, 30 Jan 2013 06:31:20 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id BB7E721F8B64 for ; Wed, 30 Jan 2013 06:31:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAP0QA1HGmAcF/2dsb2JhbABFgkgjskyJGxZzgh4BAQEBAxIbXAIBCA0BAwQBAQsdBzIUCQgCBAESCBqHbQELoVicdJBeYQOXKYRxijuCd4Ik X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208,217";a="46579469" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 30 Jan 2013 09:30:36 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Jan 2013 09:30:35 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Wed, 30 Jan 2013 09:31:35 -0500 From: "Romascanu, Dan (Dan)" To: Marc Linsner , "lmap@ietf.org" Thread-Topic: BOF Request Thread-Index: AQHN/vUtfoYVvaVRx0Gd0JQVjLF4gZhh7rMA Date: Wed, 30 Jan 2013 14:31:35 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA07AA5F@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA07AA5FAZFFEXMB04globala_" MIME-Version: 1.0 Subject: Re: [lmap] BOF Request X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2013 14:31:21 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA07AA5FAZFFEXMB04globala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually it's http://trac.tools.ietf.org/bof/trac/wiki#Transport isn't it? Dan From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Mar= c Linsner Sent: Wednesday, January 30, 2013 4:21 PM To: lmap@ietf.org Subject: [lmap] BOF Request We submitted a request for a session at Orlando. The AD telechat is tomorr= ow. http://trac.tools.ietf.org/bof/trac/wiki#OperationsandManagement -Marc- --_000_9904FB1B0159DA42B0B887B7FA8119CA07AA5FAZFFEXMB04globala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually it’s

 <= /p>

http://trac.tools.ietf.org/bof/trac/wik= i#Transport

 

isn’t it?

 <= /p>

Dan

 <= /p>

From: lmap-bou= nces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Marc Linsner
Sent: Wednesday, January 30, 2013 4:21 PM
To: lmap@ietf.org
Subject: [lmap] BOF Request

 

We submitted a request for = a session at Orlando.  The AD telechat is tomorrow.<= /p>

 

 

-Marc-

--_000_9904FB1B0159DA42B0B887B7FA8119CA07AA5FAZFFEXMB04globala_-- From Martin.Stiemerling@neclab.eu Wed Jan 30 06:49:09 2013 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 66B2621F898A for ; Wed, 30 Jan 2013 06:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.409 X-Spam-Level: X-Spam-Status: No, score=-103.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0x0obQteD-HS for ; Wed, 30 Jan 2013 06:49:08 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A616D21F8964 for ; Wed, 30 Jan 2013 06:49:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 143B8102F9A for ; Wed, 30 Jan 2013 15:49:08 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otTzfWVwVUX6 for ; Wed, 30 Jan 2013 15:49:08 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id ECCA1102F97 for ; Wed, 30 Jan 2013 15:49:02 +0100 (CET) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 30 Jan 2013 15:49:01 +0100 Message-ID: <510932DE.8050300@neclab.eu> Date: Wed, 30 Jan 2013 15:49:02 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <9904FB1B0159DA42B0B887B7FA8119CA07AA5F@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA07AA5F@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.1.1.190] Subject: Re: [lmap] BOF Request X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2013 14:49:09 -0000 On 01/30/2013 03:31 PM, Romascanu, Dan (Dan) wrote: > Actually it’s > > http://trac.tools.ietf.org/bof/trac/wiki#Transport > > isn’t it? Right, at least for now until we have figured out if this lives in Transport or OPS. Martin > > Dan > > *From:*lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] *On Behalf > Of *Marc Linsner > *Sent:* Wednesday, January 30, 2013 4:21 PM > *To:* lmap@ietf.org > *Subject:* [lmap] BOF Request > > We submitted a request for a session at Orlando. The AD telechat is > tomorrow. > > http://trac.tools.ietf.org/bof/trac/wiki#OperationsandManagement > > -Marc- > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From yaojk@cnnic.cn Wed Jan 30 07:41:18 2013 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 C790221F8A9B for ; Wed, 30 Jan 2013 07:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.996 X-Spam-Level: X-Spam-Status: No, score=-97.996 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxW5gj9joGZq for ; Wed, 30 Jan 2013 07:41:18 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 1791F21F8A89 for ; Wed, 30 Jan 2013 07:41:15 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO [10.200.189.43]) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 30 Jan 2013 23:41:05 +0800 From: yaojk@cnnic.cn To: Marc Linsner , Date: Wed, 30 Jan 2013 23:45:33 +0800 Message-ID: <4K0DmrJTJFKz.M6pbQwHk@smtp2.cnnic.cn> X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [lmap] =?utf-8?b?5Zue5aSN77yaICBCT0YgUmVxdWVzdA==?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2013 15:41:18 -0000 Good news=EF=BC=81 I strongly support it. Many things have been done in many organizations such as CNNIC. Standardazation is a good direction=EF=BC=81 Jiankang Yao -----=E5=8E=9F=E4=BF=A1=E6=81=AF----- =E5=8F=91=E8=87=AA=EF=BC=9A Marc Linsner =E5=8F=91=E9=80=81=EF=BC=9A 2013/01/30, 22:21=20 =E6=94=B6=E4=BB=B6=E4=BA=BA: lmap@ietf.org =E4=B8=BB=E9=A2=98=EF=BC=9A [lmap] BOF Request From mlinsner@cisco.com Wed Jan 30 09:43:01 2013 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 539EE21F87B3 for ; Wed, 30 Jan 2013 09:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.152 X-Spam-Level: X-Spam-Status: No, score=-9.152 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVvDHAlKUYPP for ; Wed, 30 Jan 2013 09:43:00 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C33A021F84B6 for ; Wed, 30 Jan 2013 09:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1317; q=dns/txt; s=iport; t=1359567780; x=1360777380; h=date:subject:from:to:message-id:mime-version; bh=zK2sUIQcILIWZ0VmBfpSIKqBz8bagJ5ibkCzwXrB81M=; b=l25P5M2gzwTCWiu++jZ5KwBbYnSBL8b7KWJPR43TGRvq+V+bwr+o8zsm raWeP2RafcTJyHJ/1v7Ghy+AdUft1tpKoIiF0npssmisDdf92zqT/2iiE 9YGvYHFpTwadAfzVS0w9RR2bhnJ6NJxiELDl5dsuvNblyvxN+eCV+AJoG Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAlaCVGtJXHB/2dsb2JhbABFgkm8RRZzghUQPU8LAQ59FIgkoGihMo1jgykDiGGNLIVuil2DFQ X-IronPort-AV: E=Sophos;i="4.84,569,1355097600"; d="scan'208,217";a="170610944" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 30 Jan 2013 17:42:54 +0000 Received: from [10.116.195.114] (rtp-mlinsner-8711.cisco.com [10.116.195.114]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0UHgqZm027647 for ; Wed, 30 Jan 2013 17:42:53 GMT User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Wed, 30 Jan 2013 12:42:51 -0500 From: Marc Linsner To: Message-ID: Thread-Topic: IPFIX vs LMAP Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3442394573_1029337" Subject: [lmap] IPFIX vs LMAP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2013 17:43:01 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3442394573_1029337 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Can someone familiar with IPFIX contrast, in a few sentences, the differences between it and LMAP? Can IPFIX be made tweaked to fulfill the LMAP requirements? I'm asking as I'm not familiar with IPFIX and know I'll miss something trying to read that architecture. Thanks, -Marc- --B_3442394573_1029337 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Can someone familiar with IP= FIX contrast, in a few sentences, the differences between it and LMAP?
=

Can IPFIX be made tweaked to fulfill the LMAP requiremen= ts?

I'm asking as I'm not familiar with IPFIX and k= now I'll miss something trying to read that architecture.

Thanks,

-Marc-
--B_3442394573_1029337-- From j.schoenwaelder@jacobs-university.de Wed Jan 30 10:12:17 2013 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 E994F21F84C2 for ; Wed, 30 Jan 2013 10:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.137 X-Spam-Level: X-Spam-Status: No, score=-103.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkX38Rf-ZRDp for ; Wed, 30 Jan 2013 10:12:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFF021F8480 for ; Wed, 30 Jan 2013 10:12:16 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BC4321B6C; Wed, 30 Jan 2013 19:12:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rRnTYa_Ac6Un; Wed, 30 Jan 2013 19:12:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAB1B21B27; Wed, 30 Jan 2013 19:12:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 08BD02449429; Wed, 30 Jan 2013 19:12:18 +0100 (CET) Date: Wed, 30 Jan 2013 19:12:18 +0100 From: Juergen Schoenwaelder To: Marc Linsner Message-ID: <20130130181218.GA21225@elstar.local> Mail-Followup-To: Marc Linsner , lmap@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: lmap@ietf.org Subject: Re: [lmap] IPFIX vs LMAP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 18:12:18 -0000 On Wed, Jan 30, 2013 at 12:42:51PM -0500, Marc Linsner wrote: > Can someone familiar with IPFIX contrast, in a few sentences, the > differences between it and LMAP? > > Can IPFIX be made tweaked to fulfill the LMAP requirements? > > I'm asking as I'm not familiar with IPFIX and know I'll miss something > trying to read that architecture. My understanding is that LMAP is not a protocol. LMAP may make use of say existing protocols such as IPFIX for shipping measurement results and it may make use of other existing protocols to lets say configure test schedules. That said, the LMAP effort may lead to extension of existing protocols (e.g. new LMAP specific IPFIX information elements, new LMAP specific data models, new IPPM metrics, ...). It is not clear at this point in time that LMAP needs to spin its own protocol. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From yaojk@cnnic.cn Wed Jan 30 19:45:20 2013 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 8990E21F84D7 for ; Wed, 30 Jan 2013 19:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.346 X-Spam-Level: X-Spam-Status: No, score=-98.346 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_93=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB2OhPOQo2z0 for ; Wed, 30 Jan 2013 19:45:20 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 89C3721F84BA for ; Wed, 30 Jan 2013 19:45:16 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 31 Jan 2013 11:45:10 +0800 Message-ID: <9BD4DA72C6214364A07889F73338342A@LENOVO47E041CF> From: "Jiankang YAO" To: "Juergen Schoenwaelder" , "Marc Linsner" References: <20130130181218.GA21225@elstar.local> Date: Thu, 31 Jan 2013 11:45:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: lmap@ietf.org Subject: Re: [lmap] IPFIX vs LMAP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 03:45:20 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkp1ZXJnZW4gU2Nob2Vud2Fl bGRlciIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NClRvOiAiTWFyYyBM aW5zbmVyIiA8bWxpbnNuZXJAY2lzY28uY29tPg0KQ2M6IDxsbWFwQGlldGYub3JnPg0KU2VudDog VGh1cnNkYXksIEphbnVhcnkgMzEsIDIwMTMgMjoxMiBBTQ0KU3ViamVjdDogUmU6IFtsbWFwXSBJ UEZJWCB2cyBMTUFQDQoNCg0KPiBPbiBXZWQsIEphbiAzMCwgMjAxMyBhdCAxMjo0Mjo1MVBNIC0w NTAwLCBNYXJjIExpbnNuZXIgd3JvdGU6DQo+PiBDYW4gc29tZW9uZSBmYW1pbGlhciB3aXRoIElQ RklYIGNvbnRyYXN0LCBpbiBhIGZldyBzZW50ZW5jZXMsIHRoZQ0KPj4gZGlmZmVyZW5jZXMgYmV0 d2VlbiBpdCBhbmQgTE1BUD8NCj4+IA0KPj4gQ2FuIElQRklYIGJlIG1hZGUgdHdlYWtlZCB0byBm dWxmaWxsIHRoZSBMTUFQIHJlcXVpcmVtZW50cz8NCj4+IA0KPj4gSSdtIGFza2luZyBhcyBJJ20g bm90IGZhbWlsaWFyIHdpdGggSVBGSVggYW5kIGtub3cgSSdsbCBtaXNzIHNvbWV0aGluZw0KPj4g dHJ5aW5nIHRvIHJlYWQgdGhhdCBhcmNoaXRlY3R1cmUuDQo+IA0KPiBNeSB1bmRlcnN0YW5kaW5n IGlzIHRoYXQgTE1BUCBpcyBub3QgYSBwcm90b2NvbC4NCj4gDQo+IExNQVAgbWF5IG1ha2UgdXNl IG9mIHNheSBleGlzdGluZyBwcm90b2NvbHMgc3VjaCBhcyBJUEZJWCBmb3Igc2hpcHBpbmcNCj4g bWVhc3VyZW1lbnQgcmVzdWx0cyBhbmQgaXQgbWF5IG1ha2UgdXNlIG9mIG90aGVyIGV4aXN0aW5n IHByb3RvY29scyB0bw0KPiBsZXRzIHNheSBjb25maWd1cmUgdGVzdCBzY2hlZHVsZXMuDQo+IA0K DQpteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgTE1BUCBtYXkgdXNlIHNvbWUgZXhpc3RpbmcgcHJv dG9jb2xzLGJ1dCB3aWxsIGNyZWF0ZSBpdHMgb3duIHN0dWZmLg0KSXQgaXMgZ29vZCB0byBjcmVh dGUgdGhlIHByb3RvY29sIGZvciBMTUFQLg0KDQpKaWFua2FuZyBZYW8NCg0KPiBUaGF0IHNhaWQs IHRoZSBMTUFQIGVmZm9ydCBtYXkgbGVhZCB0byBleHRlbnNpb24gb2YgZXhpc3RpbmcgcHJvdG9j b2xzDQo+IChlLmcuIG5ldyBMTUFQIHNwZWNpZmljIElQRklYIGluZm9ybWF0aW9uIGVsZW1lbnRz LCBuZXcgTE1BUCBzcGVjaWZpYw0KPiBkYXRhIG1vZGVscywgbmV3IElQUE0gbWV0cmljcywgLi4u KS4gSXQgaXMgbm90IGNsZWFyIGF0IHRoaXMgcG9pbnQgaW4NCj4gdGltZSB0aGF0IExNQVAgbmVl ZHMgdG8gc3BpbiBpdHMgb3duIHByb3RvY29sLg0KPiANCj4gL2pzDQo+IA0KPiAtLSANCj4gSnVl cmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dt YkgNCj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxLCAyODc1 OSBCcmVtZW4sIEdlcm1hbnkNCj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0 cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IGxtYXAgbWFpbGluZyBsaXN0DQo+IGxtYXBAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sbWFw From trammell@tik.ee.ethz.ch Wed Jan 30 23:00:24 2013 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 E997A21F86B1 for ; Wed, 30 Jan 2013 23:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLuLYBUmmf9q for ; Wed, 30 Jan 2013 23:00:23 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 844FB21F86B7 for ; Wed, 30 Jan 2013 23:00:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4E406D9312; Thu, 31 Jan 2013 08:00:16 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fn4renPMUkeH; Thu, 31 Jan 2013 08:00:16 +0100 (MET) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E9FA7D9305; Thu, 31 Jan 2013 08:00:15 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: Date: Thu, 31 Jan 2013 08:00:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <003FAA66-CC55-4249-8800-04477250A3DA@tik.ee.ethz.ch> References: To: Marc Linsner X-Mailer: Apple Mail (2.1499) Cc: lmap@ietf.org Subject: Re: [lmap] IPFIX vs LMAP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 07:00:25 -0000 Hi, Mark, all, IPFIX is a push-based data export protocol for network-relevant data = (sampled packets with PSAMP, flows, flow aggregates, etc.). It defines a = set of Information Elements (IEs) = (http://www.iana.org/assignments/ipfix) mainly applicable to layers 2 = through 4, and a binary data export protocol in which record types are = defined through templates (vectors of these IEs).=20 As for IPFIX in LMAP, for any arrangement in which an MA is exporting = data on demand to a collector, and that data is semantically relatively = flat (think tables, not arbitrary trees), it's certainly applicable as a = reporting protocol. When looking at the architecture in RFC5470 in LMAP = terms, the Metering Process and the Exporting Process are the MA, and = the Collecting Process is the collector.=0D RFC6728 defines a configuration data model for IPFIX entities using = NETCONF; I'm not a NETCONF expert though, so it's not clear to me how = easily this could be adapted into a controller-MA protocol for LMAP. There are as yet no bindings between IPFIX and the IPPM metrics, though = we expect IEs to be defined for common IPPM metrics within IPPM, perhaps = based on one of the draft-bagnulo-ippm-new-registry drafts. (Note that = there are already some non-IPPM performance metrics in the registry: IEs = 385-387 use the RFC3550 definition of jitter, instead of IPPM delay = variation.) Best regards, Brian On Jan 30, 2013, at 6:42 PM, Marc Linsner wrote: > Can someone familiar with IPFIX contrast, in a few sentences, the = differences between it and LMAP? >=20 > Can IPFIX be made tweaked to fulfill the LMAP requirements? >=20 > I'm asking as I'm not familiar with IPFIX and know I'll miss something = trying to read that architecture. >=20 > Thanks, >=20 > -Marc- > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From bclaise@cisco.com Thu Jan 31 03:57:28 2013 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 0368A21F8442 for ; Thu, 31 Jan 2013 03:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwPEjXYG1LBO for ; Thu, 31 Jan 2013 03:57:27 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D741521F8432 for ; Thu, 31 Jan 2013 03:57:06 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0VBH021018448; Thu, 31 Jan 2013 12:17:00 +0100 (CET) Received: from [10.55.86.15] (dhcp-10-55-86-15.cisco.com [10.55.86.15]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0VBG9SM028074; Thu, 31 Jan 2013 12:16:24 +0100 (CET) Message-ID: <510A5279.5040906@cisco.com> Date: Thu, 31 Jan 2013 11:16:09 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jiankang YAO References: <20130130181218.GA21225@elstar.local> <9BD4DA72C6214364A07889F73338342A@LENOVO47E041CF> In-Reply-To: <9BD4DA72C6214364A07889F73338342A@LENOVO47E041CF> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marc Linsner , Juergen Schoenwaelder , lmap@ietf.org Subject: Re: [lmap] IPFIX vs LMAP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 11:57:28 -0000 On 31/01/2013 03:45, Jiankang YAO wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "Marc Linsner" > Cc: > Sent: Thursday, January 31, 2013 2:12 AM > Subject: Re: [lmap] IPFIX vs LMAP > > >> On Wed, Jan 30, 2013 at 12:42:51PM -0500, Marc Linsner wrote: >>> Can someone familiar with IPFIX contrast, in a few sentences, the >>> differences between it and LMAP? >>> >>> Can IPFIX be made tweaked to fulfill the LMAP requirements? >>> >>> I'm asking as I'm not familiar with IPFIX and know I'll miss something >>> trying to read that architecture. >> My understanding is that LMAP is not a protocol. >> >> LMAP may make use of say existing protocols such as IPFIX for shipping >> measurement results and it may make use of other existing protocols to >> lets say configure test schedules. >> > my understanding is that LMAP may use some existing protocols,but will create its own stuff. > It is good to create the protocol for LMAP. Why? What is specific to your problem that requires a new protocol? Disclaimer: I'm not up to date with the mailing list and drafts, so maybe I missed it. Regards, Benoit > > Jiankang Yao > >> That said, the LMAP effort may lead to extension of existing protocols >> (e.g. new LMAP specific IPFIX information elements, new LMAP specific >> data models, new IPPM metrics, ...). It is not clear at this point in >> time that LMAP needs to spin its own protocol. >> >> /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 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > From dengguangqing@cnnic.cn Thu Jan 31 05:34:48 2013 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 9509621F86B2 for ; Thu, 31 Jan 2013 05:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.429 X-Spam-Level: X-Spam-Status: No, score=0.429 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGH+OSp9cGSD for ; Thu, 31 Jan 2013 05:34:47 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 173E921F86AE for ; Thu, 31 Jan 2013 05:34:43 -0800 (PST) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO dgq-pc) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 31 Jan 2013 21:34:34 +0800 Date: Thu, 31 Jan 2013 21:34:33 +0800 From: "Guangqing Deng" To: "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA07AA5F@AZ-FFEXMB04.global.avaya.com>, <510932DE.8050300@neclab.eu> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201301312134328526701@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart660876316748_=----" Subject: Re: [lmap] BOF Request X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dengguangqing List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 13:34:48 -0000 This is a multi-part message in MIME format. ------=_001_NextPart660876316748_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 R3JlYXQgbmV3cyEgSSBhbSBpbnRlcmVzdGVkIGluIHRoZSBuZXR3b3JrIG1lYXN1cmVtZW50IGFu ZCBoYXZlIGRvbmUgc2V2ZXJhbCBsYXJnZSBzY2FsZSBtZWFzdXJlbWVudHMgKHRvZ2V0aGVyIHdp dGggbXkgY29sbGVhZ3VlcykgdG93YXJkcyBicm9hZGJhbmQgbmV0d29yayBwZXJmb3JtYW5jZSB3 aXRoIHNldmVyYWwgbWVhc3VyZW1lbnQgY29sbGVjdG9ycywgY29udHJvbGxlcnMgYW5kIG5lYXJs eSA2MCB0aG91c2FuZHMgb2YgbWVhc3VyZW1lbnQgYWdlbnRzIChNQSkuIE9mIGNvdXJzZSwgdGhl IHByb3RvY29sIHVzZWQgdG8gY29ubmVjdCB0aGUgY29tcG9uZW50cyAobmFtZWx5IHRoZSBjb250 cm9sbGVyLCBjb2xsZWN0b3IgYW5kIE1BKSBpcyBwcml2YXRlLiBXaXRoIHNvbWUgZXhwZXJpZW5j ZSBnYWluZWQgZnJvbSBzdWNoIG1lYXN1cmVtZW50cywgSSB3b3VsZCBsaWtlIHRvIGRvIHNvbWUg Y29udHJpYnV0aW9uIHRvIHRoZSBzdGFuZGFyZGl6YXRpb24gb2YgdGhlIG5ldHdvcmsgbWVhc3Vy ZW1lbnQgcHJvdG9jb2wgd2l0aGluIHRoaXMgV0cuDQoNCg0KDQoNCkd1YW5ncWluZyBEZW5nDQpj bm5pYyANCg0KRnJvbTogTWFydGluIFN0aWVtZXJsaW5nDQpEYXRlOiAyMDEzLTAxLTMwIDIyOjQ5 DQpUbzogbG1hcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtsbWFwXSBCT0YgUmVxdWVzdA0KDQoN Ck9uIDAxLzMwLzIwMTMgMDM6MzEgUE0sIFJvbWFzY2FudSwgRGFuIChEYW4pIHdyb3RlOg0KPiBB Y3R1YWxseSBpdJJzDQo+DQo+IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2JvZi90cmFjL3dp a2kjVHJhbnNwb3J0DQo+DQo+IGlzbpJ0IGl0Pw0KDQpSaWdodCwgYXQgbGVhc3QgZm9yIG5vdyB1 bnRpbCB3ZSBoYXZlIGZpZ3VyZWQgb3V0IGlmIHRoaXMgbGl2ZXMgaW4gDQpUcmFuc3BvcnQgb3Ig T1BTLg0KDQogICBNYXJ0aW4NCg0KPg0KPiBEYW4NCj4NCj4gKkZyb206KmxtYXAtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZg0KPiBPZiAq TWFyYyBMaW5zbmVyDQo+ICpTZW50OiogV2VkbmVzZGF5LCBKYW51YXJ5IDMwLCAyMDEzIDQ6MjEg UE0NCj4gKlRvOiogbG1hcEBpZXRmLm9yZw0KPiAqU3ViamVjdDoqIFtsbWFwXSBCT0YgUmVxdWVz dA0KPg0KPiBXZSBzdWJtaXR0ZWQgYSByZXF1ZXN0IGZvciBhIHNlc3Npb24gYXQgT3JsYW5kby4g IFRoZSBBRCB0ZWxlY2hhdCBpcw0KPiB0b21vcnJvdy4NCj4NCj4gaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvYm9mL3RyYWMvd2lraSNPcGVyYXRpb25zYW5kTWFuYWdlbWVudA0KPg0KPiAtTWFy Yy0NCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gbG1hcCBtYWlsaW5nIGxpc3QNCj4gbG1hcEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXANCj4NCg0KLS0gDQptYXJ0aW4uc3RpZW1l cmxpbmdAbmVjbGFiLmV1DQoNCk5FQyBMYWJvcmF0b3JpZXMgRXVyb3BlIC0gTmV0d29yayBSZXNl YXJjaCBEaXZpc2lvbiBORUMgRXVyb3BlIExpbWl0ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMg SG91c2UsIDEgVmljdG9yaWEgUm9hZCwgTG9uZG9uIFczIDZCTA0KUmVnaXN0ZXJlZCBpbiBFbmds YW5kIDI4Mw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CmxtYXAgbWFpbGluZyBsaXN0DQpsbWFwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2xtYXA= ------=_001_NextPart660876316748_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Great news! I am interes= ted in the=20 network measurement and have done several large scale measurements (togeth= er=20 with my colleagues) towards broadband network performance with several=20 measurement collectors, controllers and nearly 60 thousands of measurement= =20 agents (MA). Of course, the protocol used to connect the components (namel= y the=20 controller, collector and MA) is private. With some experience gained from= such=20 measurements, I would like to do some contribution to the standardization = of the=20 network measurement protocol within this=20 WG.

 
Gua= ngqing=20 Deng
cnnic 
 
Date: 2013-01-30 22:49
To: lmap@ietf.org
Subject: Re: [lmap] BOF Request
 
 
On 01/30/2013 03:31 PM, Romascanu, Dan = (Dan) wrote:
> Actually it=92s
>
> http://trac.tools.ietf.org/bof/trac/wiki#Transport
>
> isn=92t it?
 
Right, at least for now until we h= ave figured out if this lives in 
Transport or OPS.
 
   Martin
 
>
> Dan
>
> *From:*lmap-bounces@ietf.org [mailto:lmap-bounces@ietf= .org] *On Behalf
> Of *Marc Linsner
> *Sent:* Wednesday, January 30, 2013&nbs= p;4:21 PM
> *To:* lmap@ietf.org
> *Subject:* [lmap] BOF Request
>
> We submitted a request for a = session at Orlando.  The AD telechat is=
> tomorrow.
>
> http://trac.tools.ietf.org/bof/trac/wiki#OperationsandManag= ement
>
> -Marc-
>
>
>
> _______________________________________________
> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap
>
 
-- 
martin.stiemerling@neclab.eu
 
NEC Laboratories Europe - Network Research&n= bsp;Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria&nbs= p;Road, London W3 6BL
Registered in England 283
_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap
------=_001_NextPart660876316748_=------ From marcelo@it.uc3m.es Thu Jan 31 06:05:00 2013 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 95E8121F86BC for ; Thu, 31 Jan 2013 06:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Mvc1+6Hkn79 for ; Thu, 31 Jan 2013 06:04:59 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 67AD421F8659 for ; Thu, 31 Jan 2013 06:04:59 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B56D889483B for ; Thu, 31 Jan 2013 15:04:57 +0100 (CET) X-uc3m-safe: yes Received: from dummyhost23.it.uc3m.es (unknown [163.117.139.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id A8ED376B24C for ; Thu, 31 Jan 2013 15:04:57 +0100 (CET) Message-ID: <510A7A09.60300@it.uc3m.es> Date: Thu, 31 Jan 2013 15:04:57 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: lmap@ietf.org References: <20130130181218.GA21225@elstar.local> <9BD4DA72C6214364A07889F73338342A@LENOVO47E041CF> <510A5279.5040906@cisco.com> In-Reply-To: <510A5279.5040906@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Thu, 31 Jan 2013 15:04:57 +0100 (CET) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19602.003 X-TM-AS-Result: No--23.840-7.0-31-1 X-imss-scan-details: No--23.840-7.0-31-1 Subject: Re: [lmap] IPFIX vs LMAP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 14:05:00 -0000 Hi Benoit, Let me take a stab to this. One of the goals of LMAP is to allow a controller (i.e. piece of code that is in charge of controlling which and when some measurement are done by measurement agents distributed all over the place) to request a specific measurement agent to perform a specific test, at a specific time, with these specific input parameters. In order to do that, we can re use a protocol to transport this information (e.g. http) but we need to define a data format that will allow to say, execute test number 5 with the following parameters, and the following time, with the following schedulling. AFAICT, we dont have such data format to express this. Now, this is very specific to the test, so the question is whether is there a data format that is generic enough to support all the relevant tests and that still defines something. I (we) belive the answer is yes. Similarly, another goal of LMAP would be to define the data format to allow the measurement agent to report the results of the tests executed to a "collector". This is what i understand is more similar to IPFIX, but yet again, the question is whether the generic data format needed to report arbitrary tests is currnelty available. The final goal is to buy a CPE out of the box, run a controller out of hte box and that the standard controller can request the CPE to run test numer 5 with input parameter a,b and c at time X. I hope this makes sense and clarifies something. Regards, marcelo El 31/01/13 12:16, Benoit Claise escribió: > On 31/01/2013 03:45, Jiankang YAO wrote: >> ----- Original Message ----- >> From: "Juergen Schoenwaelder" >> To: "Marc Linsner" >> Cc: >> Sent: Thursday, January 31, 2013 2:12 AM >> Subject: Re: [lmap] IPFIX vs LMAP >> >> >>> On Wed, Jan 30, 2013 at 12:42:51PM -0500, Marc Linsner wrote: >>>> Can someone familiar with IPFIX contrast, in a few sentences, the >>>> differences between it and LMAP? >>>> >>>> Can IPFIX be made tweaked to fulfill the LMAP requirements? >>>> >>>> I'm asking as I'm not familiar with IPFIX and know I'll miss something >>>> trying to read that architecture. >>> My understanding is that LMAP is not a protocol. >>> >>> LMAP may make use of say existing protocols such as IPFIX for shipping >>> measurement results and it may make use of other existing protocols to >>> lets say configure test schedules. >>> >> my understanding is that LMAP may use some existing protocols,but >> will create its own stuff. >> It is good to create the protocol for LMAP. > Why? > What is specific to your problem that requires a new protocol? > > Disclaimer: I'm not up to date with the mailing list and drafts, so > maybe I missed it. > > Regards, Benoit >> >> Jiankang Yao >> >>> That said, the LMAP effort may lead to extension of existing protocols >>> (e.g. new LMAP specific IPFIX information elements, new LMAP specific >>> data models, new IPPM metrics, ...). It is not clear at this point in >>> time that LMAP needs to spin its own protocol. >>> >>> /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 >> _______________________________________________ >> 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 dromasca@avaya.com Thu Jan 31 06:48:06 2013 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 E76F621F8622 for ; Thu, 31 Jan 2013 06:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnaBxJE8GzYj for ; Thu, 31 Jan 2013 06:48:06 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0511821F8507 for ; Thu, 31 Jan 2013 06:48:05 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAP0QA1GHCzI1/2dsb2JhbABCA4Jru2cWc4IeAQEBAQIBAQEBD1wXAgICAQgNAwEBAwEBAQodBxsMCxQDBggCBAESCBqHZwYBC6FYnHQEjg2CTWEDiCyKLolAijuCd4Ik X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208";a="46752653" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 31 Jan 2013 09:47:19 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 31 Jan 2013 09:47:50 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Thu, 31 Jan 2013 09:48:22 -0500 From: "Romascanu, Dan (Dan)" To: marcelo bagnulo braun , "lmap@ietf.org" Thread-Topic: [lmap] IPFIX vs LMAP Thread-Index: AQHN/6oyWkhAYwUiP0ifku4LRXr1ophjzGOA//+2sbA= Date: Thu, 31 Jan 2013 14:48:21 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA07BAAC@AZ-FFEXMB04.global.avaya.com> References: <20130130181218.GA21225@elstar.local> <9BD4DA72C6214364A07889F73338342A@LENOVO47E041CF> <510A5279.5040906@cisco.com> <510A7A09.60300@it.uc3m.es> In-Reply-To: <510A7A09.60300@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] IPFIX vs LMAP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 14:48:07 -0000 Hi Marcelo,=20 So can't LMAP use YANG to specify the data format that will define and trig= ger execution of the tests, and IPFIX to report the results of the tests?=20 We are already facing a multiplication of protocols from the IETF and other= SDOs, and this is not a good thing - not for operators, not for vendors. R= eusing existing protocols and writing data models in already existing data = modeling languages should be preferred, I believe.=20 Regards, Dan > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > marcelo bagnulo braun > Sent: Thursday, January 31, 2013 4:05 PM > To: lmap@ietf.org > Subject: Re: [lmap] IPFIX vs LMAP >=20 > Hi Benoit, >=20 > Let me take a stab to this. >=20 > One of the goals of LMAP is to allow a controller (i.e. piece of code > that is in charge of controlling which and when some measurement are > done by measurement agents distributed all over the place) to request a > specific measurement agent to perform a specific test, at a specific > time, with these specific input parameters. >=20 > In order to do that, we can re use a protocol to transport this > information (e.g. http) but we need to define a data format that will > allow to say, execute test number 5 with the following parameters, and > the following time, with the following schedulling. AFAICT, we dont have > such data format to express this. Now, this is very specific to the > test, so the question is whether is there a data format that is generic > enough to support all the relevant tests and that still defines > something. I (we) belive the answer is yes. >=20 > Similarly, another goal of LMAP would be to define the data format to > allow the measurement agent to report the results of the tests executed > to a "collector". This is what i understand is more similar to IPFIX, > but yet again, the question is whether the generic data format needed to > report arbitrary tests is currnelty available. >=20 > The final goal is to buy a CPE out of the box, run a controller out of > hte box and that the standard controller can request the CPE to run test > numer 5 with input parameter a,b and c at time X. >=20 >=20 > I hope this makes sense and clarifies something. >=20 > Regards, marcelo >=20 >=20 > El 31/01/13 12:16, Benoit Claise escribi=F3: > > On 31/01/2013 03:45, Jiankang YAO wrote: > >> ----- Original Message ----- > >> From: "Juergen Schoenwaelder" > >> To: "Marc Linsner" > >> Cc: > >> Sent: Thursday, January 31, 2013 2:12 AM > >> Subject: Re: [lmap] IPFIX vs LMAP > >> > >> > >>> On Wed, Jan 30, 2013 at 12:42:51PM -0500, Marc Linsner wrote: > >>>> Can someone familiar with IPFIX contrast, in a few sentences, the > >>>> differences between it and LMAP? > >>>> > >>>> Can IPFIX be made tweaked to fulfill the LMAP requirements? > >>>> > >>>> I'm asking as I'm not familiar with IPFIX and know I'll miss > >>>> something trying to read that architecture. > >>> My understanding is that LMAP is not a protocol. > >>> > >>> LMAP may make use of say existing protocols such as IPFIX for > >>> shipping measurement results and it may make use of other existing > >>> protocols to lets say configure test schedules. > >>> > >> my understanding is that LMAP may use some existing protocols,but > >> will create its own stuff. > >> It is good to create the protocol for LMAP. > > Why? > > What is specific to your problem that requires a new protocol? > > > > Disclaimer: I'm not up to date with the mailing list and drafts, so > > maybe I missed it. > > > > Regards, Benoit > >> > >> Jiankang Yao > >> > >>> That said, the LMAP effort may lead to extension of existing > >>> protocols (e.g. new LMAP specific IPFIX information elements, new > >>> LMAP specific data models, new IPPM metrics, ...). It is not clear > >>> at this point in time that LMAP needs to spin its own protocol. > >>> > >>> /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 > >> _______________________________________________ > >> 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 > > >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From philip.eardley@bt.com Thu Jan 31 07:42:56 2013 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 4785421F856D for ; Thu, 31 Jan 2013 07:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y49vJQaMfEhp for ; Thu, 31 Jan 2013 07:42:55 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 6372821F855F for ; Thu, 31 Jan 2013 07:42:48 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 31 Jan 2013 15:42:26 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.36]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Thu, 31 Jan 2013 15:42:41 +0000 From: To: , Date: Thu, 31 Jan 2013 15:42:40 +0000 Thread-Topic: [lmap] BOF Request Thread-Index: Ac3/t8LOckF/4+KMTlKKVhXvRUFcRAAEXxLQ Message-ID: <9510D26531EF184D9017DF24659BB87F341A04BC7E@EMV65-UKRD.domain1.systemhost.net> References: <9904FB1B0159DA42B0B887B7FA8119CA07AA5F@AZ-FFEXMB04.global.avaya.com>, <510932DE.8050300@neclab.eu> <201301312134328526701@cnnic.cn> In-Reply-To: <201301312134328526701@cnnic.cn> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F341A04BC7EEMV65UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] BOF Request X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 15:42:56 -0000 --_000_9510D26531EF184D9017DF24659BB87F341A04BC7EEMV65UKRDdoma_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 ZG8geW91IGhhdmUgYSB3aGl0ZXBhcGVyIGFib3V0IHlvdXIgc3lzdGVtPyBJoa9tIGludGVyZXN0 ZWQgdG8gdW5kZXJzdGFuZCB3aGF0IHlvdXIgZnJhbWV3b3JrIGlzLCB3aGF0IHlvdSBtZWFzdXJl IGFuZCBob3cgeW91IHJlcG9ydCwgd2hldGhlciB0aGVzZSBhcmUgc29mdHdhcmUgb3IgaGFyZHdh cmUgYmFzZWQgTUFzLCBldGMNCnRoYW5rcw0KcGhpbA0KRnJvbTogbG1hcC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bG1hcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3VhbmdxaW5n IERlbmcNClNlbnQ6IDMxIEphbnVhcnkgMjAxMyAxMzozNQ0KVG86IGxtYXBAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbbG1hcF0gQk9GIFJlcXVlc3QNCg0KR3JlYXQgbmV3cyEgSSBhbSBpbnRlcmVz dGVkIGluIHRoZSBuZXR3b3JrIG1lYXN1cmVtZW50IGFuZCBoYXZlIGRvbmUgc2V2ZXJhbCBsYXJn ZSBzY2FsZSBtZWFzdXJlbWVudHMgKHRvZ2V0aGVyIHdpdGggbXkgY29sbGVhZ3VlcykgdG93YXJk cyBicm9hZGJhbmQgbmV0d29yayBwZXJmb3JtYW5jZSB3aXRoIHNldmVyYWwgbWVhc3VyZW1lbnQg Y29sbGVjdG9ycywgY29udHJvbGxlcnMgYW5kIG5lYXJseSA2MCB0aG91c2FuZHMgb2YgbWVhc3Vy ZW1lbnQgYWdlbnRzIChNQSkuIE9mIGNvdXJzZSwgdGhlIHByb3RvY29sIHVzZWQgdG8gY29ubmVj dCB0aGUgY29tcG9uZW50cyAobmFtZWx5IHRoZSBjb250cm9sbGVyLCBjb2xsZWN0b3IgYW5kIE1B KSBpcyBwcml2YXRlLiBXaXRoIHNvbWUgZXhwZXJpZW5jZSBnYWluZWQgZnJvbSBzdWNoIG1lYXN1 cmVtZW50cywgSSB3b3VsZCBsaWtlIHRvIGRvIHNvbWUgY29udHJpYnV0aW9uIHRvIHRoZSBzdGFu ZGFyZGl6YXRpb24gb2YgdGhlIG5ldHdvcmsgbWVhc3VyZW1lbnQgcHJvdG9jb2wgd2l0aGluIHRo aXMgV0cuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpHdWFuZ3FpbmcgRGVu Zw0KY25uaWMNCg0KRnJvbTogTWFydGluIFN0aWVtZXJsaW5nPG1haWx0bzptYXJ0aW4uc3RpZW1l cmxpbmdAbmVjbGFiLmV1Pg0KRGF0ZTogMjAxMy0wMS0zMCAyMjo0OQ0KVG86IGxtYXBAaWV0Zi5v cmc8bWFpbHRvOmxtYXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2xtYXBdIEJPRiBSZXF1ZXN0 DQoNCg0KT24gMDEvMzAvMjAxMyAwMzozMSBQTSwgUm9tYXNjYW51LCBEYW4gKERhbikgd3JvdGU6 DQo+IEFjdHVhbGx5IGl0knMNCj4NCj4gaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9mL3Ry YWMvd2lraSNUcmFuc3BvcnQNCj4NCj4gaXNuknQgaXQ/DQoNClJpZ2h0LCBhdCBsZWFzdCBmb3Ig bm93IHVudGlsIHdlIGhhdmUgZmlndXJlZCBvdXQgaWYgdGhpcyBsaXZlcyBpbg0KVHJhbnNwb3J0 IG9yIE9QUy4NCg0KICAgTWFydGluDQoNCj4NCj4gRGFuDQo+DQo+ICpGcm9tOipsbWFwLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYNCj4g T2YgKk1hcmMgTGluc25lcg0KPiAqU2VudDoqIFdlZG5lc2RheSwgSmFudWFyeSAzMCwgMjAxMyA0 OjIxIFBNDQo+ICpUbzoqIGxtYXBAaWV0Zi5vcmc8bWFpbHRvOmxtYXBAaWV0Zi5vcmc+DQo+ICpT dWJqZWN0OiogW2xtYXBdIEJPRiBSZXF1ZXN0DQo+DQo+IFdlIHN1Ym1pdHRlZCBhIHJlcXVlc3Qg Zm9yIGEgc2Vzc2lvbiBhdCBPcmxhbmRvLiAgVGhlIEFEIHRlbGVjaGF0IGlzDQo+IHRvbW9ycm93 Lg0KPg0KPiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ib2YvdHJhYy93aWtpI09wZXJhdGlv bnNhbmRNYW5hZ2VtZW50DQo+DQo+IC1NYXJjLQ0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBsbWFwIG1haWxpbmcgbGlzdA0KPiBs bWFwQGlldGYub3JnPG1haWx0bzpsbWFwQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2xtYXANCj4NCg0KLS0NCm1hcnRpbi5zdGllbWVybGluZ0BuZWNs YWIuZXU8bWFpbHRvOm1hcnRpbi5zdGllbWVybGluZ0BuZWNsYWIuZXU+DQoNCk5FQyBMYWJvcmF0 b3JpZXMgRXVyb3BlIC0gTmV0d29yayBSZXNlYXJjaCBEaXZpc2lvbiBORUMgRXVyb3BlIExpbWl0 ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwgTG9uZG9u IFczIDZCTA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4Mw0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCmxtYXAgbWFpbGluZyBsaXN0DQpsbWFwQGlldGYu b3JnPG1haWx0bzpsbWFwQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9sbWFwDQo= --_000_9510D26531EF184D9017DF24659BB87F341A04BC7EEMV65UKRDdoma_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

= do you have a whitepaper about your system? I=A1=AFm interested to understa= nd what your framework is, what you measure and how you report, whether the= se are software or hardware based MAs, etc

thanks

ph= il

From: lmap-bounces@ietf.= org [mailto:lmap-bounces@ietf.org] On Behalf Of Guangqing Deng
Sent: 31 January 2013 13:35
To: lmap@ietf.org
Subject:= Re: [lmap] BOF Request

 

Great news! I am interested in the network measur= ement and have done several large scale measurements (together with my coll= eagues) towards broadband network performance with several measurement coll= ectors, controllers and nearly 60 thousands of measurement agents (MA). Of = course, the protocol used to connect the components (namely the controller,= collector and MA) is private. With some experience gained from such measur= ements, I would like to do some contribution to the standardization of the = network measurement protocol within this WG.

 

<= /div>

G= uangqing Deng
cnnic =

 

Date: 2013-01-30 22:49

<= /div><= div>

Subject: Re: [lm= ap] BOF Request

 

 =

On 01/30/2013&nbs= p;03:31 PM,&nb= sp;Romascanu, Dan (Dan) wrote:

> Actually=  it=92s

> 

> 

>&nbs= p;isn=92t it?

 

 at&nbs= p;least for&nb= sp;now until&n= bsp;we have&nb= sp;figured out=  if this&= nbsp;lives in&= nbsp;

Transport&nbs= p;or OPS.<= /p>

 

  &nbs= p;Martin

 

> 

>=  Dan

> <= /o:p>

> *From:*lmap-bo= unces@ietf.org [mailto:lmap-bounces@ietf.org] = *On Behalf

> Of *Marc Linsner

> *Sent:* = Wednesday, January&nb= sp;30, 2013&nb= sp;4:21 PM=

> *To:* <= /span>lmap@ietf.org<= /span>

> *Subject:* [lmap] BOF<= span style=3D'font-size:10.5pt;font-family:"Times New Roman","serif";color:= navy'> Request

>&nb= sp;

> We<= span style=3D'font-size:10.5pt;font-family:"Times New Roman","serif";color:= navy'> submitted a request for= a sess= ion at Or= lando.  The AD telechat is

> tomorrow.

> 

=

>=  

> -M= arc-

> 

>= ; 

> 

<= div>

= > _____________________________________= __________

>  mailing <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>list

> <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>> https://www.ietf.org/mailman/listinfo/lmap=

> 

 

-- 

 

NEC L= aboratories Europe - Network Research Division=  NEC EuropeLimited

Registered=  Office: NEC House, 1 Victoria Ro= ad, London  6BL

<= p class=3DMsoNormal style=3D'margin:0cm;margin-bottom:.0001pt'>Regi= stered in England 283

_= ______________________________________________

<= div>

= lmap mailing list

= --_000_9510D26531EF184D9017DF24659BB87F341A04BC7EEMV65UKRDdoma_-- From yaojk@cnnic.cn Thu Jan 31 16:51:17 2013 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 CF53721F8A54 for ; Thu, 31 Jan 2013 16:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.82 X-Spam-Level: X-Spam-Status: No, score=-98.82 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc5Q7SycAV6D for ; Thu, 31 Jan 2013 16:51:14 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 388F321F8A56 for ; Thu, 31 Jan 2013 16:51:11 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 01 Feb 2013 08:51:05 +0800 Message-ID: <07442E161D554D25A131C795E0707BA9@LENOVO47E041CF> From: "Jiankang YAO" To: , , References: <9904FB1B0159DA42B0B887B7FA8119CA07AA5F@AZ-FFEXMB04.global.avaya.com>, <510932DE.8050300@neclab.eu> <201301312134328526701@cnnic.cn> <9510D26531EF184D9017DF24659BB87F341A04BC7E@EMV65-UKRD.domain1.systemhost.net> Date: Fri, 1 Feb 2013 08:51:05 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_015F_01CE0059.45437060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [lmap] BOF Request X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 00:51:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_015F_01CE0059.45437060 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Q05OSUMncyBzeXN0ZW0gaXMgcGVyZmVjdGx5IHNhbWUgdG8gdGhlIGFyY2h0ZWN0dXJlIHByb3Bv c2VkIGluIGRyYWZ0LXNjaHVsenJpbm5lLWxtYXAtcmVxdWlyZW1lbnRzLTAwLg0KVGhlIE1BcyBh cmUgc29mdHdhcmUgYmFzZWQuDQpHdWFuZ3Fpbmcgd2lsbCBnaXZlIG1vcmUgZGV0YWlscy4NCg0K SWYgdGhlIEJPRiBpcyBpbnRlcmVzdGVkIGluIGl0LCBJIGNhbiBwcmVzZW50IGl0IGluIHRoZSBM TUFQIEJPRiBtZWV0aW5nIGlmIGl0IGNhbiBnZXRzIGEgc2Vzc2lvbi4NCg0KdGhhbmtzLg0KDQpK aWFua2FuZyBZYW8NCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogcGhp bGlwLmVhcmRsZXlAYnQuY29tIA0KICBUbzogZGVuZ2d1YW5ncWluZ0Bjbm5pYy5jbiA7IGxtYXBA aWV0Zi5vcmcgDQogIFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDMxLCAyMDEzIDExOjQyIFBNDQog IFN1YmplY3Q6IFJlOiBbbG1hcF0gQk9GIFJlcXVlc3QNCg0KDQogIGRvIHlvdSBoYXZlIGEgd2hp dGVwYXBlciBhYm91dCB5b3VyIHN5c3RlbT8gSaGvbSBpbnRlcmVzdGVkIHRvIHVuZGVyc3RhbmQg d2hhdCB5b3VyIGZyYW1ld29yayBpcywgd2hhdCB5b3UgbWVhc3VyZSBhbmQgaG93IHlvdSByZXBv cnQsIHdoZXRoZXIgdGhlc2UgYXJlIHNvZnR3YXJlIG9yIGhhcmR3YXJlIGJhc2VkIE1BcywgZXRj DQoNCiAgdGhhbmtzDQoNCiAgcGhpbA0KDQogIEZyb206IGxtYXAtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEd1YW5ncWluZyBEZW5n DQogIFNlbnQ6IDMxIEphbnVhcnkgMjAxMyAxMzozNQ0KICBUbzogbG1hcEBpZXRmLm9yZw0KICBT dWJqZWN0OiBSZTogW2xtYXBdIEJPRiBSZXF1ZXN0DQoNCiAgIA0KDQogIEdyZWF0IG5ld3MhIEkg YW0gaW50ZXJlc3RlZCBpbiB0aGUgbmV0d29yayBtZWFzdXJlbWVudCBhbmQgaGF2ZSBkb25lIHNl dmVyYWwgbGFyZ2Ugc2NhbGUgbWVhc3VyZW1lbnRzICh0b2dldGhlciB3aXRoIG15IGNvbGxlYWd1 ZXMpIHRvd2FyZHMgYnJvYWRiYW5kIG5ldHdvcmsgcGVyZm9ybWFuY2Ugd2l0aCBzZXZlcmFsIG1l YXN1cmVtZW50IGNvbGxlY3RvcnMsIGNvbnRyb2xsZXJzIGFuZCBuZWFybHkgNjAgdGhvdXNhbmRz IG9mIG1lYXN1cmVtZW50IGFnZW50cyAoTUEpLiBPZiBjb3Vyc2UsIHRoZSBwcm90b2NvbCB1c2Vk IHRvIGNvbm5lY3QgdGhlIGNvbXBvbmVudHMgKG5hbWVseSB0aGUgY29udHJvbGxlciwgY29sbGVj dG9yIGFuZCBNQSkgaXMgcHJpdmF0ZS4gV2l0aCBzb21lIGV4cGVyaWVuY2UgZ2FpbmVkIGZyb20g c3VjaCBtZWFzdXJlbWVudHMsIEkgd291bGQgbGlrZSB0byBkbyBzb21lIGNvbnRyaWJ1dGlvbiB0 byB0aGUgc3RhbmRhcmRpemF0aW9uIG9mIHRoZSBuZXR3b3JrIG1lYXN1cmVtZW50IHByb3RvY29s IHdpdGhpbiB0aGlzIFdHLg0KDQogICANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICBH dWFuZ3FpbmcgRGVuZw0KICBjbm5pYyANCg0KICAgDQoNCiAgRnJvbTogTWFydGluIFN0aWVtZXJs aW5nDQoNCiAgRGF0ZTogMjAxMy0wMS0zMCAyMjo0OQ0KDQogIFRvOiBsbWFwQGlldGYub3JnDQoN CiAgU3ViamVjdDogUmU6IFtsbWFwXSBCT0YgUmVxdWVzdA0KDQogICANCg0KICAgDQoNCiAgT24g MDEvMzAvMjAxMyAwMzozMSBQTSwgUm9tYXNjYW51LCBEYW4gKERhbikgd3JvdGU6DQoNCiAgPiBB Y3R1YWxseSBpdJJzDQoNCiAgPiANCg0KICA+IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2Jv Zi90cmFjL3dpa2kjVHJhbnNwb3J0DQoNCiAgPiANCg0KICA+IGlzbpJ0IGl0Pw0KDQogICANCg0K ICBSaWdodCwgYXQgbGVhc3QgZm9yIG5vdyB1bnRpbCB3ZSBoYXZlIGZpZ3VyZWQgb3V0IGlmIHRo aXMgbGl2ZXMgaW4gDQoNCiAgVHJhbnNwb3J0IG9yIE9QUy4NCg0KICAgDQoNCiAgICAgTWFydGlu DQoNCiAgIA0KDQogID4gDQoNCiAgPiBEYW4NCg0KICA+IA0KDQogID4gKkZyb206KmxtYXAtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZg0K DQogID4gT2YgKk1hcmMgTGluc25lcg0KDQogID4gKlNlbnQ6KiBXZWRuZXNkYXksIEphbnVhcnkg MzAsIDIwMTMgNDoyMSBQTQ0KDQogID4gKlRvOiogbG1hcEBpZXRmLm9yZw0KDQogID4gKlN1Ympl Y3Q6KiBbbG1hcF0gQk9GIFJlcXVlc3QNCg0KICA+IA0KDQogID4gV2Ugc3VibWl0dGVkIGEgcmVx dWVzdCBmb3IgYSBzZXNzaW9uIGF0IE9ybGFuZG8uICBUaGUgQUQgdGVsZWNoYXQgaXMNCg0KICA+ IHRvbW9ycm93Lg0KDQogID4gDQoNCiAgPiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ib2Yv dHJhYy93aWtpI09wZXJhdGlvbnNhbmRNYW5hZ2VtZW50DQoNCiAgPiANCg0KICA+IC1NYXJjLQ0K DQogID4gDQoNCiAgPiANCg0KICA+IA0KDQogID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KICA+IGxtYXAgbWFpbGluZyBsaXN0DQoNCiAgPiBsbWFw QGlldGYub3JnDQoNCiAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xt YXANCg0KICA+IA0KDQogICANCg0KICAtLSANCg0KICBtYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFi LmV1DQoNCiAgIA0KDQogIE5FQyBMYWJvcmF0b3JpZXMgRXVyb3BlIC0gTmV0d29yayBSZXNlYXJj aCBEaXZpc2lvbiBORUMgRXVyb3BlIExpbWl0ZWQNCg0KICBSZWdpc3RlcmVkIE9mZmljZTogTkVD IEhvdXNlLCAxIFZpY3RvcmlhIFJvYWQsIExvbmRvbiBXMyA2QkwNCg0KICBSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgMjgzDQoNCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KICBsbWFwIG1haWxpbmcgbGlzdA0KDQogIGxtYXBAaWV0Zi5vcmcNCg0KICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXANCg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQoNCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgbG1hcCBtYWlsaW5nIGxpc3QNCiAgbG1hcEBpZXRmLm9yZw0KICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXANCg== ------=_NextPart_000_015F_01CE0059.45437060 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptID0gDQoiaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIj48SEVBRD4NCjxNRVRBIGNvbnRl bnQ9InRleHQvaHRtbDsgY2hhcnNldD1nYjIzMTIiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0K PE1FVEEgbmFtZT1HRU5FUkFUT1IgY29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTM5NCI+PCEt LVtpZiAhbXNvXT4NCjxTVFlMRT52XDoqIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkN Cn0NCm9cOiogew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjVk1MKQ0KfQ0Kd1w6KiB7DQoJQkVI QVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQouc2hhcGUgew0KCUJFSEFWSU9SOiB1cmwoI2Rl ZmF1bHQjVk1MKQ0KfQ0KPC9TVFlMRT4NCjwhW2VuZGlmXS0tPg0KPFNUWUxFPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBh bm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpT aW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQg NCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTWljcm9zb2Z0IFlhSGVpIjsNCglw YW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxAU2ltU3VuIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlxATWljcm9zb2Z0IFlhSGVpIjsNCglwYW5vc2UtMTowIDAgMCAwIDAg MCAwIDAgMCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlNpbVN1biIsInNlcmlmIjsN Cgltc28tYmVsaWV2ZS1ub3JtYWwtbGVmdDp5ZXM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi U2ltU3VuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0Fj ZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjAN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L1NUWUxFPg0KPCFbaWYgbXNvIDldPjxzdHlsZT5wLk1zb05vcm1hbA0KCXttYXJnaW4tbGVm dDo3LjVwdDt9DQo8L3N0eWxlPjwhW2VuZGlmXT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJNQVJHSU46IDcuNXB0IiBs YW5nPUVOLUdCIGxpbms9Ymx1ZSBiZ0NvbG9yPSNjY2U4Y2Ygdkxpbms9cHVycGxlPg0KPERJVj48 Rk9OVCBzaXplPTI+Q05OSUMncyBzeXN0ZW0gaXMgcGVyZmVjdGx5Jm5ic3A7c2FtZSB0byB0aGUg YXJjaHRlY3R1cmUgDQpwcm9wb3NlZCBpbiBkcmFmdC1zY2h1bHpyaW5uZS1sbWFwLXJlcXVpcmVt ZW50cy0wMC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGUgTUFzIGFyZSBzb2Z0 d2FyZSBiYXNlZC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5HdWFuZ3Fpbmcgd2ls bCBnaXZlIG1vcmUgZGV0YWlscy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JZiB0aGUgQk9GIGlzIGludGVyZXN0 ZWQgaW4gaXQsJm5ic3A7SSBjYW4gcHJlc2VudCBpdCBpbiB0aGUgDQpMTUFQIEJPRiBtZWV0aW5n IGlmIGl0IGNhbiBnZXRzIGEgc2Vzc2lvbi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj50aGFua3MuPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+SmlhbmthbmcgWWFvPC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iQk9S REVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1S SUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCDLzszlIj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElW Pg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgy87M5TsgQkFDS0dST1VORDogI2U0ZTRlNDsgZm9u dC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9cGhpbGlwLmVhcmRsZXlA YnQuY29tIA0KICBocmVmPSJtYWlsdG86cGhpbGlwLmVhcmRsZXlAYnQuY29tIj5waGlsaXAuZWFy ZGxleUBidC5jb208L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgy87M5SI+PEI+ VG86PC9CPiA8QSB0aXRsZT1kZW5nZ3VhbmdxaW5nQGNubmljLmNuIA0KICBocmVmPSJtYWlsdG86 ZGVuZ2d1YW5ncWluZ0Bjbm5pYy5jbiI+ZGVuZ2d1YW5ncWluZ0Bjbm5pYy5jbjwvQT4gOyA8QSAN CiAgdGl0bGU9bG1hcEBpZXRmLm9yZyBocmVmPSJtYWlsdG86bG1hcEBpZXRmLm9yZyI+bG1hcEBp ZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDLzszlIj48Qj5TZW50 OjwvQj4gVGh1cnNkYXksIEphbnVhcnkgMzEsIDIwMTMgMTE6NDIgDQogIFBNPC9ESVY+DQogIDxE SVYgc3R5bGU9IkZPTlQ6IDlwdCDLzszlIj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtsbWFwXSBCT0Yg UmVxdWVzdDwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJViBjbGFzcz1Xb3JkU2VjdGlv bjE+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAn Q2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5k byANCiAgeW91IGhhdmUgYSB3aGl0ZXBhcGVyIGFib3V0IHlvdXIgc3lzdGVtPyBJoa9tIGludGVy ZXN0ZWQgdG8gdW5kZXJzdGFuZCB3aGF0IA0KICB5b3VyIGZyYW1ld29yayBpcywgd2hhdCB5b3Ug bWVhc3VyZSBhbmQgaG93IHlvdSByZXBvcnQsIHdoZXRoZXIgdGhlc2UgYXJlIA0KICBzb2Z0d2Fy ZSBvciBoYXJkd2FyZSBiYXNlZCBNQXMsIGV0YzxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywn c2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPnRoYW5rczxvOnA+ PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05U LVNJWkU6IDExcHQiPnBoaWw8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxESVY+DQogIDxESVYg DQogIHN0eWxlPSJCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1 bSBub25lOyBQQURESU5HLUJPVFRPTTogMGNtOyBQQURESU5HLUxFRlQ6IDBjbTsgUEFERElORy1S SUdIVDogMGNtOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBt ZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQogIDxQIHN0eWxlPSJNQVJHSU46IDBjbSAw Y20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PEI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTog J1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiIA0KICBsYW5nPUVOLVVTPkZy b206PC9TUEFOPjwvQj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fu cy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz4gPEEgDQogIGhyZWY9Im1haWx0 bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmciPmxtYXAtYm91bmNlc0BpZXRmLm9yZzwvQT4gDQogIFtt YWlsdG86bG1hcC1ib3VuY2VzQGlldGYub3JnXSA8Qj5PbiBCZWhhbGYgT2YgPC9CPkd1YW5ncWlu ZyANCiAgRGVuZzxCUj48Qj5TZW50OjwvQj4gMzEgSmFudWFyeSAyMDEzIDEzOjM1PEJSPjxCPlRv OjwvQj4gPEEgDQogIGhyZWY9Im1haWx0bzpsbWFwQGlldGYub3JnIj5sbWFwQGlldGYub3JnPC9B PjxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtsbWFwXSANCiAgQk9GIFJlcXVlc3Q8bzpwPjwvbzpw PjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvUD4NCiAgPERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNs YXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv bWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2siIGxhbmc9RU4tVVM+R3JlYXQgDQogIG5ld3MhIEkg YW0gaW50ZXJlc3RlZCBpbiB0aGUgbmV0d29yayBtZWFzdXJlbWVudCBhbmQgaGF2ZSBkb25lIHNl dmVyYWwgbGFyZ2UgDQogIHNjYWxlIG1lYXN1cmVtZW50cyAodG9nZXRoZXIgd2l0aCBteSBjb2xs ZWFndWVzKSB0b3dhcmRzIGJyb2FkYmFuZCBuZXR3b3JrIA0KICBwZXJmb3JtYW5jZSB3aXRoIHNl dmVyYWwgbWVhc3VyZW1lbnQgY29sbGVjdG9ycywgY29udHJvbGxlcnMgYW5kIG5lYXJseSA2MCAN CiAgdGhvdXNhbmRzIG9mIG1lYXN1cmVtZW50IGFnZW50cyAoTUEpLiBPZiBjb3Vyc2UsIHRoZSBw cm90b2NvbCB1c2VkIHRvIGNvbm5lY3QgDQogIHRoZSBjb21wb25lbnRzIChuYW1lbHkgdGhlIGNv bnRyb2xsZXIsIGNvbGxlY3RvciBhbmQgTUEpIGlzIHByaXZhdGUuIFdpdGggc29tZSANCiAgZXhw ZXJpZW5jZSBnYWluZWQgZnJvbSBzdWNoIG1lYXN1cmVtZW50cywgSSB3b3VsZCBsaWtlIHRvIGRv IHNvbWUgY29udHJpYnV0aW9uIA0KICB0byB0aGUgc3RhbmRhcmRpemF0aW9uIG9mIHRoZSBuZXR3 b3JrIG1lYXN1cmVtZW50IHByb3RvY29sIHdpdGhpbiB0aGlzIA0KICBXRy48L1NQQU4+PFNQQU4g c3R5bGU9IkNPTE9SOiBuYXZ5Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+ DQogIDxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4g DQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6 IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJG T05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQt U0laRTogMTAuNXB0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVYgc3R5bGU9 Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZP TlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1T SVpFOiAxMC41cHQiPg0KICA8SFIgc3R5bGU9IldJRFRIOiAxNTcuNXB0OyBDT0xPUjogI2I1YzRk ZiIgYWxpZ249bGVmdCBTSVpFPTEgd2lkdGg9MjEwIA0Kbm9TaGFkZT4NCiAgPC9TUEFOPjwvRElW Pg0KICA8RElWPg0KICA8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9y bWFsPjxTUEFOIA0KICBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwLjVwdCI+R3Vh bmdxaW5nIERlbmc8QlI+Y25uaWM8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTog J1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwLjVw dCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQg WWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+PG86cD48L286 cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDBwdCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1l cyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5i c3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWkn LCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+PG86cD48L286cD48L1NQ QU4+PC9QPjwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iQk9SREVSLUJPVFRPTTogbWVkaXVtIG5v bmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBjbTsgUEFERElO Ry1MRUZUOiAwY207IFBBRERJTkctUklHSFQ6IDBjbTsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQg c29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KICA8 RElWPg0KICA8RElWPg0KICA8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgQkFDS0dST1VO RDogI2VmZWZlZiIgY2xhc3M9TXNvTm9ybWFsPjxCPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1J TFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5 cHQiPkZyb206PC9TUEFOPjwvQj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogOXB0Ij4mbmJzcDs8 L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3Nl cmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdCI+PEEgDQogIGhyZWY9Im1haWx0bzpt YXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1Ij5NYXJ0aW4gDQogIFN0aWVtZXJsaW5nPC9BPjxv OnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAwcHQ7IEJBQ0tHUk9VTkQ6ICNlZmVmZWYiIGNsYXNzPU1zb05vcm1hbD48Qj48U1BB TiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xP UjogYmxhY2s7IEZPTlQtU0laRTogOXB0Ij5EYXRlOjwvU1BBTj48L0I+PFNQQU4gDQogIHN0eWxl PSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IGJsYWNrOyBG T05ULVNJWkU6IDlwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5cHQi PjIwMTMtMDEtMzA8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5l dyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdCI+Jm5ic3A7PC9T UEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJp Zic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5cHQiPjIyOjQ5PG86cD48L286cD48L1NQQU4+ PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgQkFD S0dST1VORDogI2VmZWZlZiIgY2xhc3M9TXNvTm9ybWFsPjxCPjxTUEFOIA0KICBzdHlsZT0iRk9O VC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1T SVpFOiA5cHQiPlRvOjwvU1BBTj48L0I+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1Rp bWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdCI+Jm5i c3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWkn LCdzZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5cHQiPjxBIA0KICBocmVmPSJtYWls dG86bG1hcEBpZXRmLm9yZyI+bG1hcEBpZXRmLm9yZzwvQT48bzpwPjwvbzpwPjwvU1BBTj48L1A+ PC9ESVY+DQogIDxESVY+DQogIDxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBCQUNLR1JP VU5EOiAjZWZlZmVmIiBjbGFzcz1Nc29Ob3JtYWw+PEI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZB TUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6 IDlwdCI+U3ViamVjdDo8L1NQQU4+PC9CPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU aW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5cHQiPiZu YnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVp Jywnc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogOXB0Ij5SZTogDQogIFtsbWFwXSBC T0YgUmVxdWVzdDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj48L0RJVj48L0RJVj4NCiAgPERJ Vj4NCiAgPERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05v cm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2Vy aWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiAN CiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjog bmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAg PERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48 U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBD T0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5 bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsg Rk9OVC1TSVpFOiAxMC41cHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4N CiAgPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiAN CiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjog bmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPk9uPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1G QU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6 IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNy b3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+MDEv MzAvMjAxMzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv bWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BB Tj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYn OyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPjAzOjMxPC9TUEFOPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5 OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1G QU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6 IDEwLjVwdCI+UE0sPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBO ZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7 PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdz ZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Um9tYXNjYW51LDwvU1BBTj48 U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBD T0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5 bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsg Rk9OVC1TSVpFOiAxMC41cHQiPkRhbjwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZ OiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41 cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0 IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPihEYW4pPC9T UEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJp Zic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBu YXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+d3JvdGU6PG86cD48L286cD48L1NQQU4+PC9QPjwvRElW Pg0KICA8RElWPg0KICA8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9y bWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJp Zic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jmd0OzwvU1BBTj48U1BBTiANCiAg c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2 eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQt RkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpF OiAxMC41cHQiPkFjdHVhbGx5PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU aW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+ Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFI ZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+aXQ8U1BBTiANCiAg bGFuZz1aSC1DTj6SczwvU1BBTj48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+ DQogIDxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4g DQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6 IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9Q PjwvRElWPg0KICA8RElWPg0KICA8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9 TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWkn LCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jmd0OzwvU1BBTj48U1BB TiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xP UjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9 IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9O VC1TSVpFOiAxMC41cHQiPjxBIA0KICBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9i b2YvdHJhYy93aWtpI1RyYW5zcG9ydCI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9mL3Ry YWMvd2lraSNUcmFuc3BvcnQ8L0E+PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElW Pg0KICA8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9S OiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwv UD48L0RJVj4NCiAgPERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNz PU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVp Jywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZndDs8L1NQQU4+PFNQ QU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09M T1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxl PSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZP TlQtU0laRTogMTAuNXB0Ij5pc248U1BBTiANCiAgbGFuZz1aSC1DTj6SdDwvU1BBTj48L1NQQU4+ PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsg Q09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0 eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7 IEZPTlQtU0laRTogMTAuNXB0Ij5pdD88bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxE SVY+DQogIDxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQ QU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09M T1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxl PSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZP TlQtU0laRTogMTAuNXB0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQog IDxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQog IHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5h dnk7IEZPTlQtU0laRTogMTAuNXB0Ij5SaWdodCw8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05U LUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0la RTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01p Y3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij5h dDwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywn c2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BB TiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xP UjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPmxlYXN0PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05U LVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVw dCI+Zm9yPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9t YW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFO PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7 IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+bm93PC9TUEFOPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBG T05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1J TFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEw LjVwdCI+dW50aWw8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5l dyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8 L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3Nl cmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij53ZTwvU1BBTj48U1BBTiANCiAg c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2 eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQt RkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpF OiAxMC41cHQiPmhhdmU8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVz IE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJz cDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScs J3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij5maWd1cmVkPC9TUEFOPjxT UEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENP TE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBG T05ULVNJWkU6IDEwLjVwdCI+b3V0PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVw dCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQg WWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+aWY8L1NQQU4+ PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsg Q09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0 eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7 IEZPTlQtU0laRTogMTAuNXB0Ij50aGlzPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1J TFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEw LjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3Nv ZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+bGl2ZXM8 L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3Nl cmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4g DQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6 IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij5pbjwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQt RkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpF OiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWlj cm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPjxv OnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZ OiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41 cHQiPlRyYW5zcG9ydDwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNw OzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywn c2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPm9yPC9TUEFOPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBu YXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9O VC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJ WkU6IDEwLjVwdCI+T1BTLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAg PFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAg c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2 eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQt RkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpF OiAxMC41cHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgc3R5 bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9 IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9O VC1TSVpFOiAxMC41cHQiPiZuYnNwOyZuYnNwOyZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9 IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9O VC1TSVpFOiAxMC41cHQiPk1hcnRpbjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJ Vj4NCiAgPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BB TiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xP UjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9 IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9O VC1TSVpFOiAxMC41cHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAg PFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAg c3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2 eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+PC9E SVY+DQogIDxESVY+DQogIDxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3Nl cmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mZ3Q7PC9TUEFOPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBu YXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9O VC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJ WkU6IDEwLjVwdCI+RGFuPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8 UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5 OyBGT05ULVNJWkU6IDEwLjVwdCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD48L0RJ Vj4NCiAgPERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05v cm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2Vy aWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZndDs8L1NQQU4+PFNQQU4gDQog IHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5h dnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05U LUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0la RTogMTAuNXB0Ij4qRnJvbToqbG1hcC1ib3VuY2VzQGlldGYub3JnPC9TUEFOPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5 OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1G QU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6 IDEwLjVwdCI+WzxBIA0KICBocmVmPSJtYWlsdG86bG1hcC1ib3VuY2VzQGlldGYub3JnIj5tYWls dG86bG1hcC1ib3VuY2VzQGlldGYub3JnPC9BPl08L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05U LUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0la RTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01p Y3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4q T248L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbics J3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQ QU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09M T1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij5CZWhhbGY8bzpwPjwvbzpwPjwvU1BBTj48L1A+ PC9ESVY+DQogIDxESVY+DQogIDxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1N c29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScs J3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mZ3Q7PC9TUEFOPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9S OiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05U LVNJWkU6IDEwLjVwdCI+T2Y8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1Rp bWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4m bmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhl aScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4qTWFyYzwvU1BBTj48 U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBD T0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5 bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsg Rk9OVC1TSVpFOiAxMC41cHQiPkxpbnNuZXI8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQog IDxESVY+DQogIDxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsg Q09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mZ3Q7PC9TUEFOPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBG T05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1J TFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEw LjVwdCI+KlNlbnQ6KjwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNw OzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywn c2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPldlZG5lc2RheSw8L1NQQU4+ PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsg Q09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0 eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7 IEZPTlQtU0laRTogMTAuNXB0Ij5KYW51YXJ5PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1G QU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6 IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNy b3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+MzAs PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdz ZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9S OiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+MjAxMzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZP TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1T SVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAn TWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQi PjQ6MjE8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21h bicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+ PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsg Q09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij5QTTxvOnA+PC9vOnA+PC9TUEFOPjwvUD48 L0RJVj4NCiAgPERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1z b05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywn c2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZndDs8L1NQQU4+PFNQQU4g DQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6 IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJG T05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQt U0laRTogMTAuNXB0Ij4qVG86KjwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAn VGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQi PiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlh SGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPjxBIA0KICBocmVm PSJtYWlsdG86bG1hcEBpZXRmLm9yZyI+bG1hcEBpZXRmLm9yZzwvQT48bzpwPjwvbzpwPjwvU1BB Tj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBj bGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZ YUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mZ3Q7PC9TUEFO PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7 IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5 OyBGT05ULVNJWkU6IDEwLjVwdCI+KlN1YmplY3Q6KjwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZP TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1T SVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAn TWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQi PltsbWFwXTwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv bWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BB Tj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYn OyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPkJPRjwvU1BBTj48U1BBTiANCiAgc3R5 bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsg Rk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFN SUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAx MC41cHQiPlJlcXVlc3Q8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQ IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0 eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7 IEZPTlQtU0laRTogMTAuNXB0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPjwvRElW Pg0KICA8RElWPg0KICA8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9y bWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJp Zic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jmd0OzwvU1BBTj48U1BBTiANCiAg c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2 eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQt RkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpF OiAxMC41cHQiPldlPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBO ZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7 PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdz ZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+c3VibWl0dGVkPC9TUEFOPjxT UEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENP TE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBG T05ULVNJWkU6IDEwLjVwdCI+YTwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAn VGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQi PiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlh SGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPnJlcXVlc3Q8L1NQ QU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3Nlcmlm JzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQog IHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5h dnk7IEZPTlQtU0laRTogMTAuNXB0Ij5mb3I8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZB TUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTog MTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jv c29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij5hPC9T UEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJp Zic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBu YXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+c2Vzc2lvbjwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZP TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1T SVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAn TWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQi PmF0PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4n LCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxT UEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENP TE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+T3JsYW5kby48L1NQQU4+PFNQQU4gDQogIHN0 eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7 IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDsmbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJG T05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQt U0laRTogMTAuNXB0Ij5UaGU8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1Rp bWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4m bmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhl aScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij5BRDwvU1BBTj48U1BB TiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xP UjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9 IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9O VC1TSVpFOiAxMC41cHQiPnRlbGVjaGF0PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1J TFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEw LjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3Nv ZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+aXM8bzpw PjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIHN0eWxlPSJNQVJHSU46IDBj bSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTog J01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0 Ij4mZ3Q7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9t YW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFO PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7 IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+dG9tb3Jyb3cuPG86cD48L286cD48L1NQ QU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIg Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQg WWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFN SUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAx MC41cHQiPiZndDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5l dyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8 L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3Nl cmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij48QSANCiAgaHJlZj0iaHR0cDov L3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9mL3RyYWMvd2lraSNPcGVyYXRpb25zYW5kTWFuYWdlbWVu dCI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9mL3RyYWMvd2lraSNPcGVyYXRpb25zYW5k TWFuYWdlbWVudDwvQT48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQ IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0 eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7 IEZPTlQtU0laRTogMTAuNXB0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPjwvRElW Pg0KICA8RElWPg0KICA8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9y bWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJp Zic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jmd0OzwvU1BBTj48U1BBTiANCiAg c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2 eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQt RkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpF OiAxMC41cHQiPi1NYXJjLTxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAg PFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAg c3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2 eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+PC9E SVY+DQogIDxESVY+DQogIDxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3Nl cmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mZ3Q7PG86cD4mbmJzcDs8L286 cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDBwdCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNy b3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jmd0 OzxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgc3R5bGU9 Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZP TlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1T SVpFOiAxMC41cHQiPiZndDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1Rp bWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4m bmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhl aScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48 L0RJVj4NCiAgPERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1z b05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywn c2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZndDs8L1NQQU4+PFNQQU4g DQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6 IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJG T05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQt U0laRTogMTAuNXB0Ij5sbWFwPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU aW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+ Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFI ZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+bWFpbGluZzwvU1BB Tj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYn OyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAg c3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2 eTsgRk9OVC1TSVpFOiAxMC41cHQiPmxpc3Q8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQog IDxESVY+DQogIDxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsg Q09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mZ3Q7PC9TUEFOPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBG T05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1J TFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEw LjVwdCI+PEEgDQogIGhyZWY9Im1haWx0bzpsbWFwQGlldGYub3JnIj5sbWFwQGlldGYub3JnPC9B PjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFN SUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAx MC41cHQiPiZndDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5l dyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8 L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3Nl cmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij48QSANCiAgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sbWFwIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2xtYXA8L0E+PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0K ICA8RElWPg0KICA8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFs PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7 IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9T UEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQi IGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3 IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwv U1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2Vy aWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwv UD48L0RJVj4NCiAgPERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNz PU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVp Jywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPi0tPC9TUEFOPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9S OiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05U LVNJWkU6IDEwLjVwdCI+PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8 UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5 OyBGT05ULVNJWkU6IDEwLjVwdCI+PEEgDQogIGhyZWY9Im1haWx0bzptYXJ0aW4uc3RpZW1lcmxp bmdAbmVjbGFiLmV1Ij5tYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1PC9BPjxvOnA+PC9vOnA+ PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAw cHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNw OzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywn c2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPjxvOnA+PC9vOnA+PC9TUEFO PjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNs YXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlh SGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPk5FQzwvU1BBTj48 U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBD T0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5 bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsg Rk9OVC1TSVpFOiAxMC41cHQiPkxhYm9yYXRvcmllczwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZP TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1T SVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAn TWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQi PkV1cm9wZTwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv bWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BB Tj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYn OyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPi08L1NQQU4+PFNQQU4gDQogIHN0eWxl PSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZP TlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlM WTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAu NXB0Ij5OZXR3b3JrPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBO ZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7 PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdz ZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+UmVzZWFyY2g8L1NQQU4+PFNQ QU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09M T1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxl PSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZP TlQtU0laRTogMTAuNXB0Ij5EaXZpc2lvbjwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFN SUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAx MC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9z b2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPk5FQzwv U1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2Vy aWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiAN CiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjog bmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPkV1cm9wZTwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZP TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1T SVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAn TWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQi PkxpbWl0ZWQ8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJG T05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQt U0laRTogMTAuNXB0Ij5SZWdpc3RlcmVkPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1J TFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEw LjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3Nv ZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+T2ZmaWNl OjwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywn c2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BB TiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xP UjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPk5FQzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZP TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1T SVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAn TWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQi PkhvdXNlLDwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv bWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BB Tj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYn OyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPjE8L1NQQU4+PFNQQU4gDQogIHN0eWxl PSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZP TlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlM WTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAu NXB0Ij5WaWN0b3JpYTwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNw OzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywn c2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPlJvYWQsPC9TUEFOPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9S OiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05U LVNJWkU6IDEwLjVwdCI+TG9uZG9uPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVw dCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQg WWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+VzM8L1NQQU4+ PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsg Q09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0 eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7 IEZPTlQtU0laRTogMTAuNXB0Ij42Qkw8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxE SVY+DQogIDxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQ QU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09M T1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij5SZWdpc3RlcmVkPC9TUEFOPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5 OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1G QU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6 IDEwLjVwdCI+aW48L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5l dyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8 L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3Nl cmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij5FbmdsYW5kPC9TUEFOPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9S OiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05U LVNJWkU6IDEwLjVwdCI+MjgzPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0K ICA8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBu YXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQ IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0 eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3NlcmlmJzsgQ09MT1I6IG5hdnk7 IEZPTlQtU0laRTogMTAuNXB0Ij5sbWFwPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1J TFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEw LjVwdCI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3Nv ZnQgWWFIZWknLCdzZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+bWFpbGlu ZzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywn c2VyaWYnOyBDT0xPUjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzwvU1BBTj48U1BB TiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWljcm9zb2Z0IFlhSGVpJywnc2VyaWYnOyBDT0xP UjogbmF2eTsgRk9OVC1TSVpFOiAxMC41cHQiPmxpc3Q8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9E SVY+DQogIDxESVY+DQogIDxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ01pY3Jvc29mdCBZYUhlaScsJ3Nl cmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTAuNXB0Ij48QSANCiAgaHJlZj0ibWFpbHRv OmxtYXBAaWV0Zi5vcmciPmxtYXBAaWV0Zi5vcmc8L0E+PG86cD48L286cD48L1NQQU4+PC9QPjwv RElWPg0KICA8RElWPg0KICA8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNv Tm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNaWNyb3NvZnQgWWFIZWknLCdz ZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwLjVwdCI+PEEgDQogIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1hcCI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sbWFwPC9BPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj48 L0RJVj48L0RJVj4NCiAgPFA+DQogIDxIUj4NCg0KICA8UD48L1A+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+bG1hcCBtYWlsaW5nIA0KICBsaXN0PEJS PmxtYXBAaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s bWFwPEJSPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_015F_01CE0059.45437060--