From acmorton@att.com Fri Feb 1 05:33: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 22A0F21F8A04 for ; Fri, 1 Feb 2013 05:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 NaSV2A6EOnOa for ; Fri, 1 Feb 2013 05:33:16 -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 5995321F8A0C for ; Fri, 1 Feb 2013 05:33:16 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 72C0A1205B1 for ; Fri, 1 Feb 2013 08:34:48 -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 0E4B3F00F1 for ; Fri, 1 Feb 2013 08:33: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; Fri, 1 Feb 2013 08:33:16 -0500 From: "MORTON JR., ALFRED (AL)" To: "lmap@ietf.org" Date: Fri, 1 Feb 2013 08:33:15 -0500 Thread-Topic: I-D Action: draft-morton-ippm-lmap-path-00.txt Thread-Index: Ac4AEnOcfQYpllI/Se2CDyE3Q3e/6gAbez9w Message-ID: References: <20130201002344.18146.17390.idtracker@ietfa.amsl.com> In-Reply-To: <20130201002344.18146.17390.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] FW: I-D Action: draft-morton-ippm-lmap-path-00.txt 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 13:33:17 -0000 LMAP-list, This draft describes another element needed for large-scale measurement. Comments are welcome, but probably on one list, also announced on ippm... regards, Al > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] > On Behalf Of internet-drafts@ietf.org > Sent: Thursday, January 31, 2013 7:24 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-morton-ippm-lmap-path-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : A Reference Path and Measurement Points for LMAP > Author(s) : Marcelo Bagnulo > Trevor Burbridge > Sam Crawford > Phil Eardley > Al Morton > Filename : draft-morton-ippm-lmap-path-00.txt > Pages : 10 > Date : 2013-01-31 >=20 > Abstract: > This document defines a reference path for Large-scale Measurement of > Broadband Access Performance (LMAP) and measurement points for > commonly used performance metrics. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-morton-ippm-lmap-path >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-morton-ippm-lmap-path-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From bs7652@att.com Fri Feb 1 07:42:19 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 F085E21F8D3F for ; Fri, 1 Feb 2013 07:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.932 X-Spam-Level: X-Spam-Status: No, score=-106.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 9+gXTDUSNKCi for ; Fri, 1 Feb 2013 07:42:18 -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 BCB6D21F8D5F for ; Fri, 1 Feb 2013 07:42:18 -0800 (PST) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id a52eb015.2aaad795d940.2567442.00-506.7123656.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 01 Feb 2013 15:42:18 +0000 (UTC) X-MXL-Hash: 510be25a2ae05cb1-72f522857ec057f82f2c569768d020f5715c34b2 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 952eb015.0.2567431.00-379.7123612.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 01 Feb 2013 15:42:18 +0000 (UTC) X-MXL-Hash: 510be25a7f523b85-d8b57bf2c7830fab1120f8b3fc8ac9cc73b3fb0b 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 r11FgFRu017259; Fri, 1 Feb 2013 10:42:17 -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 r11FgBM0017181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2013 10:42:12 -0500 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by sflint04.pst.cso.att.com (RSA Interceptor); Fri, 1 Feb 2013 10:33:05 -0500 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.02.0328.009; Fri, 1 Feb 2013 10:33:01 -0500 From: "STARK, BARBARA H" To: "Romascanu, Dan (Dan)" , marcelo bagnulo braun , "lmap@ietf.org" Thread-Topic: [lmap] IPFIX vs LMAP Thread-Index: AQHN/2Veep3JJoFvakuvfwxk9s3WqJhjncSAgAAvKYCAAAwggIABPg1g Date: Fri, 1 Feb 2013 15:33:00 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130239F8A@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <20130130181218.GA21225@elstar.local> <9BD4DA72C6214364A07889F73338342A@LENOVO47E041CF> <510A5279.5040906@cisco.com> <510A7A09.60300@it.uc3m.es> <9904FB1B0159DA42B0B887B7FA8119CA07BAAC@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA07BAAC@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.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=OKOQK1mB 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=VCknP5uVr] X-AnalysisOut: [o8A:10 a=48vgC7mUAAAA:8 a=Zrl4AWY-ZX-6_hL-R_IA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10] 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: Fri, 01 Feb 2013 15:42:20 -0000 > So can't LMAP use YANG to specify the data format that will define and > trigger execution of the tests, and IPFIX to report the results of the te= sts? >=20 > We are already facing a multiplication of protocols from the IETF and oth= er > SDOs, and this is not a good thing - not for operators, not for vendors. > Reusing existing protocols and writing data models in already existing da= ta > modeling languages should be preferred, I believe. If the data elements that are needed for configuration and control (trigger= ing execution, etc.) could be identified, it's rather easy to put them into= a format suitable for use with all sorts of protocols, including (but cert= ainly not limited to) netconf, TR-069, OMA-DM, and SNMP. If the data elements that need to be collected and reported could be identi= fied, it's rather easy to figure out how to collect/report them using all s= orts of protocols, including IPFIX and IPDR. I absolutely agree that we should avoid defining yet another new protocol f= or these functions. If "near real time" triggering is needed from a "contro= l" protocol (external to the protocol used to actually run a test), in conj= unction with some clock synchronization, that might require some tweaking o= f an existing protocol -- I don't know yet, and would need more input from = the people with expertise in running measurements. I have no objection to or comment on an IETF recommendation regarding use o= f IPFIX for LMAP. But please expect other SDOs/SIGs to also make protocol r= ecommendations. And the market-place will pick the winner(s). Service provi= ders who already have an extensive embedded base of devices that use certai= n protocols for existing configuration, control, and data collection will l= ikely prefer to continue to use those protocols, and just add the additiona= l data elements -- especially where the measurement capabilities are added = to these existing devices. As long as the data elements, measurements, and = high level operational architecture (consisting of broadly-defined operatio= nal functions) are reasonably common, there will be multiple operational (c= onfiguration, data collection, etc.) protocol options available. There does= seem to be strong agreement in orgs I'm familiar with that IETF has strong= expertise in ippm for helping to identify measurements and related data el= ements. I think http://tools.ietf.org/html/draft-morton-ippm-lmap-path-00 i= s very helpful towards that goal. Barbara From dengguangqing@cnnic.cn Mon Feb 4 00:00:22 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 638EF21F881A for ; Mon, 4 Feb 2013 00:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.215 X-Spam-Level: **** X-Spam-Status: No, score=4.215 tagged_above=-999 required=5 tests=[AWL=-3.786, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345] 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 S6lMzZdQ7eEg for ; Mon, 4 Feb 2013 00:00:21 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 8CB2321F884A for ; Mon, 4 Feb 2013 00:00:17 -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; Mon, 04 Feb 2013 16:00:10 +0800 Date: Mon, 4 Feb 2013 16:00:09 +0800 From: "Guangqing Deng" To: "philip.eardley@bt.com" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA07AA5F@AZ-FFEXMB04.global.avaya.com>, <510932DE.8050300@neclab.eu> <201301312134328526701@cnnic.cn>, <9510D26531EF184D9017DF24659BB87F341A04BC7E@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: <201302041600085138026@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart234400146083_=----" Subject: [lmap] =?gb2312?b?u9i4tDogUmU6ICBCT0YgUmVxdWVzdA==?= 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, 04 Feb 2013 08:00:22 -0000 This is a multi-part message in MIME format. ------=_001_NextPart234400146083_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIHBoaWwsIHRoYW5rIHlvdSBmb3IgeW91ciBhdHRlbnRpb24uIFVuZm9ydHVuYXRlbHksIHRo ZXJlIGlzIG5vdCBhIHdoaXRlcGFwZXIgYWJvdXQgdGhpcyBtZWFzdXJlbWVudCBzeXN0ZW0gYXQg dGhlIG1vbWVudC4gVGhlbiBJoa9kIGxpa2UgdG8gZ2l2ZSBhIGJyaWVmIGludHJvZHVjdGlvbiBv ZiB0aGlzIHN5c3RlbSB3aG9zZSBhcmNoaXRlY3R1cmUgaXMgc2ltaWxhciB0byB0aGUgb25lIHN0 YXRlZCBpbiBkcmFmdC1zY2h1bHpyaW5uZS1sbWFwLXJlcXVpcmVtZW50cy0wMC4gQmFzaWNhbGx5 LCB0aGVyZSBhcmUgZm91ciBjb21wb25lbnRzIGluIHRoaXMgc3lzdGVtOiBNZWFzdXJlbWVudCBD b250cm9sbGVyLCBEYXRhIENvbGxlY3RvciwgTWVhc3VyZW1lbnQgQ2xpZW50IGFuZCBNZWFzdXJl bWVudCBTZXJ2ZXIuIEp1c3QgYXMgc2FpZCBpbiB0aGUgYWJvdmUgZHJhZnQsIHRoZSBNZWFzdXJl bWVudCBDb250cm9sbGVyIGFuZCB0aGUgRGF0YSBDb2xsZWN0b3IgYXJlIGdlbmVyYWxseSB1c2Vk IHRvIHNlbmQgaW5zdHJ1Y3Rpb25zIHRvIGFuZCBjb2xsZWN0IHJhdyBtZWFzdXJlbWVudCBkYXRh IGZyb20gdGhlIE1lYXN1cmVtZW50IENsaWVudCwgcmVzcGVjdGl2ZWx5LiBJbiBvdXIgc3lzdGVt LCB0aGUgTWVhc3VyZW1lbnQgQ2xpZW50IGlzIHNvZnR3YXJlLWJhc2VkIGFuZCBpbnN0YWxsZWQg b24gdm9sdW50ZWVyc6GvIGVuZCBob3N0cyAod2hpY2ggYXJlIHVzdWFsbHkgZGVza3RvcHMgYW5k IGxhcHRvcHMpLiBUaGUgTWVhc3VyZW1lbnQgU2V2ZXIgY2FuIGJlIGRpdmlkZWQgaW50byB0d28g a2luZHM6IHRoZSBmaXJzdCBraW5kIGlzIHRoZSBkZWRpY2F0ZWQgbWVhc3VyZW1lbnQgc2VydmVy cyBkZXBsb3llZCBieSB1czsgdGhlIHNlY29uZCBraW5kIGlzIHdlYiBzZXJ2ZXJzIGRlcGxveWVk IGJ5IG90aGVyIHNlcnZpY2UgcHJvdmlkZXJzIGluIHRoZSBJbnRlcm5ldC4gT2YgY291cnNlLCB0 aGUgbnVtYmVyIG9mIHRoZSBmaXJzdCBraW5kIG9mIHNlcnZlcnMgaXMgbXVjaCBzbWFsbGVyIHRo YW4gdGhhdCBvZiB0aGUgc2Vjb25kIGtpbmQuIFdlIGhhdmUgZG9uZSBzZXZlcmFsIG5ldHdvcmsg bWVhc3VyZW1lbnRzIGJ5IHRoaXMgc3lzdGVtLiBGb3IgaW5zdGFuY2UsIHdpdGggbmVhcmx5IDYw LDAwMCBNZWFzdXJlbWVudCBDbGllbnRzLCB3ZSBkaWQgYSBtZWFzdXJlbWVudCBhdCB0aGUgZW5k IG9mIDIwMTEgdG8gZXZhbHVhdGUgdGhlIHVzZXItcGVyY2VpdmVkIGJhbmR3aWR0aCwgdG8gbW9u aXRvciB0aGUgcGVyZm9ybWFuY2UgZHluYW1pY3Mgb2YgdGhlIGNvcmUgbmV0d29yayBhbmQgdG8g Y29tcGFyZSB0aGUgdXNlciBwZXJjZWl2ZWQgcXVhbGl0eSBvZiBzZXJ2aWNlIChRb1MpIG9mIGRp ZmZlcmVudCBzZXJ2aWNlIHByb3ZpZGVycyAod2hpY2ggcHJvdmlkZSB3ZWIgc2VydmljZXMgbGlr ZSB3ZWIgYnJvd3NpbmcsIGZpbGUgc2hhcmluZyBhbmQgdmlkZW8gc3RyZWFtaW5nLCBldGMpLiBU byBhY2hpZXZlIGFib3ZlIG9iamVjdHMsIGVhY2ggTWVhc3VyZW1lbnQgQ2xpZW50IHJlcG9ydHMg ZG96ZW5zIG9mIGtpbmRzIG9mIGRhdGEgc2VnbWVudHMgKGluIHRlcm1zIG9mIGtleSB2YWx1ZSBw YWlycykgc3VjaCBhcyBwaW5nIGxhdGVuY3ksIHRyYWNlcm91dGUgZGF0YSwgRE5TIHJlc29sdmlu ZyB0aW1lLCBUQ1AgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IHRpbWUgYW5kIHNvIG9uIHRvIHRo ZSBEYXRhIENvbGxlY3RvciBzZXJ2ZXIuIEFib3ZlIGlzIGEgYnJpZWYgaW50cm9kdWN0aW9uIG9m IG91ciBzeXN0ZW0sIHBsZWFzZSBmZWVsIGZyZWUgdG8gdGFsayBhYm91dCB5b3VyIG9waW5pb25z Lg0KDQoNCg0KDQpHdWFuZ3FpbmcgRGVuZw0KQ05OSUMgDQoNCreivP7Iy6O6IHBoaWxpcC5lYXJk bGV5QGJ0LmNvbQ0Kt6LLzcqxvOSjuiAyMDEzLTAxLTMxIDIzOjQyDQrK1bz+yMujuiBkZW5nZ3Vh bmdxaW5nQGNubmljLmNuOyBsbWFwQGlldGYub3JnDQrW98zio7ogUmU6IFtsbWFwXSBCT0YgUmVx dWVzdA0KZG8geW91IGhhdmUgYSB3aGl0ZXBhcGVyIGFib3V0IHlvdXIgc3lzdGVtPyBJoa9tIGlu dGVyZXN0ZWQgdG8gdW5kZXJzdGFuZCB3aGF0IHlvdXIgZnJhbWV3b3JrIGlzLCB3aGF0IHlvdSBt ZWFzdXJlIGFuZCBob3cgeW91IHJlcG9ydCwgd2hldGhlciB0aGVzZSBhcmUgc29mdHdhcmUgb3Ig aGFyZHdhcmUgYmFzZWQgTUFzLCBldGMNCnRoYW5rcw0KcGhpbA0KRnJvbTogbG1hcC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bG1hcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3Vh bmdxaW5nIERlbmcNClNlbnQ6IDMxIEphbnVhcnkgMjAxMyAxMzozNQ0KVG86IGxtYXBAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbbG1hcF0gQk9GIFJlcXVlc3QNCiANCkdyZWF0IG5ld3MhIEkgYW0g aW50ZXJlc3RlZCBpbiB0aGUgbmV0d29yayBtZWFzdXJlbWVudCBhbmQgaGF2ZSBkb25lIHNldmVy YWwgbGFyZ2Ugc2NhbGUgbWVhc3VyZW1lbnRzICh0b2dldGhlciB3aXRoIG15IGNvbGxlYWd1ZXMp IHRvd2FyZHMgYnJvYWRiYW5kIG5ldHdvcmsgcGVyZm9ybWFuY2Ugd2l0aCBzZXZlcmFsIG1lYXN1 cmVtZW50IGNvbGxlY3RvcnMsIGNvbnRyb2xsZXJzIGFuZCBuZWFybHkgNjAgdGhvdXNhbmRzIG9m IG1lYXN1cmVtZW50IGFnZW50cyAoTUEpLiBPZiBjb3Vyc2UsIHRoZSBwcm90b2NvbCB1c2VkIHRv IGNvbm5lY3QgdGhlIGNvbXBvbmVudHMgKG5hbWVseSB0aGUgY29udHJvbGxlciwgY29sbGVjdG9y IGFuZCBNQSkgaXMgcHJpdmF0ZS4gV2l0aCBzb21lIGV4cGVyaWVuY2UgZ2FpbmVkIGZyb20gc3Vj aCBtZWFzdXJlbWVudHMsIEkgd291bGQgbGlrZSB0byBkbyBzb21lIGNvbnRyaWJ1dGlvbiB0byB0 aGUgc3RhbmRhcmRpemF0aW9uIG9mIHRoZSBuZXR3b3JrIG1lYXN1cmVtZW50IHByb3RvY29sIHdp dGhpbiB0aGlzIFdHLg0KIA0KDQoNCg0KR3VhbmdxaW5nIERlbmcNCmNubmljIA0KIA0KRnJvbTog TWFydGluIFN0aWVtZXJsaW5nDQpEYXRlOiAyMDEzLTAxLTMwIDIyOjQ5DQpUbzogbG1hcEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtsbWFwXSBCT0YgUmVxdWVzdA0KIA0KIA0KT24gMDEvMzAvMjAx MyAwMzozMSBQTSwgUm9tYXNjYW51LCBEYW4gKERhbikgd3JvdGU6DQo+IEFjdHVhbGx5IGl0knMN Cj4gDQo+IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2JvZi90cmFjL3dpa2kjVHJhbnNwb3J0 DQo+IA0KPiBpc26SdCBpdD8NCiANClJpZ2h0LCBhdCBsZWFzdCBmb3Igbm93IHVudGlsIHdlIGhh dmUgZmlndXJlZCBvdXQgaWYgdGhpcyBsaXZlcyBpbiANClRyYW5zcG9ydCBvciBPUFMuDQogDQog ICBNYXJ0aW4NCiANCj4gDQo+IERhbg0KPiANCj4gKkZyb206KmxtYXAtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZg0KPiBPZiAqTWFyYyBM aW5zbmVyDQo+ICpTZW50OiogV2VkbmVzZGF5LCBKYW51YXJ5IDMwLCAyMDEzIDQ6MjEgUE0NCj4g KlRvOiogbG1hcEBpZXRmLm9yZw0KPiAqU3ViamVjdDoqIFtsbWFwXSBCT0YgUmVxdWVzdA0KPiAN Cj4gV2Ugc3VibWl0dGVkIGEgcmVxdWVzdCBmb3IgYSBzZXNzaW9uIGF0IE9ybGFuZG8uICBUaGUg QUQgdGVsZWNoYXQgaXMNCj4gdG9tb3Jyb3cuDQo+IA0KPiBodHRwOi8vdHJhYy50b29scy5pZXRm Lm9yZy9ib2YvdHJhYy93aWtpI09wZXJhdGlvbnNhbmRNYW5hZ2VtZW50DQo+IA0KPiAtTWFyYy0N Cj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gbG1hcCBtYWlsaW5nIGxpc3QNCj4gbG1hcEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXANCj4gDQogDQotLSANCm1hcnRpbi5zdGll bWVybGluZ0BuZWNsYWIuZXUNCiANCk5FQyBMYWJvcmF0b3JpZXMgRXVyb3BlIC0gTmV0d29yayBS ZXNlYXJjaCBEaXZpc2lvbiBORUMgRXVyb3BlIExpbWl0ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBO RUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwgTG9uZG9uIFczIDZCTA0KUmVnaXN0ZXJlZCBpbiBF bmdsYW5kIDI4Mw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCmxtYXAgbWFpbGluZyBsaXN0DQpsbWFwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2xtYXA= ------=_001_NextPart234400146083_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, phil, thank you for your attention. Unfortuna= tely,=20 there is not a whitepaper about this measurement system at the moment. The= n I=A1=AFd=20 like to give a brief introduction of this system whose architecture is sim= ilar=20 to the one stated in draft-schulzrinne-lmap-requirements-00. Basically, th= ere=20 are four components in this system: Measurement Controller, Data Collector= ,=20 Measurement Client and Measurement Server. Just as said in the above draft= , the=20 Measurement Controller and the Data Collector are generally used to send=20 instructions to and collect raw measurement data from the Measurement Clie= nt,=20 respectively. In our system, the Measurement Client is software-based and=20 installed on volunteers=A1=AF end hosts (which are usually desktops and la= ptops). The=20 Measurement Sever can be divided into two kinds: the first kind is the ded= icated=20 measurement servers deployed by us; the second kind is web servers deploye= d by=20 other service providers in the Internet. Of course, the number of the firs= t kind=20 of servers is much smaller than that of the second kind. We have done seve= ral=20 network measurements by this system. For instance, with nearly 60,000=20 Measurement Clients, we did a measurement at the end of 2011 to evaluate t= he=20 user-perceived bandwidth, to monitor the performance dynamics of the core=20 network and to compare the user perceived quality of service (QoS) of diff= erent=20 service providers (which provide web services like web browsing, file shar= ing=20 and video streaming, etc). To achieve above objects, each Measurement Clie= nt=20 reports dozens of kinds of data segments (in terms of key value pairs) suc= h as=20 ping latency, traceroute data, DNS resolving time, TCP connection establis= hment=20 time and so on to the Data Collector server. Above is a brief introduction= of=20 our system, please feel free to talk about your opinions.

 
Guangqing=20 Deng
CNN= IC 
 
=B7=A2=BC=FE=C8=CB=A3=BA philip.eardley@bt.com
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2013-01-31 23:42
=CA=D5=BC=FE=C8=CB=A3=BA dengguangqing@cnnic.cn; lmap@ietf.org
=D6=F7=CC=E2=A3=BA Re: [lmap] BOF Request

do=20 you have a whitepaper about your system? I=A1=AFm interested to understand= what your=20 framework is, what you measure and how you report, whether these are softw= are or=20 hardware based MAs, etc

thanks

phil

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

 

Great=20 news! I am interested in the network measurement and have done several lar= ge=20 scale measurements (together with my colleagues) towards broadband network= =20 performance with several measurement collectors, controllers and nearly 60= =20 thousands of measurement agents (MA). Of course, the protocol used to conn= ect=20 the components (namely the controller, collector and MA) is private. With = some=20 experience gained from such measurements, I would like to do some contribu= tion=20 to the standardization of the network measurement protocol within this=20 WG.

 

Guangqing Deng
cnnic 

 

From: Martin=20 Stiemerling

Date: 2013-01-30 22:49

To: lmap@ietf.org

Subject: Re:=20 [lmap] BOF Request

 

 

On 01/30/2013 03:31 PM, Romascanu, Dan (Dan) wrote:

> Actually it=92s

> 

> http://trac.to= ols.ietf.org/bof/trac/wiki#Transport

> 

> isn=92t 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<= /o:p>

> 

> -Marc-

> 

> 

> 

> _______________________________________________

> lmap mailing list

> lmap@ietf.org

> https://www.ietf.org/m= ailman/listinfo/lmap

> 

 

-- 

martin.stiemerling@neclab.eu<= /A>

 

NEC Laboratories Europe - Network Research Division NEC Europe Limited

Registered Office: NEC House, 1 Victoria Road, London W3 6BL

Registered in England 283

_______________________________________________

lmap mailing list

lmap@ietf.org

https://www.ietf.org/m= ailman/listinfo/lmap

------=_001_NextPart234400146083_=------ From Michael.K.Bugenhagen@centurylink.com Mon Feb 4 08:52:31 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 120AD21F8569 for ; Mon, 4 Feb 2013 08:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.600, 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 hEZogVFjmV6S for ; Mon, 4 Feb 2013 08:52:30 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id D82D621F855F for ; Mon, 4 Feb 2013 08:52:29 -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 r14GqLdU024052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 09:52:21 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 0BCB71E0060; Mon, 4 Feb 2013 09:52:07 -0700 (MST) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id E07D51E005F; Mon, 4 Feb 2013 09:52:06 -0700 (MST) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r14Gq6hu022359; Mon, 4 Feb 2013 09:52:06 -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 r14Gq6oE022351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Feb 2013 09:52:06 -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; Mon, 4 Feb 2013 10:52:06 -0600 From: "Bugenhagen, Michael K" To: "'James Miller'" , Marc Linsner Thread-Topic: a note on buffer bloat Thread-Index: AQHOAvf2BoEReNYx/kevrJpOrGkVVQ== Date: Mon, 4 Feb 2013 16:52:05 +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: multipart/alternative; boundary="_000_A68F3CAC468B2E48BB775ACE2DD99B5E046676EBpodcwmbxex505ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'mattmathis@google.com'" , 'Al Morton' , "lmap@ietf.org" Subject: [lmap] a note on buffer bloat 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, 04 Feb 2013 16:52:31 -0000 --_000_A68F3CAC468B2E48BB775ACE2DD99B5E046676EBpodcwmbxex505ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, Marc, At the last IETF meeting we had a discussion on buffer bloat now being an i= ssue. I'm now hearing that this may have been part of some newly deployed technol= ogies and the tweaks to those implementations have fixed the issue. I'm hoping that someone can validate that in the Next IETF meeting, was it = a transitional problem, or is it still an issue. Thanks, Mike --_000_A68F3CAC468B2E48BB775ACE2DD99B5E046676EBpodcwmbxex505ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

James, Marc,

 <= /p>

At the last IETF meeting = we had a discussion on buffer bloat now being an issue.

I’m now hearing tha= t this may have been part of some newly deployed technologies and the tweak= s to those implementations have fixed the issue.

 <= /p>

I’m hoping that som= eone can validate that in the Next IETF meeting, was it a transitional prob= lem, or is it still an issue.

 <= /p>

Thanks,=

Mike

--_000_A68F3CAC468B2E48BB775ACE2DD99B5E046676EBpodcwmbxex505ct_-- From hannes.tschofenig@gmx.net Mon Feb 4 08:58: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 D943921F8996 for ; Mon, 4 Feb 2013 08:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.326 X-Spam-Level: X-Spam-Status: No, score=-102.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, 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 1NsYnUN-DZF5 for ; Mon, 4 Feb 2013 08:58:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB5821F8939 for ; Mon, 4 Feb 2013 08:58:51 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0La1J5-1Ugege2iGj-00lp5M for ; Mon, 04 Feb 2013 17:58:49 +0100 Received: (qmail invoked by alias); 04 Feb 2013 16:58:49 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.100]) [88.115.219.140] by mail.gmx.net (mp027) with SMTP; 04 Feb 2013 17:58:49 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19cdJoS/Flc0P8IGiWtv02Yc8aSMAu0SdDtylNyiK YG1wbczOeNlVBQ Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: Date: Mon, 4 Feb 2013 18:58:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5803178D-09D8-4DBD-BBEC-1F72E8F18C4B@gmx.net> References: To: "Bugenhagen, Michael K" X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: 'Al Morton' , 'James Miller' , "lmap@ietf.org" , Marc Linsner , "'mattmathis@google.com'" , Hannes Tschofenig Subject: Re: [lmap] a note on buffer bloat 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, 04 Feb 2013 16:58:52 -0000 Hi Michael,=20 have a look at the recently updated congestion control workshop were we = discussed this and similar issues: http://tools.ietf.org/html/draft-iab-cc-workshop-report-00 Ciao Hannes On Feb 4, 2013, at 6:52 PM, Bugenhagen, Michael K wrote: > James, Marc, > =20 > At the last IETF meeting we had a discussion on buffer bloat now being = an issue. > I=92m now hearing that this may have been part of some newly deployed = technologies and the tweaks to those implementations have fixed the = issue. > =20 > I=92m hoping that someone can validate that in the Next IETF meeting, = was it a transitional problem, or is it still an issue. > =20 > Thanks, > Mike > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From Henning.Schulzrinne@fcc.gov Mon Feb 4 09:23: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 B658421F8949 for ; Mon, 4 Feb 2013 09:23:12 -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 9FE8t3UINg+F for ; Mon, 4 Feb 2013 09:23:11 -0800 (PST) Received: from dmz-mail1.fcc.gov (dmz-mail1.fcc.gov [192.104.54.105]) by ietfa.amsl.com (Postfix) with ESMTP id AD6EB21F88B2 for ; Mon, 4 Feb 2013 09:23:11 -0800 (PST) Received: from P2PXMB13.fccnet.win.fcc.gov ([fe80::6593:6526:65f8:66b7]) by p2pxcas01.fccnet.win.fcc.gov ([fe80::1d27:de47:ad2e:9062%13]) with mapi id 14.01.0438.000; Mon, 4 Feb 2013 12:23:09 -0500 From: Henning Schulzrinne To: "Bugenhagen, Michael K" , 'James Miller' , Marc Linsner Thread-Topic: a note on buffer bloat Thread-Index: AQHOAvgOuacX/RFmJ0mndx5/DQbNpZhp8HXd Date: Mon, 4 Feb 2013 17:23:08 +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: [192.104.54.63] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" , "'mattmathis@google.com'" , 'Al Morton' Subject: Re: [lmap] a note on buffer bloat 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, 04 Feb 2013 17:23:14 -0000 For one recent perspective, see: Mark Allman. Comments on Bufferbloat, ACM SIGCOMM Computer Communication R= eview, 43(1), January 2013. http://www.icir.org/mallman/papers/bufferbloat-ccr13.pdf My summary would be: it occurs, but may not be quite as common as sometimes= claimed. There are also some fairly easy fixes (smaller buffers) and some = more complicated ones (new TCP). ________________________________ From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Bugenhagen= , Michael K [Michael.K.Bugenhagen@centurylink.com] Sent: Monday, February 04, 2013 11:52 AM To: 'James Miller'; Marc Linsner Cc: 'mattmathis@google.com'; 'Al Morton'; lmap@ietf.org Subject: [lmap] a note on buffer bloat James, Marc, At the last IETF meeting we had a discussion on buffer bloat now being an i= ssue. I=92m now hearing that this may have been part of some newly deployed techn= ologies and the tweaks to those implementations have fixed the issue. I=92m hoping that someone can validate that in the Next IETF meeting, was i= t a transitional problem, or is it still an issue. Thanks, Mike From nweaver@icsi.berkeley.edu Mon Feb 4 09:42:53 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 F3D9321F881C for ; Mon, 4 Feb 2013 09:42:52 -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 Uep3LG+aubZW for ; Mon, 4 Feb 2013 09:42:52 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCB921F84B2 for ; Mon, 4 Feb 2013 09:42:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 55CFE2C4006; Mon, 4 Feb 2013 09:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UKTaIgUuecHt; Mon, 4 Feb 2013 09:42:52 -0800 (PST) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 0A8822C4002; Mon, 4 Feb 2013 09:42:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Nicholas Weaver In-Reply-To: Date: Mon, 4 Feb 2013 09:42:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <00BB7722-5A78-4034-8227-8264DB44A26F@icsi.berkeley.edu> References: , To: Henning Schulzrinne X-Mailer: Apple Mail (2.1283) Cc: Nicholas Weaver , 'Al Morton' , 'James Miller' , "lmap@ietf.org" , Marc Linsner , "'mattmathis@google.com'" , "Bugenhagen, Michael K" Subject: Re: [lmap] a note on buffer bloat 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, 04 Feb 2013 17:42:53 -0000 On Feb 4, 2013, at 9:23 AM, Henning Schulzrinne wrote: > For one recent perspective, see: >=20 >=20 > Mark Allman. Comments on Bufferbloat, ACM SIGCOMM Computer = Communication Review, 43(1), January 2013. >=20 > http://www.icir.org/mallman/papers/bufferbloat-ccr13.pdf >=20 >=20 > My summary would be: it occurs, but may not be quite as common as = sometimes claimed. There are also some fairly easy fixes (smaller = buffers) and some more complicated ones (new TCP). It also depends on how much latency under load you can tolerate. If you can tolerate 100ms of additional latency under load (the 90% = solution) there is a ton of available options out there, from just = shorter buffers sized in delays to cool stuff like Remote Active Queue = Management. If you need 20ms or less of latency under load, you need multiple queues = in the bottleneck and smart queue management that can recognize (or is = suitably marked) the realtime traffic and make sure it doesn't see = induced delays when the bottleneck is congested. From Michael.K.Bugenhagen@centurylink.com Mon Feb 4 10:30:33 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 8EE9821F8A84 for ; Mon, 4 Feb 2013 10:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 yuwYngICZPS0 for ; Mon, 4 Feb 2013 10:30:33 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id D40D121F8A74 for ; Mon, 4 Feb 2013 10:30:32 -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 r14IUTrP003969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 12:30:29 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id D8A5E1E005D; Mon, 4 Feb 2013 12:30:23 -0600 (CST) Received: from sudnp797.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 98DB01E0069; Mon, 4 Feb 2013 12:30:23 -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 r14IUNAg007624; Mon, 4 Feb 2013 11:30:23 -0700 (MST) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.qintra.com [151.117.206.28]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r14IUMbS007618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Feb 2013 11:30:22 -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; Mon, 4 Feb 2013 12:30:22 -0600 From: "Bugenhagen, Michael K" To: "'Henning Schulzrinne'" , "'James Miller'" , Marc Linsner Thread-Topic: a note on buffer bloat Thread-Index: AQHOAvf2BoEReNYx/kevrJpOrGkVVZhqVz4A//+tQ9A= Date: Mon, 4 Feb 2013 18:30:21 +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" , "'mattmathis@google.com'" , 'Al Morton' Subject: Re: [lmap] a note on buffer bloat 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, 04 Feb 2013 18:30:33 -0000 Henning, Yes that reflects what I heard, the best practices now reflect the small= er settings and only operators who haven't picked that up yet would still h= ave a problem. Good test problem to solve (at test that could conclude buffer bloat), but= the problem may now be much less prolific, that is unless a new technology= brings the issue back. Regards, and thanks, Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Monday, February 04, 2013 11:23 AM To: Bugenhagen, Michael K; 'James Miller'; Marc Linsner Cc: 'mattmathis@google.com'; 'Al Morton'; lmap@ietf.org Subject: RE: a note on buffer bloat For one recent perspective, see: Mark Allman. Comments on Bufferbloat, ACM SIGCOMM Computer Communication R= eview, 43(1), January 2013. http://www.icir.org/mallman/papers/bufferbloat-ccr13.pdf My summary would be: it occurs, but may not be quite as common as sometimes= claimed. There are also some fairly easy fixes (smaller buffers) and some = more complicated ones (new TCP). ________________________________ From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Bugenhagen= , Michael K [Michael.K.Bugenhagen@centurylink.com] Sent: Monday, February 04, 2013 11:52 AM To: 'James Miller'; Marc Linsner Cc: 'mattmathis@google.com'; 'Al Morton'; lmap@ietf.org Subject: [lmap] a note on buffer bloat James, Marc, At the last IETF meeting we had a discussion on buffer bloat now being an i= ssue. I'm now hearing that this may have been part of some newly deployed technol= ogies and the tweaks to those implementations have fixed the issue. I'm hoping that someone can validate that in the Next IETF meeting, was it = a transitional problem, or is it still an issue. Thanks, Mike From Henning.Schulzrinne@fcc.gov Mon Feb 4 11:11: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 9483121F873B for ; Mon, 4 Feb 2013 11:11:14 -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 gb8CctxKUxOU for ; Mon, 4 Feb 2013 11:11:13 -0800 (PST) Received: from dmz-mail1.fcc.gov (dmz-mail1.fcc.gov [192.104.54.105]) by ietfa.amsl.com (Postfix) with ESMTP id 3559F21F86E3 for ; Mon, 4 Feb 2013 11:11:12 -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; Mon, 4 Feb 2013 14:11:11 -0500 From: Henning Schulzrinne To: "Bugenhagen, Michael K" , 'James Miller' , Marc Linsner Thread-Topic: a note on buffer bloat Thread-Index: AQHOAvgOuacX/RFmJ0mndx5/DQbNpZhp8HXdgABozYD//7arxA== Date: Mon, 4 Feb 2013 19:11:11 +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: [192.104.54.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" , "'mattmathis@google.com'" , 'Al Morton' Subject: Re: [lmap] a note on buffer bloat 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, 04 Feb 2013 19:11:14 -0000 I suspect there are still a fair number of cable/DSL modems out there that = have excessive buffers and offer no DiffServ; I see bufferbloat more as a n= etwork failure mode rather than an average performance issue.=0A= =0A= ________________________________________=0A= From: Bugenhagen, Michael K [Michael.K.Bugenhagen@centurylink.com]=0A= Sent: Monday, February 04, 2013 1:30 PM=0A= To: Henning Schulzrinne; 'James Miller'; Marc Linsner=0A= Cc: 'mattmathis@google.com'; 'Al Morton'; lmap@ietf.org=0A= Subject: RE: a note on buffer bloat=0A= =0A= Henning,=0A= =0A= Yes that reflects what I heard, the best practices now reflect the small= er settings and only operators who haven't picked that up yet would still h= ave a problem.=0A= =0A= Good test problem to solve (at test that could conclude buffer bloat), but= the problem may now be much less prolific, that is unless a new technology= brings the issue back.=0A= =0A= Regards, and thanks,=0A= Mike=0A= =0A= =0A= =0A= =0A= =0A= -----Original Message-----=0A= From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=0A= Sent: Monday, February 04, 2013 11:23 AM=0A= To: Bugenhagen, Michael K; 'James Miller'; Marc Linsner=0A= Cc: 'mattmathis@google.com'; 'Al Morton'; lmap@ietf.org=0A= Subject: RE: a note on buffer bloat=0A= =0A= For one recent perspective, see:=0A= =0A= =0A= Mark Allman. Comments on Bufferbloat, ACM SIGCOMM Computer Communication R= eview, 43(1), January 2013.=0A= =0A= http://www.icir.org/mallman/papers/bufferbloat-ccr13.pdf=0A= =0A= =0A= My summary would be: it occurs, but may not be quite as common as sometimes= claimed. There are also some fairly easy fixes (smaller buffers) and some = more complicated ones (new TCP).=0A= =0A= ________________________________=0A= From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Bugenhagen= , Michael K [Michael.K.Bugenhagen@centurylink.com]=0A= Sent: Monday, February 04, 2013 11:52 AM=0A= To: 'James Miller'; Marc Linsner=0A= Cc: 'mattmathis@google.com'; 'Al Morton'; lmap@ietf.org=0A= Subject: [lmap] a note on buffer bloat=0A= =0A= James, Marc,=0A= =0A= At the last IETF meeting we had a discussion on buffer bloat now being an i= ssue.=0A= I'm now hearing that this may have been part of some newly deployed technol= ogies and the tweaks to those implementations have fixed the issue.=0A= =0A= I'm hoping that someone can validate that in the Next IETF meeting, was it = a transitional problem, or is it still an issue.=0A= =0A= Thanks,=0A= Mike=0A= From sharam.hakimi@exfo.com Mon Feb 4 13:03: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 E0BF621F8A1C for ; Mon, 4 Feb 2013 13:03:40 -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.900, 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 g6pn+dOkK1Y0 for ; Mon, 4 Feb 2013 13:03:40 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 0711121F84B9 for ; Mon, 4 Feb 2013 13:03:39 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Feb 2013 16:03:38 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Feb 2013 16:03:38 -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, 4 Feb 2013 15:57:32 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA0231067D@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] a note on buffer bloat Thread-Index: AQHOAvgOuacX/RFmJ0mndx5/DQbNpZhp8HXdgABozYD//7arxIAAHD1w References: , , From: "Sharam Hakimi" To: "Henning Schulzrinne" , "Bugenhagen, Michael K" , "James Miller" , "Marc Linsner" X-OriginalArrivalTime: 04 Feb 2013 21:03:38.0186 (UTC) FILETIME=[1A6092A0:01CE031B] Cc: Al Morton , mattmathis@google.com, lmap@ietf.org Subject: Re: [lmap] a note on buffer bloat 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, 04 Feb 2013 21:03:41 -0000 I would say that it is becoming more of a congestion control issue. With home networks capable of autonomous communication (gaming, internal streaming, etc.) while other devices communicate with the internet these modems/routers have to have some buffer in order to operate effectively. Sharam -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, February 04, 2013 2:11 PM To: Bugenhagen, Michael K; 'James Miller'; Marc Linsner Cc: lmap@ietf.org; 'mattmathis@google.com'; 'Al Morton' Subject: Re: [lmap] a note on buffer bloat I suspect there are still a fair number of cable/DSL modems out there that have excessive buffers and offer no DiffServ; I see bufferbloat more as a network failure mode rather than an average performance issue. ________________________________________ From: Bugenhagen, Michael K [Michael.K.Bugenhagen@centurylink.com] Sent: Monday, February 04, 2013 1:30 PM To: Henning Schulzrinne; 'James Miller'; Marc Linsner Cc: 'mattmathis@google.com'; 'Al Morton'; lmap@ietf.org Subject: RE: a note on buffer bloat Henning, Yes that reflects what I heard, the best practices now reflect the smaller settings and only operators who haven't picked that up yet would still have a problem. Good test problem to solve (at test that could conclude buffer bloat), but the problem may now be much less prolific, that is unless a new technology brings the issue back. Regards, and thanks, Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Monday, February 04, 2013 11:23 AM To: Bugenhagen, Michael K; 'James Miller'; Marc Linsner Cc: 'mattmathis@google.com'; 'Al Morton'; lmap@ietf.org Subject: RE: a note on buffer bloat For one recent perspective, see: Mark Allman. Comments on Bufferbloat, ACM SIGCOMM Computer Communication Review, 43(1), January 2013. http://www.icir.org/mallman/papers/bufferbloat-ccr13.pdf My summary would be: it occurs, but may not be quite as common as sometimes claimed. There are also some fairly easy fixes (smaller buffers) and some more complicated ones (new TCP). ________________________________ From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Bugenhagen, Michael K [Michael.K.Bugenhagen@centurylink.com] Sent: Monday, February 04, 2013 11:52 AM To: 'James Miller'; Marc Linsner Cc: 'mattmathis@google.com'; 'Al Morton'; lmap@ietf.org Subject: [lmap] a note on buffer bloat James, Marc, At the last IETF meeting we had a discussion on buffer bloat now being an issue. I'm now hearing that this may have been part of some newly deployed technologies and the tweaks to those implementations have fixed the issue. I'm hoping that someone can validate that in the Next IETF meeting, was it a transitional problem, or is it still an issue. Thanks, Mike _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From jerome.benoit@grenouille.com Mon Feb 4 13:17:05 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 1D66921F8B0A for ; Mon, 4 Feb 2013 13:17:05 -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 nIta4BJu0Z7R for ; Mon, 4 Feb 2013 13:17:04 -0800 (PST) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6D00421F8A48 for ; Mon, 4 Feb 2013 13:17:04 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id D94547F1FC for ; Mon, 4 Feb 2013 22:17:02 +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 JNXis_ZJyvi9 for ; Mon, 4 Feb 2013 22:16:52 +0100 (CET) Date: Mon, 4 Feb 2013 22:16:51 +0100 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: lmap@ietf.org Message-ID: <20130204221651.37c7664e@nemesis.grenouille.com> In-Reply-To: <201301290940068432111@cnnic.cn> References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> <9510D26531EF184D9017DF24659BB87F3419D404C3@EMV65-UKRD.domain1.systemhost.net> <201301290940068432111@cnnic.cn> 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_/kmxyP8uLWBD6U.jp/H6NNJ4"; protocol="application/pgp-signature" 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, 04 Feb 2013 21:17:05 -0000 --Sig_/kmxyP8uLWBD6U.jp/H6NNJ4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, 29 Jan 2013 09:40:07 +0800 "Guangqing Deng" wrote: > Thanks for Mirja's point. Usually, the bottleneck links in internet are t= hose cross-ISP links. If the collector and the MA are in different ISPs, th= e measurement traffic from MAs to collectors will bring huge pressure to th= e already busy cross-ISP links. So how to reduce the cross-ISP measurement = traffic while not reducing the measurement accuracy may be a challenging pr= oblem that needs more consideration.=20 Indeed.=20 First, you can't have a stateful protocol to achieve this goal (stateful at layer 3, OK, not at layer 7). Second, you can't have a binary protocol to structure the measurements results, it generate too much packets and compression in the payload will then be a pain in the ass. Third, I do not know what is the status of the logical component responsible to synchronize every single MA in the measurement system, but I still think it's a must have and the synchronization algo and proto must also be thought in a way to not overload the network AND the hosting infrastructure resources.=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_/kmxyP8uLWBD6U.jp/H6NNJ4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlEQJUMACgkQ+qDLUJ/pFh0HbgCgkMy3ojoGLAGPQhyHTV3JaPu7 3WgAoMP7KrhhkNe8MPJUW0nRl3Si42iN =sk/x -----END PGP SIGNATURE----- --Sig_/kmxyP8uLWBD6U.jp/H6NNJ4-- From dengguangqing@cnnic.cn Mon Feb 4 18:19: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 24D0721F87FE for ; Mon, 4 Feb 2013 18:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.403 X-Spam-Level: * X-Spam-Status: No, score=1.403 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, MIME_8BIT_HEADER=0.3, 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 ztLAt9EjiNcM for ; Mon, 4 Feb 2013 18:19:12 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 3AFA321F8512 for ; Mon, 4 Feb 2013 18:19:10 -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, 05 Feb 2013 10:19:02 +0800 Date: Tue, 5 Feb 2013 10:19:02 +0800 From: "Guangqing Deng" To: =?utf-8?B?SsOpcsO0bWUgQmVub2l0?= , "lmap@ietf.org" References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> <9510D26531EF184D9017DF24659BB87F3419D404C3@EMV65-UKRD.domain1.systemhost.net> <201301290940068432111@cnnic.cn>, <20130204221651.37c7664e@nemesis.grenouille.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201302051019022349522@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart843677666588_=----" 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, 05 Feb 2013 02:19:13 -0000 This is a multi-part message in MIME format. ------=_001_NextPart843677666588_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksamVyb21lLCBjb21tZW50cyBhcmUgaW5saW5lIGJlbG93Lg0KDQoNCg0KR3VhbmdxaW5nIERl bmcNCkNOTklDIA0KDQpGcm9tOiBKw6lyw7RtZSBCZW5vaXQNCkRhdGU6IDIwMTMtMDItMDUgMDU6 MTYNClRvOiBsbWFwDQpTdWJqZWN0OiBSZTogW2xtYXBdIG1lYXN1cmVtZW50IHRyYWZmaWMgbG9h ZCBbd2FzOiBSZTogUHJvcG9zZWQgTE1BUCBDaGFydGVyXQ0KT24gVHVlLCAyOSBKYW4gMjAxMyAw OTo0MDowNyArMDgwMA0KIkd1YW5ncWluZyBEZW5nIiA8ZGVuZ2d1YW5ncWluZ0Bjbm5pYy5jbj4g d3JvdGU6DQoNCj4gVGhhbmtzIGZvciBNaXJqYSdzIHBvaW50LiBVc3VhbGx5LCB0aGUgYm90dGxl bmVjayBsaW5rcyBpbiBpbnRlcm5ldCBhcmUgdGhvc2UgY3Jvc3MtSVNQIGxpbmtzLiBJZiB0aGUg Y29sbGVjdG9yIGFuZCB0aGUgTUEgYXJlIGluIGRpZmZlcmVudCBJU1BzLCB0aGUgbWVhc3VyZW1l bnQgdHJhZmZpYyBmcm9tIE1BcyB0byBjb2xsZWN0b3JzIHdpbGwgYnJpbmcgaHVnZSBwcmVzc3Vy ZSB0byB0aGUgYWxyZWFkeSBidXN5IGNyb3NzLUlTUCBsaW5rcy4gU28gaG93IHRvIHJlZHVjZSB0 aGUgY3Jvc3MtSVNQIG1lYXN1cmVtZW50IHRyYWZmaWMgd2hpbGUgbm90IHJlZHVjaW5nIHRoZSBt ZWFzdXJlbWVudCBhY2N1cmFjeSBtYXkgYmUgYSBjaGFsbGVuZ2luZyBwcm9ibGVtIHRoYXQgbmVl ZHMgbW9yZSBjb25zaWRlcmF0aW9uLiANCg0KSW5kZWVkLiANCg0KRmlyc3QsIHlvdSBjYW4ndCBo YXZlIGEgc3RhdGVmdWwgcHJvdG9jb2wgdG8gYWNoaWV2ZSB0aGlzIGdvYWwgKHN0YXRlZnVsDQph dCBsYXllciAzLCBPSywgbm90IGF0IGxheWVyIDcpLg0KU2Vjb25kLCB5b3UgY2FuJ3QgaGF2ZSBh IGJpbmFyeSBwcm90b2NvbCB0byBzdHJ1Y3R1cmUgdGhlIG1lYXN1cmVtZW50cw0KcmVzdWx0cywg aXQgZ2VuZXJhdGUgdG9vIG11Y2ggcGFja2V0cyBhbmQgY29tcHJlc3Npb24gaW4gdGhlIHBheWxv YWQNCndpbGwgdGhlbiBiZSBhIHBhaW4gaW4gdGhlIGFzcy4NClRoZSBwYWNrZXQgc2VudCBieSBv bmUgTUEgY2FuIGJlIGdlbmVyYWxseSBkaXZpZGVkIGludG8gdHdvIGtpbmRzOiBvbmUgaXMgdGhv c2Ugc2VudCB0byB0aGUgbWVhc3VyZW1lbnQgc2VydmVyIGZvciB0cmlnZ2VyaW5nIGEgbWVhc3Vy ZW1lbnQ7IHRoZSBvdGhlciBpcyB0aG9zZSBzZW50IHRvIGRhdGEgY29sbGVjdG9yIHNlcnZlciB0 byByZXBvcnQgdGhlIG1lYXN1cmVtZW50IHJlc3VsdC4gSGVyZSwgdGhlIHNpZ25hbGluZyB0cmFm ZmljIChiZXR3ZWVuIE1BIGFuZCBtZWFzdXJlbWVudCBjb250cm9sbGVyLCBmb3IgaW5zdGFuY2Up IGlzIG9taXR0ZWQuIFRoZSBmb3JtZXIga2luZCBvZiBwYWNrZXQgdXN1YWxseSBjYW5ub3QgYmUg Y29tcHJlc3NlZDsgd2hpbGUgdGhlIGxhdHRlciBraW5kIG9mIHBhY2tldCBtYXkgYmUgY29tcHJl c3NlZCBiZWZvcmUgc2VuZGluZyBpdCB0byB0aGUgZGF0YSBjb2xsZWN0b3Igc2VydmVyLiBUaHJv dWdoIGFjdHVhbCBtZWFzdXJlbWVudCwgaXQgaXMgZm91bmQgdGhhdCBJbnRlcm5ldCB0cmFmZmlj IHZvbHVtZSBmcm9tIDggcC5tLiB0byAxMSBwLm0uIGV2ZXJ5ZGF5IGlzIG11Y2ggbGFyZ2VyIHRo YW4gdGhhdCBmcm9tIDEgYS5tLiB0byA1IGEubS4gU28gYW5vdGhlciB3YXkgdG8gcmVkdWNlIHRo ZSBlZmZlY3Qgb24gbmV0d29yayBpbmZyYXN0cnVjdHVyZSBpcyB0byBsZXQgdGhlIE1BIHNlbmQg bWVhc3VyZW1lbnQgcmVzdWx0cyB3aGVuIHRoZSBuZXR3b3JrIGlzIG5vdCBzbyBidXN5LiANCg0K VGhpcmQsIEkgZG8gbm90IGtub3cgd2hhdCBpcyB0aGUgc3RhdHVzIG9mIHRoZSBsb2dpY2FsIGNv bXBvbmVudA0KcmVzcG9uc2libGUgdG8gc3luY2hyb25pemUgZXZlcnkgc2luZ2xlIE1BIGluIHRo ZSBtZWFzdXJlbWVudCBzeXN0ZW0sDQpidXQgSSBzdGlsbCB0aGluayBpdCdzIGEgbXVzdCBoYXZl IGFuZCB0aGUgc3luY2hyb25pemF0aW9uIGFsZ28gYW5kDQpwcm90byBtdXN0IGFsc28gYmUgdGhv dWdodCBpbiBhIHdheSB0byBub3Qgb3ZlcmxvYWQgdGhlIG5ldHdvcmsgQU5EIHRoZQ0KaG9zdGlu ZyBpbmZyYXN0cnVjdHVyZSByZXNvdXJjZXMuIA0KVXN1YWxseSwgdGhlIHN5bmNocm9uaXphdGlv biBiZXR3ZWVuIHRoZSBNQSBhbmQgdGhlIG1lYXN1cmVtZW50IHNlcnZlciBtYXkgZGVwZW5kIG9u IHRoZSBjaG9zZW4gcGVyZm9ybWFuY2UgbWV0cmljIGFuZCBSRkNzIGluIElQUE0gd29yayBncm91 cCBtYXkgYmUgaGVscGZ1bC4gV2hpbGUgZm9yIHRoZSBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiB0 aGUgTUEgYW5kIHRoZSBtZWFzdXJlbWVudCBjb250cm9sbGVyIChvciB0aGUgZGF0YSBjb2xsZWN0 b3IpLCBpdCBzZWVtIHRoYXQgdGhlIOKAnGhlYXJ0YmVhdOKAnSBtZWNoYW5pc20gY2FuIGJlIHRh a2VuIGludG8gY29uc2lkZXJhdGlvbi4gDQoNCi0tIA0KSsOpcsO0bWUgQmVub2l0IGFrYSBmcmFn Z2xlDQpMYSBNw6l0w6lvIGR1IE5ldCAtIGh0dHA6Ly9ncmVub3VpbGxlLmNvbQ0KT3BlblBHUCBL ZXkgSUQgOiA5RkU5MTYxRA0KS2V5IGZpbmdlcnByaW50IDogOUNBNCAwMjQ5IEFGNTcgQTM1QiAz NEIzIEFDMTUgRkFBMCBDQjUwIDlGRTkgMTYxRA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCmxtYXAgbWFpbGluZyBsaXN0DQpsbWFwQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXA= ------=_001_NextPart843677666588_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi,jerome, comments are inline below.
Guangqing=20 Deng
CNNIC 
 
Date: 2013-02-05 05:16
To: lmap
Subject: Re: [lmap] measurement traffic load [was: Re: Pr= oposed=20 LMAP Charter]
On Tue, 29 Jan 2013 09:40:07 +0800
"Guangqing Deng" <dengguangqing@cnnic.cn> wrote:=
 
> Thanks for Mirja's point. Usually, = ;the bottleneck links in internet are those&= nbsp;cross-ISP links. If the collector and t= he MA are in different ISPs, the measur= ement traffic from MAs to collectors will&nb= sp;bring huge pressure to the already busy&n= bsp;cross-ISP links. So how to reduce the&nb= sp;cross-ISP measurement traffic while not reduci= ng the measurement accuracy may be a ch= allenging problem that needs more consideration.&= nbsp;
 
Indeed. 
 
First, you can't have a stateful protoc= ol to achieve this goal (stateful
at layer 3, OK, not at layer 7).
Second, you can't have a binary protoco= l to structure the measurements
results, it generate too much packets a= nd compression in the payload
will then be a pain in the ass.
The packet sent by one = MA can be=20 generally divided into two kinds: one is those sent to the measurement ser= ver=20 for triggering a measurement; the other is those sent to data collector se= rver=20 to report the measurement result. Here, the signaling traffic (between MA = and=20 measurement controller, for instance) is omitted. The former kind of packe= t=20 usually cannot be compressed; while the latter kind of packet may be compr= essed=20 before sending it to the data collector server. Through actual measurement= , it=20 is found that Internet traffic volume from 8 p.m. to 11 p.m. everyday is m= uch=20 larger than that from 1 a.m. to 5 a.m. So another way to reduce the effect= =20 on network infrastructure is to let the MA sen= d=20 measurement results when the network is not so=20 busy.=20
 
Third, I do not know what is the&n= bsp;status of the logical component
responsible to synchronize every single MA&n= bsp;in the measurement system,
but I still think it's a must have=  and the synchronization algo and
proto must also be thought in a wa= y to not overload the network AND the
hosting infrastructure resources. 

Usually, the synchronization between the MA and t= he=20 measurement server may depend on the chosen performance metric and RFCs in= IPPM=20 work group may be helpful. While for the synchronization between the MA an= d the=20 measurement controller (or the data collector), it seem that the =E2=80=9C= heartbeat=E2=80=9D=20 mechanism can be taken into consideration.=20

 
-- 
J=C3=A9r=C3=B4me Benoit aka fraggle
La M=C3=A9t=C3=A9o du Net - http://grenouill= e.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B&n= bsp;34B3 AC15 FAA0 CB50 9FE9 161D
 
 
 
_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap
 
------=_001_NextPart843677666588_=------ From trammell@tik.ee.ethz.ch Tue Feb 5 01:24: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 F036421F879A for ; Tue, 5 Feb 2013 01:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 L79PVswVrjzD for ; Tue, 5 Feb 2013 01:24:13 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 983A121F8753 for ; Tue, 5 Feb 2013 01:24:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 845DED930B; Tue, 5 Feb 2013 10:24:12 +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 v0ELkgF2KlHx; Tue, 5 Feb 2013 10:24:12 +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 27CB2D9309; Tue, 5 Feb 2013 10:24:12 +0100 (MET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <20130204221651.37c7664e@nemesis.grenouille.com> Date: Tue, 5 Feb 2013 10:24:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> <9510D26531EF184D9017DF24659BB87F3419D404C3@EMV65-UKRD.domain1.systemhost.net> <201301290940068432111@cnnic.cn> <20130204221651.37c7664e@nemesis.grenouille.com> To: =?iso-8859-1?Q?J=E9r=F4me_Benoit?= X-Mailer: Apple Mail (2.1499) Cc: 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: Tue, 05 Feb 2013 09:24:15 -0000 Hi, Jerome, all, On Feb 4, 2013, at 10:16 PM, J=E9r=F4me Benoit = wrote: > On Tue, 29 Jan 2013 09:40:07 +0800 > "Guangqing Deng" wrote: >=20 >> 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 huge = pressure to the already busy cross-ISP links. So how to reduce the = cross-ISP measurement traffic while not reducing the measurement = accuracy may be a challenging problem that needs more consideration.=20 >=20 > Indeed.=20 >=20 > First, you can't have a stateful protocol to achieve this goal = (stateful > at layer 3, OK, not at layer 7). Clearly. Even just the normal connectivity churn of so many machines = under someone else's physical control rules this out. > Second, you can't have a binary protocol to structure the measurements > results, it generate too much packets and compression in the payload > will then be a pain in the ass. I'm not sure I follow this point. > Third, I do not know what is the status of the logical component > responsible to synchronize every single MA in the measurement system, > but I still think it's a must have and the synchronization algo and > proto must also be thought in a way to not overload the network AND = the > hosting infrastructure resources.=20 There's two points to synchronization: making sure each MA knows what to = do (control sync), and making sure it does that at the right time (clock = sync). As long as your measurement plan doesn't (1) change often or (2) = involve receiving results in anything like real time, you can split your = synchronization in two. Let something like NTP sync clocks (not good = enough for lining up multiple observations of the same packet on a = high-speed link on its own, but it should do for scheduling of broadband = measurements). Since what we're basically building is a legitimate = volunteer botnet, we can probably take some inspiration from successful = botnet C&C: our goal is to reduce measurement control load to increase = scalability, while the goal of a botnet is to evade detection. Both = involve treading lightly on the network. So control sync happens via = pull from a known CDN or redirect thereto, P2P flooding, etc., etc. Best regards, Brian > --=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 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From jerome.benoit@grenouille.com Tue Feb 5 04:24: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 A754521F8609 for ; Tue, 5 Feb 2013 04:24:55 -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 0-EsEmRAR099 for ; Tue, 5 Feb 2013 04:24:52 -0800 (PST) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED6B21F85AB for ; Tue, 5 Feb 2013 04:24:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 5BDEF7F2A6; Tue, 5 Feb 2013 13:24: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 umArn5zsujKL; Tue, 5 Feb 2013 13:24:41 +0100 (CET) Date: Tue, 5 Feb 2013 13:24:39 +0100 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: Brian Trammell Message-ID: <20130205132439.28eb2425@nemesis.grenouille.com> In-Reply-To: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> <9510D26531EF184D9017DF24659BB87F3419D404C3@EMV65-UKRD.domain1.systemhost.net> <201301290940068432111@cnnic.cn> <20130204221651.37c7664e@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_/Z0cDzPzQvVglFd_AkxIQnuV"; protocol="application/pgp-signature" Cc: 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: Tue, 05 Feb 2013 12:24:55 -0000 --Sig_/Z0cDzPzQvVglFd_AkxIQnuV Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, 5 Feb 2013 10:24:11 +0100 Brian Trammell wrote: >=20 > > Second, you can't have a binary protocol to structure the measurements > > results, it generate too much packets and compression in the payload > > will then be a pain in the ass. >=20 > I'm not sure I follow this point. For information exchange between each logical components in the system. If you choose binary protocol that structure de data exchanged, you will have more packets than say RESTful protocol.=20 >=20 > > Third, I do not know what is the status of the logical component > > responsible to synchronize every single MA in the measurement system, > > but I still think it's a must have and the synchronization algo and > > proto must also be thought in a way to not overload the network AND the > > hosting infrastructure resources.=20 >=20 > There's two points to synchronization: making sure each MA knows what to = do (control sync),=20 It's the hard point that need to trigger a high convergence time in the system to avoid out of sync measurement run with overloading the network. Really tricky to design. =20 > and making sure it does that at the right time (clock sync).=20 That's a prerequisite for the former.=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_/Z0cDzPzQvVglFd_AkxIQnuV Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlEQ+ggACgkQ+qDLUJ/pFh26sACgqZTNc4b/5PtCf6WsmrCiI31e FGEAoOalLMIFJpn49RJTYQLKrPnGSTRP =umWa -----END PGP SIGNATURE----- --Sig_/Z0cDzPzQvVglFd_AkxIQnuV-- From jerome.benoit@grenouille.com Tue Feb 5 04:41: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 B28AF21F889C for ; Tue, 5 Feb 2013 04:41:09 -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 L5sFew9i7tQk for ; Tue, 5 Feb 2013 04:41:09 -0800 (PST) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id AB19D21F8893 for ; Tue, 5 Feb 2013 04:41:08 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id ABF1C7F02E; Tue, 5 Feb 2013 13:41:07 +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 vIPP_37I5Lly; Tue, 5 Feb 2013 13:40:58 +0100 (CET) Date: Tue, 5 Feb 2013 13:40:57 +0100 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: "Guangqing Deng" Message-ID: <20130205134057.65ffcc50@nemesis.grenouille.com> In-Reply-To: <201302051019022349522@cnnic.cn> References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> <9510D26531EF184D9017DF24659BB87F3419D404C3@EMV65-UKRD.domain1.systemhost.net> <201301290940068432111@cnnic.cn> <20130204221651.37c7664e@nemesis.grenouille.com> <201302051019022349522@cnnic.cn> 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_/D7HRbwq1rL1EFE6truxIwsv"; protocol="application/pgp-signature" Cc: "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: Tue, 05 Feb 2013 12:41:09 -0000 --Sig_/D7HRbwq1rL1EFE6truxIwsv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 5 Feb 2013 10:19:02 +0800 "Guangqing Deng" wrote: > > The packet sent by one MA can be generally divided into two kinds: one is= those sent to the measurement server for triggering a measurement; the oth= er is those sent to data collector server to report the measurement result.= =20 Two main kinds I think : the probing traffic and all the information exchange inside the measurement system : control traffic, collector traffic and so on.=20 My main interest is for now the information exchange inside the measurement system. =20 >Here, the signaling traffic (between MA and measurement controller, for in= stance) is omitted. The former kind of packet usually cannot be compressed;= while the latter kind of packet may be compressed before sending it to the= data collector server. Through actual measurement, it is found that Intern= et traffic volume from 8 p.m. to 11 p.m. everyday is much larger than that = from 1 a.m. to 5 a.m. So another way to reduce the effect on network infras= tructure is to let the MA send measurement results when the network is not = so busy.=20 Agreed. The MA will need to buffer them. =20 >=20 > Third, I do not know what is the status of the logical component > responsible to synchronize every single MA in the measurement system, > but I still think it's a must have and the synchronization algo and > proto must also be thought in a way to not overload the network AND the > hosting infrastructure resources.=20 > Usually, the synchronization between the MA and the measurement server ma= y depend on the chosen performance metric and RFCs in IPPM work group may b= e helpful. While for the synchronization between the MA and the measurement= controller (or the data collector), it seem that the =E2=80=9Cheartbeat=E2= =80=9D mechanism can be taken into consideration. Hearbeat is OK as a mechanism for signalling states of the measurement agents. What about capabilities ?=20 --=20 J=C3=A9r=C3=B4me Benoit aka fraggle La M=C3=A9t=C3=A9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/D7HRbwq1rL1EFE6truxIwsv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlEQ/dkACgkQ+qDLUJ/pFh2PkwCglG8ir8TNIYCpRRsZovGGniQ2 p6kAoMfDyM5PZEuwoD53kRNkGercOwfS =I4kJ -----END PGP SIGNATURE----- --Sig_/D7HRbwq1rL1EFE6truxIwsv-- From trammell@tik.ee.ethz.ch Tue Feb 5 05:34:22 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 8A4D721F87F9 for ; Tue, 5 Feb 2013 05:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 GYwsC0E2weGx for ; Tue, 5 Feb 2013 05:34:22 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id AB06E21F87D3 for ; Tue, 5 Feb 2013 05:34:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D25E2D9309; Tue, 5 Feb 2013 14:34:19 +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 fGmOZVRs91Tb; Tue, 5 Feb 2013 14:34:19 +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 91F7FD9304; Tue, 5 Feb 2013 14:34:19 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <20130205132439.28eb2425@nemesis.grenouille.com> Date: Tue, 5 Feb 2013 14:34:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1B0004FA-EB61-4BD8-8E38-9B3D895E3E28@tik.ee.ethz.ch> References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> <9510D26531EF184D9017DF24659BB87F3419D404C3@EMV65-UKRD.domain1.systemhost.net> <201301290940068432111@cnnic.cn> <20130204221651.37c7664e@nemesis.grenouille.com> <20130205132439.28eb2425@nemesis.grenouille.com> To: =?iso-8859-1?Q?J=E9r=F4me_Benoit?= X-Mailer: Apple Mail (2.1283) Cc: 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: Tue, 05 Feb 2013 13:34:22 -0000 Hi, Jerome, all, On 5 Feb 2013, at 13:24 , J=E9r=F4me Benoit wrote: > On Tue, 5 Feb 2013 10:24:11 +0100 > Brian Trammell wrote: >=20 >>=20 >>> Second, you can't have a binary protocol to structure the = measurements >>> results, it generate too much packets and compression in the payload >>> will then be a pain in the ass. >>=20 >> I'm not sure I follow this point. >=20 > For information exchange between each logical components in the = system. > If you choose binary protocol that structure de data exchanged, you > will have more packets than say RESTful protocol.=20 Okay, sorry, I understand what you're saying, but I don't see any = correlation between data encoding and packet count. Compressibility, = similarly, is a function of the entropy in the data being represented = first, and is only secondarily related to the encoding and framing, = unless the encoding and framing are gratuitously inefficient. >>> Third, I do not know what is the status of the logical component >>> responsible to synchronize every single MA in the measurement = system, >>> but I still think it's a must have and the synchronization algo and >>> proto must also be thought in a way to not overload the network AND = the >>> hosting infrastructure resources.=20 >>=20 >> There's two points to synchronization: making sure each MA knows what = to do (control sync),=20 >=20 > It's the hard point that need to trigger a high convergence time in = the > system to avoid out of sync measurement run with overloading the > network. Really tricky to design. =20 I'm not understanding your point here... I think we might be making = different assumptions about the arrangement of the MAs... >> and making sure it does that at the right time (clock sync).=20 >=20 > That's a prerequisite for the former.=20 Well, if you want it to work, yes, it helps if the clocks are synced. :) = But my point was that clock synchronization and control distribution are = separate functions of the control protocol(s) -- and further, that clock = synchronization with the accuracy required by LMAP would seem already to = be solved by NTP. The assumption I'm making here is that each measurement specification = has a time at which it should run, and a time at which it should report = results, as part of the specification, and that the MA compares this = with its system clock (which should be synchronized with the system = clocks of other MAs, of course) to decide when to do what. Without a = common time reference or an allowance for the time it takes a = measurement specification to make it to the MA, yes, synchronization is = a whole lot harder. Best regards, Brian > 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 Tue Feb 5 06:41: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 5A0E921F8984 for ; Tue, 5 Feb 2013 06:41:37 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 fXCzIJiwwJhO for ; Tue, 5 Feb 2013 06:41:36 -0800 (PST) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id BDAAD21F897A for ; Tue, 5 Feb 2013 06:41:36 -0800 (PST) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 02a11115.5b831940.1209832.00-505.3316605.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 05 Feb 2013 14:41:36 +0000 (UTC) X-MXL-Hash: 51111a20321359db-0615dfb3b841aac8df847fd8d2a1986ee17a9f20 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 81a11115.0.1209786.00-447.3316458.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 05 Feb 2013 14:41:36 +0000 (UTC) X-MXL-Hash: 51111a200090c5db-0851f4e6e05bd4151118d106fa2fb43401f1f94f 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 r15EfSiA031440; Tue, 5 Feb 2013 09:41:28 -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 r15EfJA5031379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Feb 2013 09:41:20 -0500 Received: from GAALPA1MSGHUB9B.ITServices.sbc.com (gaalpa1msghub9b.itservices.sbc.com [130.8.36.88]) by sflint04.pst.cso.att.com (RSA Interceptor); Tue, 5 Feb 2013 09:41:02 -0500 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9B.ITServices.sbc.com ([130.8.36.88]) with mapi id 14.02.0328.009; Tue, 5 Feb 2013 09:41:01 -0500 From: "STARK, BARBARA H" To: Brian Trammell , =?iso-8859-1?Q?J=E9r=F4me_Benoit?= Thread-Topic: [lmap] measurement traffic load [was: Re: Proposed LMAP Charter] Thread-Index: AQHOAx0AxdMFkjiibk6AxlKMyiu395hrUrSAgAAybICAABN3gP//u3pw Date: Tue, 5 Feb 2013 14:41:01 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113023BB4B@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> <9510D26531EF184D9017DF24659BB87F3419D404C3@EMV65-UKRD.domain1.systemhost.net> <201301290940068432111@cnnic.cn> <20130204221651.37c7664e@nemesis.grenouille.com> <20130205132439.28eb2425@nemesis.grenouille.com> <1B0004FA-EB61-4BD8-8E38-9B3D895E3E28@tik.ee.ethz.ch> In-Reply-To: <1B0004FA-EB61-4BD8-8E38-9B3D895E3E28@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.130.223] Content-Type: text/plain; charset="iso-8859-1" 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=R42076tX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=sBstySHZAiMA:10 a=mHWMNHSBTXIA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=-WB-heVITkQA:10 a=thEDIgb7OZSuSMcHtjwA:9 a=wPNLvf] X-AnalysisOut: [GTeEIA:10] Cc: "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: Tue, 05 Feb 2013 14:41:37 -0000 > > Brian Trammell wrote: > Well, if you want it to work, yes, it helps if the clocks are synced. :) = But my > point was that clock synchronization and control distribution are separat= e > functions of the control protocol(s) -- and further, that clock synchroni= zation > with the accuracy required by LMAP would seem already to be solved by > NTP. I'm really hoping that this is a consensus conclusion that we can reach. Th= is assumption (that NTP would be sufficient for the needs of LMAP) would ma= ke the overall architecture much less complex than if we were to try to int= roduce more precise clock synchronization. Lower complexity is a wonderful = goal to strive for. I'm very much in favor of aiming our sights at "good en= ough" rather than "100% perfect". I suspect that the end customers will be = much better served by an architecture that is "good enough", rather than on= e that is over-engineered to achieve a level of precision that those end cu= stomers aren't asking for. Barbara From Michael.K.Bugenhagen@centurylink.com Tue Feb 5 07:36: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 8F05B21F8893 for ; Tue, 5 Feb 2013 07:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, 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 yZ+5b++NcOxM for ; Tue, 5 Feb 2013 07:36:07 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id E896621F887F for ; Tue, 5 Feb 2013 07:36:06 -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 r15FZZhM021534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Feb 2013 08:35:36 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id AE1631E0060; Tue, 5 Feb 2013 08:35:30 -0700 (MST) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 90CD31E007A; Tue, 5 Feb 2013 08:35:30 -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 r15FZUP9019943; Tue, 5 Feb 2013 08:35:30 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r15FXhLp017723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 08:35:27 -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; Tue, 5 Feb 2013 09:32:55 -0600 From: "Bugenhagen, Michael K" To: "'Brian Trammell'" , =?iso-8859-1?Q?J=E9r=F4me_Benoit?= Thread-Topic: [lmap] measurement traffic load [was: Re: Proposed LMAP Charter] Thread-Index: AQHN/cGR85Ov4UtsZ0SYRV7udYXD1phqoveAgADLN4CAADJsgIAAE3eA//+6vnA= Date: Tue, 5 Feb 2013 15:32:53 +0000 Message-ID: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> <9510D26531EF184D9017DF24659BB87F3419D404C3@EMV65-UKRD.domain1.systemhost.net> <201301290940068432111@cnnic.cn> <20130204221651.37c7664e@nemesis.grenouille.com> <20130205132439.28eb2425@nemesis.grenouille.com> <1B0004FA-EB61-4BD8-8E38-9B3D895E3E28@tik.ee.ethz.ch> In-Reply-To: <1B0004FA-EB61-4BD8-8E38-9B3D895E3E28@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "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: Tue, 05 Feb 2013 15:36:07 -0000 I think we should consider test validation criteria as part of the output o= f the test.. 1) Did it have good "time and date"..=20 2) Does the tester "know" the provisioned speed - (I don't mean assumed...) 3) Was the test conducted successfully=20 - No customer traffic interrupted it - No abnormal test termination occurred - was the there any abnormal conditions (CPU high use, ...) that could hav= e impacted the test =09 These are far too often left out of pre-test checks. Regards, Mike =09 -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: Tuesday, February 05, 2013 7:34 AM To: J=E9r=F4me Benoit Cc: lmap@ietf.org Subject: Re: [lmap] measurement traffic load [was: Re: Proposed LMAP Charte= r] Hi, Jerome, all, On 5 Feb 2013, at 13:24 , J=E9r=F4me Benoit wrote: > On Tue, 5 Feb 2013 10:24:11 +0100 > Brian Trammell wrote: >=20 >>=20 >>> Second, you can't have a binary protocol to structure the=20 >>> measurements results, it generate too much packets and compression=20 >>> in the payload will then be a pain in the ass. >>=20 >> I'm not sure I follow this point. >=20 > For information exchange between each logical components in the system. > If you choose binary protocol that structure de data exchanged, you=20 > will have more packets than say RESTful protocol. Okay, sorry, I understand what you're saying, but I don't see any correlati= on between data encoding and packet count. Compressibility, similarly, is a= function of the entropy in the data being represented first, and is only s= econdarily related to the encoding and framing, unless the encoding and fra= ming are gratuitously inefficient. >>> Third, I do not know what is the status of the logical component=20 >>> responsible to synchronize every single MA in the measurement=20 >>> system, but I still think it's a must have and the synchronization=20 >>> algo and proto must also be thought in a way to not overload the=20 >>> network AND the hosting infrastructure resources. >>=20 >> There's two points to synchronization: making sure each MA knows what=20 >> to do (control sync), >=20 > It's the hard point that need to trigger a high convergence time in=20 > the system to avoid out of sync measurement run with overloading the=20 > network. Really tricky to design. I'm not understanding your point here... I think we might be making differe= nt assumptions about the arrangement of the MAs... >> and making sure it does that at the right time (clock sync).=20 >=20 > That's a prerequisite for the former.=20 Well, if you want it to work, yes, it helps if the clocks are synced. :) Bu= t my point was that clock synchronization and control distribution are sepa= rate functions of the control protocol(s) -- and further, that clock synchr= onization with the accuracy required by LMAP would seem already to be solve= d by NTP. The assumption I'm making here is that each measurement specification has a= time at which it should run, and a time at which it should report results,= as part of the specification, and that the MA compares this with its syste= m clock (which should be synchronized with the system clocks of other MAs, = of course) to decide when to do what. Without a common time reference or an= allowance for the time it takes a measurement specification to make it to = the MA, yes, synchronization is a whole lot harder. Best regards, Brian > J=E9r=F4me Benoit aka fraggle > La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key= =20 > fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D=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 jerome.benoit@grenouille.com Tue Feb 5 14:28: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 2EF1321F8621 for ; Tue, 5 Feb 2013 14:28:17 -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=[AWL=0.000, 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 G7DJdglgccRE for ; Tue, 5 Feb 2013 14:28:16 -0800 (PST) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4A621F861A for ; Tue, 5 Feb 2013 14:28:14 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 4278C7F602; Tue, 5 Feb 2013 23:28:13 +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 41ThNw1DqUP7; Tue, 5 Feb 2013 23:28:04 +0100 (CET) Date: Tue, 5 Feb 2013 23:28:03 +0100 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: Brian Trammell Message-ID: <20130205232803.191f4a6f@nemesis.grenouille.com> In-Reply-To: <1B0004FA-EB61-4BD8-8E38-9B3D895E3E28@tik.ee.ethz.ch> References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> <9510D26531EF184D9017DF24659BB87F3419D404C3@EMV65-UKRD.domain1.systemhost.net> <201301290940068432111@cnnic.cn> <20130204221651.37c7664e@nemesis.grenouille.com> <20130205132439.28eb2425@nemesis.grenouille.com> <1B0004FA-EB61-4BD8-8E38-9B3D895E3E28@tik.ee.ethz.ch> 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_/G7mrZH9KUw2z4FPDPXwrZTW"; protocol="application/pgp-signature" Cc: 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: Tue, 05 Feb 2013 22:28:17 -0000 --Sig_/G7mrZH9KUw2z4FPDPXwrZTW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, 5 Feb 2013 14:34:19 +0100 Brian Trammell wrote: > > > For information exchange between each logical components in the system. > > If you choose binary protocol that structure de data exchanged, you > > will have more packets than say RESTful protocol.=20 >=20 > Okay, sorry, I understand what you're saying, but I don't see any correla= tion between data encoding and packet count. Compressibility, similarly, is= a function of the entropy in the data being represented first, and is only= secondarily related to the encoding and framing, unless the encoding and f= raming are gratuitously inefficient. Ok, but can we just state that all network procotols inside the measurement system must really take care of efficiency regarding number keepalived and state-full of connexion, data size exchanged to begin with ? =20 >=20 > >>> Third, I do not know what is the status of the logical component > >>> responsible to synchronize every single MA in the measurement system, > >>> but I still think it's a must have and the synchronization algo and > >>> proto must also be thought in a way to not overload the network AND t= he > >>> hosting infrastructure resources.=20 > >>=20 > >> There's two points to synchronization: making sure each MA knows what = to do (control sync),=20 > >=20 > > It's the hard point that need to trigger a high convergence time in the > > system to avoid out of sync measurement run with overloading the ^out > > network. Really tricky to design. =20 >=20 > I'm not understanding your point here... I think we might be making diffe= rent assumptions about the arrangement of the MAs... The time synchronization is one part. I'm talking about another type of synchronisation : the one that permit to run measurement with topological information, the one that permit to run a measurement only if more than say N MAs are online and support the feature X. I do have that kind of measurements scenarios. It's what I call measurement system coherence. Time synchronization is a good feature, really. But certain measurements do not care that much about time synchronization in the whole measurement system (they care much about local clock stability) but they care about the number N of MAs online behind the same network link and the features on the N MAs online.=20 >=20 > Well, if you want it to work, yes, it helps if the clocks are synced. :) = But my point was that clock synchronization and control distribution are se= parate functions of the control protocol(s) -- and further, that clock sync= hronization with the accuracy required by LMAP would seem already to be sol= ved by NTP. It will depends ... some scenario require ms accuracy (or even ns, but not in real world :)), some do not care.=20 >=20 > The assumption I'm making here is that each measurement specification has= a time at which it should run, and a time at which it should report result= s, as part of the specification, and that the MA compares this with its sys= tem clock (which should be synchronized with the system clocks of other MAs= , of course) to decide when to do what. Without a common time reference or = an allowance for the time it takes a measurement specification to make it t= o the MA, yes, synchronization is a whole lot harder. I hope this mail make my point clearer : I want to talk about a global coherence in the measurement system. Time synchronization is one type of coherence. I think the LMAP WG should care about other type of coherency such as :=20 - Keeping track of MA capabilities - Keeping track of MA states - Keeping track of MA localisation - geo and topo -=20 - Keeping track of MA time synchronization=20 Cheers.=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_/G7mrZH9KUw2z4FPDPXwrZTW Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlERh3MACgkQ+qDLUJ/pFh0i6wCg2ZOBVHmGM39ANSd2WmamWmYL FkIAnRFV4QcPeUCFq5AC0Q93/adQ1k1n =ZbXR -----END PGP SIGNATURE----- --Sig_/G7mrZH9KUw2z4FPDPXwrZTW-- From trammell@tik.ee.ethz.ch Wed Feb 6 00:02: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 22D8221F8522 for ; Wed, 6 Feb 2013 00:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.324 X-Spam-Level: X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 JT1BpbpP3tzB for ; Wed, 6 Feb 2013 00:02:20 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 2182F21F84CE for ; Wed, 6 Feb 2013 00:02:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C49E2D930A; Wed, 6 Feb 2013 09:02:17 +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 ChUo-YxM+eoQ; Wed, 6 Feb 2013 09:02:17 +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 6A0D4D9304; Wed, 6 Feb 2013 09:02:17 +0100 (MET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <20130205232803.191f4a6f@nemesis.grenouille.com> Date: Wed, 6 Feb 2013 09:02:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> <201301281805.59838.mirja.kuehlewind@ikr.uni-stuttgart.de> <9510D26531EF184D9017DF24659BB87F3419D404C3@EMV65-UKRD.domain1.systemhost.net> <201301290940068432111@cnnic.cn> <20130204221651.37c7664e@nemesis.grenouille.com> <20130205132439.28eb2425@nemesis.grenouille.com> <1B0004FA-EB61-4BD8-8E38-9B3D895E3E28@tik.ee.ethz.ch> <20130205232803.191f4a6f@nemesis.grenouille.com> To: =?iso-8859-1?Q?J=E9r=F4me_Benoit?= X-Mailer: Apple Mail (2.1499) Cc: 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: Wed, 06 Feb 2013 08:02:21 -0000 Hi, Jerome, On Feb 5, 2013, at 11:28 PM, J=E9r=F4me Benoit = wrote: > On Tue, 5 Feb 2013 14:34:19 +0100 > Brian Trammell wrote: >=20 >>=20 >>> For information exchange between each logical components in the = system. >>> If you choose binary protocol that structure de data exchanged, you >>> will have more packets than say RESTful protocol.=20 >>=20 >> Okay, sorry, I understand what you're saying, but I don't see any = correlation between data encoding and packet count. Compressibility, = similarly, is a function of the entropy in the data being represented = first, and is only secondarily related to the encoding and framing, = unless the encoding and framing are gratuitously inefficient. >=20 > Ok, but can we just state that all network procotols inside the > measurement system must really take care of efficiency regarding > number keepalived and state-full of connexion, data size exchanged to > begin with ? =20 Absolutely. And the point that efficiency isn't just about how many = bytes sent, but in how many packets, and when, is well-taken, too. >>>>> Third, I do not know what is the status of the logical component >>>>> responsible to synchronize every single MA in the measurement = system, >>>>> but I still think it's a must have and the synchronization algo = and >>>>> proto must also be thought in a way to not overload the network = AND the >>>>> hosting infrastructure resources.=20 >>>>=20 >>>> There's two points to synchronization: making sure each MA knows = what to do (control sync),=20 >>>=20 >>> It's the hard point that need to trigger a high convergence time in = the >>> system to avoid out of sync measurement run with overloading the > ^out >>> network. Really tricky to design. =20 >>=20 >> I'm not understanding your point here... I think we might be making = different assumptions about the arrangement of the MAs... >=20 > The time synchronization is one part. I'm talking about another type = of > synchronisation : the one that permit to run measurement with > topological information, the one that permit to run a measurement only > if more than say N MAs are online and support the feature X. I do have > that kind of measurements scenarios. It's what I call measurement > system coherence. Ahhhhh. Got it. Yeah, that's a hard problem. > Time synchronization is a good feature, really. But > certain measurements do not care that much about time synchronization > in the whole measurement system (they care much about local clock > stability) but they care about the number N of MAs online behind the > same network link and the features on the N MAs online.=20 >=20 >>=20 >> Well, if you want it to work, yes, it helps if the clocks are synced. = :) But my point was that clock synchronization and control distribution = are separate functions of the control protocol(s) -- and further, that = clock synchronization with the accuracy required by LMAP would seem = already to be solved by NTP. >=20 > It will depends ... some scenario require ms accuracy (or even ns, but > not in real world :)), some do not care.=20 Indeed. ms level should be good enough if you're using time-based = coordination. >> The assumption I'm making here is that each measurement specification = has a time at which it should run, and a time at which it should report = results, as part of the specification, and that the MA compares this = with its system clock (which should be synchronized with the system = clocks of other MAs, of course) to decide when to do what. Without a = common time reference or an allowance for the time it takes a = measurement specification to make it to the MA, yes, synchronization is = a whole lot harder. >=20 > I hope this mail make my point clearer : I want to talk about a global > coherence in the measurement system. Time synchronization is one type > of coherence. I think the LMAP WG should care about other type of > coherency such as :=20 >=20 > - Keeping track of MA capabilities > - Keeping track of MA states For these first two, a RESTful protocol seems a natural fit.=20 > - Keeping track of MA localisation - geo and topo -=20 I tend to see localization as a capability as well: "I can see/send = packets (on this AS/subnet/behind or through this piece of = infrastructure/in this geographic region/etc.)" Geoloc gets into privacy = concerns, of course. Fortunately, we've already got a working group for = that, too. :) > - Keeping track of MA time synchronization=20 Again, I think applying NTP here is probably advisable. But in general, I agree -- and thanks for clearing up the coherency = issue for me, it makes sense now. Cheers, Brian= From bclaise@cisco.com Wed Feb 6 07:00: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 56A0921F87A5 for ; Wed, 6 Feb 2013 07:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.562 X-Spam-Level: X-Spam-Status: No, score=-10.562 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=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 6qQMeEbnHKWf for ; Wed, 6 Feb 2013 07:00:35 -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 774DB21F8545 for ; Wed, 6 Feb 2013 07:00:35 -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 r16F0YHj021659 for ; Wed, 6 Feb 2013 16:00:34 +0100 (CET) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r16F0InO007565 for ; Wed, 6 Feb 2013 16:00:28 +0100 (CET) Message-ID: <51127002.20108@cisco.com> Date: Wed, 06 Feb 2013 16:00:18 +0100 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: "lmap@ietf.org" References: <51126DA9.1050807@cisco.com> In-Reply-To: <51126DA9.1050807@cisco.com> X-Forwarded-Message-Id: <51126DA9.1050807@cisco.com> Content-Type: multipart/alternative; boundary="------------080207070106070404050006" Subject: [lmap] LMAP BoF has been approved. 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, 06 Feb 2013 15:00:37 -0000 This is a multi-part message in MIME format. --------------080207070106070404050006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Let us share the good news. The IESG approved this BoF. Even if it was initially requested in TSV, the BoF will be sponsored in OPS by Benoit Claise. The BoF information have been updated (See http://trac.tools.ietf.org/bof/trac/wiki/WikiStart) *Large-Scale Measurement of Broadband Performance (LMAP) * * Status: Requested. * Type: WG forming (1st attempt). * Responsible AD: Benoit Claise, OPS * BOF Chairs: Dan Romascanu (dromasca@avaya.com ), Al Morton (acmorton@att.com )) * Attendance: 80 * Session length 120 minutes * Conflicts to avoid: First level priority: IPPM, ECRIT, BMWG, OPSAREA/OPSAWG, IPFIX, EMAN, NETCONF, NETMOD, XRBLOCK, DIME, RADEXT, SACM BoF, TSVAREA, ALTO, CDNI, NFSV4, PPSP, TSVWG Second level priority: CONEX * Does it require WebEX? No * Does it require Meetecho? No * Mailing list: lmap@ieft.org * List archive: http://www.ietf.org/mail-archive/web/lmap/current/maillist.html * Documents: draft-schulzrinne-lmap-requirements , draft-linsner-lmap-use-cases , and draft-morton-ippm-lmap-path-00 The chairs have been chosen based on their levels of expertise/experience in OPS, measurement, and IETF. Thanks Dan and Al for accepting the chair positions. Goals for this BoF: - be in synch on the problem statement and use cases - understand what the existing IETF protocols and data models (IPPM, NETCONF/YANG, IPFIX, etc...) can or can't do for LMAP. This will certainly require a little of education directly from the experts during the BoF. - clarify what's in scope or not for LMAP Finally, let me stress that a proper preparation is key to a BoF success. http://tools.ietf.org/html/rfc5434 "Considerations for Having a Successful Birds-of-a-Feather (BOF) Session" is a first good step. Regards, Martin Stiemerling (TSV) and Benoit Claise (OPS) --------------080207070106070404050006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Let us share the good news. The IESG approved this BoF.
Even if it was initially requested in TSV, the BoF will be sponsored in OPS by Benoit Claise.
The BoF information have been updated (See http://trac.tools.ietf.org/bof/trac/wiki/WikiStart)

Large-Scale Measurement of Broadband Performance (LMAP)

The chairs have been chosen based on their levels of expertise/experience in OPS, measurement, and IETF. Thanks Dan and Al for accepting the chair positions.

Goals for this BoF:
- be in synch on the problem statement and use cases
- understand what the existing IETF protocols and data models (IPPM, NETCONF/YANG, IPFIX, etc...) can or can't do for LMAP. This will certainly require a little of education directly from the experts during the BoF.
- clarify what's in scope or not for LMAP

Finally, let me stress that a proper preparation is key to a BoF success.
http://tools.ietf.org/html/rfc5434  "Considerations for Having a Successful Birds-of-a-Feather (BOF) Session" is a first good step.

Regards, Martin Stiemerling (TSV) and Benoit Claise (OPS)


--------------080207070106070404050006-- From yaojk@cnnic.cn Wed Feb 6 07:59:12 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 2B14621F8947 for ; Wed, 6 Feb 2013 07:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.701 X-Spam-Level: X-Spam-Status: No, score=-99.701 tagged_above=-999 required=5 tests=[AWL=1.346, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 J1n2Tc+u-TYc for ; Wed, 6 Feb 2013 07:59:11 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id D365921F85CB for ; Wed, 6 Feb 2013 07:59:09 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO computer) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 06 Feb 2013 23:58:58 +0800 Message-ID: <002501ce0482$e007a4e0$6801a8c0@computer> From: "Jiankang Yao" To: "Benoit Claise" , References: <51126DA9.1050807@cisco.com> <51127002.20108@cisco.com> Date: Wed, 6 Feb 2013 23:58:56 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CE04C5.ECF942B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3664 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Subject: Re: [lmap] LMAP BoF has been approved. 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, 06 Feb 2013 15:59:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0022_01CE04C5.ECF942B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable great! ----- Original Message -----=20 From: Benoit Claise=20 To: lmap@ietf.org=20 Sent: Wednesday, February 06, 2013 11:00 PM Subject: [lmap] LMAP BoF has been approved. Dear all, Let us share the good news. The IESG approved this BoF. Even if it was initially requested in TSV, the BoF will be sponsored = in OPS by Benoit Claise. The BoF information have been updated (See = http://trac.tools.ietf.org/bof/trac/wiki/WikiStart) Large-Scale Measurement of Broadband Performance (LMAP) a.. Status: Requested.=20 b.. Type: WG forming (1st attempt).=20 c.. Responsible AD: Benoit Claise, OPS=20 d.. BOF Chairs: Dan Romascanu (=E2=80=8Bdromasca@avaya.com), Al = Morton (=E2=80=8Bacmorton@att.com))=20 e.. Attendance: 80=20 f.. Session length 120 minutes=20 g.. Conflicts to avoid:=20 First level priority: IPPM, ECRIT, BMWG, OPSAREA/OPSAWG, IPFIX, = EMAN, NETCONF, NETMOD, XRBLOCK, DIME, RADEXT, SACM BoF, TSVAREA, ALTO, = CDNI, NFSV4, PPSP, TSVWG=20 Second level priority: CONEX=20 h.. Does it require WebEX? No=20 i.. Does it require Meetecho? No=20 j.. Mailing list: =E2=80=8B =E2=80=8Blmap@ieft.org=20 k.. List archive: = =E2=80=8B=E2=80=8Bhttp://www.ietf.org/mail-archive/web/lmap/current/maill= ist.html=20 l.. Documents: draft-schulzrinne-lmap-requirements, = draft-linsner-lmap-use-cases, and draft-morton-ippm-lmap-path-00=20 The chairs have been chosen based on their levels of = expertise/experience in OPS, measurement, and IETF. Thanks Dan and Al = for accepting the chair positions. Goals for this BoF: - be in synch on the problem statement and use cases - understand what the existing IETF protocols and data models (IPPM, = NETCONF/YANG, IPFIX, etc...) can or can't do for LMAP. This will = certainly require a little of education directly from the experts during = the BoF. - clarify what's in scope or not for LMAP Finally, let me stress that a proper preparation is key to a BoF = success.=20 http://tools.ietf.org/html/rfc5434 "Considerations for Having a = Successful Birds-of-a-Feather (BOF) Session" is a first good step. Regards, Martin Stiemerling (TSV) and Benoit Claise (OPS) -------------------------------------------------------------------------= ----- _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap ------=_NextPart_000_0022_01CE04C5.ECF942B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
great!
----- Original Message -----
From:=20 Benoit = Claise=20
Sent: Wednesday, February 06, = 2013 11:00=20 PM
Subject: [lmap] LMAP BoF has = been=20 approved.

Dear all,

Let us share the good news. The = IESG=20 approved this BoF.
Even if it was initially requested in TSV, the = BoF will=20 be sponsored in OPS by Benoit Claise.
The BoF information have been = updated=20 (See http://trac.tools.ietf.org/bof/trac/wiki/WikiSta= rt)

Large-Scale Measurement of Broadband Performance=20 (LMAP)

The chairs have been chosen based on their = levels of=20 expertise/experience in OPS, measurement, and IETF. Thanks Dan and Al = for=20 accepting the chair positions.

Goals for this BoF:
- be in = synch on=20 the problem statement and use cases
- understand what the existing = IETF=20 protocols and data models (IPPM, NETCONF/YANG, IPFIX, etc...) can or = can't do=20 for LMAP. This will certainly require a little of education directly = from the=20 experts during the BoF.
- clarify what's in scope or not for=20 LMAP

Finally, let me stress that a proper preparation is key to = a BoF=20 success.
http://tools.ietf.org/html/rf= c5434 =20 "Considerations for Having a Successful Birds-of-a-Feather (BOF) = Session" is a=20 first good step.

Regards, Martin Stiemerling (TSV) and Benoit = Claise=20 (OPS)


_______________________________________________
lmap mailing = = list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap
------=_NextPart_000_0022_01CE04C5.ECF942B0-- From mlinsner@cisco.com Wed Feb 6 08:50: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 2883A21F8505 for ; Wed, 6 Feb 2013 08:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.162 X-Spam-Level: X-Spam-Status: No, score=-9.162 tagged_above=-999 required=5 tests=[AWL=0.040, 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 FQ7b1Y1PN+TQ for ; Wed, 6 Feb 2013 08:50:29 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 19B3D21F85DF for ; Wed, 6 Feb 2013 08:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8573; q=dns/txt; s=iport; t=1360169429; x=1361379029; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=tkV9K/TbKxFfzGzaVCIpLOV1+QTdgs7h6KM6hWiI0vg=; b=kPLwtsXc19Ye6G/BbwelEXZcep1z7GbS4nA9dJOj3UXYIOd47VpyQlud SP3NdIHSqjG6AoghtsSCYNgYdpniLV5MMqzPpBBQl2fxM/6iXcpGIdELZ 7C5e9Owa0NDfZqbvmlDi9uO4jEDHmjjQFqzLsmUCUTCcQiYSnnvrWqpwO I=; X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; d="scan'208,217";a="174112138" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 06 Feb 2013 16:50:28 +0000 Received: from [10.116.195.119] (rtp-mlinsner-8716.cisco.com [10.116.195.119]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r16GoQxe012248; Wed, 6 Feb 2013 16:50:27 GMT User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Wed, 06 Feb 2013 11:50:25 -0500 From: Marc Linsner To: Benoit Claise , "lmap@ietf.org" Message-ID: Thread-Topic: [lmap] LMAP BoF has been approved. In-Reply-To: <51127002.20108@cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3442996228_655591" Subject: Re: [lmap] LMAP BoF has been approved. 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, 06 Feb 2013 16:50:30 -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_3442996228_655591 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Great! thanks Benoit & Martin! From: Benoit Claise Date: Wednesday, February 6, 2013 10:00 AM To: "lmap@ietf.org" Subject: [lmap] LMAP BoF has been approved. > =20 > Dear all, > =20 > =20 > Let us share the good news. The IESG approved this BoF. > Even if it was initially requested in TSV, the BoF will be sponsored in = OPS > by Benoit Claise. > The BoF information have been updated (See > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart) > =20 >> =20 >>=20 >> Large-Scale Measurement of Broadband Performance (LMAP) >> =20 >> =20 >> * Status: Requested. >> * Type: WG forming (1st attempt). >> * =20 >> * Responsible AD: Benoit Claise, OPS >> * =20 >> * BOF Chairs: Dan Romascanu (=E2=80=8Bdromasca@avaya.com), Al Morton >> (=E2=80=8Bacmorton@att.com)) >> * =20 >> * Attendance: 80 >> * =20 >> * Session length 120 minutes >> * =20 >> * Conflicts to avoid: >> * First level priority: IPPM, ECRIT, BMWG, OPSAREA/OPSAWG, IPFIX, EMAN, >> NETCONF, NETMOD, XRBLOCK, DIME, RADEXT, SACM BoF, TSVAREA, ALTO, CDNI, N= FSV4, >> PPSP, TSVWG=20 >> * Second level priority: CONEX >> * =20 >> * Does it require WebEX? No >> * Does it require Meetecho? No >> * Mailing list: =E2=80=8B =E2=80=8Blmap@ieft.org >> * List archive:=20 >> =E2=80=8B=E2=80=8Bhttp://www.ietf.org/mail-archive/web/lmap/current/maillist.html >> * Documents: draft-schulzrinne-lmap-requirements >> , >> draft-linsner-lmap-use-cases >> , and >> draft-morton-ippm-lmap-path-00 >> >> =20 > The chairs have been chosen based on their levels of expertise/experienc= e in > OPS, measurement, and IETF. Thanks Dan and Al for accepting the chair > positions. > =20 > Goals for this BoF: > - be in synch on the problem statement and use cases > - understand what the existing IETF protocols and data models (IPPM, > NETCONF/YANG, IPFIX, etc...) can or can't do for LMAP. This will certainl= y > require a little of education directly from the experts during the BoF. > - clarify what's in scope or not for LMAP > =20 > Finally, let me stress that a proper preparation is key to a BoF success= . > http://tools.ietf.org/html/rfc5434 "Considerations for Having a Success= ful > Birds-of-a-Feather (BOF) Session" is a first good step. > =20 > Regards, Martin Stiemerling (TSV) and Benoit Claise (OPS) > =20 > =20 > =20 > =20 > _______________________________________________ lmap mailing list > lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap --B_3442996228_655591 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Great!  thanks Benoit &= amp; Martin!

From: B= enoit Claise <bclaise@cisco.com>= ;
Date: Wednesday, February 6, 201= 3 10:00 AM
To: "lmap@ietf.org" <lmap@ietf= .org>
Subject: [lmap] LMAP = BoF has been approved.

Dear all,

Let us share the good news. The IESG approved this BoF.
Even if it was initially requested in TSV, the BoF will be sponsored in OPS by Benoit Claise.
The BoF information have been updated (See http://trac.tools.ietf.org/bof/trac/wiki/WikiStart)

Large-Scale Measurement of Broadband Performance (LMAP)

The chairs have been chosen based on their levels of expertise/experience in OPS, measurement, and IETF. Thanks Dan and Al for accepting the chair positions.

Goals for this BoF:
- be in synch on the problem statement and use cases
- understand what the existing IETF protocols and data models (IPPM, NETCONF/YANG, IPFIX, etc...) can or can't do for LMAP. This will certainly require a little of education directly from the experts during the BoF.
- clarify what's in scope or not for LMAP

Finally, let me stress that a proper preparation is key to a BoF success.
http://tools.ietf.org/html/rfc5434  "Considerations for Having a Successful Birds-of-a-Feather (BOF) Session" is a first good step.

Regards, Martin Stiemerling (TSV) and Benoit Claise (OPS)


_______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/m= ailman/listinfo/lmap
--B_3442996228_655591-- From jason_livingood@cable.comcast.com Thu Feb 7 13:54: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 AFB6321F87EE for ; Thu, 7 Feb 2013 13:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.147 X-Spam-Level: X-Spam-Status: No, score=-104.147 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 Mi2GZnvbp7s3 for ; Thu, 7 Feb 2013 13:54:57 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2A29B21F86D4 for ; Thu, 7 Feb 2013 13:54:57 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.55065453; Thu, 07 Feb 2013 14:25:12 -0700 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.149]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Thu, 7 Feb 2013 16:54:48 -0500 From: "Livingood, Jason" Thread-Topic: [lmap] a note on buffer bloat Thread-Index: AQHOBX2+2Ns73T7kHkyizykTP9P/nA== Date: Thu, 7 Feb 2013 21:54:47 +0000 Message-ID: <10229F86C86EB444898E629583FD41715C41B6F5@PACDCEXMB06.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.71] Content-Type: multipart/alternative; boundary="_000_10229F86C86EB444898E629583FD41715C41B6F5PACDCEXMB06cabl_" MIME-Version: 1.0 To: "Bugenhagen, Michael K" , "'James Miller'" , Marc Linsner Cc: "lmap@ietf.org" , "'mattmathis@google.com'" , 'Al Morton' Subject: Re: [lmap] a note on buffer bloat 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, 07 Feb 2013 21:54:57 -0000 --_000_10229F86C86EB444898E629583FD41715C41B6F5PACDCEXMB06cabl_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have no idea whatsoever if it will be ready on time or not, but a few of = us are working on buffer bloat demo for bits and bytes. Still lots to do am= ong other priorities but we're working on it. :-) - Jason On 2/4/13 11:52 AM, "Bugenhagen, Michael K" > wrote: James, Marc, At the last IETF meeting we had a discussion on buffer bloat now being an i= ssue. I=92m now hearing that this may have been part of some newly deployed techn= ologies and the tweaks to those implementations have fixed the issue. I=92m hoping that someone can validate that in the Next IETF meeting, was i= t a transitional problem, or is it still an issue. Thanks, Mike --_000_10229F86C86EB444898E629583FD41715C41B6F5PACDCEXMB06cabl_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3C45BBE6299C974DBA8323E8AF8956CF@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
I have no idea whatsoever if it will be ready on time or not, but a fe= w of us are working on buffer bloat demo for bits and bytes. Still lots to = do among other priorities but we're working on it. :-)

- Jason


On 2/4/13 11:52 AM, "Bugenhagen, Michael K" <Michael.K.Bugenhagen@centurylin= k.com> wrote:

James, Marc,

 

At the last IETF meeting we had a = discussion on buffer bloat now being an issue.

I=92m now hearing that this may ha= ve been part of some newly deployed technologies and the tweaks to those im= plementations have fixed the issue.

 

I=92m hoping that someone can vali= date that in the Next IETF meeting, was it a transitional problem, or is it= still an issue.

 

Thanks,

Mike

 --_000_10229F86C86EB444898E629583FD41715C41B6F5PACDCEXMB06cabl_-- From mlinsner@cisco.com Thu Feb 7 14:13: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 53DE621F8563 for ; Thu, 7 Feb 2013 14:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.168 X-Spam-Level: X-Spam-Status: No, score=-9.168 tagged_above=-999 required=5 tests=[AWL=0.034, 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 qlFVaC7T6Ki0 for ; Thu, 7 Feb 2013 14:12:59 -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 23ADC21F8431 for ; Thu, 7 Feb 2013 14:12:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1102; q=dns/txt; s=iport; t=1360275175; x=1361484775; h=date:subject:from:to:message-id:mime-version; bh=1jjzdqIk2XWjfPEqCpjhA83A3++wiTRowWwBU2lLT6Y=; b=Fqsj0If0tFdx7nCJDNgq1h0liUjSeWIsDXnbOvFgDh/1CksExa5C6Lrr fPtXZqVTyvJmYPVpBXEYO1NdoQcLuisLoa5YovXa8SIlB46h00X8npBmk D1p2xOMWlHowbTcLmZeNxFdOfdIo2lSYHYfmiWbYYADwtTP2jMEghZC1a Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQOAGAmFFGtJXG+/2dsb2JhbABFgkmDOYFhgUSFVqhKhkuBbW8Wc4IWED1PCwGBEwyIJAyefKEfBI4zgykDiGaNO4VwimKDHg X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; d="scan'208,217";a="174663852" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 07 Feb 2013 22:12:54 +0000 Received: from [10.116.195.119] (rtp-mlinsner-8716.cisco.com [10.116.195.119]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r17MCrqN029381 for ; Thu, 7 Feb 2013 22:12:54 GMT User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Thu, 07 Feb 2013 17:12:52 -0500 From: Marc Linsner To: Message-ID: Thread-Topic: preliminary agenda is out Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3443101974_1828733" Subject: [lmap] preliminary agenda is out 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, 07 Feb 2013 22:13:00 -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_3443101974_1828733 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit https://datatracker.ietf.org/meeting/86/agenda.html LMAP Bof Wednesday afternoon @ 1510 Keep in mind, the final agenda won't be publish until 2/15 -Marc- --B_3443101974_1828733 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

LMAP Bof Wednesday afternoon @ 1510

Keep in mind, the final agenda won't be publish unti= l 2/15

-Marc-
--B_3443101974_1828733-- From marcelo@it.uc3m.es Fri Feb 8 02:56: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 E119521F8806 for ; Fri, 8 Feb 2013 02:56:56 -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 hJnkwIUk+JF6 for ; Fri, 8 Feb 2013 02:56:56 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3D99A21F8733 for ; Fri, 8 Feb 2013 02:56:55 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 01C8086BC73 for ; Fri, 8 Feb 2013 11:56:54 +0100 (CET) X-uc3m-safe: yes Received: from [192.168.1.100] (r190-135-28-0.dialup.adsl.anteldata.net.uy [190.135.28.0]) (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 3BAAB76621B for ; Fri, 8 Feb 2013 11:56:52 +0100 (CET) Message-ID: <5114D9F1.6000802@it.uc3m.es> Date: Fri, 08 Feb 2013 11:56:49 +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: <20130208105429.13543.58572.idtracker@ietfa.amsl.com> In-Reply-To: <20130208105429.13543.58572.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130208105429.13543.58572.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTHACL 134 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Fri, 08 Feb 2013 11:56:53 +0100 (CET) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19622.006 X-TM-AS-Result: No--8.400-7.0-31-1 X-imss-scan-details: No--8.400-7.0-31-1 Subject: [lmap] Fwd: I-D Action: draft-bagnulo-lmap-ipfix-00.txt 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, 08 Feb 2013 10:56:57 -0000 Hi, Following Dan's comments, we have tried to explore how IPFIX can be used to report test results from the measurement agent to the collector. Please find it described in the following draft. Comments are welcome. Regards, marcelo -------- Mensaje original -------- Asunto: I-D Action: draft-bagnulo-lmap-ipfix-00.txt Fecha: Fri, 08 Feb 2013 02:54:29 -0800 De: internet-drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An LMAP application for IPFIX Author(s) : Marcelo Bagnulo Brian Trammell Filename : draft-bagnulo-lmap-ipfix-00.txt Pages : 9 Date : 2013-02-08 Abstract: This document explores the possibility of using IPFIX to report test results from a Measurement Agent to a Collector, in the context of a large measurement platform. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bagnulo-lmap-ipfix There's also a htmlized version available at: http://tools.ietf.org/html/draft-bagnulo-lmap-ipfix-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From mlinsner@cisco.com Fri Feb 8 13:11: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 5B2DE21F8BEF for ; Fri, 8 Feb 2013 13:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.872 X-Spam-Level: X-Spam-Status: No, score=-9.872 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599, 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 akQSaU-Zpo3B for ; Fri, 8 Feb 2013 13:11:53 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 356C021F8C16 for ; Fri, 8 Feb 2013 13:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1427; q=dns/txt; s=iport; t=1360357913; x=1361567513; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=DBOD0/Q513DOLfegROrD1UUq1rAOuYkJb5oWxRPSMjo=; b=agmXjQRo8JPDua3+5raGqBUEKjeQ8PUSAVYczjzj61ECspXRe/TnW3nz JLGfbPvMh2QAHodQh+9eIymALyM5D9NNY1SZFrcYDbqSrr7HvqSQw29QI KEFUMbRicB4ffYXmOJRsi7cfV89Oddosn4UV+l/3lnEvsJZ8SCAfjGvN0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAGZpFVGtJXG9/2dsb2JhbABFg3i9ExZzgh8BAgQ8AToVCIETAQYDBhyICAcFniyhDI4zgykDiDA2jT6BHYRUimKDHg X-IronPort-AV: E=Sophos;i="4.84,632,1355097600"; d="scan'208";a="174854307" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 08 Feb 2013 21:11:52 +0000 Received: from [10.116.195.119] (rtp-mlinsner-8716.cisco.com [10.116.195.119]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r18LBonN027279 for ; Fri, 8 Feb 2013 21:11:52 GMT User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 08 Feb 2013 16:11:50 -0500 From: Marc Linsner To: Message-ID: Thread-Topic: New Version Notification for draft-linsner-lmap-use-cases-01.txt In-Reply-To: <20130208211042.20595.29406.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: [lmap] FW: New Version Notification for draft-linsner-lmap-use-cases-01.txt 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, 08 Feb 2013 21:11:55 -0000 Fyi=8A > >A new version of I-D, draft-linsner-lmap-use-cases-01.txt >has been successfully submitted by Marc Linsner and posted to the >IETF repository. > >Filename: draft-linsner-lmap-use-cases >Revision: 01 >Title: Large-Scale Broadband Measurement Use Cases >Creation date: 2013-02-08 >WG ID: Individual Submission >Number of pages: 15 >URL: =20 >http://www.ietf.org/internet-drafts/draft-linsner-lmap-use-cases-01.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-linsner-lmap-use-cases >Htmlized: =20 >http://tools.ietf.org/html/draft-linsner-lmap-use-cases-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-linsner-lmap-use-cases-01 > >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. > > > =20 > =20 > > >The IETF Secretariat > From mlinsner@cisco.com Fri Feb 8 13:23: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 0E1BB21F8B8D for ; Fri, 8 Feb 2013 13:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.264 X-Spam-Level: X-Spam-Status: No, score=-9.264 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 KzAlgR+ThwBY for ; Fri, 8 Feb 2013 13:22:59 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7853721F8A67 for ; Fri, 8 Feb 2013 13:22:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1929; q=dns/txt; s=iport; t=1360358578; x=1361568178; h=date:subject:from:to:message-id:mime-version; bh=BJZ3WfhWUjio5bgHcKpgFc3FVe78BsyrLkKbHN91oWI=; b=ZA7lqQcppREieLCLgnC/iQv1TBo1Um2Q5iKutVlcRHd8ZUS3nBDWMlcY m+PDyHocaWcGdeMI/tBBcZe8hYQgo1wi8UiTY37vyjud4DtcmRhsmC77R qYKQyHGdYoYI7B9cNFRnvAZ3KMizR+3R86USW2PCSIQm8kIvdCDxbFJLq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKprFVGtJXG8/2dsb2JhbABFgkm+QxZzghYQPTcYCwGBH4gknjuhDo4zgykDiGaNPoVximKDHg X-IronPort-AV: E=Sophos;i="4.84,632,1355097600"; d="scan'208,217";a="174857632" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 08 Feb 2013 21:22:58 +0000 Received: from [10.116.195.119] (rtp-mlinsner-8716.cisco.com [10.116.195.119]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r18LMurS018247 for ; Fri, 8 Feb 2013 21:22:57 GMT User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Fri, 08 Feb 2013 16:22:55 -0500 From: Marc Linsner To: Message-ID: Thread-Topic: Use Case draft Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3443185377_1678608" Subject: [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, 08 Feb 2013 21:23:02 -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_3443185377_1678608 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, As you can see, we submitted 01 of the Use Case draft. Major additions describing the Internet Service Provider Use Case, text from Philip Eardley (now co-author). Also added a Regulator Use Case from James Miller. I'd like opinions on whether this draft is the right place for the Terminology: Roles & Basic Elements discussion that was taking place back on January 2 before the charter/bof discussion took center stage. There is still time to spin this before the deadline of Feb. 25. Fire away, Marc Linsner Philip Eardley --B_3443185377_1678608 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
All,

As you can see, we submitted 01 of the Use Case draft.  Major additio= ns describing the Internet Service Provider Use Case, text from Philip Eardl= ey (now co-author).  Also added a Regulator Use Case from James Miller.=

I'd like opinions on whether this draft is the rig= ht place for the Terminology: Roles & Basic Elements discussion that was= taking place back on January 2 before the charter/bof discussion took cente= r stage.

There is still time to spin this before th= e deadline of Feb. 25.

Fire away,

Marc Linsner
Philip Eardley


<= /div> --B_3443185377_1678608-- From jamesmilleresquire@gmail.com Fri Feb 8 15:24: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 DA3BE21F8B7D for ; Fri, 8 Feb 2013 15:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=0.375, 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 BcsTtAVmyhgS for ; Fri, 8 Feb 2013 15:24:00 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1B45521F8B70 for ; Fri, 8 Feb 2013 15:23:59 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id o1so1434164wic.17 for ; Fri, 08 Feb 2013 15:23:59 -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=GRZH4gg0MBFpi5EwiW33dVpwBuz2DjkTqEY4CeCvex0=; b=RK0I7uR1rIBZVMAFvRtjMYH5GTEVrxKvIPJJ7cwOmJ0xJi5SkP/EBnKsk40epNC9Hx dWFficd+hPozXdkeQyqSxuRqBd1lfXZGZzQrrScK/70YvoQk/q9QMxMGLErI6vUS+IsB Z7W4X3d2GhjVDv3fAoli6Q1R8dEy7klwnctHV9ifEG3qm+ZOb/zGRQww+uWzRH22REXN ycDJMNaYeqJasfcMP8J/iVg6aQU019xy+SYtrW+3Df5IQdw776Io5J9+hv2NgOqaWOdo v/f/K8Q8SqX7rQE4d2hwVoL/zUo52TrSex2+lfwaW3co5a/FfMP33IcQO185A/88rqHD 35kQ== X-Received: by 10.194.24.42 with SMTP id r10mr12775752wjf.2.1360365839094; Fri, 08 Feb 2013 15:23:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.105.36 with HTTP; Fri, 8 Feb 2013 15:23:29 -0800 (PST) In-Reply-To: References: From: James Miller Date: Fri, 8 Feb 2013 18:23:29 -0500 Message-ID: To: Marc Linsner Content-Type: multipart/alternative; boundary=047d7b5d96599a937704d53eda27 Cc: lmap@ietf.org Subject: Re: [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, 08 Feb 2013 23:24:01 -0000 --047d7b5d96599a937704d53eda27 Content-Type: text/plain; charset=ISO-8859-1 Marc, I think that an updated draft with the regulatory section would answer several questions that were on the list. I don't have an opinion on the roles basic elements point, though use case does seem congruent. On Fri, Feb 8, 2013 at 4:22 PM, Marc Linsner wrote: > Roles & Basic Elements discussion that was taking place back on January 2 > before the charter/bof discussion took center stage --047d7b5d96599a937704d53eda27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Marc,

I think that an updated draft with the regulatory = section would answer several questions that were on the list. =A0I don'= t have an opinion on the roles basic elements point, though use case does s= eem congruent.

On Fri, Feb 8, 2013 at 4:22 PM, Marc Li= nsner <mlinsner@cisco.com> wrote:
Roles & Basic Elements discussion that was taking place back on January= 2 before the charter/bof discussion took center stage

--047d7b5d96599a937704d53eda27-- From acmorton@att.com Tue Feb 12 09:14: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 5033321F8CE9 for ; Tue, 12 Feb 2013 09:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.434 X-Spam-Level: X-Spam-Status: No, score=-106.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 pgPHn-8D26DJ for ; Tue, 12 Feb 2013 09:14:27 -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 9C1FA21F8CF6 for ; Tue, 12 Feb 2013 09:14:24 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 427C51205A0; Tue, 12 Feb 2013 12:16:22 -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 3A681F00F2; Tue, 12 Feb 2013 12:14:24 -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; Tue, 12 Feb 2013 12:14:24 -0500 From: "MORTON JR., ALFRED (AL)" To: marcelo bagnulo braun , "lmap@ietf.org" Date: Tue, 12 Feb 2013 12:14:23 -0500 Thread-Topic: [lmap] Fwd: I-D Action: draft-bagnulo-lmap-ipfix-00.txt Thread-Index: Ac4F6wj0x2IJrN4jStGh+/tN3EvO6QDUot5w Message-ID: References: <20130208105429.13543.58572.idtracker@ietfa.amsl.com> <5114D9F1.6000802@it.uc3m.es> In-Reply-To: <5114D9F1.6000802@it.uc3m.es> 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 Subject: Re: [lmap] Fwd: I-D Action: draft-bagnulo-lmap-ipfix-00.txt 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, 12 Feb 2013 17:14:28 -0000 Hi Marcelo and Brian, This is a good initial examination of the=20 reporting problem seen through IPFIX-glasses,=20 and it seems to be a decent match. A couple of comments below, Al > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > marcelo bagnulo braun > Sent: Friday, February 08, 2013 5:57 AM > To: lmap@ietf.org > Subject: [lmap] Fwd: I-D Action: draft-bagnulo-lmap-ipfix-00.txt >=20 > Hi, >=20 > Following Dan's comments, we have tried to explore how IPFIX can be used > to report test results from the measurement agent to the collector. > Please find it described in the following draft. > Comments are welcome. >=20 > Regards, marcelo >=20 >=20 > -------- Mensaje original -------- > Asunto: I-D Action: draft-bagnulo-lmap-ipfix-00.txt ... > There's also a htmlized version available at: http://tools.ietf.org/html/draft-bagnulo-lmap-ipfix-00 >=20 In section 2: Part of the information can be conveyed using the fields in the IPFIX header, namely: o Information about the MA: In order to convey the MA identifier we can use the Observation Domain field present in the IPFIX header. This would allow to have up to 2^32 MA, which seems sufficient. Although the 32-bit identifier range is huge, it may be helpful in the long term to structure the MA identifiers in one way, so they can convey=20 some limited info about the MA beyond unique identity.=20 MAC addresses provide one example structure http://en.wikipedia.org/wiki/MA= C_address I suggest the MA Identifier format goes on the to-standardize list (which seems to be section 5). more section 2: o An identifier of the scheduling strategy used to perform the test. Again, this will be a new IE, called testSchedule and its values will be the values defined in the Scheduling registry of [I-D.bagnulo-ippm-new-registry-independent]. The potential input parameters for the schedule, such as the rate, we probably need a new IE for each of these. Usual scheduling distributions only require a rate, so we can define a new IE called scheduleRate which value will contain the rate for the requested distribution. While rate fit Poisson and Periodic very well, some test streams require as many as three stream specifications: + a rate for sending ensembles of packets + a rate for sending packets within each ensemble + the number of packets in each the ensemble so it seems these are all potential IE, if I understand how it will work. section 3: This is a useful example, and at the same time I'm sure many readers will think there are many IE repeated here=20 to convey each singleton of UDP Latency. The observation simply encourages the investigation of a more compact option under IPFIX rules - something to think about. And section 4 seems to describe exactly that, so to clarify: section 4: Would use of the Options Template mean that all these: metricIdentifier =3D UDP_Latency as per [I-D.bagnulo-ippm-new-registry-independent] testSchedule =3D Periodic as per [I-D.bagnulo-ippm-new-registry-independent] scheduleRate =3D 1 outputType =3D Raw as per [I-D.bagnulo-ippm-new-registry-independent] testEnvironment =3D No-cross-traffic as per [I-D.bagnulo-ippm-new-registry-independent] sourceIPv4Address =3D 192.0.2.1 destinationIPv4Address =3D 203.0.113.1 sourceTransportPort =3D 23677 destinationTransportPort =3D 34567 would appear only once in the exchange that describes a finite-length test? =20 From trammell@tik.ee.ethz.ch Wed Feb 13 00:56:47 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 8792121F8816 for ; Wed, 13 Feb 2013 00:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.18 X-Spam-Level: X-Spam-Status: No, score=-6.18 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1L9eCTlcpPV for ; Wed, 13 Feb 2013 00:56:46 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 11E5321F8812 for ; Wed, 13 Feb 2013 00:56:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 46796D930B; Wed, 13 Feb 2013 09:56:27 +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 uYZg12KatZ3g; Wed, 13 Feb 2013 09:56:27 +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 E279FD930A; Wed, 13 Feb 2013 09:56:26 +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: Wed, 13 Feb 2013 09:56:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <08C9D56E-8352-4A60-9DCF-8E75BB19D59C@tik.ee.ethz.ch> References: <20130208105429.13543.58572.idtracker@ietfa.amsl.com> <5114D9F1.6000802@it.uc3m.es> To: "MORTON JR., ALFRED (AL)" X-Mailer: Apple Mail (2.1499) Cc: marcelo bagnulo braun , "lmap@ietf.org" Subject: Re: [lmap] I-D Action: draft-bagnulo-lmap-ipfix-00.txt 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, 13 Feb 2013 08:56:47 -0000 hi, Al, Thanks for the comments! Comments/questions inline. On Feb 12, 2013, at 6:14 PM, "MORTON JR., ALFRED (AL)" = wrote: > Hi Marcelo and Brian, >=20 > This is a good initial examination of the=20 > reporting problem seen through IPFIX-glasses,=20 > and it seems to be a decent match. >=20 > A couple of comments below, > Al >=20 >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf = Of >> marcelo bagnulo braun >> Sent: Friday, February 08, 2013 5:57 AM >> To: lmap@ietf.org >> Subject: [lmap] Fwd: I-D Action: draft-bagnulo-lmap-ipfix-00.txt >>=20 >> Hi, >>=20 >> Following Dan's comments, we have tried to explore how IPFIX can be = used >> to report test results from the measurement agent to the collector. >> Please find it described in the following draft. >> Comments are welcome. >>=20 >> Regards, marcelo >>=20 >>=20 >> -------- Mensaje original -------- >> Asunto: I-D Action: draft-bagnulo-lmap-ipfix-00.txt > ... >> There's also a htmlized version available at: > http://tools.ietf.org/html/draft-bagnulo-lmap-ipfix-00 >>=20 >=20 > In section 2: > Part of the information can be conveyed using the fields in the = IPFIX > header, namely: >=20 > o Information about the MA: In order to convey the MA identifier we > can use the Observation Domain field present in the IPFIX header. > This would allow to have up to 2^32 MA, which seems sufficient. >=20 > Although the 32-bit identifier range is huge, it may be helpful in the > long term to structure the MA identifiers in one way, so they can = convey=20 > some limited info about the MA beyond unique identity.=20 > MAC addresses provide one example structure = http://en.wikipedia.org/wiki/MAC_address > I suggest the MA Identifier format goes on the to-standardize list > (which seems to be section 5). Yep. We could certainly define a 32-bit MAID with structure, then say = "an MA is coterminous with an IPFIX Observation Domain" in the = lmap-ipfix binding. Will 32 bits be enough? > more section 2: > o An identifier of the scheduling strategy used to perform the = test. > Again, this will be a new IE, called testSchedule and its values > will be the values defined in the Scheduling registry of > [I-D.bagnulo-ippm-new-registry-independent]. The potential input > parameters for the schedule, such as the rate, we probably need a > new IE for each of these. Usual scheduling distributions only > require a rate, so we can define a new IE called scheduleRate > which value will contain the rate for the requested distribution. >=20 > While rate fit Poisson and Periodic very well, some test streams = require > as many as three stream specifications: > + a rate for sending ensembles of packets > + a rate for sending packets within each ensemble > + the number of packets in each the ensemble > so it seems these are all potential IE, if I understand how it will = work. Will we ever (realistically) have nesting of ensembles? (e.g. pattern-1 =3D 3ms delay 200 packets/3ms; pattern 2 =3D 10 ms delay = pattern-1 4ms delay pattern-1) > section 3: > This is a useful example, and at the same time > I'm sure many readers will think there are many IE repeated here=20 > to convey each singleton of UDP Latency. The observation simply > encourages the investigation of a more compact option under > IPFIX rules - something to think about. And section 4 seems > to describe exactly that, so to clarify: There's a couple of reasons to start from here. First of all, Options (as below) are essentially an on-wire way to = compress scoped values; the API at the MA and at the Collector should = give you access to those values as if they are properties of the record = anyway. So this view looks like the the resulting data received by the = collector, if not precisely how it will be represented. Second, I'm a little skeptical of the true cost-benefit of compressing = things this way. If you're dealing with a federated system in which each = measurement may be forwarded / correlated / aggregated / transformed by = different mediators (collectors which process and re-export information = -- in the LMAP case, think intermediate collectors at each POP), then = scoping things to sessions so as to reduce redundancy means you need to = keep those sessions separate across mediation sessions, or have those = mediators do something like remap re-exported sessions to a = commonPropertiesId (see RFC 5473). The tradeoff here is on-wire = efficiency for complexity. At high degrees of aggregation and low rates of export, you end up with = almost every record having all the values anyway: the channel from the = MA to the first level collector might send one message every second, the = channel from that collector back to central reporting would have one = record per MA per second, bundled together into messages. Now you have = to export the parameters for each MA (or find properties common to all = MAs, and split the common properties into MA, sub-global, and global), = and so on. The math changes depending on how much information is common to each = record from an MA (test conditions) how much information is different = (test results), and how it will be aggregated as it moves toward the = center; we should actually do an analysis based on expected measurement = traffic load to see what we should recommend sticking in options and = what not. What seems self-evident looking at a single record has to be = considered in the context of how it will scale up and out. > section 4: > Would use of the Options Template mean that all these: > metricIdentifier =3D UDP_Latency as per > [I-D.bagnulo-ippm-new-registry-independent] > testSchedule =3D Periodic as per > [I-D.bagnulo-ippm-new-registry-independent] > scheduleRate =3D 1 > outputType =3D Raw as per > [I-D.bagnulo-ippm-new-registry-independent] > testEnvironment =3D No-cross-traffic as per > [I-D.bagnulo-ippm-new-registry-independent] > sourceIPv4Address =3D 192.0.2.1 > destinationIPv4Address =3D 203.0.113.1 > sourceTransportPort =3D 23677 > destinationTransportPort =3D 34567 >=20 > would appear only once in the exchange that describes a finite-length = test? That's the idea. Options in this case bind values to sessions, which is = essentially a way of compressing the data at the IPFIX level by making = it implicit. Cheers, Brian > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From acmorton@att.com Thu Feb 14 15:30: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 0FFB821F8780 for ; Thu, 14 Feb 2013 15:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.403 X-Spam-Level: X-Spam-Status: No, score=-106.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 FqCMgGK0QuN5 for ; Thu, 14 Feb 2013 15:30:20 -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 84E7E21F86DD for ; Thu, 14 Feb 2013 15:30:20 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 28A73120F92; Thu, 14 Feb 2013 18:32:23 -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 E5667F00C6; Thu, 14 Feb 2013 18:30:19 -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, 14 Feb 2013 18:30:19 -0500 From: "MORTON JR., ALFRED (AL)" To: Brian Trammell Date: Thu, 14 Feb 2013 18:30:17 -0500 Thread-Topic: [lmap] I-D Action: draft-bagnulo-lmap-ipfix-00.txt Thread-Index: Ac4JyAxsrS26ftLoSpKNbTMAKK7ilgBP7dRQ Message-ID: References: <20130208105429.13543.58572.idtracker@ietfa.amsl.com> <5114D9F1.6000802@it.uc3m.es> <08C9D56E-8352-4A60-9DCF-8E75BB19D59C@tik.ee.ethz.ch> In-Reply-To: <08C9D56E-8352-4A60-9DCF-8E75BB19D59C@tik.ee.ethz.ch> 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: marcelo bagnulo braun , "lmap@ietf.org" Subject: Re: [lmap] I-D Action: draft-bagnulo-lmap-ipfix-00.txt 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, 14 Feb 2013 23:30:23 -0000 Hi Brian, Thanks for your questions to further discussion, and especially for your detailed reply revealing some of the complexities of scale when intermediate collectors and re-exporting are necessary. Very thoughtful stuff: I sense you have already been living in the world of Large-Scale. Regarding MA Identification, 32 bits will certainly get us started, but we don't need to set a limit this week :-) . The main point is to=20 get the MAID format on our to-do list for standardization, and we've=20 begun the discussion with 3 messages. Since you mentioned a possible=20 proliferation of collectors, maybe we should be considering more than Mas when assigning ID... "Would we ever have Nesting of ensembles?" I never say never, but I actually thought of a legitimate use case. One would pre-load the test path with one type of ensemble rate & length, then perform the measurement with another ensemble, different rate and leng= th. The same thing could be handled with a form of multi-stage scheduling, which a few of us discussed last week, and I'll repeat some of what I wrote for everyone here: ... it seems fairly simple to use the current registries for metric, scheduling, output and (desired?) enviro= nment to indicate the specifications that will likely change from test to test. Plus, we need two more specifications: + pause time following a measurement of a set of singletons (sample) + indicator that the *following* test specification is to run concurrently = (& below) So, an AA0000001 test series could be registered and used to perform (this is for a latency test performed on its own,=20 environment_1 allows cross traffic, then a BTC test with concurrent latency, no cross traffic other than test traffic): - UDP Latency_1, Poisson_3, output_4, environment_1, pause=3D5000ms, & BulkTransCap_1, LocalCtrl, output_1, environment_0, pause=3D1000ms, - UDP Latency_1, Poisson_3, output_4, environment_0, pause=3D1000ms, - END There are many specs that don't change from test to test,=20 like Source address, Dest address, overall test sequence start time, measurement points (mp100, mp150), so one view of the test schedule would simply list these factors and "test sequence=3DAA0000001". Al > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: Wednesday, February 13, 2013 3:56 AM > To: MORTON JR., ALFRED (AL) > Cc: marcelo bagnulo braun; lmap@ietf.org > Subject: Re: [lmap] I-D Action: draft-bagnulo-lmap-ipfix-00.txt >=20 > hi, Al, >=20 > Thanks for the comments! Comments/questions inline. >=20 > On Feb 12, 2013, at 6:14 PM, "MORTON JR., ALFRED (AL)" > wrote: >=20 > > Hi Marcelo and Brian, > > > > This is a good initial examination of the > > reporting problem seen through IPFIX-glasses, > > and it seems to be a decent match. > > > > A couple of comments below, > > Al > > > >> -----Original Message----- > >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf O= f > >> marcelo bagnulo braun > >> Sent: Friday, February 08, 2013 5:57 AM > >> To: lmap@ietf.org > >> Subject: [lmap] Fwd: I-D Action: draft-bagnulo-lmap-ipfix-00.txt > >> > >> Hi, > >> > >> Following Dan's comments, we have tried to explore how IPFIX can be > used > >> to report test results from the measurement agent to the collector. > >> Please find it described in the following draft. > >> Comments are welcome. > >> > >> Regards, marcelo > >> > >> > >> -------- Mensaje original -------- > >> Asunto: I-D Action: draft-bagnulo-lmap-ipfix-00.txt > > ... > >> There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-bagnulo-lmap-ipfix-00 > >> > > > > In section 2: > > Part of the information can be conveyed using the fields in the IPFIX > > header, namely: > > > > o Information about the MA: In order to convey the MA identifier we > > can use the Observation Domain field present in the IPFIX header. > > This would allow to have up to 2^32 MA, which seems sufficient. > > > > Although the 32-bit identifier range is huge, it may be helpful in the > > long term to structure the MA identifiers in one way, so they can conve= y > > some limited info about the MA beyond unique identity. > > MAC addresses provide one example structure > http://en.wikipedia.org/wiki/MAC_address > > I suggest the MA Identifier format goes on the to-standardize list > > (which seems to be section 5). >=20 > Yep. We could certainly define a 32-bit MAID with structure, then say "an > MA is coterminous with an IPFIX Observation Domain" in the lmap-ipfix > binding. Will 32 bits be enough? >=20 > > more section 2: > > o An identifier of the scheduling strategy used to perform the test. > > Again, this will be a new IE, called testSchedule and its values > > will be the values defined in the Scheduling registry of > > [I-D.bagnulo-ippm-new-registry-independent]. The potential input > > parameters for the schedule, such as the rate, we probably need a > > new IE for each of these. Usual scheduling distributions only > > require a rate, so we can define a new IE called scheduleRate > > which value will contain the rate for the requested distribution. > > > > While rate fit Poisson and Periodic very well, some test streams requir= e > > as many as three stream specifications: > > + a rate for sending ensembles of packets > > + a rate for sending packets within each ensemble > > + the number of packets in each the ensemble > > so it seems these are all potential IE, if I understand how it will > work. >=20 > Will we ever (realistically) have nesting of ensembles? >=20 > (e.g. pattern-1 =3D 3ms delay 200 packets/3ms; pattern 2 =3D 10 ms delay > pattern-1 4ms delay pattern-1) >=20 > > section 3: > > This is a useful example, and at the same time > > I'm sure many readers will think there are many IE repeated here > > to convey each singleton of UDP Latency. The observation simply > > encourages the investigation of a more compact option under > > IPFIX rules - something to think about. And section 4 seems > > to describe exactly that, so to clarify: >=20 > There's a couple of reasons to start from here. >=20 > First of all, Options (as below) are essentially an on-wire way to > compress scoped values; the API at the MA and at the Collector should giv= e > you access to those values as if they are properties of the record anyway= . > So this view looks like the the resulting data received by the collector, > if not precisely how it will be represented. >=20 > Second, I'm a little skeptical of the true cost-benefit of compressing > things this way. If you're dealing with a federated system in which each > measurement may be forwarded / correlated / aggregated / transformed by > different mediators (collectors which process and re-export information -= - > in the LMAP case, think intermediate collectors at each POP), then scopin= g > things to sessions so as to reduce redundancy means you need to keep thos= e > sessions separate across mediation sessions, or have those mediators do > something like remap re-exported sessions to a commonPropertiesId (see RF= C > 5473). The tradeoff here is on-wire efficiency for complexity. >=20 > At high degrees of aggregation and low rates of export, you end up with > almost every record having all the values anyway: the channel from the MA > to the first level collector might send one message every second, the > channel from that collector back to central reporting would have one > record per MA per second, bundled together into messages. Now you have to > export the parameters for each MA (or find properties common to all MAs, > and split the common properties into MA, sub-global, and global), and so > on. >=20 > The math changes depending on how much information is common to each > record from an MA (test conditions) how much information is different > (test results), and how it will be aggregated as it moves toward the > center; we should actually do an analysis based on expected measurement > traffic load to see what we should recommend sticking in options and what > not. What seems self-evident looking at a single record has to be > considered in the context of how it will scale up and out. >=20 > > section 4: > > Would use of the Options Template mean that all these: > > metricIdentifier =3D UDP_Latency as per > > [I-D.bagnulo-ippm-new-registry-independent] > > testSchedule =3D Periodic as per > > [I-D.bagnulo-ippm-new-registry-independent] > > scheduleRate =3D 1 > > outputType =3D Raw as per > > [I-D.bagnulo-ippm-new-registry-independent] > > testEnvironment =3D No-cross-traffic as per > > [I-D.bagnulo-ippm-new-registry-independent] > > sourceIPv4Address =3D 192.0.2.1 > > destinationIPv4Address =3D 203.0.113.1 > > sourceTransportPort =3D 23677 > > destinationTransportPort =3D 34567 > > > > would appear only once in the exchange that describes a finite-length > test? >=20 > That's the idea. Options in this case bind values to sessions, which is > essentially a way of compressing the data at the IPFIX level by making it > implicit. >=20 > Cheers, >=20 > Brian >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap From trammell@tik.ee.ethz.ch Fri Feb 15 06:48:42 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 711CA21F8AE6 for ; Fri, 15 Feb 2013 06:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.022, 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 oE+13CSTQ0Al for ; Fri, 15 Feb 2013 06:48:41 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E872521F8AB4 for ; Fri, 15 Feb 2013 06:48:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0692AD930B; Fri, 15 Feb 2013 15:48:40 +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 1AntY-XdUrd4; Fri, 15 Feb 2013 15:48:39 +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 B7B18D9307; Fri, 15 Feb 2013 15:48:39 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Fri, 15 Feb 2013 15:48:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130208105429.13543.58572.idtracker@ietfa.amsl.com> <5114D9F1.6000802@it.uc3m.es> <08C9D56E-8352-4A60-9DCF-8E75BB19D59C@tik.ee.ethz.ch> To: "MORTON JR., ALFRED (AL)" X-Mailer: Apple Mail (2.1283) Cc: marcelo bagnulo braun , "lmap@ietf.org" Subject: Re: [lmap] I-D Action: draft-bagnulo-lmap-ipfix-00.txt 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, 15 Feb 2013 14:48:42 -0000 hi Al, all, a couple of brief points inline (will have to think more about the = ensemble nesting thing)... On 15 Feb 2013, at 0:30 , MORTON JR., ALFRED (AL) wrote: > Hi Brian, >=20 > Thanks for your questions to further discussion, and especially for > your detailed reply revealing some of the complexities of scale > when intermediate collectors and re-exporting are necessary. > Very thoughtful stuff: I sense you have already been living in the > world of Large-Scale. > Regarding MA Identification, 32 bits will certainly get us started, > but we don't need to set a limit this week :-) . The main point is to=20= > get the MAID format on our to-do list for standardization, and we've=20= > begun the discussion with 3 messages. Since you mentioned a possible=20= > proliferation of collectors, maybe we should be considering more than > Mas when assigning ID... Indeed. If a mediator (collector and re-exporter with some intermediate = process that correlates/aggregates/filters/etc the records sent across = it) generates substantially new data records (i.e., by deriving a new = metric through spatial or temporal composition), it's generally = considered a new Observation Domain.=20 So we probably want to identify anything that sends reports with a MAID. > "Would we ever have Nesting of ensembles?" > I never say never, but I actually thought of a legitimate use case. > One would pre-load the test path with one type of ensemble rate & = length, > then perform the measurement with another ensemble, different rate and = length. > The same thing could be handled with a form of multi-stage scheduling, > which a few of us discussed last week, and I'll repeat some of what > I wrote for everyone here: >=20 > ... it seems fairly simple to use > the current registries for metric, scheduling, output and (desired?) = environment > to indicate the specifications that will likely change from test to = test. > Plus, we need two more specifications: >=20 > + pause time following a measurement of a set of singletons (sample) > + indicator that the *following* test specification is to run = concurrently (& below) >=20 > So, an AA0000001 test series could be registered and used to perform > (this is for a latency test performed on its own,=20 > environment_1 allows cross traffic, then a BTC test > with concurrent latency, no cross traffic other than test traffic): >=20 > - UDP Latency_1, Poisson_3, output_4, environment_1, pause=3D5000ms, > & BulkTransCap_1, LocalCtrl, output_1, environment_0, pause=3D1000ms, > - UDP Latency_1, Poisson_3, output_4, environment_0, pause=3D1000ms, > - END >=20 > There are many specs that don't change from test to test,=20 > like Source address, Dest address, overall test sequence start time, > measurement points (mp100, mp150), so one view of the test schedule > would simply list these factors and "test sequence=3DAA0000001". Then we probably want to use an explicit test sequence identifier, and = use options records to define the test sequence parameters. We may also = want to have two sequence identifiers, one for metrics-registry keys = representing the environment, test schedule, etc., and one representing = test parameters like the source, destination, etc... Cheers, Brian > Al >=20 >> -----Original Message----- >> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >> Sent: Wednesday, February 13, 2013 3:56 AM >> To: MORTON JR., ALFRED (AL) >> Cc: marcelo bagnulo braun; lmap@ietf.org >> Subject: Re: [lmap] I-D Action: draft-bagnulo-lmap-ipfix-00.txt >>=20 >> hi, Al, >>=20 >> Thanks for the comments! Comments/questions inline. >>=20 >> On Feb 12, 2013, at 6:14 PM, "MORTON JR., ALFRED (AL)" = >> wrote: >>=20 >>> Hi Marcelo and Brian, >>>=20 >>> This is a good initial examination of the >>> reporting problem seen through IPFIX-glasses, >>> and it seems to be a decent match. >>>=20 >>> A couple of comments below, >>> Al >>>=20 >>>> -----Original Message----- >>>> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On = Behalf Of >>>> marcelo bagnulo braun >>>> Sent: Friday, February 08, 2013 5:57 AM >>>> To: lmap@ietf.org >>>> Subject: [lmap] Fwd: I-D Action: draft-bagnulo-lmap-ipfix-00.txt >>>>=20 >>>> Hi, >>>>=20 >>>> Following Dan's comments, we have tried to explore how IPFIX can be >> used >>>> to report test results from the measurement agent to the collector. >>>> Please find it described in the following draft. >>>> Comments are welcome. >>>>=20 >>>> Regards, marcelo >>>>=20 >>>>=20 >>>> -------- Mensaje original -------- >>>> Asunto: I-D Action: draft-bagnulo-lmap-ipfix-00.txt >>> ... >>>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-bagnulo-lmap-ipfix-00 >>>>=20 >>>=20 >>> In section 2: >>> Part of the information can be conveyed using the fields in the = IPFIX >>> header, namely: >>>=20 >>> o Information about the MA: In order to convey the MA identifier = we >>> can use the Observation Domain field present in the IPFIX = header. >>> This would allow to have up to 2^32 MA, which seems sufficient. >>>=20 >>> Although the 32-bit identifier range is huge, it may be helpful in = the >>> long term to structure the MA identifiers in one way, so they can = convey >>> some limited info about the MA beyond unique identity. >>> MAC addresses provide one example structure >> http://en.wikipedia.org/wiki/MAC_address >>> I suggest the MA Identifier format goes on the to-standardize list >>> (which seems to be section 5). >>=20 >> Yep. We could certainly define a 32-bit MAID with structure, then say = "an >> MA is coterminous with an IPFIX Observation Domain" in the lmap-ipfix >> binding. Will 32 bits be enough? >>=20 >>> more section 2: >>> o An identifier of the scheduling strategy used to perform the = test. >>> Again, this will be a new IE, called testSchedule and its values >>> will be the values defined in the Scheduling registry of >>> [I-D.bagnulo-ippm-new-registry-independent]. The potential = input >>> parameters for the schedule, such as the rate, we probably need = a >>> new IE for each of these. Usual scheduling distributions only >>> require a rate, so we can define a new IE called scheduleRate >>> which value will contain the rate for the requested = distribution. >>>=20 >>> While rate fit Poisson and Periodic very well, some test streams = require >>> as many as three stream specifications: >>> + a rate for sending ensembles of packets >>> + a rate for sending packets within each ensemble >>> + the number of packets in each the ensemble >>> so it seems these are all potential IE, if I understand how it will >> work. >>=20 >> Will we ever (realistically) have nesting of ensembles? >>=20 >> (e.g. pattern-1 =3D 3ms delay 200 packets/3ms; pattern 2 =3D 10 ms = delay >> pattern-1 4ms delay pattern-1) >>=20 >>> section 3: >>> This is a useful example, and at the same time >>> I'm sure many readers will think there are many IE repeated here >>> to convey each singleton of UDP Latency. The observation simply >>> encourages the investigation of a more compact option under >>> IPFIX rules - something to think about. And section 4 seems >>> to describe exactly that, so to clarify: >>=20 >> There's a couple of reasons to start from here. >>=20 >> First of all, Options (as below) are essentially an on-wire way to >> compress scoped values; the API at the MA and at the Collector should = give >> you access to those values as if they are properties of the record = anyway. >> So this view looks like the the resulting data received by the = collector, >> if not precisely how it will be represented. >>=20 >> Second, I'm a little skeptical of the true cost-benefit of = compressing >> things this way. If you're dealing with a federated system in which = each >> measurement may be forwarded / correlated / aggregated / transformed = by >> different mediators (collectors which process and re-export = information -- >> in the LMAP case, think intermediate collectors at each POP), then = scoping >> things to sessions so as to reduce redundancy means you need to keep = those >> sessions separate across mediation sessions, or have those mediators = do >> something like remap re-exported sessions to a commonPropertiesId = (see RFC >> 5473). The tradeoff here is on-wire efficiency for complexity. >>=20 >> At high degrees of aggregation and low rates of export, you end up = with >> almost every record having all the values anyway: the channel from = the MA >> to the first level collector might send one message every second, the >> channel from that collector back to central reporting would have one >> record per MA per second, bundled together into messages. Now you = have to >> export the parameters for each MA (or find properties common to all = MAs, >> and split the common properties into MA, sub-global, and global), and = so >> on. >>=20 >> The math changes depending on how much information is common to each >> record from an MA (test conditions) how much information is different >> (test results), and how it will be aggregated as it moves toward the >> center; we should actually do an analysis based on expected = measurement >> traffic load to see what we should recommend sticking in options and = what >> not. What seems self-evident looking at a single record has to be >> considered in the context of how it will scale up and out. >>=20 >>> section 4: >>> Would use of the Options Template mean that all these: >>> metricIdentifier =3D UDP_Latency as per >>> [I-D.bagnulo-ippm-new-registry-independent] >>> testSchedule =3D Periodic as per >>> [I-D.bagnulo-ippm-new-registry-independent] >>> scheduleRate =3D 1 >>> outputType =3D Raw as per >>> [I-D.bagnulo-ippm-new-registry-independent] >>> testEnvironment =3D No-cross-traffic as per >>> [I-D.bagnulo-ippm-new-registry-independent] >>> sourceIPv4Address =3D 192.0.2.1 >>> destinationIPv4Address =3D 203.0.113.1 >>> sourceTransportPort =3D 23677 >>> destinationTransportPort =3D 34567 >>>=20 >>> would appear only once in the exchange that describes a = finite-length >> test? >>=20 >> That's the idea. Options in this case bind values to sessions, which = is >> essentially a way of compressing the data at the IPFIX level by = making it >> implicit. >>=20 >> Cheers, >>=20 >> Brian >>=20 >>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap From j.schoenwaelder@jacobs-university.de Sat Feb 16 06:17: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 5C58221F8953 for ; Sat, 16 Feb 2013 06:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.85 X-Spam-Level: X-Spam-Status: No, score=-102.85 tagged_above=-999 required=5 tests=[AWL=0.399, 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 Ul6P6D0b1-Y7 for ; Sat, 16 Feb 2013 06:17:00 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B102F21F88E6 for ; Sat, 16 Feb 2013 06:16:59 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE5FB20C01 for ; Sat, 16 Feb 2013 15:16:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HGVdFKmylR8G for ; Sat, 16 Feb 2013 15:16:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 849CE20BF3 for ; Sat, 16 Feb 2013 15:16:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5CC4F2494786; Sat, 16 Feb 2013 15:17:06 +0100 (CET) Resent-From: Juergen Schoenwaelder Resent-Date: Sat, 16 Feb 2013 15:17:06 +0100 Resent-Message-ID: <20130216141706.GB99830@elstar.local> Resent-To: lmap@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS01.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server id 14.2.342.3; Sat, 16 Feb 2013 15:15:18 +0100 Received: from atlas1.jacobs-university.de (atlas1a.jacobs-university.de [212.201.44.13]) by hermes.jacobs-university.de (Postfix) with ESMTP id A85E320BF3 for ; Sat, 16 Feb 2013 15:15:25 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by atlas1.jacobs-university.de (Postfix) with ESMTP id 9FEC63D3 for ; Sat, 16 Feb 2013 15:15:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas1b.jacobs-university.de ([212.201.44.13]) by localhost (demetrius2.jacobs-university.de [212.201.44.47]) (amavisd-new, port 10030) with ESMTP id 2AKLPB3ExbTS for ; Sat, 16 Feb 2013 15:15:24 +0100 (CET) X-JacobsISPWhiteListed: No X-policyd-weight: using cached result; rate:hard: -7.6 Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by atlas1b.jacobs-university.de (Postfix) with ESMTP for ; Sat, 16 Feb 2013 15:15:24 +0100 (CET) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583ED21F8943; Sat, 16 Feb 2013 06:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1361024084; bh=+eVtXVPWX0nQInqUr7Bil+m7Wn1jlH865ckVrFsoMYs=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=KH0QmvPOeEoBCCMQrte4lalzQMCa+rFiBslN9/1wuffIRjfFY+hIj9hSK6DqgmU0V mgfGz6aWxgCYvtY3ipsN75b/XX8JtINHeazoDRctkqD/9YdbFSvhQksq1oACh8kwc6 eDxF62BePWbeBHEkFCthJnMBx1gpdZ7FHYLDLwHc= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F15821F892D for ; Sat, 16 Feb 2013 06:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 AFxNRummKNCX for ; Sat, 16 Feb 2013 06:14:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F245621F8922 for ; Sat, 16 Feb 2013 06:14:40 -0800 (PST) From: To: X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130216141440.6754.40337.idtracker@ietfa.amsl.com> Date: Sat, 16 Feb 2013 06:14:40 -0800 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: i-d-announce-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: SHUBCAS01.jacobs.jacobs-university.de X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 Subject: [lmap] I-D Action: draft-schoenw-lmap-netconf-00.txt X-BeenThere: lmap@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 14:17:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Considerations on using NETCONF with LMAP Measurement Agents Author(s) : Juergen Schoenwaelder Filename : draft-schoenw-lmap-netconf-00.txt Pages : 8 Date : 2013-02-16 Abstract: This document discusses how the NETCONF protocol can be used to configure LMAP measurement agents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-schoenw-lmap-netconf There's also a htmlized version available at: http://tools.ietf.org/html/draft-schoenw-lmap-netconf-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From j.schoenwaelder@jacobs-university.de Sat Feb 16 06:17: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 6AE9C21F88E6 for ; Sat, 16 Feb 2013 06:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.866 X-Spam-Level: X-Spam-Status: No, score=-102.866 tagged_above=-999 required=5 tests=[AWL=0.383, 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 32Z6EQButIW3 for ; Sat, 16 Feb 2013 06:17:00 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B231321F8922 for ; Sat, 16 Feb 2013 06:16:59 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C77D820BF3 for ; Sat, 16 Feb 2013 15:16:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kzxog4IwQZOL for ; Sat, 16 Feb 2013 15:16:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 84B8420BF9 for ; Sat, 16 Feb 2013 15:16:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 51F392494785; Sat, 16 Feb 2013 15:17:06 +0100 (CET) Resent-From: Juergen Schoenwaelder Resent-Date: Sat, 16 Feb 2013 15:17:05 +0100 Resent-Message-ID: <20130216141705.GA99830@elstar.local> Resent-To: lmap@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS02.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server id 14.2.342.3; Sat, 16 Feb 2013 15:14:45 +0100 Received: from atlas1.jacobs-university.de (atlas1a.jacobs-university.de [212.201.44.13]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3357720BF3 for ; Sat, 16 Feb 2013 15:14:52 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by atlas1.jacobs-university.de (Postfix) with ESMTP id 2DFF23D3 for ; Sat, 16 Feb 2013 15:14:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Authentication-Results: demetrius1.jacobs-university.de (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org Received: from atlas1a.jacobs-university.de ([212.201.44.13]) by localhost (demetrius1.jacobs-university.de [212.201.44.46]) (amavisd-new, port 10030) with ESMTP id eHdlHg_0zVBC for ; Sat, 16 Feb 2013 15:14:47 +0100 (CET) X-JacobsISPWhiteListed: No X-policyd-weight: using cached result; rate:hard: -7.6 Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by atlas1a.jacobs-university.de (Postfix) with ESMTP for ; Sat, 16 Feb 2013 15:14:47 +0100 (CET) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F7621F891A; Sat, 16 Feb 2013 06:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1361024068; bh=02Lo3hnMU1TkHKl2P7SgMeWzaGS9vjs01khNGy+/FLI=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=vX9oXAVxd5dKF6PjiE2Ws8j/ukpWB/fS7H+Fic95PIaLBSLvnIp78bs7OAR5OSg0P nuqNgO41is/y+bWZBr03D9Q+l0v1BAygvfZVAEdijgj5jM3YgLRIWZdWdFiS1JzQz9 3OzjJ4I0ZBx/dZ6aPMLwRfMo5VFE1TKxiag+WDpE= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1782C21F88D1 for ; Sat, 16 Feb 2013 06:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 WiDUDlRinni7 for ; Sat, 16 Feb 2013 06:14:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972AF21F881A for ; Sat, 16 Feb 2013 06:14:24 -0800 (PST) From: To: X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130216141424.7476.56807.idtracker@ietfa.amsl.com> Date: Sat, 16 Feb 2013 06:14:24 -0800 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: i-d-announce-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: SHUBCAS02.jacobs.jacobs-university.de X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 Subject: [lmap] I-D Action: draft-schoenw-lmap-yang-00.txt X-BeenThere: lmap@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 14:17:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A YANG Data Model for LMAP Measurement Agents Author(s) : Juergen Schoenwaelder Filename : draft-schoenw-lmap-yang-00.txt Pages : 10 Date : 2013-02-16 Abstract: This document sketches a data model for configuring and scheduling tests for large scale broadband access network measurements. The data model is defined using the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-schoenw-lmap-yang There's also a htmlized version available at: http://tools.ietf.org/html/draft-schoenw-lmap-yang-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From mohamed.boucadair@orange.com Mon Feb 18 05:09:27 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 C9E4621F88BC for ; Mon, 18 Feb 2013 05:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 0jM8r4AZBZh8 for ; Mon, 18 Feb 2013 05:09:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 325E321F88A2 for ; Mon, 18 Feb 2013 05:09:27 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 033E118C889 for ; Mon, 18 Feb 2013 14:09:25 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id E018835C045 for ; Mon, 18 Feb 2013 14:09:24 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 18 Feb 2013 14:09:22 +0100 From: To: "lmap@ietf.org" Date: Mon, 18 Feb 2013 14:09:22 +0100 Thread-Topic: draft-boucadair-lmap-considerations Thread-Index: Ac4N2J+mH3nC807/SKeiO3Ebgvm8+QAAEZLA Message-ID: <94C682931C08B048B7A8645303FDC9F36EB1A52CB0@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.31.121227 Cc: JACQUENET Christian OLNC/OLN Subject: [lmap] draft-boucadair-lmap-considerations 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, 18 Feb 2013 13:09:28 -0000 Dear all, We submitted this new I-D. Comments are welcome. Cheers, Med -----Message d'origine----- De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Envoy=E9 : lundi 18 f=E9vrier 2013 14:05 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : JACQUENET Christian OLNC/OLN Objet : New Version Notification for draft-boucadair-lmap-considerations-00= .txt A new version of I-D, draft-boucadair-lmap-considerations-00.txt has been successfully submitted by Mohamed Boucadair and posted to the IETF repository. Filename: draft-boucadair-lmap-considerations Revision: 00 Title: Large scale Measurement of Access network Performance (LMAP): Requ= irements and Issues from a Network Provider Perspective Creation date: 2013-02-18 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-boucadair-lmap-c= onsiderations-00.txt Status: http://datatracker.ietf.org/doc/draft-boucadair-lmap-consi= derations Htmlized: http://tools.ietf.org/html/draft-boucadair-lmap-considerat= ions-00 Abstract: This document raises several points related to the ongoing LMAP (Large scale Measurement of Access network Performance) effort. The goal is to contribute to define a scope for LMAP and its expected contribution. = =20 The IETF Secretariat From bs7652@att.com Mon Feb 18 13:36: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 11B3021F8C68 for ; Mon, 18 Feb 2013 13:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 7+s+uiQCpEED for ; Mon, 18 Feb 2013 13:36:14 -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 3999C21F8BF2 for ; Mon, 18 Feb 2013 13:36:14 -0800 (PST) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id dce92215.0.1183641.00-462.3275585.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 18 Feb 2013 21:36:14 +0000 (UTC) X-MXL-Hash: 51229ece316fed4d-fe791fa251c5134a100d2a56d665631587cbf0bb 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 r1ILaBK4016359; Mon, 18 Feb 2013 16:36:13 -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 r1ILa3fm016151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2013 16:36:05 -0500 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by sflint04.pst.cso.att.com (RSA Interceptor); Mon, 18 Feb 2013 16:35:07 -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.0328.009; Mon, 18 Feb 2013 16:35:07 -0500 From: "STARK, BARBARA H" To: "mohamed.boucadair@orange.com" , "lmap@ietf.org" Thread-Topic: draft-boucadair-lmap-considerations Thread-Index: Ac4N2J+mH3nC807/SKeiO3Ebgvm8+QAAEZLAAA4hYhA= Date: Mon, 18 Feb 2013 21:35:06 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113024E931@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <94C682931C08B048B7A8645303FDC9F36EB1A52CB0@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB1A52CB0@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.58.16] 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=Ob0v+GvY c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=wftcnzok5uwA:10 a=Roqpss4dzdYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=09t_GYf-Q9EA:10 a=48vgC7mUAAAA:8 a=EkJluKtiG5tDS8] X-AnalysisOut: [bGGxMA:9 a=CjuIK1q_8ugA:10] Cc: JACQUENET Christian OLNC/OLN Subject: Re: [lmap] draft-boucadair-lmap-considerations 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, 18 Feb 2013 21:36:15 -0000 > Filename: draft-boucadair-lmap-considerations > Title: Large scale Measurement of Access network Performance > (LMAP): Requirements and Issues from a Network Provider Perspective > URL: http://www.ietf.org/internet-drafts/draft-boucadair-lmap= -considerations-00.txt > Abstract: > This document raises several points related to the ongoing LMAP > (Large scale Measurement of Access network Performance) effort. The > goal is to contribute to define a scope for LMAP and its expected > contribution. Thanks. I think this is good as a foundation for some much needed discussio= n. I have some questions around what this draft's intended focus/scope is, = that may help clarify some of the questions raised in the draft. The document's title states that it is intended to provide the Network Prov= ider's perspective. Does that mean that the intention is to provide the req= uirements that a Network Provider has for the systems, network elements, de= vices, and applications that are managed/controlled by the Network Provider= ? And are these all of the requirements that a Network Provider might have = (in the global LMAP context), or just the ones that a Network Provider want= s the IETF to help with? If it is not intended to restrict itself to a Network Provider's requiremen= ts for their own boxes and applications, then I would recommend splitting o= ut the requirements that a Network Provider has for their own things, and a= ny other requirements that the draft may include. I would also recommend ch= aracterizing the other requirements. Are they requirements of others on Net= work Providers? Are they requirements of a Network Provider (a subset of "o= thers" from the previous question) on other Network Providers? Or are they = requirements of a Network Provider on others (End Users, etc.)? Personally,= I would prefer not to include any of these sorts of requirements in this d= raft (I think they should be in a different draft that does not claim to ex= press the Network Provider's perspective). But if they are included, they s= hould be clearly delineated -- it's important to distinguish between requir= ements one entity is attempting to impose on another, vs. requirements that= an entity is imposing on themselves. I would also recommend restricting the scope of the draft to requirements t= hat Network Providers want the IETF to help with. The draft discusses "domain". I would suggest distinguishing between "netwo= rk domain" and "management domain". For example, the Customer Premises Netw= ork (CPN) is a distinct network domain. The Network Provider whose perspect= ive this is, may have managed devices or applications residing in the CPN, = or in the network of some server hosting provider. As an employee of a "Net= work Provider", I would definitely express interest in seeing the framework= consider inter-"network domain" measurement. Inter-"management domain" is = a different story. In the context of what I said above, I think that inter-= "management domain" only needs to be included in this draft if there is a N= etwork Provider who is actively asking the IETF for help with that, in the = context of providing interfaces to their own boxes and applications. [Note = that if there is no Network Provider asking for such help, this does not ne= cessarily mean that Network Providers are uninterested in such a capability= -- merely that they are not asking the IETF to help solve it.] Barbara From ken.ko@adtran.com Mon Feb 18 17:32:35 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 713BC21E8051 for ; Mon, 18 Feb 2013 17:32:35 -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=[AWL=0.000, 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 ZuvOxTRTmp3c for ; Mon, 18 Feb 2013 17:32:34 -0800 (PST) Received: from p02c12o148.mxlogic.net (p02c12o148.mxlogic.net [208.65.145.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7830D21E8044 for ; Mon, 18 Feb 2013 17:32:34 -0800 (PST) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o148.mxlogic.net(mxl_mta-7.0.0-0) over TLS secured channel with ESMTP id 136d2215.0.96553.00-257.214044.p02c12o148.mxlogic.net (envelope-from ); Mon, 18 Feb 2013 18:32:34 -0700 (MST) X-MXL-Hash: 5122d63237a38ca2-141003d136a365dfa13577a9497bc3436370df39 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%14]) with mapi id 14.01.0438.000; Mon, 18 Feb 2013 19:32:33 -0600 From: KEN KO To: "lmap@ietf.org" Thread-Topic: New Version Notification for draft-ko-ippm-streaming-performance-00.txt Thread-Index: Ac4OQMS3FC9HA0KDQhS43wqPoWr0UQ== Date: Tue, 19 Feb 2013 01:32:32 +0000 Message-ID: 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=E/l6U9hl c=1 sm=1 a=0XgpNN2/4a34ymu16SVwsQ==:17 a] X-AnalysisOut: [=aQomRHkrLCgA:10 a=0sAT2sIeamgA:10 a=qZHQZMT3apYA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=O4Ev-HXITIQA:10 a=48vgC7mUAAAA:8 a=uxsNnmEpOFoZZ] X-AnalysisOut: [X7s_jYA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=7OeGc_qWhM] X-AnalysisOut: [vJcE1-:21 a=N854cPHJ9X9sZLTb:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Subject: [lmap] FW: New Version Notification for draft-ko-ippm-streaming-performance-00.txt 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, 19 Feb 2013 01:32:35 -0000 TE1BUCwNCg0KSGVyZSBpcyBhIG5ldyBJLUQgcmVsYXRpbmcgdG8gdGVzdGluZyBmb3Igc3RyZWFt aW5nIHBlcmZvcm1hbmNlIGp1c3Qgc3VibWl0dGVkIHRvIGlwcG0gdGhhdCBzaG91bGQgYmUgYXBw bGljYWJsZSB0byBsYXJnZSBzY2FsZSB0ZXN0aW5nLiBJbnN0ZWFkIG9mIHNlbmRpbmcgYSBzdHJl YW0gdG8gZGlyZWN0bHkgdGVzdCBvbmUgY29uZGl0aW9uLCBpdCBhcHBsaWVzIGEgc3RyZWFtaW5n IG1vZGVsIHRvIG1ldHJpY3MgZnJvbSBUQ1AgdGhyb3VnaHB1dCB0ZXN0aW5nIHRvIGVzdGltYXRl IHBlcmZvcm1hbmNlIGZvciBhbnkgbnVtYmVyIG9mIGNvbmRpdGlvbnMuIA0KDQpDb21tZW50cyBh cmUgd2VsY29tZSBvdmVyIG9uIHRoZSBpcHBtIHRocmVhZC4NCg0KUmVnYXJkcywNCktlbiBLbw0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgRmVi cnVhcnkgMTgsIDIwMTMgMTo1MCBQTQ0KVG86IEtFTiBLTw0KU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1rby1pcHBtLXN0cmVhbWluZy1wZXJmb3JtYW5jZS0wMC50 eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQta28taXBwbS1zdHJlYW1pbmctcGVy Zm9ybWFuY2UtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEtlbiBL byBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQt a28taXBwbS1zdHJlYW1pbmctcGVyZm9ybWFuY2UNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIE1v ZGVsLUJhc2VkIEVzdGltYXRpb24gb2YgU3RyZWFtaW5nIFBlcmZvcm1hbmNlDQpDcmVhdGlvbiBk YXRlOgkgMjAxMy0wMi0xOA0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIg b2YgcGFnZXM6IDE4DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWtvLWlwcG0tc3RyZWFtaW5nLXBlcmZvcm1hbmNlLTAwLnR4dA0KU3Rh dHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtvLWlw cG0tc3RyZWFtaW5nLXBlcmZvcm1hbmNlDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWtvLWlwcG0tc3RyZWFtaW5nLXBlcmZvcm1hbmNlLTAwDQoNCg0K QWJzdHJhY3Q6DQogICBUaGlzIG1lbW8gZGVmaW5lcyBtZXRyaWNzIHBsdXMgYSBtZXRob2RvbG9n eSBmb3IgcG9zdC1tZWFzdXJlbWVudA0KICAgcHJvY2Vzc2luZyBvZiBzYW1wbGUgbWV0cmljcyB0 byBldmFsdWF0ZSBuZXR3b3JrIHBhdGggcGVyZm9ybWFuY2UNCiAgIHJlbGF0aXZlIHRvIHN0cmVh bWluZyB2aWRlbyB0cmFmZmljLiBUaGUgbWV0cmljcyBhcmUgYmFzZWQgb24NCiAgIGVzdGFibGlz aGVkIG1ldGhvZG9sb2dpZXMgZm9yIFRDUCB0aHJvdWdocHV0IHRlc3RpbmcuIFRoZSBwb3N0LQ0K ICAgcHJvY2Vzc2luZyBtZXRob2RvbG9neSBpcyBiYXNlZCBvbiBhIG1vZGVsIG9mIHN0cmVhbWlu ZyB0cmFmZmljIHRoYXQNCiAgIGFsbG93cyBhIGdpdmVuIHNhbXBsZSBtZXRyaWMgdG8gYmUgZXZh bHVhdGVkIGFnYWluc3QgbXVsdGlwbGUgc2V0cw0KICAgb2YgcGFyYW1ldGVycyByZXByZXNlbnRp bmcgZGlmZmVyZW50IHN0cmVhbWluZyByYXRlcywgZGVsYXlzIGFuZA0KICAgYnVmZmVyaW5nIHZh bHVlcy4gVGhlIHJlc3VsdHMgb2YgdGhlIHBvc3QtcHJvY2Vzc2luZyBtZXRob2RvbG9neSBhcmUN CiAgIGRlcml2ZWQgbWV0cmljcyB0aGF0IGFyZSBzdWl0YWJsZSBmb3Igc3RhdGlzdGljYWwgYW5h bHlzaXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQo= From mohamed.boucadair@orange.com Mon Feb 18 22:35:22 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 5E64221F8D02 for ; Mon, 18 Feb 2013 22:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 JcRqwMKg2qAg for ; Mon, 18 Feb 2013 22:35:21 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 53C8D21F8CAB for ; Mon, 18 Feb 2013 22:35:21 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id F2E3E3B47DD; Tue, 19 Feb 2013 07:35:19 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D941527C053; Tue, 19 Feb 2013 07:35:19 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 19 Feb 2013 07:35:15 +0100 From: To: "STARK, BARBARA H" , "lmap@ietf.org" Date: Tue, 19 Feb 2013 07:35:14 +0100 Thread-Topic: draft-boucadair-lmap-considerations Thread-Index: Ac4N2J+mH3nC807/SKeiO3Ebgvm8+QAAEZLAAA4hYhAAFe0EUA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EB29BAA27@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB1A52CB0@PUEXCB1B.nanterre.francetelecom.fr> <2D09D61DDFA73D4C884805CC7865E6113024E931@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113024E931@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.19.60319 Cc: JACQUENET Christian OLNC/OLN Subject: Re: [lmap] draft-boucadair-lmap-considerations 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, 19 Feb 2013 06:35:22 -0000 Dear Barbara, Thank you for reading and providing comments.=20 The initial goal of the draft is to focus on the requirements from a networ= k provider for LMAP system.=20 I agree with your comment regarding the "domain" notion. This will be clari= fied in the next version of the draft.=20 BTW, we will be more than happy to welcome contributions from other network= providers. Cheers, Med=20 >-----Message d'origine----- >De : STARK, BARBARA H [mailto:bs7652@att.com]=20 >Envoy=E9 : lundi 18 f=E9vrier 2013 22:35 >=C0 : BOUCADAIR Mohamed OLNC/OLN; lmap@ietf.org >Cc : JACQUENET Christian OLNC/OLN >Objet : RE: draft-boucadair-lmap-considerations > >> Filename: draft-boucadair-lmap-considerations >> Title: Large scale Measurement of Access=20 >network Performance >> (LMAP): Requirements and Issues from a Network Provider Perspective >> URL: =20 >http://www.ietf.org/internet-drafts/draft-boucadair-lmap-consid erations-00.txt >> Abstract: >> This document raises several points related to the ongoing LMAP >> (Large scale Measurement of Access network Performance)=20 >effort. The >> goal is to contribute to define a scope for LMAP and its expected >> contribution. > >Thanks. I think this is good as a foundation for some much=20 >needed discussion. I have some questions around what this=20 >draft's intended focus/scope is, that may help clarify some of=20 >the questions raised in the draft. > >The document's title states that it is intended to provide the=20 >Network Provider's perspective. Does that mean that the=20 >intention is to provide the requirements that a Network=20 >Provider has for the systems, network elements, devices, and=20 >applications that are managed/controlled by the Network=20 >Provider? And are these all of the requirements that a Network=20 >Provider might have (in the global LMAP context), or just the=20 >ones that a Network Provider wants the IETF to help with? > >If it is not intended to restrict itself to a Network=20 >Provider's requirements for their own boxes and applications,=20 >then I would recommend splitting out the requirements that a=20 >Network Provider has for their own things, and any other=20 >requirements that the draft may include. I would also=20 >recommend characterizing the other requirements. Are they=20 >requirements of others on Network Providers? Are they=20 >requirements of a Network Provider (a subset of "others" from=20 >the previous question) on other Network Providers? Or are they=20 >requirements of a Network Provider on others (End Users,=20 >etc.)? Personally, I would prefer not to include any of these=20 >sorts of requirements in this draft (I think they should be in=20 >a different draft that does not claim to express the Network=20 >Provider's perspective). But if they are included, they should=20 >be clearly delineated -- it's important to distinguish between=20 >requirements one entity is attempting to impose on another,=20 >vs. requirements that an entity is imposing on themselves. > >I would also recommend restricting the scope of the draft to=20 >requirements that Network Providers want the IETF to help with. > >The draft discusses "domain". I would suggest distinguishing=20 >between "network domain" and "management domain". For example,=20 >the Customer Premises Network (CPN) is a distinct network=20 >domain. The Network Provider whose perspective this is, may=20 >have managed devices or applications residing in the CPN, or=20 >in the network of some server hosting provider. As an employee=20 >of a "Network Provider", I would definitely express interest=20 >in seeing the framework consider inter-"network domain"=20 >measurement. Inter-"management domain" is a different story.=20 >In the context of what I said above, I think that=20 >inter-"management domain" only needs to be included in this=20 >draft if there is a Network Provider who is actively asking=20 >the IETF for help with that, in the context of providing=20 >interfaces to their own boxes and applications. [Note that if=20 >there is no Network Provider asking for such help, this does=20 >not necessarily mean that Network Providers are uninterested=20 >in such a capability -- merely that they are not asking the=20 >IETF to help solve it.] >Barbara >= From philip.eardley@bt.com Tue Feb 19 00:39: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 5019D21F8830 for ; Tue, 19 Feb 2013 00:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.053 X-Spam-Level: X-Spam-Status: No, score=-103.053 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, J_CHICKENPOX_72=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 tHgMZ0+oWTsZ for ; Tue, 19 Feb 2013 00:39:14 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7C55021F87EE for ; Tue, 19 Feb 2013 00:39:14 -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; Tue, 19 Feb 2013 08:39:13 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.59]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Tue, 19 Feb 2013 08:39:12 +0000 From: To: Date: Tue, 19 Feb 2013 08:39:11 +0000 Thread-Topic: New Version Notification for draft-eardley-lmap-framework-00.txt Thread-Index: Ac4OFgmN0EV6oQM1QK+54tGbch1jqQAZPDzQ Message-ID: <9510D26531EF184D9017DF24659BB87F342EB3F137@EMV65-UKRD.domain1.systemhost.net> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [lmap] FW: New Version Notification for draft-eardley-lmap-framework-00.txt 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, 19 Feb 2013 08:39:15 -0000 V2UgdHJpZWQgdG8gc3VtbWFyaXNlIHRoZSBkaXNjdXNzaW9uIHRoYXQgbGVkIHRvIHRoZSBCb0Yg LSB3aXRoIHRoZSBpbnRlbnRpb24gb2YgaW1wcm92aW5nIHRoZSBCb0YuDQoNCkNvbW1lbnRzIGFw cHJlY2lhdGVkIC0gd2lsbCB0cnkgYW5kIGNhcHR1cmUgdGhlbSBpbiBhIC0wMSB2ZXJzaW9uLg0K DQp0aGFua3MsDQpiZXN0IHdpc2hlcywNClBoaWxpcCBFYXJkbGV5Lg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogMTggRmVicnVhcnkgMjAxMyAyMDoyNQ0K VG86IEVhcmRsZXksUEwsUGhpbGlwLFRVQjggUg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1lYXJkbGV5LWxtYXAtZnJhbWV3b3JrLTAwLnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1lYXJkbGV5LWxtYXAtZnJhbWV3b3JrLTAwLnR4dA0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQaGlsaXAgRWFyZGxleSBhbmQgcG9zdGVk IHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWVhcmRsZXktbG1h cC1mcmFtZXdvcmsNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIEEgZnJhbWV3b3JrIGZvciBsYXJn ZS1zY2FsZSBtZWFzdXJlbWVudHMNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTAyLTE4DQpHcm91cDoJ CSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTINClVSTDogICAgICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZWFyZGxleS1s bWFwLWZyYW1ld29yay0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1lYXJkbGV5LWxtYXAtZnJhbWV3b3JrDQpIdG1saXplZDogICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWVhcmRsZXktbG1hcC1mcmFtZXdv cmstMDANCgkNCg0KQWJzdHJhY3Q6DQogICBNZWFzdXJpbmcgYnJvYWRiYW5kIHNlcnZpY2Ugb24g YSBsYXJnZSBzY2FsZSByZXF1aXJlcyBzdGFuZGFyZGlzYXRpb24NCiAgIG9mIHRoZSBsb2dpY2Fs IGFyY2hpdGVjdHVyZSBhbmQgYSBkZXNjcmlwdGlvbiBvZiB0aGUga2V5IHByb3RvY29scw0KICAg dGhhdCBjb29yZGluYXRlIGludGVyYWN0aW9ucyBiZXR3ZWVuIHRoZSBjb21wb25lbnRzLiAgVGhl IGRvY3VtZW50DQogICBwcmVzZW50cyBhbiBvdmVyYWxsIGZyYW1ld29yayBmb3IgbGFyZ2Utc2Nh bGUgbWVhc3VyZW1lbnRzLCBhbmQNCiAgIGRpc2N1c3NlcyB3aGljaCBlbGVtZW50cyBjb3VsZCBi ZSBzdGFuZGFyZGlzZWQgaW4gdGhlIElFVEYuICBJdCBpcw0KICAgaW50ZW5kZWQgdG8gYXNzaXN0 IHRoZSBkaXNjdXNzaW9ucyBhYm91dCB0aGUgcG90ZW50aWFsIGNyZWF0aW9uIG9mDQogICB0aGUg TE1BUCB3b3JraW5nIGdyb3VwLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0K From Jan.Seedorf@neclab.eu Tue Feb 19 02:29: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 3DFC321F87AF for ; Tue, 19 Feb 2013 02:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 PF4aGcLHKOyH for ; Tue, 19 Feb 2013 02:29:01 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7022021F8D45 for ; Tue, 19 Feb 2013 02:28:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D5D1C1032CC; Tue, 19 Feb 2013 11:28:57 +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 t3R8qhZcTfZA; Tue, 19 Feb 2013 11:28:57 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id B68221032CB; Tue, 19 Feb 2013 11:28:42 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 19 Feb 2013 11:28:42 +0100 From: Jan Seedorf To: "lmap@ietf.org" Thread-Topic: New Draft "ALTO for LMAP" Thread-Index: Ac4Oi6mcJ/Qe+4WcQQ6yrXjfzkiEXA== Date: Tue, 19 Feb 2013 10:28:29 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE5544C879@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Enrico Marocco , "Vijay K. Gurbani \(vkg@bell-labs.com\)" Subject: [lmap] New Draft "ALTO for 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: Tue, 19 Feb 2013 10:29:02 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgZHJhZnQgdGhhdCBvdXRsaW5lcyBob3cg QUxUTyBjb3VsZCBiZSB1c2VkIHRvIGV4cG9ydC9leHBsb2l0IExNQVAgbWVhc3VyZW1lbnQgcmVz dWx0cy4gQ29tbWVudHMgYXJlIHZlcnkgd2VsY29tZS4NCg0KSWYgcG9zc2libGUsIHdlIHdvdWxk IGJlIGhhcHB5IHRvIGJyaWVmbHkgZXhwbGFpbiBvdXIgaWRlYXMgYXQgdGhlIEJPRiBpbiBPcmxh bmRvLg0KDQogLSBKYW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE4LCAyMDEzIDM6NTUgUE0NClRvOiBlbnJpY28ubWFyb2Nj b0B0ZWxlY29taXRhbGlhLml0DQpDYzogdmtnQGJlbGwtbGFicy5jb207IEphbiBTZWVkb3JmDQpT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNlZWRvcmYtbG1hcC1h bHRvLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zZWVkb3JmLWxtYXAt YWx0by0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRW5yaWNvIE1h cm9jY28gYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBk cmFmdC1zZWVkb3JmLWxtYXAtYWx0bw0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgQUxUTyBmb3Ig TE1BUA0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDItMTgNCkdyb3VwOgkJIEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMg0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zZWVkb3JmLWxtYXAtYWx0by0wMC50eHQN ClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1z ZWVkb3JmLWxtYXAtYWx0bw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1zZWVkb3JmLWxtYXAtYWx0by0wMA0KDQoNCkFic3RyYWN0Og0KICAgSW4gdGhl IGNvbnRleHQgb2YgTGFyZ2UtU2NhbGUgTWVhc3VyZW1lbnQgb2YgQnJvYWRiYW5kIFBlcmZvcm1h bmNlDQogICAoTE1BUCksIG1lYXN1cm1lbnQgcmVzdWx0cyBhcmUgY3VycmVudGx5IG1hZGUgYXZh aWxhYmxlIHRvIHRoZSBwdWJsaWMNCiAgIGVpdGhlciBhdCB0aGUgZmluZXN0IGdyYW51bGFyaXR5 IGxldmVsIChlLmcuIGFzIGEgbGlzdCBvZiByZXN1bHRzIG9mDQogICBhbGwgaW5kaXZpZHVhbCB0 ZXN0cyksIG9yIGluIGEgdmVyeSBoaWdoIGxldmVsIGh1bWFuLXJlYWRhYmxlIGZvcm1hdA0KICAg KGUuZy4gYXMgUERGIHJlcG9ydHMpLg0KDQogICBUaGlzIGRvY3VtZW50IGFyZ3VlcyB0aGF0IHRo ZXJlIGlzIGEgbmVlZCBmb3IgYW4gaW50ZXJtZWRpYXRlIHdheSB0bw0KICAgcHJvdmlkZSBhY2Nl c3MgdG8gbGFyZ2Utc2NhbGUgbmV0d29yayBtZWFzdXJlbWVudCByZXN1bHRzLCBmbGV4aWJsZQ0K ICAgZW5vdWdoIHRvIGVuYWJsZSBxdWVyeWluZyBvZiBzcGVjaWZpYyBhbmQgcG9zc2libHkgYWdn cmVnYXRlZCBkYXRhLg0KICAgVGhlIEFwcGxpY2F0aW9uLUxheWVyIFRyYWZmaWMgT3B0aW1pemF0 aW9uIChBTFRPKSBQcm90b2NvbCwgZGVmaW5lZA0KICAgd2l0aCB0aGUgZ29hbCB0byBwcm92aWRl IGFwcGxpY2F0aW9ucyB3aXRoIG5ldHdvcmsgaW5mb3JtYXRpb24sIHNlZW1zDQogICBhIGdvb2Qg Y2FuZGlkYXRlIHRvIGZ1bGZpbGwgc3VjaCBhIHJvbGUuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From acmorton@att.com Tue Feb 19 11:04: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 C04E021F8E66 for ; Tue, 19 Feb 2013 11:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.437 X-Spam-Level: X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 0dfM49x8X4uj for ; Tue, 19 Feb 2013 11:04:49 -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 358A41F0C4E for ; Tue, 19 Feb 2013 11:04:48 -0800 (PST) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 173D7120C2F; Tue, 19 Feb 2013 14:07:00 -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 CC382E36DA; Tue, 19 Feb 2013 13:58:23 -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; Tue, 19 Feb 2013 14:04:45 -0500 From: "MORTON JR., ALFRED (AL)" To: Benoit Claise , "lmap@ietf.org" Date: Tue, 19 Feb 2013 14:04:44 -0500 Thread-Topic: Draft Agenda [was: LMAP BoF has been approved.] Thread-Index: Ac4O0/pYJRW4w7TWRXiKv33bF479JQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F1312FAF1A1E624DA0972D1C9A91379A1BF83B0435njfpsrvexg7re_" MIME-Version: 1.0 Subject: [lmap] Draft Agenda [was: LMAP BoF has been approved.] 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, 19 Feb 2013 19:04:51 -0000 --_000_F1312FAF1A1E624DA0972D1C9A91379A1BF83B0435njfpsrvexg7re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TE1BUCBsaXN0LA0KDQpXZSBoYXZlIHByZXBhcmVkIGEgZHJhZnQgQm9GIGFnZW5kYSwNCmFuZCBu b3cgdGhhdCBvdXIgcG9zdGluZyByaWdodHMgYXJlIGluc3RhbGxlZCwNCml0IGNhbiBiZSBmb3Vu ZCB3aXRoIGFsbCBtZWV0aW5nIG1hdGVyaWFsczoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvODYvYWdlbmRhL2FnZW5kYS04Ni1sbWFwDQoNCldlIGJlbGlldmUgd2UgaGF2ZSBlbWJy YWNlZCB0aGUgdHN1bmFtaSBvZiAwMCBkcmFmdHMNCmFuZCBmb3VuZCBhbGwgdGhvc2UgdGhhdCBh cmUgcmVsZXZhbnQsDQphbmQgY29udGFjdGVkIGFsbC0xIG9mIHRoZSBwcmVzZW50ZXJzLg0KDQpD b21tZW50cyB0byB0aGUgbGlzdCwgcGxlYXNlLA0KRGFuIGFuZCBBbA0KYm9mIGNvLWNoYWlycw0K DQpGcm9tOiBsbWFwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBCZW5vaXQgQ2xhaXNlDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDA2LCAyMDEzIDEwOjAwIEFNDQpUbzogbG1hcEBpZXRmLm9yZw0KU3ViamVjdDogW2xtYXBdIExN QVAgQm9GIGhhcyBiZWVuIGFwcHJvdmVkLg0KDQpEZWFyIGFsbCwNCg0KTGV0IHVzIHNoYXJlIHRo ZSBnb29kIG5ld3MuIFRoZSBJRVNHIGFwcHJvdmVkIHRoaXMgQm9GLg0KRXZlbiBpZiBpdCB3YXMg aW5pdGlhbGx5IHJlcXVlc3RlZCBpbiBUU1YsIHRoZSBCb0Ygd2lsbCBiZSBzcG9uc29yZWQgaW4g T1BTIGJ5IEJlbm9pdCBDbGFpc2UuDQpUaGUgQm9GIGluZm9ybWF0aW9uIGhhdmUgYmVlbiB1cGRh dGVkIChTZWUgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9mL3RyYWMvd2lraS9XaWtpU3Rh cnQpDQoNCkxhcmdlLVNjYWxlIE1lYXN1cmVtZW50IG9mIEJyb2FkYmFuZCBQZXJmb3JtYW5jZSAo TE1BUCkNCg0KICogICBTdGF0dXM6IFJlcXVlc3RlZC4NCiAqICAgVHlwZTogV0cgZm9ybWluZyAo MXN0IGF0dGVtcHQpLg0KICogICBSZXNwb25zaWJsZSBBRDogQmVub2l0IENsYWlzZSwgT1BTDQog KiAgIEJPRiBDaGFpcnM6IERhbiBSb21hc2NhbnUgKOKAi2Ryb21hc2NhQGF2YXlhLmNvbTxtYWls dG86ZHJvbWFzY2FAYXZheWEuY29tPiksIEFsIE1vcnRvbiAo4oCLYWNtb3J0b25AYXR0LmNvbTxt YWlsdG86YWNtb3J0b25AYXR0LmNvbT4pKQ0KICogICBBdHRlbmRhbmNlOiA4MA0KICogICBTZXNz aW9uIGxlbmd0aCAxMjAgbWludXRlcw0KICogICBDb25mbGljdHMgdG8gYXZvaWQ6DQpGaXJzdCBs ZXZlbCBwcmlvcml0eTogSVBQTSwgRUNSSVQsIEJNV0csIE9QU0FSRUEvT1BTQVdHLCBJUEZJWCwg RU1BTiwgTkVUQ09ORiwgTkVUTU9ELCBYUkJMT0NLLCBESU1FLCBSQURFWFQsIFNBQ00gQm9GLCBU U1ZBUkVBLCBBTFRPLCBDRE5JLCBORlNWNCwgUFBTUCwgVFNWV0cNClNlY29uZCBsZXZlbCBwcmlv cml0eTogQ09ORVgNCiAqICAgRG9lcyBpdCByZXF1aXJlIFdlYkVYPyBObw0KICogICBEb2VzIGl0 IHJlcXVpcmUgTWVldGVjaG8/IE5vDQogKiAgIE1haWxpbmcgbGlzdDog4oCLIOKAi2xtYXBAaWVm dC5vcmc8bWFpbHRvOmxtYXBAaWVmdC5vcmc+DQogKiAgIExpc3QgYXJjaGl2ZTog4oCL4oCLaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2xtYXAvY3VycmVudC9tYWlsbGlzdC5o dG1sPGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sbWFwL2N1cnJlbnQvbWFp bGxpc3QuaHRtbD4NCiAqICAgRG9jdW1lbnRzOiBkcmFmdC1zY2h1bHpyaW5uZS1sbWFwLXJlcXVp cmVtZW50czxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2h1bHpyaW5uZS1sbWFw LXJlcXVpcmVtZW50cz4sIGRyYWZ0LWxpbnNuZXItbG1hcC11c2UtY2FzZXM8aHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtbGluc25lci1sbWFwLXVzZS1jYXNlcz4sIGFuZCBkcmFmdC1t b3J0b24taXBwbS1sbWFwLXBhdGgtMDA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bW9ydG9uLWlwcG0tbG1hcC1wYXRoLTAwPg0KVGhlIGNoYWlycyBoYXZlIGJlZW4gY2hvc2VuIGJh c2VkIG9uIHRoZWlyIGxldmVscyBvZiBleHBlcnRpc2UvZXhwZXJpZW5jZSBpbiBPUFMsIG1lYXN1 cmVtZW50LCBhbmQgSUVURi4gVGhhbmtzIERhbiBhbmQgQWwgZm9yIGFjY2VwdGluZyB0aGUgY2hh aXIgcG9zaXRpb25zLg0KDQpHb2FscyBmb3IgdGhpcyBCb0Y6DQotIGJlIGluIHN5bmNoIG9uIHRo ZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgdXNlIGNhc2VzDQotIHVuZGVyc3RhbmQgd2hhdCB0aGUg ZXhpc3RpbmcgSUVURiBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIChJUFBNLCBORVRDT05GL1lB TkcsIElQRklYLCBldGMuLi4pIGNhbiBvciBjYW4ndCBkbyBmb3IgTE1BUC4gVGhpcyB3aWxsIGNl cnRhaW5seSByZXF1aXJlIGEgbGl0dGxlIG9mIGVkdWNhdGlvbiBkaXJlY3RseSBmcm9tIHRoZSBl eHBlcnRzIGR1cmluZyB0aGUgQm9GLg0KLSBjbGFyaWZ5IHdoYXQncyBpbiBzY29wZSBvciBub3Qg Zm9yIExNQVANCg0KRmluYWxseSwgbGV0IG1lIHN0cmVzcyB0aGF0IGEgcHJvcGVyIHByZXBhcmF0 aW9uIGlzIGtleSB0byBhIEJvRiBzdWNjZXNzLg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNTQzNCAgIkNvbnNpZGVyYXRpb25zIGZvciBIYXZpbmcgYSBTdWNjZXNzZnVsIEJpcmRzLW9m LWEtRmVhdGhlciAoQk9GKSBTZXNzaW9uIiBpcyBhIGZpcnN0IGdvb2Qgc3RlcC4NCg0KUmVnYXJk cywgTWFydGluIFN0aWVtZXJsaW5nIChUU1YpIGFuZCBCZW5vaXQgQ2xhaXNlIChPUFMpDQoNCg== --_000_F1312FAF1A1E624DA0972D1C9A91379A1BF83B0435njfpsrvexg7re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLmljb24NCgl7bXNvLXN0 eWxlLW5hbWU6aWNvbjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6NTgzNDU5OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQwODM2ODk2Njt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBiZ2NvbG9yPXdoaXRlIGxhbmc9RU4tVVMg bGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5MTUFQIGxpc3QsPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5XZSBoYXZlIHByZXBh cmVkIGEgZHJhZnQgQm9GIGFnZW5kYSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7Y29sb3I6d2luZG93dGV4dCc+YW5kIG5vdyB0aGF0IG91ciBwb3N0aW5nIHJpZ2h0cyBh cmUgaW5zdGFsbGVkLCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29s b3I6d2luZG93dGV4dCc+aXQgY2FuIGJlIGZvdW5kIHdpdGggYWxsIG1lZXRpbmcgbWF0ZXJpYWxz OiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4 dCc+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Ni9hZ2VuZGEvYWdl bmRhLTg2LWxtYXAiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODYvYWdlbmRhL2Fn ZW5kYS04Ni1sbWFwPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtj b2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7Y29sb3I6d2luZG93dGV4dCc+V2UgYmVsaWV2ZSB3ZSBoYXZlIGVtYnJhY2VkIHRoZSB0 c3VuYW1pIG9mIDAwIGRyYWZ0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5hbmQgZm91bmQgYWxsIHRob3NlIHRoYXQgYXJlIHJlbGV2YW50 LCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4 dCc+YW5kIGNvbnRhY3RlZCBhbGwtMSBvZiB0aGUgcHJlc2VudGVycy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPkNvbW1lbnRz IHRvIHRoZSBsaXN0LCBwbGVhc2UsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciO2NvbG9yOndpbmRvd3RleHQnPkRhbiBhbmQgQWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+Ym9mIGNvLWNoYWlyczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3Rl eHQnPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+IGxtYXAtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9m IDwvYj5CZW5vaXQgQ2xhaXNlPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA2 LCAyMDEzIDEwOjAwIEFNPGJyPjxiPlRvOjwvYj4gbG1hcEBpZXRmLm9yZzxicj48Yj5TdWJqZWN0 OjwvYj4gW2xtYXBdIExNQVAgQm9GIGhhcyBiZWVuIGFwcHJvdmVkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPkRlYXIgYWxsLDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxicj5MZXQgdXMgc2hhcmUgdGhlIGdvb2QgbmV3cy4gVGhlIElFU0cgYXBwcm92 ZWQgdGhpcyBCb0YuPGJyPkV2ZW4gaWYgaXQgd2FzIGluaXRpYWxseSByZXF1ZXN0ZWQgaW4gVFNW LCB0aGUgQm9GIHdpbGwgYmUgc3BvbnNvcmVkIGluIE9QUyBieSBCZW5vaXQgQ2xhaXNlLjxicj5U aGUgQm9GIGluZm9ybWF0aW9uIGhhdmUgYmVlbiB1cGRhdGVkIChTZWUgPGEgaHJlZj0iaHR0cDov L3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9mL3RyYWMvd2lraS9XaWtpU3RhcnQiPmh0dHA6Ly90cmFj LnRvb2xzLmlldGYub3JnL2JvZi90cmFjL3dpa2kvV2lraVN0YXJ0PC9hPik8bzpwPjwvbzpwPjwv cD48cD48c3Ryb25nPkxhcmdlLVNjYWxlIE1lYXN1cmVtZW50IG9mIEJyb2FkYmFuZCBQZXJmb3Jt YW5jZSAoTE1BUCk8L3N0cm9uZz48bzpwPjwvbzpwPjwvcD48dWwgdHlwZT1kaXNjPjxsaSBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xJz5TdGF0dXM6IFJlcXVlc3RlZC4g PG86cD48L286cD48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBs Zm8xJz5UeXBlOiBXRyBmb3JtaW5nICgxc3QgYXR0ZW1wdCkuIDxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+UmVzcG9uc2libGUgQUQ6 IEJlbm9pdCBDbGFpc2UsIE9QUyA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPkJPRiBDaGFpcnM6IERhbiBSb21hc2NhbnUgKDxhIGhy ZWY9Im1haWx0bzpkcm9tYXNjYUBhdmF5YS5jb20iPjxzcGFuIGNsYXNzPWljb24+4oCLPC9zcGFu PmRyb21hc2NhQGF2YXlhLmNvbTwvYT4pLCBBbCBNb3J0b24gKDxhIGhyZWY9Im1haWx0bzphY21v cnRvbkBhdHQuY29tIj48c3BhbiBjbGFzcz1pY29uPuKAizwvc3Bhbj5hY21vcnRvbkBhdHQuY29t PC9hPikpIDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSc+QXR0ZW5kYW5jZTogODAgPG86cD48L286cD48L2xpPjxsaSBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xJz5TZXNzaW9uIGxlbmd0aCAxMjAgbWludXRl cyA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEnPkNvbmZsaWN0cyB0byBhdm9pZDogPGJyPkZpcnN0IGxldmVsIHByaW9yaXR5OiBJUFBN LCBFQ1JJVCwgQk1XRywgT1BTQVJFQS9PUFNBV0csIElQRklYLCBFTUFOLCBORVRDT05GLCBORVRN T0QsIFhSQkxPQ0ssIERJTUUsIFJBREVYVCwgU0FDTSBCb0YsIFRTVkFSRUEsIEFMVE8sIENETkks IE5GU1Y0LCBQUFNQLCBUU1ZXRyA8YnI+U2Vjb25kIGxldmVsIHByaW9yaXR5OiBDT05FWCA8bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEn PkRvZXMgaXQgcmVxdWlyZSBXZWJFWD8gTm8gPG86cD48L286cD48L2xpPjxsaSBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xJz5Eb2VzIGl0IHJlcXVpcmUgTWVldGVjaG8/ IE5vIDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSc+TWFpbGluZyBsaXN0OiDigIsgPGEgaHJlZj0ibWFpbHRvOmxtYXBAaWVmdC5vcmci PjxzcGFuIGNsYXNzPWljb24+4oCLPC9zcGFuPmxtYXBAaWVmdC5vcmc8L2E+IDxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+TGlzdCBh cmNoaXZlOiDigIs8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv bG1hcC9jdXJyZW50L21haWxsaXN0Lmh0bWwiPjxzcGFuIGNsYXNzPWljb24+4oCLPC9zcGFuPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sbWFwL2N1cnJlbnQvbWFpbGxpc3Qu aHRtbDwvYT4gPG86cD48L286cD48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww IGxldmVsMSBsZm8xJz5Eb2N1bWVudHM6IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXNjaHVsenJpbm5lLWxtYXAtcmVxdWlyZW1lbnRzIj5kcmFmdC1zY2h1bHpyaW5u ZS1sbWFwLXJlcXVpcmVtZW50czwvYT4sIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWxpbnNuZXItbG1hcC11c2UtY2FzZXMiPmRyYWZ0LWxpbnNuZXItbG1hcC11c2Ut Y2FzZXM8L2E+LCBhbmQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bW9ydG9uLWlwcG0tbG1hcC1wYXRoLTAwIj5kcmFmdC1tb3J0b24taXBwbS1sbWFwLXBhdGgtMDA8 L2E+IDxvOnA+PC9vOnA+PC9saT48L3VsPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWJvdHRvbToxMi4wcHQnPlRoZSBjaGFpcnMgaGF2ZSBiZWVuIGNob3NlbiBiYXNlZCBvbiB0aGVp ciBsZXZlbHMgb2YgZXhwZXJ0aXNlL2V4cGVyaWVuY2UgaW4gT1BTLCBtZWFzdXJlbWVudCwgYW5k IElFVEYuIFRoYW5rcyBEYW4gYW5kIEFsIGZvciBhY2NlcHRpbmcgdGhlIGNoYWlyIHBvc2l0aW9u cy48YnI+PGJyPkdvYWxzIGZvciB0aGlzIEJvRjo8YnI+LSBiZSBpbiBzeW5jaCBvbiB0aGUgcHJv YmxlbSBzdGF0ZW1lbnQgYW5kIHVzZSBjYXNlczxicj4tIHVuZGVyc3RhbmQgd2hhdCB0aGUgZXhp c3RpbmcgSUVURiBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIChJUFBNLCBORVRDT05GL1lBTkcs IElQRklYLCBldGMuLi4pIGNhbiBvciBjYW4ndCBkbyBmb3IgTE1BUC4gVGhpcyB3aWxsIGNlcnRh aW5seSByZXF1aXJlIGEgbGl0dGxlIG9mIGVkdWNhdGlvbiBkaXJlY3RseSBmcm9tIHRoZSBleHBl cnRzIGR1cmluZyB0aGUgQm9GLjxicj4tIGNsYXJpZnkgd2hhdCdzIGluIHNjb3BlIG9yIG5vdCBm b3IgTE1BUDxicj48YnI+RmluYWxseSwgbGV0IG1lIHN0cmVzcyB0aGF0IGEgcHJvcGVyIHByZXBh cmF0aW9uIGlzIGtleSB0byBhIEJvRiBzdWNjZXNzLiA8YnI+PGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNTQzNCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTQz NDwvYT4mbmJzcDsgJnF1b3Q7Q29uc2lkZXJhdGlvbnMgZm9yIEhhdmluZyBhIFN1Y2Nlc3NmdWwg QmlyZHMtb2YtYS1GZWF0aGVyIChCT0YpIFNlc3Npb24mcXVvdDsgaXMgYSBmaXJzdCBnb29kIHN0 ZXAuPGJyPjxicj5SZWdhcmRzLCBNYXJ0aW4gU3RpZW1lcmxpbmcgKFRTVikgYW5kIEJlbm9pdCBD bGFpc2UgKE9QUyk8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_F1312FAF1A1E624DA0972D1C9A91379A1BF83B0435njfpsrvexg7re_-- From j.schoenwaelder@jacobs-university.de Tue Feb 19 14: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 05B6821F887F for ; Tue, 19 Feb 2013 14:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.182 X-Spam-Level: X-Spam-Status: No, score=-103.182 tagged_above=-999 required=5 tests=[AWL=0.067, 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 d-z5-k4b3xnb for ; Tue, 19 Feb 2013 14:03:09 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 42AA321F886E for ; Tue, 19 Feb 2013 14:03:09 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A08BE20BD8; Tue, 19 Feb 2013 23:03:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ae3D0UD6k-7c; Tue, 19 Feb 2013 23:03:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2DF3820BD5; Tue, 19 Feb 2013 23:03:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BE8D1249E6C8; Tue, 19 Feb 2013 23:03:16 +0100 (CET) Date: Tue, 19 Feb 2013 23:03:16 +0100 From: Juergen Schoenwaelder To: "MORTON JR., ALFRED (AL)" Message-ID: <20130219220316.GB12870@elstar.local> Mail-Followup-To: "MORTON JR., ALFRED (AL)" , Benoit Claise , "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: Benoit Claise , "lmap@ietf.org" Subject: Re: [lmap] Draft Agenda [was: LMAP BoF has been approved.] 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: Tue, 19 Feb 2013 22:03:10 -0000 On Tue, Feb 19, 2013 at 02:04:44PM -0500, MORTON JR., ALFRED (AL) wrote: > > We believe we have embraced the tsunami of 00 drafts > and found all those that are relevant, Al, you may want to add http://www.ietf.org/id/draft-schoenw-lmap-netconf-00.txt to the reading list. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Michael.K.Bugenhagen@centurylink.com Tue Feb 19 14:06:26 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 6107E21F886E for ; Tue, 19 Feb 2013 14:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 PR3YE+haEXDn for ; Tue, 19 Feb 2013 14:06:23 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id BE15B21F8815 for ; Tue, 19 Feb 2013 14:06:22 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r1JM6J8F012362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2013 16:06:19 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 650CE1E004E; Tue, 19 Feb 2013 15:06:14 -0700 (MST) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 4967C1E005E; Tue, 19 Feb 2013 15:06:14 -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 r1JM6Dkc003015; Tue, 19 Feb 2013 15:06:14 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r1JM6D6s002986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 15:06:13 -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; Tue, 19 Feb 2013 16:06:13 -0600 From: "Bugenhagen, Michael K" To: "'Juergen Schoenwaelder'" , "MORTON JR., ALFRED (AL)" Thread-Topic: [lmap] Draft Agenda [was: LMAP BoF has been approved.] Thread-Index: Ac4O0/pYJRW4w7TWRXiKv33bF479JQASztgAAAyHx3A= Date: Tue, 19 Feb 2013 22:06:13 +0000 Message-ID: References: <20130219220316.GB12870@elstar.local> In-Reply-To: <20130219220316.GB12870@elstar.local> 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: Benoit Claise , "lmap@ietf.org" Subject: Re: [lmap] Draft Agenda [was: LMAP BoF has been approved.] 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, 19 Feb 2013 22:06:27 -0000 Al, Claise, Just a FYI..=20 There is a high probability of a Liaison being sent from the BBF to th= e IETF on their work in the area. Up to you if you want to slot out some time to talk about it or not. I'm still putting our other forest fires, and need to review the new draft = yet - my apologies for being behind. Regards, Mike -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Jue= rgen Schoenwaelder Sent: Tuesday, February 19, 2013 4:03 PM To: MORTON JR., ALFRED (AL) Cc: Benoit Claise; lmap@ietf.org Subject: Re: [lmap] Draft Agenda [was: LMAP BoF has been approved.] On Tue, Feb 19, 2013 at 02:04:44PM -0500, MORTON JR., ALFRED (AL) wrote: >=20 > We believe we have embraced the tsunami of 00 drafts and found all=20 > those that are relevant, Al, you may want to add http://www.ietf.org/id/draft-schoenw-lmap-netconf-00.txt to the reading list. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From christian.jacquenet@orange.com Tue Feb 19 00:51: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 AAED021F8801 for ; Tue, 19 Feb 2013 00:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 xGs6QIG9Kn4N for ; Tue, 19 Feb 2013 00:51:36 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3B921F87D1 for ; Tue, 19 Feb 2013 00:51:35 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 0D2192DC0A2; Tue, 19 Feb 2013 09:51:34 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E49A527C046; Tue, 19 Feb 2013 09:51:33 +0100 (CET) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 19 Feb 2013 09:51:32 +0100 From: To: "STARK, BARBARA H" , BOUCADAIR Mohamed OLNC/OLN , "lmap@ietf.org" Date: Tue, 19 Feb 2013 09:51:31 +0100 Thread-Topic: draft-boucadair-lmap-considerations Thread-Index: Ac4N2J+mH3nC807/SKeiO3Ebgvm8+QAAEZLAAA4hYhAAGtHcYA== Message-ID: <12359_1361263893_51233D15_12359_487_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A6F56CB3D@PUEXCB1C.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB1A52CB0@PUEXCB1B.nanterre.francetelecom.fr> <2D09D61DDFA73D4C884805CC7865E6113024E931@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113024E931@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 X-Mailman-Approved-At: Tue, 19 Feb 2013 14:43:30 -0800 Subject: Re: [lmap] draft-boucadair-lmap-considerations 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, 19 Feb 2013 08:51:37 -0000 Barbara, Thanks for your feedback. A couple of comments below in addition to Med's.= =20 [snip] Thanks. I think this is good as a foundation for some much needed discussio= n. I have some questions around what this draft's intended focus/scope is, = that may help clarify some of the questions raised in the draft. The document's title states that it is intended to provide the Network Prov= ider's perspective. Does that mean that the intention is to provide the req= uirements that a Network Provider has for the systems, network elements, de= vices, and applications that are managed/controlled by the Network Provider? CJ: that's the intent indeed. But one of the primary goals is to stimulate = discussions about issues raised LMAP systems from a service provider's pers= pective.=20 And are these all of the requirements that a Network Provider might have (i= n the global LMAP context), or just the ones that a Network Provider wants = the IETF to help with? CJ: first, I don't think we documented a comprehensive list of requirements= . We wanted to make sure the draft meets the cut-off date prior to discussi= ons in Orlando. Second, the draft indeed aims at soliciting the IETF about = these requirements and issues. As such, there may be additional requirement= s that either refer to service provider-specific operational guidelines or = to areas where other SDOs may be solicited. Admittedly, I don't have a clea= r view on the full scope of requirements yet. If it is not intended to restrict itself to a Network Provider's requiremen= ts for their own boxes and applications, then I would recommend splitting o= ut the requirements that a Network Provider has for their own things, and a= ny other requirements that the draft may include. CJ: fair enough.=20=20 I would also recommend characterizing the other requirements. Are they requ= irements of others on Network Providers? Are they requirements of a Network= Provider (a subset of "others" from the previous question) on other Networ= k Providers? CJ: this one suggests inter-domain considerations which I think need to be = tackled indeed.=20 Or are they requirements of a Network Provider on others (End Users, etc.)?= Personally, I would prefer not to include any of these sorts of requiremen= ts in this draft (I think they should be in a different draft that does not= claim to express the Network Provider's perspective). CJ: I agree, for the sake of clarity. =20 But if they are included, they should be clearly delineated -- it's importa= nt to distinguish between requirements one entity is attempting to impose o= n another, vs. requirements that an entity is imposing on themselves. CJ: right. I would also recommend restricting the scope of the draft to requirements t= hat Network Providers want the IETF to help with. CJ: agreed, that's the intent. The draft discusses "domain". I would suggest distinguishing between "netwo= rk domain" and "management domain". For example, the Customer Premises Netw= ork (CPN) is a distinct network domain. The Network Provider whose perspect= ive this is, may have managed devices or applications residing in the CPN, = or in the network of some server hosting provider. As an employee of a "Net= work Provider", I would definitely express interest in seeing the framework= consider inter-"network domain" measurement. CJ: the notion of domain introduced in the draft basically relies upon the = typical BGP domain notion, i.e., a set of network devices operated by a sin= gle administrative entity. Such devices may include CPEs for some providers= .=20=20 Inter-"management domain" is a different story. In the context of what I sa= id above, I think that inter-"management domain" only needs to be included = in this draft if there is a Network Provider who is actively asking the IET= F for help with that, in the context of providing interfaces to their own b= oxes and applications. [Note that if there is no Network Provider asking fo= r such help, this does not necessarily mean that Network Providers are unin= terested in such a capability -- merely that they are not asking the IETF t= o help solve it.] CJ: I think your notion of inter-management domain can be seen as a collate= ral effect of inter-domain considerations, where measurement practices/capa= bilities between domains may need to be exchanged/exposed/negotiated at the= level of a management layer. This is one of the areas we'd like to further= expand in the next versions of the draft.=20 Cheers, Christian. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From acmorton@att.com Tue Feb 19 16:58: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 D039321F86AF for ; Tue, 19 Feb 2013 16:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.454 X-Spam-Level: X-Spam-Status: No, score=-106.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 wEkg+j-V2a9e for ; Tue, 19 Feb 2013 16:58:44 -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 D90C421F85DA for ; Tue, 19 Feb 2013 16:58:43 -0800 (PST) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 49636120C6D; Tue, 19 Feb 2013 20:00:58 -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 DF1D8E36DD; Tue, 19 Feb 2013 19:52:20 -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; Tue, 19 Feb 2013 19:58:43 -0500 From: "MORTON JR., ALFRED (AL)" To: "Bugenhagen, Michael K" , 'Juergen Schoenwaelder' Date: Tue, 19 Feb 2013 19:58:41 -0500 Thread-Topic: [lmap] Draft Agenda [was: LMAP BoF has been approved.] Thread-Index: Ac4O0/pYJRW4w7TWRXiKv33bF479JQASztgAAAyHx3AAEyjWAA== Message-ID: References: <20130219220316.GB12870@elstar.local> 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: Benoit Claise , "lmap@ietf.org" Subject: Re: [lmap] Draft Agenda [was: LMAP BoF has been approved.] 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, 20 Feb 2013 00:58:44 -0000 Mike, thanks for the heads-up on a future liaison. it's probably enough if the link to the statement is posted on the list, so everyone can read it. It would be very unusual to discuss a reply during=20 a BoF, but the results of the BoF and follow-up discussion might be an aspect of a future reply. my 2 cents, Al > -----Original Message----- > From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com] > Sent: Tuesday, February 19, 2013 5:06 PM > To: 'Juergen Schoenwaelder'; MORTON JR., ALFRED (AL) > Cc: Benoit Claise; lmap@ietf.org > Subject: RE: [lmap] Draft Agenda [was: LMAP BoF has been approved.] >=20 > Al, Claise, >=20 > Just a FYI.. >=20 > There is a high probability of a Liaison being sent from the BBF to > the IETF on their work in the area. > Up to you if you want to slot out some time to talk about it or not. >=20 > I'm still putting our other forest fires, and need to review the new draf= t > yet - my apologies for being behind. >=20 >=20 > Regards, > Mike >=20 >=20 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: Tuesday, February 19, 2013 4:03 PM > To: MORTON JR., ALFRED (AL) > Cc: Benoit Claise; lmap@ietf.org > Subject: Re: [lmap] Draft Agenda [was: LMAP BoF has been approved.] >=20 > On Tue, Feb 19, 2013 at 02:04:44PM -0500, MORTON JR., ALFRED (AL) wrote: > > > > We believe we have embraced the tsunami of 00 drafts and found all > > those that are relevant, >=20 > Al, >=20 > you may want to add >=20 > http://www.ietf.org/id/draft-schoenw-lmap-netconf-00.txt >=20 > to the reading list. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From acmorton@att.com Tue Feb 19 17:00: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 6698D21F86F0 for ; Tue, 19 Feb 2013 17:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.461 X-Spam-Level: X-Spam-Status: No, score=-106.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 M5St7zqfUxbk for ; Tue, 19 Feb 2013 17:00:14 -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 E956A21F86D5 for ; Tue, 19 Feb 2013 17:00:13 -0800 (PST) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 73F5C120C77; Tue, 19 Feb 2013 20:02:28 -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 1242DE36DA; Tue, 19 Feb 2013 19:53:51 -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; Tue, 19 Feb 2013 20:00:13 -0500 From: "MORTON JR., ALFRED (AL)" To: Juergen Schoenwaelder Date: Tue, 19 Feb 2013 20:00:12 -0500 Thread-Topic: [lmap] Draft Agenda [was: LMAP BoF has been approved.] Thread-Index: Ac4O7PQ87pzYRhvuRECHsTXI9c87LAAGIe/A Message-ID: References: <20130219220316.GB12870@elstar.local> In-Reply-To: <20130219220316.GB12870@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Benoit Claise , "lmap@ietf.org" Subject: Re: [lmap] Draft Agenda [was: LMAP BoF has been approved.] 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, 20 Feb 2013 01:00:14 -0000 Yes, thanks for catching our omission, now I have two left to read... Al > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, February 19, 2013 5:03 PM ... > Al, >=20 > you may want to add >=20 > http://www.ietf.org/id/draft-schoenw-lmap-netconf-00.txt >=20 > to the reading list. > From Michael.K.Bugenhagen@centurylink.com Wed Feb 20 09:37:31 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 4DB5821F8775 for ; Wed, 20 Feb 2013 09:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 dR3rfM85xGk6 for ; Wed, 20 Feb 2013 09:37:30 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 8B80221F8722 for ; Wed, 20 Feb 2013 09:37:30 -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 r1KHbAwD000784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 10:37:11 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 9C7081E0053; Wed, 20 Feb 2013 11:37:05 -0600 (CST) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 70F4A1E003F; Wed, 20 Feb 2013 11:37:05 -0600 (CST) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r1KHb4al023989; Wed, 20 Feb 2013 10:37:04 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r1KHb42G023982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 10:37:04 -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; Wed, 20 Feb 2013 11:37:04 -0600 From: "Bugenhagen, Michael K" To: "'MORTON JR., ALFRED (AL)'" , Juergen Schoenwaelder Thread-Topic: [lmap] Draft Agenda [was: LMAP BoF has been approved.] Thread-Index: Ac4O0/pYJRW4w7TWRXiKv33bF479JQASztgAAAYt6AAAFjVLgA== Date: Wed, 20 Feb 2013 17:37:03 +0000 Message-ID: References: <20130219220316.GB12870@elstar.local> 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.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Benoit Claise , "lmap@ietf.org" Subject: Re: [lmap] Draft Agenda [was: LMAP BoF has been approved.] 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, 20 Feb 2013 17:37:31 -0000 Al, Juergen, It may be good to add a "requirements and goals" section to the agenda, = this seems to be a missing piece part of the project, and possibly a critic= al one at that. Regards, Mike -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of MOR= TON JR., ALFRED (AL) Sent: Tuesday, February 19, 2013 7:00 PM To: Juergen Schoenwaelder Cc: Benoit Claise; lmap@ietf.org Subject: Re: [lmap] Draft Agenda [was: LMAP BoF has been approved.] Yes, thanks for catching our omission, now I have two left to read... Al > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, February 19, 2013 5:03 PM ... > Al, >=20 > you may want to add >=20 > http://www.ietf.org/id/draft-schoenw-lmap-netconf-00.txt >=20 > to the reading list. > _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From mohamed.boucadair@orange.com Wed Feb 20 22: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 1B40221F8DE1 for ; Wed, 20 Feb 2013 22:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 aMNqE5fHgiem for ; Wed, 20 Feb 2013 22:34:47 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 519E521F8DC7 for ; Wed, 20 Feb 2013 22:34:41 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 16E5E18C119; Thu, 21 Feb 2013 07:34:40 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id EBE75238048; Thu, 21 Feb 2013 07:34:39 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 21 Feb 2013 07:34:38 +0100 From: To: "MORTON JR., ALFRED (AL)" , Benoit Claise , "lmap@ietf.org" Date: Thu, 21 Feb 2013 07:34:36 +0100 Thread-Topic: Draft Agenda [was: LMAP BoF has been approved.] Thread-Index: Ac4O0/pYJRW4w7TWRXiKv33bF479JQBKT2iw Message-ID: <94C682931C08B048B7A8645303FDC9F36EB3C82528@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EB3C82528PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.21.60325 Cc: JACQUENET Christian OLNC/OLN Subject: Re: [lmap] Draft Agenda [was: LMAP BoF has been approved.] 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, 21 Feb 2013 06:34:48 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EB3C82528PUEXCB1Bnante_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBbCwNCg0KV291bGQgaXQgYmUgcG9zc2libGUgdGhlIGZvbGxvd2luZyBzbG90DQoNCiI1 LiBGcmFtZXdvcms6IFByb2JsZW0gU3RhdGVtZW50LCBJU1AgVXNlIGNhc2UsIEdhcHMsIFJlcXVp cmVtZW50cyAtIFBoaWwgRWFyZGxleSAtIDE1IG1pbiINCg0KdG8gaW5jbHVkZSBzb21lIG9mIHRo ZSBuZXR3b3JrIHByb3ZpZGVyJyByZXF1aXJlbWVudHMgYW5kIGlzc3VlcyBkaXNjdXNzZWQgaW4g ZHJhZnQtYm91Y2FkYWlyLWxtYXAtY29uc2lkZXJhdGlvbnM/DQoNClRoYW5rcy4NCkNoZWVycywN Ck1lZA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEZSA6IGxtYXAtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBk ZSBNT1JUT04gSlIuLCBBTEZSRUQgKEFMKQ0KRW52b3nDqSA6IG1hcmRpIDE5IGbDqXZyaWVyIDIw MTMgMjA6MDUNCsOAIDogQmVub2l0IENsYWlzZTsgbG1hcEBpZXRmLm9yZw0KT2JqZXQgOiBbbG1h cF0gRHJhZnQgQWdlbmRhIFt3YXM6IExNQVAgQm9GIGhhcyBiZWVuIGFwcHJvdmVkLl0NCg0KTE1B UCBsaXN0LA0KDQpXZSBoYXZlIHByZXBhcmVkIGEgZHJhZnQgQm9GIGFnZW5kYSwNCmFuZCBub3cg dGhhdCBvdXIgcG9zdGluZyByaWdodHMgYXJlIGluc3RhbGxlZCwNCml0IGNhbiBiZSBmb3VuZCB3 aXRoIGFsbCBtZWV0aW5nIG1hdGVyaWFsczoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGlu Z3MvODYvYWdlbmRhL2FnZW5kYS04Ni1sbWFwDQoNCldlIGJlbGlldmUgd2UgaGF2ZSBlbWJyYWNl ZCB0aGUgdHN1bmFtaSBvZiAwMCBkcmFmdHMNCmFuZCBmb3VuZCBhbGwgdGhvc2UgdGhhdCBhcmUg cmVsZXZhbnQsDQphbmQgY29udGFjdGVkIGFsbC0xIG9mIHRoZSBwcmVzZW50ZXJzLg0KDQpDb21t ZW50cyB0byB0aGUgbGlzdCwgcGxlYXNlLA0KRGFuIGFuZCBBbA0KYm9mIGNvLWNoYWlycw0KDQpG cm9tOiBsbWFwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBCZW5vaXQgQ2xhaXNlDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA2 LCAyMDEzIDEwOjAwIEFNDQpUbzogbG1hcEBpZXRmLm9yZw0KU3ViamVjdDogW2xtYXBdIExNQVAg Qm9GIGhhcyBiZWVuIGFwcHJvdmVkLg0KDQpEZWFyIGFsbCwNCg0KTGV0IHVzIHNoYXJlIHRoZSBn b29kIG5ld3MuIFRoZSBJRVNHIGFwcHJvdmVkIHRoaXMgQm9GLg0KRXZlbiBpZiBpdCB3YXMgaW5p dGlhbGx5IHJlcXVlc3RlZCBpbiBUU1YsIHRoZSBCb0Ygd2lsbCBiZSBzcG9uc29yZWQgaW4gT1BT IGJ5IEJlbm9pdCBDbGFpc2UuDQpUaGUgQm9GIGluZm9ybWF0aW9uIGhhdmUgYmVlbiB1cGRhdGVk IChTZWUgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9mL3RyYWMvd2lraS9XaWtpU3RhcnQp DQoNCkxhcmdlLVNjYWxlIE1lYXN1cmVtZW50IG9mIEJyb2FkYmFuZCBQZXJmb3JtYW5jZSAoTE1B UCkNCg0KICogICBTdGF0dXM6IFJlcXVlc3RlZC4NCiAqICAgVHlwZTogV0cgZm9ybWluZyAoMXN0 IGF0dGVtcHQpLg0KICogICBSZXNwb25zaWJsZSBBRDogQmVub2l0IENsYWlzZSwgT1BTDQogKiAg IEJPRiBDaGFpcnM6IERhbiBSb21hc2NhbnUgKOKAi2Ryb21hc2NhQGF2YXlhLmNvbTxtYWlsdG86 ZHJvbWFzY2FAYXZheWEuY29tPiksIEFsIE1vcnRvbiAo4oCLYWNtb3J0b25AYXR0LmNvbTxtYWls dG86YWNtb3J0b25AYXR0LmNvbT4pKQ0KICogICBBdHRlbmRhbmNlOiA4MA0KICogICBTZXNzaW9u IGxlbmd0aCAxMjAgbWludXRlcw0KICogICBDb25mbGljdHMgdG8gYXZvaWQ6DQpGaXJzdCBsZXZl bCBwcmlvcml0eTogSVBQTSwgRUNSSVQsIEJNV0csIE9QU0FSRUEvT1BTQVdHLCBJUEZJWCwgRU1B TiwgTkVUQ09ORiwgTkVUTU9ELCBYUkJMT0NLLCBESU1FLCBSQURFWFQsIFNBQ00gQm9GLCBUU1ZB UkVBLCBBTFRPLCBDRE5JLCBORlNWNCwgUFBTUCwgVFNWV0cNClNlY29uZCBsZXZlbCBwcmlvcml0 eTogQ09ORVgNCiAqICAgRG9lcyBpdCByZXF1aXJlIFdlYkVYPyBObw0KICogICBEb2VzIGl0IHJl cXVpcmUgTWVldGVjaG8/IE5vDQogKiAgIE1haWxpbmcgbGlzdDog4oCLIOKAi2xtYXBAaWVmdC5v cmc8bWFpbHRvOmxtYXBAaWVmdC5vcmc+DQogKiAgIExpc3QgYXJjaGl2ZTog4oCL4oCLaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2xtYXAvY3VycmVudC9tYWlsbGlzdC5odG1s PGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sbWFwL2N1cnJlbnQvbWFpbGxp c3QuaHRtbD4NCiAqICAgRG9jdW1lbnRzOiBkcmFmdC1zY2h1bHpyaW5uZS1sbWFwLXJlcXVpcmVt ZW50czxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2h1bHpyaW5uZS1sbWFwLXJl cXVpcmVtZW50cz4sIGRyYWZ0LWxpbnNuZXItbG1hcC11c2UtY2FzZXM8aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbGluc25lci1sbWFwLXVzZS1jYXNlcz4sIGFuZCBkcmFmdC1tb3J0 b24taXBwbS1sbWFwLXBhdGgtMDA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbW9y dG9uLWlwcG0tbG1hcC1wYXRoLTAwPg0KVGhlIGNoYWlycyBoYXZlIGJlZW4gY2hvc2VuIGJhc2Vk IG9uIHRoZWlyIGxldmVscyBvZiBleHBlcnRpc2UvZXhwZXJpZW5jZSBpbiBPUFMsIG1lYXN1cmVt ZW50LCBhbmQgSUVURi4gVGhhbmtzIERhbiBhbmQgQWwgZm9yIGFjY2VwdGluZyB0aGUgY2hhaXIg cG9zaXRpb25zLg0KDQpHb2FscyBmb3IgdGhpcyBCb0Y6DQotIGJlIGluIHN5bmNoIG9uIHRoZSBw cm9ibGVtIHN0YXRlbWVudCBhbmQgdXNlIGNhc2VzDQotIHVuZGVyc3RhbmQgd2hhdCB0aGUgZXhp c3RpbmcgSUVURiBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIChJUFBNLCBORVRDT05GL1lBTkcs IElQRklYLCBldGMuLi4pIGNhbiBvciBjYW4ndCBkbyBmb3IgTE1BUC4gVGhpcyB3aWxsIGNlcnRh aW5seSByZXF1aXJlIGEgbGl0dGxlIG9mIGVkdWNhdGlvbiBkaXJlY3RseSBmcm9tIHRoZSBleHBl cnRzIGR1cmluZyB0aGUgQm9GLg0KLSBjbGFyaWZ5IHdoYXQncyBpbiBzY29wZSBvciBub3QgZm9y IExNQVANCg0KRmluYWxseSwgbGV0IG1lIHN0cmVzcyB0aGF0IGEgcHJvcGVyIHByZXBhcmF0aW9u IGlzIGtleSB0byBhIEJvRiBzdWNjZXNzLg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NTQzNCAgIkNvbnNpZGVyYXRpb25zIGZvciBIYXZpbmcgYSBTdWNjZXNzZnVsIEJpcmRzLW9mLWEt RmVhdGhlciAoQk9GKSBTZXNzaW9uIiBpcyBhIGZpcnN0IGdvb2Qgc3RlcC4NCg0KUmVnYXJkcywg TWFydGluIFN0aWVtZXJsaW5nIChUU1YpIGFuZCBCZW5vaXQgQ2xhaXNlIChPUFMpDQoNCg== --_000_94C682931C08B048B7A8645303FDC9F36EB3C82528PUEXCB1Bnante_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIj48SEVBRD4NCjxNRVRBIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+ DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE4NzAyIj4N CjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogV2luZ2RpbmdzOw0KfQ0KQGZvbnQt ZmFjZSB7DQoJZm9udC1mYW1pbHk6IFdpbmdkaW5nczsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiBDYWxpYnJpOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFRhaG9tYTsN Cn0NCkBwYWdlIFdvcmRTZWN0aW9uMSB7c2l6ZTogOC41aW4gMTEuMGluOyBtYXJnaW46IDEuMGlu IDEuMGluIDEuMGluIDEuMGluOyB9DQpQLk1zb05vcm1hbCB7DQoJTUFSR0lOOiAwaW4gMGluIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7IENPTE9SOiBibGFjazsg Rk9OVC1TSVpFOiAxMnB0DQp9DQpMSS5Nc29Ob3JtYWwgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7 IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOyBDT0xPUjogYmxhY2s7IEZP TlQtU0laRTogMTJwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJTUFSR0lOOiAwaW4gMGluIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7IENPTE9SOiBibGFjazsgRk9O VC1TSVpFOiAxMnB0DQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046 IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsg ew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZTsgbXNvLXN0eWxlLXBy aW9yaXR5OiA5OQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJ T046IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0KU1BBTi5Nc29IeXBlcmxp bmtGb2xsb3dlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7 IG1zby1zdHlsZS1wcmlvcml0eTogOTkNCn0NClAgew0KCUZPTlQtRkFNSUxZOiAiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiOyBDT0xPUjogYmxhY2s7IE1BUkdJTi1MRUZUOiAwaW47IEZPTlQtU0la RTogMTJwdDsgTUFSR0lOLVJJR0hUOiAwaW47IG1zby1zdHlsZS1wcmlvcml0eTogOTk7IG1zby1t YXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvDQp9DQpTUEFO Lmljb24gew0KCW1zby1zdHlsZS1uYW1lOiBpY29uDQp9DQpTUEFOLkVtYWlsU3R5bGUyMCB7DQoJ Rk9OVC1GQU1JTFk6ICJDb3VyaWVyIE5ldyI7IENPTE9SOiB3aW5kb3d0ZXh0OyBtc28tc3R5bGUt dHlwZTogcGVyc29uYWwtcmVwbHkNCn0NCi5Nc29DaHBEZWZhdWx0IHsNCglGT05ULVNJWkU6IDEw cHQ7IG1zby1zdHlsZS10eXBlOiBleHBvcnQtb25seQ0KfQ0KRElWLldvcmRTZWN0aW9uMSB7DQoJ cGFnZTogV29yZFNlY3Rpb24xDQp9DQpPTCB7DQoJTUFSR0lOLUJPVFRPTTogMGluDQp9DQpVTCB7 DQoJTUFSR0lOLUJPVFRPTTogMGluDQp9DQo8L1NUWUxFPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L0hFQUQ+DQo8Qk9EWSBsYW5nPUVOLVVTIGxpbms9 Ymx1ZSBiZ0NvbG9yPXdoaXRlIHZMaW5rPXB1cnBsZT4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0 PjxTUEFOIGNsYXNzPTEwMzI4MzIwNi0yMTAyMjAxMz48Rk9OVCBjb2xvcj0jMDAwMGZmIA0Kc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5EZWFyIEFsLDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElW IGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xMDMyODMyMDYtMjEwMjIwMTM+PEZPTlQg Y29sb3I9IzAwMDBmZiANCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PC9GT05UPjwvU1BBTj4m bmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTEwMzI4MzIw Ni0yMTAyMjAxMz48Rk9OVCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij5Xb3VsZCBpdCBiZSBwb3NzaWJsZSB0aGUgZm9sbG93aW5nIHNsb3QgDQo8L0ZPTlQ+PC9TUEFO PjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MTAzMjgzMjA2LTIx MDIyMDEzPjxGT05UIGNvbG9yPSMwMDAwZmYgDQpzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjwv Rk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz0xMDMyODMyMDYtMjEwMjIwMTM+PEZPTlQgY29sb3I9IzAwMDBmZiANCnNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+IjUuIEZyYW1ld29yazogUHJvYmxlbSBTdGF0ZW1lbnQsIElTUCBVc2Ug Y2FzZSwgR2FwcywgDQpSZXF1aXJlbWVudHMgLSBQaGlsIEVhcmRsZXkgLSAxNSBtaW4iPC9GT05U PjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTEwMzI4 MzIwNi0yMTAyMjAxMz48Rk9OVCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+ PFNQQU4gY2xhc3M9MTAzMjgzMjA2LTIxMDIyMDEzPjxGT05UIGNvbG9yPSMwMDAwZmYgDQpzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPnRvIGluY2x1ZGUmbmJzcDtzb21lIG9mIHRoZSBuZXR3b3Jr IHByb3ZpZGVyJyANCnJlcXVpcmVtZW50cyBhbmQgaXNzdWVzIGRpc2N1c3NlZCBpbiANCmRyYWZ0 LWJvdWNhZGFpci1sbWFwLWNvbnNpZGVyYXRpb25zPzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElW IGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xMDMyODMyMDYtMjEwMjIwMTM+PEZPTlQg Y29sb3I9IzAwMDBmZiANCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PC9GT05UPjwvU1BBTj4m bmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTEwMzI4MzIw Ni0yMTAyMjAxMz48Rk9OVCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij5UaGFua3MuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxT UEFOIGNsYXNzPTEwMzI4MzIwNi0yMTAyMjAxMz48Rk9OVCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij5DaGVlcnMsPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGly PWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTEwMzI4MzIwNi0yMTAyMjAxMz48Rk9OVCBjb2xv cj0jMDAwMGZmIA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5NZWQ8L0ZPTlQ+PC9TUEFOPjwv RElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MTAzMjgzMjA2LTIxMDIy MDEzPjxGT05UIGNvbG9yPSMwMDAwZmYgDQpzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjwvRk9O VD48L1NQQU4+Jm5ic3A7PC9ESVY+PEJSPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iQk9SREVSLUxF RlQ6ICMwMDAwZmYgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVw eDsgTUFSR0lOLVJJR0hUOiAwcHgiIA0KZGlyPWx0cj4NCiAgPERJViBkaXI9bHRyIGxhbmc9ZnIg Y2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgYWxpZ249bGVmdD4NCiAgPEhSIHRhYkluZGV4PS0x Pg0KICA8Rk9OVCBzaXplPTIgZmFjZT1UYWhvbWE+PEI+RGUmbmJzcDs6PC9CPiBsbWFwLWJvdW5j ZXNAaWV0Zi5vcmcgDQogIFttYWlsdG86bG1hcC1ib3VuY2VzQGlldGYub3JnXSA8Qj5EZSBsYSBw YXJ0IGRlPC9CPiBNT1JUT04gSlIuLCBBTEZSRUQgDQogIChBTCk8QlI+PEI+RW52b3nDqSZuYnNw Ozo8L0I+IG1hcmRpIDE5IGbDqXZyaWVyIDIwMTMgMjA6MDU8QlI+PEI+w4AmbmJzcDs6PC9CPiAN CiAgQmVub2l0IENsYWlzZTsgbG1hcEBpZXRmLm9yZzxCUj48Qj5PYmpldCZuYnNwOzo8L0I+IFts bWFwXSBEcmFmdCBBZ2VuZGEgW3dhczogDQogIExNQVAgQm9GIGhhcyBiZWVuIGFwcHJvdmVkLl08 QlI+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJViBjbGFzcz1Xb3JkU2Vj dGlvbjE+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZ OiAnQ291cmllciBOZXcnOyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1TSVpFOiAxMHB0Ij5MTUFQ IA0KICBsaXN0LDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxT UEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiB3aW5kb3d0 ZXh0OyBGT05ULVNJWkU6IDEwcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l dyc7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiPldlIGhhdmUgDQogIHByZXBh cmVkIGEgZHJhZnQgQm9GIGFnZW5kYSw8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBD T0xPUjogd2luZG93dGV4dDsgRk9OVC1TSVpFOiAxMHB0Ij5hbmQgbm93IA0KICB0aGF0IG91ciBw b3N0aW5nIHJpZ2h0cyBhcmUgaW5zdGFsbGVkLCA8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQ IGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBO ZXcnOyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1TSVpFOiAxMHB0Ij5pdCBjYW4gDQogIGJlIGZv dW5kIHdpdGggYWxsIG1lZXRpbmcgbWF0ZXJpYWxzOiA8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmll ciBOZXcnOyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1TSVpFOiAxMHB0Ij48QSANCiAgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Ni9hZ2VuZGEvYWdlbmRhLTg2LWxtYXAi Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODYvYWdlbmRhL2FnZW5kYS04Ni1sbWFw PC9BPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiB3aW5kb3d0ZXh0OyBG T05ULVNJWkU6IDEwcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENP TE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiPldlIA0KICBiZWxpZXZlIHdlIGhhdmUg ZW1icmFjZWQgdGhlIHRzdW5hbWkgb2YgMDAgZHJhZnRzPG86cD48L286cD48L1NQQU4+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJp ZXIgTmV3JzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBwdCI+YW5kIA0KICBmb3Vu ZCBhbGwgdGhvc2UgdGhhdCBhcmUgcmVsZXZhbnQsIDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVy IE5ldyc7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiPmFuZCANCiAgY29udGFj dGVkIGFsbC0xIG9mIHRoZSBwcmVzZW50ZXJzLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l dyc7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1G QU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQi PkNvbW1lbnRzIA0KICB0byB0aGUgbGlzdCwgcGxlYXNlLDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3Vy aWVyIE5ldyc7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiPkRhbiBhbmQgDQog IEFsPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQog IHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZP TlQtU0laRTogMTBwdCI+Ym9mIA0KICBjby1jaGFpcnM8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmll ciBOZXcnOyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1TSVpFOiAxMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvU1BBTj48L1A+DQogIDxESVYgDQogIHN0eWxlPSJCT1JERVItQk9UVE9NOiBtZWRpdW0g bm9uZTsgQk9SREVSLUxFRlQ6IGJsdWUgMS41cHQgc29saWQ7IFBBRERJTkctQk9UVE9NOiAwaW47 IFBBRERJTkctTEVGVDogNHB0OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6IG1lZGl1 bSBub25lOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogMGluIj4NCiAg PERJVj4NCiAgPERJViANCiAgc3R5bGU9IkJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JE RVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDog MGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBC T1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxCPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5z LXNlcmlmJzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBwdCI+RnJvbTo8L1NQQU4+ PC9CPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsg Q09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBwdCI+IA0KICBsbWFwLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIDxCPk9uIEJlaGFsZiBPZiANCiAg PC9CPkJlbm9pdCBDbGFpc2U8QlI+PEI+U2VudDo8L0I+IFdlZG5lc2RheSwgRmVicnVhcnkgMDYs IDIwMTMgMTA6MDAgDQogIEFNPEJSPjxCPlRvOjwvQj4gbG1hcEBpZXRmLm9yZzxCUj48Qj5TdWJq ZWN0OjwvQj4gW2xtYXBdIExNQVAgQm9GIGhhcyBiZWVuIA0KICBhcHByb3ZlZC48bzpwPjwvbzpw PjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPkRlYXIgYWxsLDxvOnA+PC9vOnA+PC9Q Pg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEJSPkxldCB1cyBzaGFyZSB0aGUgZ29v ZCBuZXdzLiBUaGUgSUVTRyBhcHByb3ZlZCB0aGlzIA0KICBCb0YuPEJSPkV2ZW4gaWYgaXQgd2Fz IGluaXRpYWxseSByZXF1ZXN0ZWQgaW4gVFNWLCB0aGUgQm9GIHdpbGwgYmUgc3BvbnNvcmVkIA0K ICBpbiBPUFMgYnkgQmVub2l0IENsYWlzZS48QlI+VGhlIEJvRiBpbmZvcm1hdGlvbiBoYXZlIGJl ZW4gdXBkYXRlZCAoU2VlIDxBIA0KICBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9i b2YvdHJhYy93aWtpL1dpa2lTdGFydCI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9mL3Ry YWMvd2lraS9XaWtpU3RhcnQ8L0E+KTxvOnA+PC9vOnA+PC9QPg0KICA8UD48U1RST05HPkxhcmdl LVNjYWxlIE1lYXN1cmVtZW50IG9mIEJyb2FkYmFuZCBQZXJmb3JtYW5jZSANCiAgKExNQVApPC9T VFJPTkc+PG86cD48L286cD48L1A+DQogIDxVTCB0eXBlPWRpc2M+DQogICAgPExJIA0KICAgIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0 bzsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xIiANCiAgICBjbGFzcz1Nc29Ob3JtYWw+U3RhdHVz OiBSZXF1ZXN0ZWQuIDxvOnA+PC9vOnA+DQogICAgPExJIA0KICAgIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0bzsgbXNvLWxpc3Q6IGww IGxldmVsMSBsZm8xIiANCiAgICBjbGFzcz1Nc29Ob3JtYWw+VHlwZTogV0cgZm9ybWluZyAoMXN0 IGF0dGVtcHQpLiA8bzpwPjwvbzpwPg0KICAgIDxMSSANCiAgICBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG87IG1zby1saXN0OiBsMCBs ZXZlbDEgbGZvMSIgDQogICAgY2xhc3M9TXNvTm9ybWFsPlJlc3BvbnNpYmxlIEFEOiBCZW5vaXQg Q2xhaXNlLCBPUFMgPG86cD48L286cD4NCiAgICA8TEkgDQogICAgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvOyBtc28tbGlzdDogbDAg bGV2ZWwxIGxmbzEiIA0KICAgIGNsYXNzPU1zb05vcm1hbD5CT0YgQ2hhaXJzOiBEYW4gUm9tYXNj YW51ICg8QSANCiAgICBocmVmPSJtYWlsdG86ZHJvbWFzY2FAYXZheWEuY29tIj48U1BBTiANCiAg ICBjbGFzcz1pY29uPuKAizwvU1BBTj5kcm9tYXNjYUBhdmF5YS5jb208L0E+KSwgQWwgTW9ydG9u ICg8QSANCiAgICBocmVmPSJtYWlsdG86YWNtb3J0b25AYXR0LmNvbSI+PFNQQU4gDQogICAgY2xh c3M9aWNvbj7igIs8L1NQQU4+YWNtb3J0b25AYXR0LmNvbTwvQT4pKSA8bzpwPjwvbzpwPg0KICAg IDxMSSANCiAgICBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJv dHRvbS1hbHQ6IGF1dG87IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSIgDQogICAgY2xhc3M9TXNv Tm9ybWFsPkF0dGVuZGFuY2U6IDgwIDxvOnA+PC9vOnA+DQogICAgPExJIA0KICAgIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0bzsgbXNv LWxpc3Q6IGwwIGxldmVsMSBsZm8xIiANCiAgICBjbGFzcz1Nc29Ob3JtYWw+U2Vzc2lvbiBsZW5n dGggMTIwIG1pbnV0ZXMgPG86cD48L286cD4NCiAgICA8TEkgDQogICAgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvOyBtc28tbGlzdDog bDAgbGV2ZWwxIGxmbzEiIA0KICAgIGNsYXNzPU1zb05vcm1hbD5Db25mbGljdHMgdG8gYXZvaWQ6 IDxCUj5GaXJzdCBsZXZlbCBwcmlvcml0eTogSVBQTSwgRUNSSVQsIA0KICAgIEJNV0csIE9QU0FS RUEvT1BTQVdHLCBJUEZJWCwgRU1BTiwgTkVUQ09ORiwgTkVUTU9ELCBYUkJMT0NLLCBESU1FLCBS QURFWFQsIA0KICAgIFNBQ00gQm9GLCBUU1ZBUkVBLCBBTFRPLCBDRE5JLCBORlNWNCwgUFBTUCwg VFNWV0cgPEJSPlNlY29uZCBsZXZlbCBwcmlvcml0eTogDQogICAgQ09ORVggPG86cD48L286cD4N CiAgICA8TEkgDQogICAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdp bi1ib3R0b20tYWx0OiBhdXRvOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzEiIA0KICAgIGNsYXNz PU1zb05vcm1hbD5Eb2VzIGl0IHJlcXVpcmUgV2ViRVg/IE5vIDxvOnA+PC9vOnA+DQogICAgPExJ IA0KICAgIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9t LWFsdDogYXV0bzsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xIiANCiAgICBjbGFzcz1Nc29Ob3Jt YWw+RG9lcyBpdCByZXF1aXJlIE1lZXRlY2hvPyBObyA8bzpwPjwvbzpwPg0KICAgIDxMSSANCiAg ICBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6 IGF1dG87IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSIgDQogICAgY2xhc3M9TXNvTm9ybWFsPk1h aWxpbmcgbGlzdDog4oCLIDxBIGhyZWY9Im1haWx0bzpsbWFwQGllZnQub3JnIj48U1BBTiANCiAg ICBjbGFzcz1pY29uPuKAizwvU1BBTj5sbWFwQGllZnQub3JnPC9BPiA8bzpwPjwvbzpwPg0KICAg IDxMSSANCiAgICBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJv dHRvbS1hbHQ6IGF1dG87IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSIgDQogICAgY2xhc3M9TXNv Tm9ybWFsPkxpc3QgYXJjaGl2ZTog4oCLPEEgDQogICAgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL2xtYXAvY3VycmVudC9tYWlsbGlzdC5odG1sIj48U1BBTiANCiAg ICBjbGFzcz1pY29uPuKAizwvU1BBTj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvbG1hcC9jdXJyZW50L21haWxsaXN0Lmh0bWw8L0E+IA0KICAgIDxvOnA+PC9vOnA+DQogICAg PExJIA0KICAgIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90 dG9tLWFsdDogYXV0bzsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xIiANCiAgICBjbGFzcz1Nc29O b3JtYWw+RG9jdW1lbnRzOiA8QSANCiAgICBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1zY2h1bHpyaW5uZS1sbWFwLXJlcXVpcmVtZW50cyI+ZHJhZnQtc2NodWx6cmlubmUt bG1hcC1yZXF1aXJlbWVudHM8L0E+LCANCiAgICA8QSANCiAgICBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1saW5zbmVyLWxtYXAtdXNlLWNhc2VzIj5kcmFmdC1saW5zbmVy LWxtYXAtdXNlLWNhc2VzPC9BPiwgDQogICAgYW5kIDxBIA0KICAgIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1vcnRvbi1pcHBtLWxtYXAtcGF0aC0wMCI+ZHJhZnQtbW9y dG9uLWlwcG0tbG1hcC1wYXRoLTAwPC9BPiANCiAgICA8bzpwPjwvbzpwPjwvTEk+PC9VTD4NCiAg PFAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQiIGNsYXNzPU1zb05vcm1hbD5UaGUgY2hhaXJz IGhhdmUgYmVlbiBjaG9zZW4gDQogIGJhc2VkIG9uIHRoZWlyIGxldmVscyBvZiBleHBlcnRpc2Uv ZXhwZXJpZW5jZSBpbiBPUFMsIG1lYXN1cmVtZW50LCBhbmQgSUVURi4gDQogIFRoYW5rcyBEYW4g YW5kIEFsIGZvciBhY2NlcHRpbmcgdGhlIGNoYWlyIHBvc2l0aW9ucy48QlI+PEJSPkdvYWxzIGZv ciB0aGlzIA0KICBCb0Y6PEJSPi0gYmUgaW4gc3luY2ggb24gdGhlIHByb2JsZW0gc3RhdGVtZW50 IGFuZCB1c2UgY2FzZXM8QlI+LSB1bmRlcnN0YW5kIA0KICB3aGF0IHRoZSBleGlzdGluZyBJRVRG IHByb3RvY29scyBhbmQgZGF0YSBtb2RlbHMgKElQUE0sIE5FVENPTkYvWUFORywgSVBGSVgsIA0K ICBldGMuLi4pIGNhbiBvciBjYW4ndCBkbyBmb3IgTE1BUC4gVGhpcyB3aWxsIGNlcnRhaW5seSBy ZXF1aXJlIGEgbGl0dGxlIG9mIA0KICBlZHVjYXRpb24gZGlyZWN0bHkgZnJvbSB0aGUgZXhwZXJ0 cyBkdXJpbmcgdGhlIEJvRi48QlI+LSBjbGFyaWZ5IHdoYXQncyBpbiANCiAgc2NvcGUgb3Igbm90 IGZvciBMTUFQPEJSPjxCUj5GaW5hbGx5LCBsZXQgbWUgc3RyZXNzIHRoYXQgYSBwcm9wZXIgcHJl cGFyYXRpb24gDQogIGlzIGtleSB0byBhIEJvRiBzdWNjZXNzLiA8QlI+PEEgDQogIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU0MzQiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzU0MzQ8L0E+Jm5ic3A7IA0KICAiQ29uc2lkZXJhdGlvbnMgZm9yIEhhdmluZyBhIFN1 Y2Nlc3NmdWwgQmlyZHMtb2YtYS1GZWF0aGVyIChCT0YpIFNlc3Npb24iIGlzIGEgDQogIGZpcnN0 IGdvb2Qgc3RlcC48QlI+PEJSPlJlZ2FyZHMsIE1hcnRpbiBTdGllbWVybGluZyAoVFNWKSBhbmQg QmVub2l0IENsYWlzZSANCiAgKE9QUyk8bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48 L0JPRFk+PC9IVE1MPg0K --_000_94C682931C08B048B7A8645303FDC9F36EB3C82528PUEXCB1Bnante_-- From Martin.Stiemerling@neclab.eu Thu Feb 21 03:46: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 EAFF521F8E07 for ; Thu, 21 Feb 2013 03:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.493 X-Spam-Level: X-Spam-Status: No, score=-103.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 bI-mvJ2oRk-s for ; Thu, 21 Feb 2013 03:46:52 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF0921F8DBB for ; Thu, 21 Feb 2013 03:46:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A9E12103379; Thu, 21 Feb 2013 12:46:51 +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 ggzXZxYBB3eR; Thu, 21 Feb 2013 12:46:51 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 8DF8D103378; Thu, 21 Feb 2013 12:46:26 +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; Thu, 21 Feb 2013 12:46:26 +0100 Message-ID: <51260912.4090906@neclab.eu> Date: Thu, 21 Feb 2013 12:46:26 +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: "Bugenhagen, Michael K" References: <20130219220316.GB12870@elstar.local> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Cc: Benoit Claise , 'Juergen Schoenwaelder' , "MORTON JR., ALFRED \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] Draft Agenda [was: LMAP BoF has been approved.] 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, 21 Feb 2013 11:46:53 -0000 Adding my 2 cents about this: On 02/19/2013 11:06 PM, Bugenhagen, Michael K wrote: > Al, Claise, > > Just a FYI.. > > There is a high probability of a Liaison being sent from the BBF to > the IETF on their work in the area. Up to you if you want to slot out > some time to talk about it or not. I would definitely not talk about liaisons at the BoF. The BoF is about finding consensus whether this LMAP is of interest to the community and also to find out what the technical issues are to be solved and what the IETF can do there. Martin > > I'm still putting our other forest fires, and need to review the new > draft yet - my apologies for being behind. > > > Regards, Mike > > > -----Original Message----- From: lmap-bounces@ietf.org > [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, February 19, 2013 4:03 PM To: MORTON JR., ALFRED (AL) > Cc: Benoit Claise; lmap@ietf.org Subject: Re: [lmap] Draft Agenda > [was: LMAP BoF has been approved.] > > On Tue, Feb 19, 2013 at 02:04:44PM -0500, MORTON JR., ALFRED (AL) > wrote: >> >> We believe we have embraced the tsunami of 00 drafts and found all >> those that are relevant, > > Al, > > you may want to add > > http://www.ietf.org/id/draft-schoenw-lmap-netconf-00.txt > > to the reading list. > > /js > -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From acmorton@att.com Thu Feb 21 04:29: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 E891421F8CE3 for ; Thu, 21 Feb 2013 04:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MXGRmec-ESTV for ; Thu, 21 Feb 2013 04:29:10 -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 B251521F8CED for ; Thu, 21 Feb 2013 04:29:09 -0800 (PST) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id C83B1120C9F; Thu, 21 Feb 2013 07:31:23 -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 95DC2E3852; Thu, 21 Feb 2013 07:22: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; Thu, 21 Feb 2013 07:29:05 -0500 From: "MORTON JR., ALFRED (AL)" To: "mohamed.boucadair@orange.com" , Benoit Claise , "lmap@ietf.org" , "Romascanu, Dan (Dan) (dromasca@avaya.com)" Date: Thu, 21 Feb 2013 07:29:03 -0500 Thread-Topic: Draft Agenda [was: LMAP BoF has been approved.] Thread-Index: Ac4O0/pYJRW4w7TWRXiKv33bF479JQBKT2iwAAvWBHA= Message-ID: References: <94C682931C08B048B7A8645303FDC9F36EB3C82528@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB3C82528@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F1312FAF1A1E624DA0972D1C9A91379A1BF83B06D8njfpsrvexg7re_" MIME-Version: 1.0 Cc: JACQUENET Christian OLNC/OLN Subject: Re: [lmap] Draft Agenda [was: LMAP BoF has been approved.] 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, 21 Feb 2013 12:29:11 -0000 --_000_F1312FAF1A1E624DA0972D1C9A91379A1BF83B06D8njfpsrvexg7re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWVkLA0KDQpZZXMsIG9uZSBwb2ludCB5b3UndmUgbWFkZSB0aGF0IChJTU8pIHNob3VsZCBi ZSBhZGRyZXNzZWQNCndpdGhpbiB0aGUgY3VycmVudCBjb25zdHJhaW50cyBvZiB0aGUgRnJhbWV3 b3JrIGRyYWZ0LA0KaXMgYWJvdXQgdGVzdGluZyBjcml0aWNhbCBzZXJ2aWNlcyB3aGljaCB0aGUN CmFjY2VzcyBJU1AgY29udHJhY3RzIGZvciwgc28gZG9lcyBub3Qgb3duIGl0c2VsZi4NCllvdXIg ZXhhbXBsZSwgRE5TIHRlc3RpbmcsIGlzIHBhcnRpY3VsYXJseSByZWxldmFudA0Kc2luY2UgZXZl cnkgdXNlciBwZXJmb3JtcyBxdWVyaWVzIHRoYXQgY3Jvc3Mgb3JnLiBib3VuZGFyaWVzLA0KYW5k IHNvIHdvdWxkIHRoZSBtZWFzdXJlbWVudCBwYXRoIGZvciBETlMgcmVzcG9uc2UgdGltZS4NCkhv d2V2ZXIsIGFsbCB0aGUgbWVhc3VyZW1lbnQgaW5mcmFzdHJ1Y3R1cmUgd291bGQgcmVtYWluDQp3 aXRoaW4gYSBzaW5nbGUgb3JnYW5pemF0aW9uJ3MgZG9tYWluLCBhbmQgd2hpbGUgSSB0aGluayB0 aGlzDQptYXRjaGVzIHRoZSBjdXJyZW50IGNvbnN0cmFpbnQsIGl0J3MgY2VydGFpbmx5IHdvcnRo IGluY2x1ZGluZy4NCg0KQWZ0ZXIgcmV2aWV3aW5nIHRoZSBVc2UgQ2FzZSBEcmFmdCwgcGFydGlj dWxhcmx5IHRoZSBkZXRhaWxlZCBJU1ANClVzZSBDYXNlLCBhbmQgdGhlIEZyYW1ld29yayBEcmFm dCBpdHNlbGYsIGNhbiB5b3UgcG9pbnQgb3V0DQphZGRpdGlvbmFsIGNvbnNpZGVyYXRpb25zIG5v dC15ZXQgZGVzY3JpYmVkIChidXQgd2l0aGluIHRoZSBjdXJyZW50DQpjb25zdHJhaW50cyk/DQoN CnRoYW5rcywNCkFsDQoNCg0KRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBbbWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb21dDQpTZW50OiBUaHVyc2RheSwgRmVicnVh cnkgMjEsIDIwMTMgMTozNSBBTQ0KVG86IE1PUlRPTiBKUi4sIEFMRlJFRCAoQUwpOyBCZW5vaXQg Q2xhaXNlOyBsbWFwQGlldGYub3JnDQpDYzogSkFDUVVFTkVUIENocmlzdGlhbiBPTE5DL09MTg0K U3ViamVjdDogUkU6IERyYWZ0IEFnZW5kYSBbd2FzOiBMTUFQIEJvRiBoYXMgYmVlbiBhcHByb3Zl ZC5dDQoNCkRlYXIgQWwsDQoNCldvdWxkIGl0IGJlIHBvc3NpYmxlIHRoZSBmb2xsb3dpbmcgc2xv dA0KDQoiNS4gRnJhbWV3b3JrOiBQcm9ibGVtIFN0YXRlbWVudCwgSVNQIFVzZSBjYXNlLCBHYXBz LCBSZXF1aXJlbWVudHMgLSBQaGlsIEVhcmRsZXkgLSAxNSBtaW4iDQoNCnRvIGluY2x1ZGUgc29t ZSBvZiB0aGUgbmV0d29yayBwcm92aWRlcicgcmVxdWlyZW1lbnRzIGFuZCBpc3N1ZXMgZGlzY3Vz c2VkIGluIGRyYWZ0LWJvdWNhZGFpci1sbWFwLWNvbnNpZGVyYXRpb25zPw0KDQpUaGFua3MuDQpD aGVlcnMsDQpNZWQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGUgOiBs bWFwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxh IHBhcnQgZGUgTU9SVE9OIEpSLiwgQUxGUkVEIChBTCkNCkVudm95w6kgOiBtYXJkaSAxOSBmw6l2 cmllciAyMDEzIDIwOjA1DQrDgCA6IEJlbm9pdCBDbGFpc2U7IGxtYXBAaWV0Zi5vcmcNCk9iamV0 IDogW2xtYXBdIERyYWZ0IEFnZW5kYSBbd2FzOiBMTUFQIEJvRiBoYXMgYmVlbiBhcHByb3ZlZC5d DQpMTUFQIGxpc3QsDQoNCldlIGhhdmUgcHJlcGFyZWQgYSBkcmFmdCBCb0YgYWdlbmRhLA0KYW5k IG5vdyB0aGF0IG91ciBwb3N0aW5nIHJpZ2h0cyBhcmUgaW5zdGFsbGVkLA0KaXQgY2FuIGJlIGZv dW5kIHdpdGggYWxsIG1lZXRpbmcgbWF0ZXJpYWxzOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9j ZWVkaW5ncy84Ni9hZ2VuZGEvYWdlbmRhLTg2LWxtYXANCg0KV2UgYmVsaWV2ZSB3ZSBoYXZlIGVt YnJhY2VkIHRoZSB0c3VuYW1pIG9mIDAwIGRyYWZ0cw0KYW5kIGZvdW5kIGFsbCB0aG9zZSB0aGF0 IGFyZSByZWxldmFudCwNCmFuZCBjb250YWN0ZWQgYWxsLTEgb2YgdGhlIHByZXNlbnRlcnMuDQoN CkNvbW1lbnRzIHRvIHRoZSBsaXN0LCBwbGVhc2UsDQpEYW4gYW5kIEFsDQpib2YgY28tY2hhaXJz DQoNCkZyb206IGxtYXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEJlbm9pdCBDbGFpc2UNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVh cnkgMDYsIDIwMTMgMTA6MDAgQU0NClRvOiBsbWFwQGlldGYub3JnDQpTdWJqZWN0OiBbbG1hcF0g TE1BUCBCb0YgaGFzIGJlZW4gYXBwcm92ZWQuDQoNCkRlYXIgYWxsLA0KDQpMZXQgdXMgc2hhcmUg dGhlIGdvb2QgbmV3cy4gVGhlIElFU0cgYXBwcm92ZWQgdGhpcyBCb0YuDQpFdmVuIGlmIGl0IHdh cyBpbml0aWFsbHkgcmVxdWVzdGVkIGluIFRTViwgdGhlIEJvRiB3aWxsIGJlIHNwb25zb3JlZCBp biBPUFMgYnkgQmVub2l0IENsYWlzZS4NClRoZSBCb0YgaW5mb3JtYXRpb24gaGF2ZSBiZWVuIHVw ZGF0ZWQgKFNlZSBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ib2YvdHJhYy93aWtpL1dpa2lT dGFydCkNCg0KTGFyZ2UtU2NhbGUgTWVhc3VyZW1lbnQgb2YgQnJvYWRiYW5kIFBlcmZvcm1hbmNl IChMTUFQKQ0KDQogKiAgIFN0YXR1czogUmVxdWVzdGVkLg0KICogICBUeXBlOiBXRyBmb3JtaW5n ICgxc3QgYXR0ZW1wdCkuDQogKiAgIFJlc3BvbnNpYmxlIEFEOiBCZW5vaXQgQ2xhaXNlLCBPUFMN CiAqICAgQk9GIENoYWlyczogRGFuIFJvbWFzY2FudSAo4oCLZHJvbWFzY2FAYXZheWEuY29tPG1h aWx0bzpkcm9tYXNjYUBhdmF5YS5jb20+KSwgQWwgTW9ydG9uICjigIthY21vcnRvbkBhdHQuY29t PG1haWx0bzphY21vcnRvbkBhdHQuY29tPikpDQogKiAgIEF0dGVuZGFuY2U6IDgwDQogKiAgIFNl c3Npb24gbGVuZ3RoIDEyMCBtaW51dGVzDQogKiAgIENvbmZsaWN0cyB0byBhdm9pZDoNCkZpcnN0 IGxldmVsIHByaW9yaXR5OiBJUFBNLCBFQ1JJVCwgQk1XRywgT1BTQVJFQS9PUFNBV0csIElQRklY LCBFTUFOLCBORVRDT05GLCBORVRNT0QsIFhSQkxPQ0ssIERJTUUsIFJBREVYVCwgU0FDTSBCb0Ys IFRTVkFSRUEsIEFMVE8sIENETkksIE5GU1Y0LCBQUFNQLCBUU1ZXRw0KU2Vjb25kIGxldmVsIHBy aW9yaXR5OiBDT05FWA0KICogICBEb2VzIGl0IHJlcXVpcmUgV2ViRVg/IE5vDQogKiAgIERvZXMg aXQgcmVxdWlyZSBNZWV0ZWNobz8gTm8NCiAqICAgTWFpbGluZyBsaXN0OiDigIsg4oCLbG1hcEBp ZWZ0Lm9yZzxtYWlsdG86bG1hcEBpZWZ0Lm9yZz4NCiAqICAgTGlzdCBhcmNoaXZlOiDigIvigIto dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbG1hcC9jdXJyZW50L21haWxsaXN0 Lmh0bWw8aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2xtYXAvY3VycmVudC9t YWlsbGlzdC5odG1sPg0KICogICBEb2N1bWVudHM6IGRyYWZ0LXNjaHVsenJpbm5lLWxtYXAtcmVx dWlyZW1lbnRzPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaHVsenJpbm5lLWxt YXAtcmVxdWlyZW1lbnRzPiwgZHJhZnQtbGluc25lci1sbWFwLXVzZS1jYXNlczxodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saW5zbmVyLWxtYXAtdXNlLWNhc2VzPiwgYW5kIGRyYWZ0 LW1vcnRvbi1pcHBtLWxtYXAtcGF0aC0wMDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1tb3J0b24taXBwbS1sbWFwLXBhdGgtMDA+DQpUaGUgY2hhaXJzIGhhdmUgYmVlbiBjaG9zZW4g YmFzZWQgb24gdGhlaXIgbGV2ZWxzIG9mIGV4cGVydGlzZS9leHBlcmllbmNlIGluIE9QUywgbWVh c3VyZW1lbnQsIGFuZCBJRVRGLiBUaGFua3MgRGFuIGFuZCBBbCBmb3IgYWNjZXB0aW5nIHRoZSBj aGFpciBwb3NpdGlvbnMuDQoNCkdvYWxzIGZvciB0aGlzIEJvRjoNCi0gYmUgaW4gc3luY2ggb24g dGhlIHByb2JsZW0gc3RhdGVtZW50IGFuZCB1c2UgY2FzZXMNCi0gdW5kZXJzdGFuZCB3aGF0IHRo ZSBleGlzdGluZyBJRVRGIHByb3RvY29scyBhbmQgZGF0YSBtb2RlbHMgKElQUE0sIE5FVENPTkYv WUFORywgSVBGSVgsIGV0Yy4uLikgY2FuIG9yIGNhbid0IGRvIGZvciBMTUFQLiBUaGlzIHdpbGwg Y2VydGFpbmx5IHJlcXVpcmUgYSBsaXR0bGUgb2YgZWR1Y2F0aW9uIGRpcmVjdGx5IGZyb20gdGhl IGV4cGVydHMgZHVyaW5nIHRoZSBCb0YuDQotIGNsYXJpZnkgd2hhdCdzIGluIHNjb3BlIG9yIG5v dCBmb3IgTE1BUA0KDQpGaW5hbGx5LCBsZXQgbWUgc3RyZXNzIHRoYXQgYSBwcm9wZXIgcHJlcGFy YXRpb24gaXMga2V5IHRvIGEgQm9GIHN1Y2Nlc3MuDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM1NDM0ICAiQ29uc2lkZXJhdGlvbnMgZm9yIEhhdmluZyBhIFN1Y2Nlc3NmdWwgQmlyZHMt b2YtYS1GZWF0aGVyIChCT0YpIFNlc3Npb24iIGlzIGEgZmlyc3QgZ29vZCBzdGVwLg0KDQpSZWdh cmRzLCBNYXJ0aW4gU3RpZW1lcmxpbmcgKFRTVikgYW5kIEJlbm9pdCBDbGFpc2UgKE9QUykNCg0K --_000_F1312FAF1A1E624DA0972D1C9A91379A1BF83B06D8njfpsrvexg7re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0K CWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRp di5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5pY29uDQoJe21zby1zdHlsZS1uYW1lOmljb247fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTQzMTc1MzY0Ow0KCW1zby1saXN0LXRl bXBsYXRlLWlkczoxNzg5Mzk4NTY2O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBiZ2NvbG9yPXdoaXRl IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9u MT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5IaSBNZWQsPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5ZZXMs IG9uZSBwb2ludCB5b3UndmUgbWFkZSB0aGF0IChJTU8pIHNob3VsZCBiZSBhZGRyZXNzZWQgPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPndp dGhpbiB0aGUgY3VycmVudCBjb25zdHJhaW50cyBvZiB0aGUgRnJhbWV3b3JrIGRyYWZ0LDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5pcyBh Ym91dCB0ZXN0aW5nIGNyaXRpY2FsIHNlcnZpY2VzIHdoaWNoIHRoZSA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+YWNjZXNzIElTUCBjb250 cmFjdHMgZm9yLCBzbyBkb2VzIG5vdCBvd24gaXRzZWxmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5Zb3VyIGV4YW1wbGUsIEROUyB0ZXN0 aW5nLCBpcyBwYXJ0aWN1bGFybHkgcmVsZXZhbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+c2luY2UgZXZlcnkgdXNlciBwZXJmb3JtcyBx dWVyaWVzIHRoYXQgY3Jvc3Mgb3JnLiBib3VuZGFyaWVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5hbmQgc28gd291bGQgdGhlIG1lYXN1 cmVtZW50IHBhdGggZm9yIEROUyByZXNwb25zZSB0aW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5Ib3dldmVyLCBhbGwgdGhlIG1lYXN1 cmVtZW50IGluZnJhc3RydWN0dXJlIHdvdWxkIHJlbWFpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz53aXRoaW4gYSBzaW5nbGUgb3JnYW5p emF0aW9uJ3MgZG9tYWluLCBhbmQgd2hpbGUgSSB0aGluayB0aGlzPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPm1hdGNoZXMgdGhlIGN1cnJl bnQgY29uc3RyYWludCwgaXQncyBjZXJ0YWlubHkgd29ydGggaW5jbHVkaW5nLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+QWZ0 ZXIgcmV2aWV3aW5nIHRoZSBVc2UgQ2FzZSBEcmFmdCwgcGFydGljdWxhcmx5IHRoZSBkZXRhaWxl ZCBJU1A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93 dGV4dCc+VXNlIENhc2UsIGFuZCB0aGUgRnJhbWV3b3JrIERyYWZ0IGl0c2VsZiwgY2FuIHlvdSBw b2ludCBvdXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2lu ZG93dGV4dCc+YWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucyBub3QteWV0IGRlc2NyaWJlZCAoYnV0 IHdpdGhpbiB0aGUgY3VycmVudCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7Y29sb3I6d2luZG93dGV4dCc+Y29uc3RyYWludHMpPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+dGhhbmtzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5BbDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4 dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRp dj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtj b2xvcjp3aW5kb3d0ZXh0Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQn PiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMjEsIDIwMTMg MTozNSBBTTxicj48Yj5Ubzo8L2I+IE1PUlRPTiBKUi4sIEFMRlJFRCAoQUwpOyBCZW5vaXQgQ2xh aXNlOyBsbWFwQGlldGYub3JnPGJyPjxiPkNjOjwvYj4gSkFDUVVFTkVUIENocmlzdGlhbiBPTE5D L09MTjxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IERyYWZ0IEFnZW5kYSBbd2FzOiBMTUFQIEJvRiBo YXMgYmVlbiBhcHByb3ZlZC5dPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xv cjpibHVlJz5EZWFyIEFsLDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dCc+PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 d2luZG93dGV4dCc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci O2NvbG9yOmJsdWUnPldvdWxkIGl0IGJlIHBvc3NpYmxlIHRoZSBmb2xsb3dpbmcgc2xvdCA8L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQnPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibHVlJz4mcXVvdDs1 LiBGcmFtZXdvcms6IFByb2JsZW0gU3RhdGVtZW50LCBJU1AgVXNlIGNhc2UsIEdhcHMsIFJlcXVp cmVtZW50cyAtIFBoaWwgRWFyZGxleSAtIDE1IG1pbiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0n Y29sb3I6d2luZG93dGV4dCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dCc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsdWUnPnRvIGluY2x1ZGUmbmJzcDtzb21lIG9m IHRoZSBuZXR3b3JrIHByb3ZpZGVyJyByZXF1aXJlbWVudHMgYW5kIGlzc3VlcyBkaXNjdXNzZWQg aW4gZHJhZnQtYm91Y2FkYWlyLWxtYXAtY29uc2lkZXJhdGlvbnM/PC9zcGFuPjxzcGFuIHN0eWxl PSdjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6Ymx1ZSc+VGhhbmtzLjwvc3Bhbj48c3BhbiBz dHlsZT0nY29sb3I6d2luZG93dGV4dCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciO2NvbG9yOmJsdWUnPkNoZWVycyw8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRv d3RleHQnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibHVl Jz5NZWQ8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQnPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjp3 aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBjbGFzcz1Nc29Ob3Jt YWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4gbGFuZz1GUiBz dHlsZT0nY29sb3I6d2luZG93dGV4dCc+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2Vu dGVyPjwvc3Bhbj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206 MTIuMHB0Jz48Yj48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5EZSZuYnNwOzo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPiBsbWFwLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIDxiPkRlIGxhIHBhcnQgZGU8L2I+ IE1PUlRPTiBKUi4sIEFMRlJFRCAoQUwpPGJyPjxiPkVudm95w6kmbmJzcDs6PC9iPiBtYXJkaSAx OSBmw6l2cmllciAyMDEzIDIwOjA1PGJyPjxiPsOAJm5ic3A7OjwvYj4gQmVub2l0IENsYWlzZTsg bG1hcEBpZXRmLm9yZzxicj48Yj5PYmpldCZuYnNwOzo8L2I+IFtsbWFwXSBEcmFmdCBBZ2VuZGEg W3dhczogTE1BUCBCb0YgaGFzIGJlZW4gYXBwcm92ZWQuXTwvc3Bhbj48c3BhbiBsYW5nPUZSIHN0 eWxlPSdjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7Y29sb3I6d2luZG93dGV4dCc+TE1BUCBsaXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+V2UgaGF2ZSBwcmVwYXJl ZCBhIGRyYWZ0IEJvRiBhZ2VuZGEsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciO2NvbG9yOndpbmRvd3RleHQnPmFuZCBub3cgdGhhdCBvdXIgcG9zdGluZyByaWdodHMgYXJl IGluc3RhbGxlZCwgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9y OndpbmRvd3RleHQnPml0IGNhbiBiZSBmb3VuZCB3aXRoIGFsbCBtZWV0aW5nIG1hdGVyaWFsczog PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQn PjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODYvYWdlbmRhL2FnZW5k YS04Ni1sbWFwIj5odHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg2L2FnZW5kYS9hZ2Vu ZGEtODYtbG1hcDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29s b3I6d2luZG93dGV4dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciO2NvbG9yOndpbmRvd3RleHQnPldlIGJlbGlldmUgd2UgaGF2ZSBlbWJyYWNlZCB0aGUgdHN1 bmFtaSBvZiAwMCBkcmFmdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6d2luZG93dGV4dCc+YW5kIGZvdW5kIGFsbCB0aG9zZSB0aGF0IGFyZSByZWxldmFudCwg PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQn PmFuZCBjb250YWN0ZWQgYWxsLTEgb2YgdGhlIHByZXNlbnRlcnMuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5Db21tZW50cyB0 byB0aGUgbGlzdCwgcGxlYXNlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5EYW4gYW5kIEFsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPmJvZiBjby1jaGFpcnM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0 Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPiBsbWFwLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8 L2I+QmVub2l0IENsYWlzZTxicj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAwNiwg MjAxMyAxMDowMCBBTTxicj48Yj5Ubzo8L2I+IGxtYXBAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8 L2I+IFtsbWFwXSBMTUFQIEJvRiBoYXMgYmVlbiBhcHByb3ZlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48YnI+TGV0IHVzIHNoYXJlIHRoZSBnb29kIG5ld3MuIFRoZSBJRVNHIGFwcHJvdmVk IHRoaXMgQm9GLjxicj5FdmVuIGlmIGl0IHdhcyBpbml0aWFsbHkgcmVxdWVzdGVkIGluIFRTViwg dGhlIEJvRiB3aWxsIGJlIHNwb25zb3JlZCBpbiBPUFMgYnkgQmVub2l0IENsYWlzZS48YnI+VGhl IEJvRiBpbmZvcm1hdGlvbiBoYXZlIGJlZW4gdXBkYXRlZCAoU2VlIDxhIGhyZWY9Imh0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL2JvZi90cmFjL3dpa2kvV2lraVN0YXJ0Ij5odHRwOi8vdHJhYy50 b29scy5pZXRmLm9yZy9ib2YvdHJhYy93aWtpL1dpa2lTdGFydDwvYT4pPG86cD48L286cD48L3A+ PHA+PHN0cm9uZz5MYXJnZS1TY2FsZSBNZWFzdXJlbWVudCBvZiBCcm9hZGJhbmQgUGVyZm9ybWFu Y2UgKExNQVApPC9zdHJvbmc+PG86cD48L286cD48L3A+PHVsIHR5cGU9ZGlzYz48bGkgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+U3RhdHVzOiBSZXF1ZXN0ZWQuIDxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSc+VHlwZTogV0cgZm9ybWluZyAoMXN0IGF0dGVtcHQpLiA8bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPlJlc3BvbnNpYmxlIEFEOiBC ZW5vaXQgQ2xhaXNlLCBPUFMgPG86cD48L286cD48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwwIGxldmVsMSBsZm8xJz5CT0YgQ2hhaXJzOiBEYW4gUm9tYXNjYW51ICg8YSBocmVm PSJtYWlsdG86ZHJvbWFzY2FAYXZheWEuY29tIj48c3BhbiBjbGFzcz1pY29uPuKAizwvc3Bhbj5k cm9tYXNjYUBhdmF5YS5jb208L2E+KSwgQWwgTW9ydG9uICg8YSBocmVmPSJtYWlsdG86YWNtb3J0 b25AYXR0LmNvbSI+PHNwYW4gY2xhc3M9aWNvbj7igIs8L3NwYW4+YWNtb3J0b25AYXR0LmNvbTwv YT4pKSA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzEnPkF0dGVuZGFuY2U6IDgwIDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+U2Vzc2lvbiBsZW5ndGggMTIwIG1pbnV0ZXMg PG86cD48L286cD48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBs Zm8xJz5Db25mbGljdHMgdG8gYXZvaWQ6IDxicj5GaXJzdCBsZXZlbCBwcmlvcml0eTogSVBQTSwg RUNSSVQsIEJNV0csIE9QU0FSRUEvT1BTQVdHLCBJUEZJWCwgRU1BTiwgTkVUQ09ORiwgTkVUTU9E LCBYUkJMT0NLLCBESU1FLCBSQURFWFQsIFNBQ00gQm9GLCBUU1ZBUkVBLCBBTFRPLCBDRE5JLCBO RlNWNCwgUFBTUCwgVFNWV0cgPGJyPlNlY29uZCBsZXZlbCBwcmlvcml0eTogQ09ORVggPG86cD48 L286cD48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xJz5E b2VzIGl0IHJlcXVpcmUgV2ViRVg/IE5vIDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+RG9lcyBpdCByZXF1aXJlIE1lZXRlY2hvPyBO byA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEnPk1haWxpbmcgbGlzdDog4oCLIDxhIGhyZWY9Im1haWx0bzpsbWFwQGllZnQub3JnIj48 c3BhbiBjbGFzcz1pY29uPuKAizwvc3Bhbj5sbWFwQGllZnQub3JnPC9hPiA8bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPkxpc3QgYXJj aGl2ZTog4oCLPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2xt YXAvY3VycmVudC9tYWlsbGlzdC5odG1sIj48c3BhbiBjbGFzcz1pY29uPuKAizwvc3Bhbj5odHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbG1hcC9jdXJyZW50L21haWxsaXN0Lmh0 bWw8L2E+IDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSc+RG9jdW1lbnRzOiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1zY2h1bHpyaW5uZS1sbWFwLXJlcXVpcmVtZW50cyI+ZHJhZnQtc2NodWx6cmlubmUt bG1hcC1yZXF1aXJlbWVudHM8L2E+LCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1saW5zbmVyLWxtYXAtdXNlLWNhc2VzIj5kcmFmdC1saW5zbmVyLWxtYXAtdXNlLWNh c2VzPC9hPiwgYW5kIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1v cnRvbi1pcHBtLWxtYXAtcGF0aC0wMCI+ZHJhZnQtbW9ydG9uLWlwcG0tbG1hcC1wYXRoLTAwPC9h PiA8bzpwPjwvbzpwPjwvbGk+PC91bD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1i b3R0b206MTIuMHB0Jz5UaGUgY2hhaXJzIGhhdmUgYmVlbiBjaG9zZW4gYmFzZWQgb24gdGhlaXIg bGV2ZWxzIG9mIGV4cGVydGlzZS9leHBlcmllbmNlIGluIE9QUywgbWVhc3VyZW1lbnQsIGFuZCBJ RVRGLiBUaGFua3MgRGFuIGFuZCBBbCBmb3IgYWNjZXB0aW5nIHRoZSBjaGFpciBwb3NpdGlvbnMu PGJyPjxicj5Hb2FscyBmb3IgdGhpcyBCb0Y6PGJyPi0gYmUgaW4gc3luY2ggb24gdGhlIHByb2Js ZW0gc3RhdGVtZW50IGFuZCB1c2UgY2FzZXM8YnI+LSB1bmRlcnN0YW5kIHdoYXQgdGhlIGV4aXN0 aW5nIElFVEYgcHJvdG9jb2xzIGFuZCBkYXRhIG1vZGVscyAoSVBQTSwgTkVUQ09ORi9ZQU5HLCBJ UEZJWCwgZXRjLi4uKSBjYW4gb3IgY2FuJ3QgZG8gZm9yIExNQVAuIFRoaXMgd2lsbCBjZXJ0YWlu bHkgcmVxdWlyZSBhIGxpdHRsZSBvZiBlZHVjYXRpb24gZGlyZWN0bHkgZnJvbSB0aGUgZXhwZXJ0 cyBkdXJpbmcgdGhlIEJvRi48YnI+LSBjbGFyaWZ5IHdoYXQncyBpbiBzY29wZSBvciBub3QgZm9y IExNQVA8YnI+PGJyPkZpbmFsbHksIGxldCBtZSBzdHJlc3MgdGhhdCBhIHByb3BlciBwcmVwYXJh dGlvbiBpcyBrZXkgdG8gYSBCb0Ygc3VjY2Vzcy4gPGJyPjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzU0MzQiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU0MzQ8 L2E+Jm5ic3A7ICZxdW90O0NvbnNpZGVyYXRpb25zIGZvciBIYXZpbmcgYSBTdWNjZXNzZnVsIEJp cmRzLW9mLWEtRmVhdGhlciAoQk9GKSBTZXNzaW9uJnF1b3Q7IGlzIGEgZmlyc3QgZ29vZCBzdGVw Ljxicj48YnI+UmVnYXJkcywgTWFydGluIFN0aWVtZXJsaW5nIChUU1YpIGFuZCBCZW5vaXQgQ2xh aXNlIChPUFMpPG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1s Pg== --_000_F1312FAF1A1E624DA0972D1C9A91379A1BF83B06D8njfpsrvexg7re_-- From mohamed.boucadair@orange.com Thu Feb 21 04:40: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 84A3821F8DAE for ; Thu, 21 Feb 2013 04:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 Nh5Kb6ffU0Kl for ; Thu, 21 Feb 2013 04:40:22 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E8C5C21F8DA2 for ; Thu, 21 Feb 2013 04:40:21 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 261CC2DC46F; Thu, 21 Feb 2013 13:40:21 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0779327C053; Thu, 21 Feb 2013 13:40:21 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 21 Feb 2013 13:40:16 +0100 From: To: "MORTON JR., ALFRED (AL)" , Benoit Claise , "lmap@ietf.org" , "Romascanu, Dan (Dan) (dromasca@avaya.com)" Date: Thu, 21 Feb 2013 13:40:14 +0100 Thread-Topic: Draft Agenda [was: LMAP BoF has been approved.] Thread-Index: Ac4O0/pYJRW4w7TWRXiKv33bF479JQBKT2iwAAvWBHAAAKrgAA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EB3C8270A@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB3C82528@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EB3C8270APUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.19.124517 Cc: JACQUENET Christian OLNC/OLN Subject: Re: [lmap] Draft Agenda [was: LMAP BoF has been approved.] 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, 21 Feb 2013 12:40:23 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EB3C8270APUEXCB1Bnante_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpkcmFmdC1ib3VjYWRhaXItKiBpbmNsdWRlcyBzb21lIHBvaW50cyBub3QgbWVudGlv bmVkIGluIG90aGVyIGRyYWZ0LSotbG1hcCBJLURzIHN1Y2ggdGhlIERTQ1AgbWFya2luZyBpbmhl cml0YW5jZTogc29tZSBvZiB0aGUgc2VydmljZXMgd2UgYXJlIGRlcGxveWluZyBkbyBub3QgdHJ1 c3QgdGhlIG1hcmtpbmcgc2V0IGJ5IHRoZSBhcHBsaWNhdGlvbiBidXQgdGhlcmUgYXJlIHNwZWNp ZmljIG1vZHVsZXMgd2hpY2ggYXJlIGVuYWJsZWQgaW4gdGhlIENQRSBmb3IgaW5zdGFuY2UuIENv bmR1Y3RpbmcgYSBzZXQgb2YgbWVhc3VyZW1lbnQgZm9yIHRob3NlIHNlcnZpY2Ugd2lsbCBuZWVk IHRvIGJlIGRlc2lnbmVkIHRvIGJlIGNvbXBsaWFudCB3aXRoIHN1Y2ggY29uc3RyYWludC4NCg0K SSBjYW4gbGlzdCBhbm90aGVyIGl0ZW0gc3VjaCBhcyB0aGUgY29tcGF0aWJpbGl0eSB3aXRoIGEg bXVsdGktYWRkcmVzc2VkIHNlcnZpY2UgZGVzaWduIHNjaGVtZSAoaW4gd2hpY2ggIGRpc3RpbmN0 IElQIGFkZHJlc3NlcyBhcmUgYXNzaWduZWQgZm9yIGVhY2ggc3Vic2NyaWJlZCBzZXJ2aWNlKTog cGFja2V0cyBpc3N1ZWQgZnJvbSBhIG1lYXN1cmVtZW50IGFnZW50IChsb2NhdGVkIGJlaGluZCB0 aGUgQ1BFKSB3aWxsIG5lZWQgdG8gYmUgYm91bmQgdG8gdGhlIGFwcHJvcHJpYXRlIHNlcnZpY2Ut c3BlY2lmaWMgY2hhbm5lbCwgZXRjLg0KDQpDaGVlcnMsDQpNZWQNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkRlIDogTU9SVE9OIEpSLiwgQUxGUkVEIChBTCkgW21haWx0bzph Y21vcnRvbkBhdHQuY29tXQ0KRW52b3nDqSA6IGpldWRpIDIxIGbDqXZyaWVyIDIwMTMgMTM6MjkN CsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgT0xOQy9PTE47IEJlbm9pdCBDbGFpc2U7IGxtYXBAaWV0 Zi5vcmc7IFJvbWFzY2FudSwgRGFuIChEYW4pIChkcm9tYXNjYUBhdmF5YS5jb20pDQpDYyA6IEpB Q1FVRU5FVCBDaHJpc3RpYW4gT0xOQy9PTE4NCk9iamV0IDogUkU6IERyYWZ0IEFnZW5kYSBbd2Fz OiBMTUFQIEJvRiBoYXMgYmVlbiBhcHByb3ZlZC5dDQoNCkhpIE1lZCwNCg0KWWVzLCBvbmUgcG9p bnQgeW91J3ZlIG1hZGUgdGhhdCAoSU1PKSBzaG91bGQgYmUgYWRkcmVzc2VkDQp3aXRoaW4gdGhl IGN1cnJlbnQgY29uc3RyYWludHMgb2YgdGhlIEZyYW1ld29yayBkcmFmdCwNCmlzIGFib3V0IHRl c3RpbmcgY3JpdGljYWwgc2VydmljZXMgd2hpY2ggdGhlDQphY2Nlc3MgSVNQIGNvbnRyYWN0cyBm b3IsIHNvIGRvZXMgbm90IG93biBpdHNlbGYuDQpZb3VyIGV4YW1wbGUsIEROUyB0ZXN0aW5nLCBp cyBwYXJ0aWN1bGFybHkgcmVsZXZhbnQNCnNpbmNlIGV2ZXJ5IHVzZXIgcGVyZm9ybXMgcXVlcmll cyB0aGF0IGNyb3NzIG9yZy4gYm91bmRhcmllcywNCmFuZCBzbyB3b3VsZCB0aGUgbWVhc3VyZW1l bnQgcGF0aCBmb3IgRE5TIHJlc3BvbnNlIHRpbWUuDQpIb3dldmVyLCBhbGwgdGhlIG1lYXN1cmVt ZW50IGluZnJhc3RydWN0dXJlIHdvdWxkIHJlbWFpbg0Kd2l0aGluIGEgc2luZ2xlIG9yZ2FuaXph dGlvbidzIGRvbWFpbiwgYW5kIHdoaWxlIEkgdGhpbmsgdGhpcw0KbWF0Y2hlcyB0aGUgY3VycmVu dCBjb25zdHJhaW50LCBpdCdzIGNlcnRhaW5seSB3b3J0aCBpbmNsdWRpbmcuDQoNCkFmdGVyIHJl dmlld2luZyB0aGUgVXNlIENhc2UgRHJhZnQsIHBhcnRpY3VsYXJseSB0aGUgZGV0YWlsZWQgSVNQ DQpVc2UgQ2FzZSwgYW5kIHRoZSBGcmFtZXdvcmsgRHJhZnQgaXRzZWxmLCBjYW4geW91IHBvaW50 IG91dA0KYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucyBub3QteWV0IGRlc2NyaWJlZCAoYnV0IHdp dGhpbiB0aGUgY3VycmVudA0KY29uc3RyYWludHMpPw0KDQp0aGFua3MsDQpBbA0KDQoNCkZyb206 IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIxLCAyMDEzIDE6MzUgQU0NClRv OiBNT1JUT04gSlIuLCBBTEZSRUQgKEFMKTsgQmVub2l0IENsYWlzZTsgbG1hcEBpZXRmLm9yZw0K Q2M6IEpBQ1FVRU5FVCBDaHJpc3RpYW4gT0xOQy9PTE4NClN1YmplY3Q6IFJFOiBEcmFmdCBBZ2Vu ZGEgW3dhczogTE1BUCBCb0YgaGFzIGJlZW4gYXBwcm92ZWQuXQ0KDQpEZWFyIEFsLA0KDQpXb3Vs ZCBpdCBiZSBwb3NzaWJsZSB0aGUgZm9sbG93aW5nIHNsb3QNCg0KIjUuIEZyYW1ld29yazogUHJv YmxlbSBTdGF0ZW1lbnQsIElTUCBVc2UgY2FzZSwgR2FwcywgUmVxdWlyZW1lbnRzIC0gUGhpbCBF YXJkbGV5IC0gMTUgbWluIg0KDQp0byBpbmNsdWRlIHNvbWUgb2YgdGhlIG5ldHdvcmsgcHJvdmlk ZXInIHJlcXVpcmVtZW50cyBhbmQgaXNzdWVzIGRpc2N1c3NlZCBpbiBkcmFmdC1ib3VjYWRhaXIt bG1hcC1jb25zaWRlcmF0aW9ucz8NCg0KVGhhbmtzLg0KQ2hlZXJzLA0KTWVkDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkRlIDogbG1hcC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bG1hcC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1PUlRPTiBKUi4sIEFM RlJFRCAoQUwpDQpFbnZvecOpIDogbWFyZGkgMTkgZsOpdnJpZXIgMjAxMyAyMDowNQ0Kw4AgOiBC ZW5vaXQgQ2xhaXNlOyBsbWFwQGlldGYub3JnDQpPYmpldCA6IFtsbWFwXSBEcmFmdCBBZ2VuZGEg W3dhczogTE1BUCBCb0YgaGFzIGJlZW4gYXBwcm92ZWQuXQ0KTE1BUCBsaXN0LA0KDQpXZSBoYXZl IHByZXBhcmVkIGEgZHJhZnQgQm9GIGFnZW5kYSwNCmFuZCBub3cgdGhhdCBvdXIgcG9zdGluZyBy aWdodHMgYXJlIGluc3RhbGxlZCwNCml0IGNhbiBiZSBmb3VuZCB3aXRoIGFsbCBtZWV0aW5nIG1h dGVyaWFsczoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODYvYWdlbmRhL2FnZW5k YS04Ni1sbWFwDQoNCldlIGJlbGlldmUgd2UgaGF2ZSBlbWJyYWNlZCB0aGUgdHN1bmFtaSBvZiAw MCBkcmFmdHMNCmFuZCBmb3VuZCBhbGwgdGhvc2UgdGhhdCBhcmUgcmVsZXZhbnQsDQphbmQgY29u dGFjdGVkIGFsbC0xIG9mIHRoZSBwcmVzZW50ZXJzLg0KDQpDb21tZW50cyB0byB0aGUgbGlzdCwg cGxlYXNlLA0KRGFuIGFuZCBBbA0KYm9mIGNvLWNoYWlycw0KDQpGcm9tOiBsbWFwLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZW5v aXQgQ2xhaXNlDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA2LCAyMDEzIDEwOjAwIEFNDQpU bzogbG1hcEBpZXRmLm9yZw0KU3ViamVjdDogW2xtYXBdIExNQVAgQm9GIGhhcyBiZWVuIGFwcHJv dmVkLg0KDQpEZWFyIGFsbCwNCg0KTGV0IHVzIHNoYXJlIHRoZSBnb29kIG5ld3MuIFRoZSBJRVNH IGFwcHJvdmVkIHRoaXMgQm9GLg0KRXZlbiBpZiBpdCB3YXMgaW5pdGlhbGx5IHJlcXVlc3RlZCBp biBUU1YsIHRoZSBCb0Ygd2lsbCBiZSBzcG9uc29yZWQgaW4gT1BTIGJ5IEJlbm9pdCBDbGFpc2Uu DQpUaGUgQm9GIGluZm9ybWF0aW9uIGhhdmUgYmVlbiB1cGRhdGVkIChTZWUgaHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvYm9mL3RyYWMvd2lraS9XaWtpU3RhcnQpDQoNCkxhcmdlLVNjYWxlIE1l YXN1cmVtZW50IG9mIEJyb2FkYmFuZCBQZXJmb3JtYW5jZSAoTE1BUCkNCg0KICogICBTdGF0dXM6 IFJlcXVlc3RlZC4NCiAqICAgVHlwZTogV0cgZm9ybWluZyAoMXN0IGF0dGVtcHQpLg0KICogICBS ZXNwb25zaWJsZSBBRDogQmVub2l0IENsYWlzZSwgT1BTDQogKiAgIEJPRiBDaGFpcnM6IERhbiBS b21hc2NhbnUgKOKAi2Ryb21hc2NhQGF2YXlhLmNvbTxtYWlsdG86ZHJvbWFzY2FAYXZheWEuY29t PiksIEFsIE1vcnRvbiAo4oCLYWNtb3J0b25AYXR0LmNvbTxtYWlsdG86YWNtb3J0b25AYXR0LmNv bT4pKQ0KICogICBBdHRlbmRhbmNlOiA4MA0KICogICBTZXNzaW9uIGxlbmd0aCAxMjAgbWludXRl cw0KICogICBDb25mbGljdHMgdG8gYXZvaWQ6DQpGaXJzdCBsZXZlbCBwcmlvcml0eTogSVBQTSwg RUNSSVQsIEJNV0csIE9QU0FSRUEvT1BTQVdHLCBJUEZJWCwgRU1BTiwgTkVUQ09ORiwgTkVUTU9E LCBYUkJMT0NLLCBESU1FLCBSQURFWFQsIFNBQ00gQm9GLCBUU1ZBUkVBLCBBTFRPLCBDRE5JLCBO RlNWNCwgUFBTUCwgVFNWV0cNClNlY29uZCBsZXZlbCBwcmlvcml0eTogQ09ORVgNCiAqICAgRG9l cyBpdCByZXF1aXJlIFdlYkVYPyBObw0KICogICBEb2VzIGl0IHJlcXVpcmUgTWVldGVjaG8/IE5v DQogKiAgIE1haWxpbmcgbGlzdDog4oCLIOKAi2xtYXBAaWVmdC5vcmc8bWFpbHRvOmxtYXBAaWVm dC5vcmc+DQogKiAgIExpc3QgYXJjaGl2ZTog4oCL4oCLaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL2xtYXAvY3VycmVudC9tYWlsbGlzdC5odG1sPGh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9sbWFwL2N1cnJlbnQvbWFpbGxpc3QuaHRtbD4NCiAqICAgRG9j dW1lbnRzOiBkcmFmdC1zY2h1bHpyaW5uZS1sbWFwLXJlcXVpcmVtZW50czxodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2h1bHpyaW5uZS1sbWFwLXJlcXVpcmVtZW50cz4sIGRyYWZ0 LWxpbnNuZXItbG1hcC11c2UtY2FzZXM8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bGluc25lci1sbWFwLXVzZS1jYXNlcz4sIGFuZCBkcmFmdC1tb3J0b24taXBwbS1sbWFwLXBhdGgt MDA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbW9ydG9uLWlwcG0tbG1hcC1wYXRo LTAwPg0KVGhlIGNoYWlycyBoYXZlIGJlZW4gY2hvc2VuIGJhc2VkIG9uIHRoZWlyIGxldmVscyBv ZiBleHBlcnRpc2UvZXhwZXJpZW5jZSBpbiBPUFMsIG1lYXN1cmVtZW50LCBhbmQgSUVURi4gVGhh bmtzIERhbiBhbmQgQWwgZm9yIGFjY2VwdGluZyB0aGUgY2hhaXIgcG9zaXRpb25zLg0KDQpHb2Fs cyBmb3IgdGhpcyBCb0Y6DQotIGJlIGluIHN5bmNoIG9uIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBh bmQgdXNlIGNhc2VzDQotIHVuZGVyc3RhbmQgd2hhdCB0aGUgZXhpc3RpbmcgSUVURiBwcm90b2Nv bHMgYW5kIGRhdGEgbW9kZWxzIChJUFBNLCBORVRDT05GL1lBTkcsIElQRklYLCBldGMuLi4pIGNh biBvciBjYW4ndCBkbyBmb3IgTE1BUC4gVGhpcyB3aWxsIGNlcnRhaW5seSByZXF1aXJlIGEgbGl0 dGxlIG9mIGVkdWNhdGlvbiBkaXJlY3RseSBmcm9tIHRoZSBleHBlcnRzIGR1cmluZyB0aGUgQm9G Lg0KLSBjbGFyaWZ5IHdoYXQncyBpbiBzY29wZSBvciBub3QgZm9yIExNQVANCg0KRmluYWxseSwg bGV0IG1lIHN0cmVzcyB0aGF0IGEgcHJvcGVyIHByZXBhcmF0aW9uIGlzIGtleSB0byBhIEJvRiBz dWNjZXNzLg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTQzNCAgIkNvbnNpZGVyYXRp b25zIGZvciBIYXZpbmcgYSBTdWNjZXNzZnVsIEJpcmRzLW9mLWEtRmVhdGhlciAoQk9GKSBTZXNz aW9uIiBpcyBhIGZpcnN0IGdvb2Qgc3RlcC4NCg0KUmVnYXJkcywgTWFydGluIFN0aWVtZXJsaW5n IChUU1YpIGFuZCBCZW5vaXQgQ2xhaXNlIChPUFMpDQoNCg== --_000_94C682931C08B048B7A8645303FDC9F36EB3C8270APUEXCB1Bnante_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIj48SEVBRD4NCjxNRVRBIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+ DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE4NzAyIj48 IS0tW2lmICFtc29dPg0KPFNUWUxFPnZcOiogew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjVk1M KQ0KfQ0Kb1w6KiB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQp3XDoqIHsNCglC RUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0NCi5zaGFwZSB7DQoJQkVIQVZJT1I6IHVybCgj ZGVmYXVsdCNWTUwpDQp9DQo8L1NUWUxFPg0KPCFbZW5kaWZdLS0+DQo8U1RZTEU+QGZvbnQtZmFj ZSB7DQoJZm9udC1mYW1pbHk6IENhbGlicmk7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWls eTogVGFob21hOw0KfQ0KQHBhZ2UgV29yZFNlY3Rpb24xIHtzaXplOiA4LjVpbiAxMS4waW47IG1h cmdpbjogMS4waW4gMS4waW4gMS4waW4gMS4waW47IH0NClAuTXNvTm9ybWFsIHsNCglNQVJHSU46 IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsgQ09M T1I6IGJsYWNrOyBGT05ULVNJWkU6IDEycHQNCn0NCkxJLk1zb05vcm1hbCB7DQoJTUFSR0lOOiAw aW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7IENPTE9S OiBibGFjazsgRk9OVC1TSVpFOiAxMnB0DQp9DQpESVYuTXNvTm9ybWFsIHsNCglNQVJHSU46IDBp biAwaW4gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsgQ09MT1I6 IGJsYWNrOyBGT05ULVNJWkU6IDEycHQNCn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQt REVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFOLk1z b0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBt c28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRF WFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFO Lk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046 IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0KUCB7DQoJRk9OVC1GQU1JTFk6 ICJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7IENPTE9SOiBibGFjazsgTUFSR0lOLUxFRlQ6IDBp bjsgRk9OVC1TSVpFOiAxMnB0OyBNQVJHSU4tUklHSFQ6IDBpbjsgbXNvLXN0eWxlLXByaW9yaXR5 OiA5OTsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1 dG8NCn0NClAuTXNvQWNldGF0ZSB7DQoJTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6 ICJUYWhvbWEiLCJzYW5zLXNlcmlmIjsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDhwdDsgbXNv LXN0eWxlLXByaW9yaXR5OiA5OTsgbXNvLXN0eWxlLWxpbms6ICJCYWxsb29uIFRleHQgQ2hhciIN Cn0NCkxJLk1zb0FjZXRhdGUgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiAi VGFob21hIiwic2Fucy1zZXJpZiI7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA4cHQ7IG1zby1z dHlsZS1wcmlvcml0eTogOTk7IG1zby1zdHlsZS1saW5rOiAiQmFsbG9vbiBUZXh0IENoYXIiDQp9 DQpESVYuTXNvQWNldGF0ZSB7DQoJTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6ICJU YWhvbWEiLCJzYW5zLXNlcmlmIjsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDhwdDsgbXNvLXN0 eWxlLXByaW9yaXR5OiA5OTsgbXNvLXN0eWxlLWxpbms6ICJCYWxsb29uIFRleHQgQ2hhciINCn0N ClNQQU4uaWNvbiB7DQoJbXNvLXN0eWxlLW5hbWU6IGljb24NCn0NClNQQU4uRW1haWxTdHlsZTE5 IHsNCglGT05ULUZBTUlMWTogIkNvdXJpZXIgTmV3IjsgQ09MT1I6IHdpbmRvd3RleHQ7IG1zby1z dHlsZS10eXBlOiBwZXJzb25hbA0KfQ0KU1BBTi5FbWFpbFN0eWxlMjEgew0KCUZPTlQtRkFNSUxZ OiAiQ291cmllciBOZXciOyBDT0xPUjogd2luZG93dGV4dDsgbXNvLXN0eWxlLXR5cGU6IHBlcnNv bmFsLXJlcGx5DQp9DQpTUEFOLkJhbGxvb25UZXh0Q2hhciB7DQoJRk9OVC1GQU1JTFk6ICJUYWhv bWEiLCJzYW5zLXNlcmlmIjsgQ09MT1I6IGJsYWNrOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5OyBt c28tc3R5bGUtbGluazogIkJhbGxvb24gVGV4dCI7IG1zby1zdHlsZS1uYW1lOiAiQmFsbG9vbiBU ZXh0IENoYXIiDQp9DQouTXNvQ2hwRGVmYXVsdCB7DQoJRk9OVC1TSVpFOiAxMHB0OyBtc28tc3R5 bGUtdHlwZTogZXhwb3J0LW9ubHkNCn0NCkRJVi5Xb3JkU2VjdGlvbjEgew0KCXBhZ2U6IFdvcmRT ZWN0aW9uMQ0KfQ0KT0wgew0KCU1BUkdJTi1CT1RUT006IDBpbg0KfQ0KVUwgew0KCU1BUkdJTi1C T1RUT006IDBpbg0KfQ0KPC9TVFlMRT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+PC9IRUFEPg0KPEJPRFkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgYmdDb2xv cj13aGl0ZSB2TGluaz1wdXJwbGU+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFz cz04OTQyODMwMTItMjEwMjIwMTM+PEZPTlQgY29sb3I9IzAwMDBmZiANCnNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+UmUtLDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249 bGVmdD48U1BBTiBjbGFzcz04OTQyODMwMTItMjEwMjIwMTM+PEZPTlQgY29sb3I9IzAwMDBmZiAN CnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxE SVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTg5NDI4MzAxMi0yMTAyMjAxMz48Rk9O VCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5kcmFmdC1ib3VjYWRh aXItKiBpbmNsdWRlcyBzb21lIHBvaW50cyBub3QgbWVudGlvbmVkIA0KaW4gb3RoZXIgZHJhZnQt Ki1sbWFwJm5ic3A7SS1EcyBzdWNoIHRoZSBEU0NQIG1hcmtpbmcgaW5oZXJpdGFuY2U6IHNvbWUg b2YgdGhlIA0Kc2VydmljZXMgd2UgYXJlIGRlcGxveWluZyBkbyBub3QgdHJ1c3QgdGhlIG1hcmtp bmcgc2V0IGJ5IHRoZSBhcHBsaWNhdGlvbiBidXQgDQp0aGVyZSZuYnNwO2FyZSBzcGVjaWZpYyBt b2R1bGVzIHdoaWNoIGFyZSZuYnNwO2VuYWJsZWQgaW4gdGhlIENQRSBmb3IgaW5zdGFuY2UuIA0K Q29uZHVjdGluZyBhIHNldCBvZiBtZWFzdXJlbWVudCBmb3IgdGhvc2Ugc2VydmljZSB3aWxsIG5l ZWQgdG8gYmUgZGVzaWduZWQgdG8gYmUgDQpjb21wbGlhbnQgd2l0aCBzdWNoIGNvbnN0cmFpbnQu Jm5ic3A7PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFO IGNsYXNzPTg5NDI4MzAxMi0yMTAyMjAxMz48Rk9OVCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9ODk0MjgzMDEyLTIxMDIyMDEzPjxGT05UIGNvbG9yPSMw MDAwZmYgDQpzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkkgY2FuIGxpc3QgYW5vdGhlciZuYnNw O2l0ZW0gc3VjaCBhcyB0aGUgY29tcGF0aWJpbGl0eSANCndpdGggYSZuYnNwO211bHRpLWFkZHJl c3NlZCBzZXJ2aWNlIGRlc2lnbiBzY2hlbWUmbmJzcDsoaW4gd2hpY2gmbmJzcDsgZGlzdGluY3Qg DQpJUCBhZGRyZXNzZXMmbmJzcDthcmUgYXNzaWduZWQmbmJzcDtmb3IgZWFjaCBzdWJzY3JpYmVk IHNlcnZpY2UpOiBwYWNrZXRzIGlzc3VlZCANCmZyb20mbmJzcDthJm5ic3A7bWVhc3VyZW1lbnQg YWdlbnQgKGxvY2F0ZWQgYmVoaW5kJm5ic3A7dGhlIENQRSkgd2lsbCBuZWVkIHRvIGJlIA0KYm91 bmQgdG8gdGhlIGFwcHJvcHJpYXRlIHNlcnZpY2Utc3BlY2lmaWMgY2hhbm5lbCwgZXRjLjwvRk9O VD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz04OTQy ODMwMTItMjEwMjIwMTM+PEZPTlQgY29sb3I9IzAwMDBmZiANCnNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0 PjxTUEFOIGNsYXNzPTg5NDI4MzAxMi0yMTAyMjAxMz48Rk9OVCBjb2xvcj0jMDAwMGZmIA0Kc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5DaGVlcnMsPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYg ZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTg5NDI4MzAxMi0yMTAyMjAxMz48Rk9OVCBj b2xvcj0jMDAwMGZmIA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5NZWQ8L0ZPTlQ+PC9TUEFO PjwvRElWPjxCUj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRFUi1MRUZUOiAjMDAwMGZmIDJw eCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdI VDogMHB4IiANCmRpcj1sdHI+DQogIDxESVYgZGlyPWx0ciBsYW5nPWZyIGNsYXNzPU91dGxvb2tN ZXNzYWdlSGVhZGVyIGFsaWduPWxlZnQ+DQogIDxIUiB0YWJJbmRleD0tMT4NCiAgPEZPTlQgc2l6 ZT0yIGZhY2U9VGFob21hPjxCPkRlJm5ic3A7OjwvQj4gTU9SVE9OIEpSLiwgQUxGUkVEIChBTCkg DQogIFttYWlsdG86YWNtb3J0b25AYXR0LmNvbV0gPEJSPjxCPkVudm95w6kmbmJzcDs6PC9CPiBq ZXVkaSAyMSBmw6l2cmllciAyMDEzIA0KICAxMzoyOTxCUj48Qj7DgCZuYnNwOzo8L0I+IEJPVUNB REFJUiBNb2hhbWVkIE9MTkMvT0xOOyBCZW5vaXQgQ2xhaXNlOyANCiAgbG1hcEBpZXRmLm9yZzsg Um9tYXNjYW51LCBEYW4gKERhbikgKGRyb21hc2NhQGF2YXlhLmNvbSk8QlI+PEI+Q2MmbmJzcDs6 PC9CPiANCiAgSkFDUVVFTkVUIENocmlzdGlhbiBPTE5DL09MTjxCUj48Qj5PYmpldCZuYnNwOzo8 L0I+IFJFOiBEcmFmdCBBZ2VuZGEgW3dhczogDQogIExNQVAgQm9GIGhhcyBiZWVuIGFwcHJvdmVk Ll08QlI+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJViBjbGFzcz1Xb3Jk U2VjdGlvbjE+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1TSVpFOiAxMHB0Ij5I aSANCiAgTWVkLDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxT UEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiB3aW5kb3d0 ZXh0OyBGT05ULVNJWkU6IDEwcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l dyc7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiPlllcywgDQogIG9uZSBwb2lu dCB5b3UndmUgbWFkZSB0aGF0IChJTU8pIHNob3VsZCBiZSBhZGRyZXNzZWQgPG86cD48L286cD48 L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZB TUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBwdCI+ d2l0aGluIA0KICB0aGUgY3VycmVudCBjb25zdHJhaW50cyBvZiB0aGUgRnJhbWV3b3JrIGRyYWZ0 LDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05U LVNJWkU6IDEwcHQiPmlzIA0KICBhYm91dCB0ZXN0aW5nIGNyaXRpY2FsIHNlcnZpY2VzIHdoaWNo IHRoZSA8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiAN CiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogd2luZG93dGV4dDsg Rk9OVC1TSVpFOiAxMHB0Ij5hY2Nlc3MgDQogIElTUCBjb250cmFjdHMgZm9yLCBzbyBkb2VzIG5v dCBvd24gaXRzZWxmLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiB3aW5k b3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiPllvdXIgDQogIGV4YW1wbGUsIEROUyB0ZXN0aW5nLCBp cyBwYXJ0aWN1bGFybHkgcmVsZXZhbnQ8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBD T0xPUjogd2luZG93dGV4dDsgRk9OVC1TSVpFOiAxMHB0Ij5zaW5jZSANCiAgZXZlcnkgdXNlciBw ZXJmb3JtcyBxdWVyaWVzIHRoYXQgY3Jvc3Mgb3JnLiBib3VuZGFyaWVzLDxvOnA+PC9vOnA+PC9T UEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1J TFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiPmFu ZCBzbyANCiAgd291bGQgdGhlIG1lYXN1cmVtZW50IHBhdGggZm9yIEROUyByZXNwb25zZSB0aW1l LjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05U LVNJWkU6IDEwcHQiPkhvd2V2ZXIsIA0KICBhbGwgdGhlIG1lYXN1cmVtZW50IGluZnJhc3RydWN0 dXJlIHdvdWxkIHJlbWFpbjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiB3 aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiPndpdGhpbiANCiAgYSBzaW5nbGUgb3JnYW5pemF0 aW9uJ3MgZG9tYWluLCBhbmQgd2hpbGUgSSB0aGluayB0aGlzPG86cD48L286cD48L1NQQU4+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Nv dXJpZXIgTmV3JzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBwdCI+bWF0Y2hlcyAN CiAgdGhlIGN1cnJlbnQgY29uc3RyYWludCwgaXQncyBjZXJ0YWlubHkgd29ydGggaW5jbHVkaW5n LjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05U LVNJWkU6IDEwcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9S OiB3aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiPkFmdGVyIA0KICByZXZpZXdpbmcgdGhlIFVz ZSBDYXNlIERyYWZ0LCBwYXJ0aWN1bGFybHkgdGhlIGRldGFpbGVkIA0KICBJU1A8bzpwPjwvbzpw PjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQt RkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1TSVpFOiAxMHB0 Ij5Vc2UgDQogIENhc2UsIGFuZCB0aGUgRnJhbWV3b3JrIERyYWZ0IGl0c2VsZiwgY2FuIHlvdSBw b2ludCBvdXQ8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BB TiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogd2luZG93dGV4 dDsgRk9OVC1TSVpFOiAxMHB0Ij5hZGRpdGlvbmFsIA0KICBjb25zaWRlcmF0aW9ucyBub3QteWV0 IGRlc2NyaWJlZCAoYnV0IHdpdGhpbiB0aGUgY3VycmVudCANCjxvOnA+PC9vOnA+PC9TUEFOPjwv UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdD b3VyaWVyIE5ldyc7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiPmNvbnN0cmFp bnRzKT88bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiAN CiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogd2luZG93dGV4dDsg Rk9OVC1TSVpFOiAxMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBD T0xPUjogd2luZG93dGV4dDsgRk9OVC1TSVpFOiAxMHB0Ij50aGFua3MsPG86cD48L286cD48L1NQ QU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlM WTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBwdCI+QWw8 bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5 bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1T SVpFOiAxMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05v cm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjog d2luZG93dGV4dDsgRk9OVC1TSVpFOiAxMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+ DQogIDxESVYgDQogIHN0eWxlPSJCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxF RlQ6IGJsdWUgMS41cHQgc29saWQ7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDog NHB0OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBCT1JERVIt UklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogMGluIj4NCiAgPERJVj4NCiAgPERJViAN CiAgc3R5bGU9IkJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVt IG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJ R0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1l ZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxT UEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6 IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBwdCI+RnJvbTo8L1NQQU4+PC9CPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IHdpbmRvd3Rl eHQ7IEZPTlQtU0laRTogMTBwdCI+IA0KICBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIFtt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0gDQogIDxCUj48Qj5TZW50OjwvQj4g VGh1cnNkYXksIEZlYnJ1YXJ5IDIxLCAyMDEzIDE6MzUgQU08QlI+PEI+VG86PC9CPiBNT1JUT04g SlIuLCANCiAgQUxGUkVEIChBTCk7IEJlbm9pdCBDbGFpc2U7IGxtYXBAaWV0Zi5vcmc8QlI+PEI+ Q2M6PC9CPiBKQUNRVUVORVQgQ2hyaXN0aWFuIA0KICBPTE5DL09MTjxCUj48Qj5TdWJqZWN0Ojwv Qj4gUkU6IERyYWZ0IEFnZW5kYSBbd2FzOiBMTUFQIEJvRiBoYXMgYmVlbiANCiAgYXBwcm92ZWQu XTxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj48L0RJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0 eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6IGJsdWU7IEZPTlQtU0laRTog MTBwdCI+RGVhciANCiAgQWwsPC9TUEFOPjxTUEFOIHN0eWxlPSJDT0xPUjogd2luZG93dGV4dCI+ PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHls ZT0iQ09MT1I6IHdpbmRvd3RleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l dyc7IENPTE9SOiBibHVlOyBGT05ULVNJWkU6IDEwcHQiPldvdWxkIGl0IGJlIA0KICBwb3NzaWJs ZSB0aGUgZm9sbG93aW5nIHNsb3QgPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iQ09MT1I6IHdpbmRv d3RleHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFO IA0Kc3R5bGU9IkNPTE9SOiB3aW5kb3d0ZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291 cmllciBOZXcnOyBDT0xPUjogYmx1ZTsgRk9OVC1TSVpFOiAxMHB0Ij4iNS4gDQogIEZyYW1ld29y azogUHJvYmxlbSBTdGF0ZW1lbnQsIElTUCBVc2UgY2FzZSwgR2FwcywgUmVxdWlyZW1lbnRzIC0g UGhpbCBFYXJkbGV5IA0KICAtIDE1IG1pbiI8L1NQQU4+PFNQQU4gc3R5bGU9IkNPTE9SOiB3aW5k b3d0ZXh0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BB TiANCnN0eWxlPSJDT0xPUjogd2luZG93dGV4dCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Nv dXJpZXIgTmV3JzsgQ09MT1I6IGJsdWU7IEZPTlQtU0laRTogMTBwdCI+dG8gDQogIGluY2x1ZGUm bmJzcDtzb21lIG9mIHRoZSBuZXR3b3JrIHByb3ZpZGVyJyByZXF1aXJlbWVudHMgYW5kIGlzc3Vl cyBkaXNjdXNzZWQgDQogIGluIGRyYWZ0LWJvdWNhZGFpci1sbWFwLWNvbnNpZGVyYXRpb25zPzwv U1BBTj48U1BBTiANCiAgc3R5bGU9IkNPTE9SOiB3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvU1BB Tj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJDT0xPUjogd2luZG93 dGV4dCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6IGJsdWU7 IEZPTlQtU0laRTogMTBwdCI+VGhhbmtzLjwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkNPTE9SOiB3 aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48 U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogYmx1ZTsg Rk9OVC1TSVpFOiAxMHB0Ij5DaGVlcnMsPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iQ09MT1I6IHdp bmRvd3RleHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxT UEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiBibHVlOyBG T05ULVNJWkU6IDEwcHQiPk1lZDwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkNPTE9SOiB3aW5kb3d0 ZXh0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiAN CnN0eWxlPSJDT0xPUjogd2luZG93dGV4dCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9QPg0K ICA8QkxPQ0tRVU9URSANCiAgc3R5bGU9IkJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JE RVItTEVGVDogYmx1ZSAxLjVwdCBzb2xpZDsgUEFERElORy1CT1RUT006IDBpbjsgTUFSR0lOOiA1 cHQgMGluIDVwdCAzLjc1cHQ7IFBBRERJTkctTEVGVDogNHB0OyBQQURESU5HLVJJR0hUOiAwaW47 IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURE SU5HLVRPUDogMGluIj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogICAgc3R5bGU9 IkNPTE9SOiB3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogICAgPERJ ViBzdHlsZT0iVEVYVC1BTElHTjogY2VudGVyIiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVy PjxTUEFOIA0KICAgIHN0eWxlPSJDT0xPUjogd2luZG93dGV4dCIgbGFuZz1GUj4NCiAgICA8SFIg YWxpZ249Y2VudGVyIFNJWkU9MiB3aWR0aD0iMTAwJSI+DQogICAgPC9TUEFOPjwvRElWPg0KICAg IDxQIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0IiBjbGFzcz1Nc29Ob3JtYWw+PEI+PFNQQU4g DQogICAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiB3 aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiIA0KICAgIGxhbmc9RlI+RGUmbmJzcDs6PC9TUEFO PjwvQj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlm JzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBwdCIgDQogICAgbGFuZz1GUj4gbG1h cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bG1hcC1ib3VuY2VzQGlldGYub3JnXSA8Qj5EZSBs YSBwYXJ0IA0KICAgIGRlPC9CPiBNT1JUT04gSlIuLCBBTEZSRUQgKEFMKTxCUj48Qj5FbnZvecOp Jm5ic3A7OjwvQj4gbWFyZGkgMTkgZsOpdnJpZXIgMjAxMyANCiAgICAyMDowNTxCUj48Qj7DgCZu YnNwOzo8L0I+IEJlbm9pdCBDbGFpc2U7IGxtYXBAaWV0Zi5vcmc8QlI+PEI+T2JqZXQmbmJzcDs6 PC9CPiANCiAgICBbbG1hcF0gRHJhZnQgQWdlbmRhIFt3YXM6IExNQVAgQm9GIGhhcyBiZWVuIGFw cHJvdmVkLl08L1NQQU4+PFNQQU4gDQogICAgc3R5bGU9IkNPTE9SOiB3aW5kb3d0ZXh0IiBsYW5n PUZSPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4g DQogICAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogd2luZG93dGV4 dDsgRk9OVC1TSVpFOiAxMHB0Ij5MTUFQIA0KICAgIGxpc3QsPG86cD48L286cD48L1NQQU4+PC9Q Pg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdDb3VyaWVyIE5ldyc7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQog ICAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogd2luZG93dGV4dDsg Rk9OVC1TSVpFOiAxMHB0Ij5XZSANCiAgICBoYXZlIHByZXBhcmVkIGEgZHJhZnQgQm9GIGFnZW5k YSw8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0K ICAgIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6IHdpbmRvd3RleHQ7 IEZPTlQtU0laRTogMTBwdCI+YW5kIA0KICAgIG5vdyB0aGF0IG91ciBwb3N0aW5nIHJpZ2h0cyBh cmUgaW5zdGFsbGVkLCA8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9y bWFsPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6 IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBwdCI+aXQgDQogICAgY2FuIGJlIGZvdW5kIHdpdGgg YWxsIG1lZXRpbmcgbWF0ZXJpYWxzOiA8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogICAgPFAgY2xh c3M9TXNvTm9ybWFsPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3 JzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBwdCI+PEEgDQogICAgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Ni9hZ2VuZGEvYWdlbmRhLTg2LWxtYXAiPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODYvYWdlbmRhL2FnZW5kYS04Ni1sbWFwPC9B PjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQog ICAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogd2luZG93dGV4dDsg Rk9OVC1TSVpFOiAxMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogICAgPFAgY2xh c3M9TXNvTm9ybWFsPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3 JzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBwdCI+V2UgDQogICAgYmVsaWV2ZSB3 ZSBoYXZlIGVtYnJhY2VkIHRoZSB0c3VuYW1pIG9mIDAwIGRyYWZ0czxvOnA+PC9vOnA+PC9TUEFO PjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1TSVpFOiAxMHB0Ij5h bmQgDQogICAgZm91bmQgYWxsIHRob3NlIHRoYXQgYXJlIHJlbGV2YW50LCA8bzpwPjwvbzpwPjwv U1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICAgIHN0eWxlPSJGT05U LUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBw dCI+YW5kIA0KICAgIGNvbnRhY3RlZCBhbGwtMSBvZiB0aGUgcHJlc2VudGVycy48bzpwPjwvbzpw PjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICAgIHN0eWxlPSJG T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTog MTBwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1h bD48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiB3 aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiPkNvbW1lbnRzIA0KICAgIHRvIHRoZSBsaXN0LCBw bGVhc2UsPG86cD48L286cD48L1NQQU4+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BB TiANCiAgICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiB3aW5kb3d0 ZXh0OyBGT05ULVNJWkU6IDEwcHQiPkRhbiANCiAgICBhbmQgQWw8bzpwPjwvbzpwPjwvU1BBTj48 L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULUZBTUlM WTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBwdCI+Ym9m IA0KICAgIGNvLWNoYWlyczxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xP Ujogd2luZG93dGV4dDsgRk9OVC1TSVpFOiAxMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48 L1A+DQogICAgPERJViANCiAgICBzdHlsZT0iQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJP UkRFUi1MRUZUOiBibHVlIDEuNXB0IHNvbGlkOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5H LUxFRlQ6IDRwdDsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsg Qk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDBpbiI+DQogICAgPERJVj4N CiAgICA8RElWIA0KICAgIHN0eWxlPSJCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVS LUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBp bjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9S REVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQogICAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxCPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3Nh bnMtc2VyaWYnOyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1TSVpFOiAxMHB0Ij5Gcm9tOjwvU1BB Tj48L0I+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJp Zic7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiPiANCiAgICBsbWFwLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIDxCPk9uIEJlaGFsZiBP ZiANCiAgICA8L0I+QmVub2l0IENsYWlzZTxCUj48Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBGZWJy dWFyeSAwNiwgMjAxMyAxMDowMCANCiAgICBBTTxCUj48Qj5Ubzo8L0I+IGxtYXBAaWV0Zi5vcmc8 QlI+PEI+U3ViamVjdDo8L0I+IFtsbWFwXSBMTUFQIEJvRiBoYXMgYmVlbiANCiAgICBhcHByb3Zl ZC48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+DQogICAgPFAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD5EZWFyIGFs bCw8bzpwPjwvbzpwPjwvUD4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48QlI+ TGV0IHVzIHNoYXJlIHRoZSBnb29kIG5ld3MuIFRoZSBJRVNHIGFwcHJvdmVkIHRoaXMgDQogICAg Qm9GLjxCUj5FdmVuIGlmIGl0IHdhcyBpbml0aWFsbHkgcmVxdWVzdGVkIGluIFRTViwgdGhlIEJv RiB3aWxsIGJlIHNwb25zb3JlZCANCiAgICBpbiBPUFMgYnkgQmVub2l0IENsYWlzZS48QlI+VGhl IEJvRiBpbmZvcm1hdGlvbiBoYXZlIGJlZW4gdXBkYXRlZCAoU2VlIDxBIA0KICAgIGhyZWY9Imh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2JvZi90cmFjL3dpa2kvV2lraVN0YXJ0Ij5odHRwOi8v dHJhYy50b29scy5pZXRmLm9yZy9ib2YvdHJhYy93aWtpL1dpa2lTdGFydDwvQT4pPG86cD48L286 cD48L1A+DQogICAgPFA+PFNUUk9ORz5MYXJnZS1TY2FsZSBNZWFzdXJlbWVudCBvZiBCcm9hZGJh bmQgUGVyZm9ybWFuY2UgDQogICAgKExNQVApPC9TVFJPTkc+PG86cD48L286cD48L1A+DQogICAg PFVMIHR5cGU9ZGlzYz4NCiAgICAgIDxMSSANCiAgICAgIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0bzsgbXNvLWxpc3Q6IGwwIGxldmVs MSBsZm8xIiANCiAgICAgIGNsYXNzPU1zb05vcm1hbD5TdGF0dXM6IFJlcXVlc3RlZC4gPG86cD48 L286cD4NCiAgICAgIDxMSSANCiAgICAgIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87 IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0bzsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xIiAN CiAgICAgIGNsYXNzPU1zb05vcm1hbD5UeXBlOiBXRyBmb3JtaW5nICgxc3QgYXR0ZW1wdCkuIDxv OnA+PC9vOnA+DQogICAgICA8TEkgDQogICAgICBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OiBh dXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG87IG1zby1saXN0OiBsMCBsZXZlbDEgbGZv MSIgDQogICAgICBjbGFzcz1Nc29Ob3JtYWw+UmVzcG9uc2libGUgQUQ6IEJlbm9pdCBDbGFpc2Us IE9QUyA8bzpwPjwvbzpwPg0KICAgICAgPExJIA0KICAgICAgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvOyBtc28tbGlzdDogbDAgbGV2 ZWwxIGxmbzEiIA0KICAgICAgY2xhc3M9TXNvTm9ybWFsPkJPRiBDaGFpcnM6IERhbiBSb21hc2Nh bnUgKDxBIA0KICAgICAgaHJlZj0ibWFpbHRvOmRyb21hc2NhQGF2YXlhLmNvbSI+PFNQQU4gDQog ICAgICBjbGFzcz1pY29uPuKAizwvU1BBTj5kcm9tYXNjYUBhdmF5YS5jb208L0E+KSwgQWwgTW9y dG9uICg8QSANCiAgICAgIGhyZWY9Im1haWx0bzphY21vcnRvbkBhdHQuY29tIj48U1BBTiANCiAg ICAgIGNsYXNzPWljb24+4oCLPC9TUEFOPmFjbW9ydG9uQGF0dC5jb208L0E+KSkgPG86cD48L286 cD4NCiAgICAgIDxMSSANCiAgICAgIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1z by1tYXJnaW4tYm90dG9tLWFsdDogYXV0bzsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xIiANCiAg ICAgIGNsYXNzPU1zb05vcm1hbD5BdHRlbmRhbmNlOiA4MCA8bzpwPjwvbzpwPg0KICAgICAgPExJ IA0KICAgICAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0 b20tYWx0OiBhdXRvOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzEiIA0KICAgICAgY2xhc3M9TXNv Tm9ybWFsPlNlc3Npb24gbGVuZ3RoIDEyMCBtaW51dGVzIDxvOnA+PC9vOnA+DQogICAgICA8TEkg DQogICAgICBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRv bS1hbHQ6IGF1dG87IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSIgDQogICAgICBjbGFzcz1Nc29O b3JtYWw+Q29uZmxpY3RzIHRvIGF2b2lkOiA8QlI+Rmlyc3QgbGV2ZWwgcHJpb3JpdHk6IElQUE0s IEVDUklULCANCiAgICAgIEJNV0csIE9QU0FSRUEvT1BTQVdHLCBJUEZJWCwgRU1BTiwgTkVUQ09O RiwgTkVUTU9ELCBYUkJMT0NLLCBESU1FLCBSQURFWFQsIA0KICAgICAgU0FDTSBCb0YsIFRTVkFS RUEsIEFMVE8sIENETkksIE5GU1Y0LCBQUFNQLCBUU1ZXRyA8QlI+U2Vjb25kIGxldmVsIA0KICAg ICAgcHJpb3JpdHk6IENPTkVYIDxvOnA+PC9vOnA+DQogICAgICA8TEkgDQogICAgICBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG87IG1z by1saXN0OiBsMCBsZXZlbDEgbGZvMSIgDQogICAgICBjbGFzcz1Nc29Ob3JtYWw+RG9lcyBpdCBy ZXF1aXJlIFdlYkVYPyBObyA8bzpwPjwvbzpwPg0KICAgICAgPExJIA0KICAgICAgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvOyBtc28t bGlzdDogbDAgbGV2ZWwxIGxmbzEiIA0KICAgICAgY2xhc3M9TXNvTm9ybWFsPkRvZXMgaXQgcmVx dWlyZSBNZWV0ZWNobz8gTm8gPG86cD48L286cD4NCiAgICAgIDxMSSANCiAgICAgIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0bzsgbXNv LWxpc3Q6IGwwIGxldmVsMSBsZm8xIiANCiAgICAgIGNsYXNzPU1zb05vcm1hbD5NYWlsaW5nIGxp c3Q6IOKAiyA8QSBocmVmPSJtYWlsdG86bG1hcEBpZWZ0Lm9yZyI+PFNQQU4gDQogICAgICBjbGFz cz1pY29uPuKAizwvU1BBTj5sbWFwQGllZnQub3JnPC9BPiA8bzpwPjwvbzpwPg0KICAgICAgPExJ IA0KICAgICAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0 b20tYWx0OiBhdXRvOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzEiIA0KICAgICAgY2xhc3M9TXNv Tm9ybWFsPkxpc3QgYXJjaGl2ZTog4oCLPEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvbG1hcC9jdXJyZW50L21haWxsaXN0Lmh0bWwiPjxTUEFOIA0K ICAgICAgY2xhc3M9aWNvbj7igIs8L1NQQU4+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL2xtYXAvY3VycmVudC9tYWlsbGlzdC5odG1sPC9BPiANCiAgICAgIDxvOnA+PC9vOnA+ DQogICAgICA8TEkgDQogICAgICBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28t bWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG87IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSIgDQogICAg ICBjbGFzcz1Nc29Ob3JtYWw+RG9jdW1lbnRzOiA8QSANCiAgICAgIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaHVsenJpbm5lLWxtYXAtcmVxdWlyZW1lbnRzIj5kcmFm dC1zY2h1bHpyaW5uZS1sbWFwLXJlcXVpcmVtZW50czwvQT4sIA0KICAgICAgPEEgDQogICAgICBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saW5zbmVyLWxtYXAtdXNlLWNh c2VzIj5kcmFmdC1saW5zbmVyLWxtYXAtdXNlLWNhc2VzPC9BPiwgDQogICAgICBhbmQgPEEgDQog ICAgICBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tb3J0b24taXBwbS1s bWFwLXBhdGgtMDAiPmRyYWZ0LW1vcnRvbi1pcHBtLWxtYXAtcGF0aC0wMDwvQT4gDQogICAgICA8 bzpwPjwvbzpwPjwvTEk+PC9VTD4NCiAgICA8UCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMTJwdCIg Y2xhc3M9TXNvTm9ybWFsPlRoZSBjaGFpcnMgaGF2ZSBiZWVuIGNob3NlbiANCiAgICBiYXNlZCBv biB0aGVpciBsZXZlbHMgb2YgZXhwZXJ0aXNlL2V4cGVyaWVuY2UgaW4gT1BTLCBtZWFzdXJlbWVu dCwgYW5kIElFVEYuIA0KICAgIFRoYW5rcyBEYW4gYW5kIEFsIGZvciBhY2NlcHRpbmcgdGhlIGNo YWlyIHBvc2l0aW9ucy48QlI+PEJSPkdvYWxzIGZvciB0aGlzIA0KICAgIEJvRjo8QlI+LSBiZSBp biBzeW5jaCBvbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHVzZSBjYXNlczxCUj4tIHVuZGVy c3RhbmQgDQogICAgd2hhdCB0aGUgZXhpc3RpbmcgSUVURiBwcm90b2NvbHMgYW5kIGRhdGEgbW9k ZWxzIChJUFBNLCBORVRDT05GL1lBTkcsIElQRklYLCANCiAgICBldGMuLi4pIGNhbiBvciBjYW4n dCBkbyBmb3IgTE1BUC4gVGhpcyB3aWxsIGNlcnRhaW5seSByZXF1aXJlIGEgbGl0dGxlIG9mIA0K ICAgIGVkdWNhdGlvbiBkaXJlY3RseSBmcm9tIHRoZSBleHBlcnRzIGR1cmluZyB0aGUgQm9GLjxC Uj4tIGNsYXJpZnkgd2hhdCdzIGluIA0KICAgIHNjb3BlIG9yIG5vdCBmb3IgTE1BUDxCUj48QlI+ RmluYWxseSwgbGV0IG1lIHN0cmVzcyB0aGF0IGEgcHJvcGVyIA0KICAgIHByZXBhcmF0aW9uIGlz IGtleSB0byBhIEJvRiBzdWNjZXNzLiA8QlI+PEEgDQogICAgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNTQzNCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTQzNDwv QT4mbmJzcDsgDQogICAgIkNvbnNpZGVyYXRpb25zIGZvciBIYXZpbmcgYSBTdWNjZXNzZnVsIEJp cmRzLW9mLWEtRmVhdGhlciAoQk9GKSBTZXNzaW9uIiBpcyANCiAgICBhIGZpcnN0IGdvb2Qgc3Rl cC48QlI+PEJSPlJlZ2FyZHMsIE1hcnRpbiBTdGllbWVybGluZyAoVFNWKSBhbmQgQmVub2l0IA0K ICAgIENsYWlzZSAoT1BTKTxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgIDxQIA0KY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPjwvRElWPjwvQkxPQ0tRVU9URT48L0RJVj48L0RJ Vj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== --_000_94C682931C08B048B7A8645303FDC9F36EB3C8270APUEXCB1Bnante_-- From marcelo@it.uc3m.es Thu Feb 21 08:29: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 28F7321F878F for ; Thu, 21 Feb 2013 08:29:49 -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 Dzse6AJ6ySBN for ; Thu, 21 Feb 2013 08:29:48 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 6027721F886A for ; Thu, 21 Feb 2013 08:29:48 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B75338946FC for ; Thu, 21 Feb 2013 17:29:46 +0100 (CET) X-uc3m-safe: yes Received: from [10.0.1.7] (27.70.218.87.dynamic.jazztel.es [87.218.70.27]) (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 87EB1767032 for ; Thu, 21 Feb 2013 17:29:46 +0100 (CET) Message-ID: <51264B7B.7080403@it.uc3m.es> Date: Thu, 21 Feb 2013 17:29:47 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "lmap@ietf.org" References: <20130221161125.29818.79560.idtracker@ietfa.amsl.com> In-Reply-To: <20130221161125.29818.79560.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130221161125.29818.79560.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTHACL 134 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Thu, 21 Feb 2013 17:29:46 +0100 (CET) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19652.000 X-TM-AS-Result: No--12.097-7.0-31-1 X-imss-scan-details: No--12.097-7.0-31-1 Subject: [lmap] Fwd: I-D Action: draft-bagnulo-lmap-ipfix-01.txt 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, 21 Feb 2013 16:29:49 -0000 Hi, We have updated the draft to include security considerations, to inlcude a short intro to IPFIX and also the use of Option template to reduce overhead Regards, marcelo -------- Mensaje original -------- Asunto: I-D Action: draft-bagnulo-lmap-ipfix-01.txt Fecha: Thu, 21 Feb 2013 08:11:25 -0800 De: internet-drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An LMAP application for IPFIX Author(s) : Marcelo Bagnulo Brian Trammell Filename : draft-bagnulo-lmap-ipfix-01.txt Pages : 13 Date : 2013-02-21 Abstract: This document explores the possibility of using IPFIX to report test results from a Measurement Agent to a Collector, in the context of a large measurement platform. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bagnulo-lmap-ipfix There's also a htmlized version available at: http://tools.ietf.org/html/draft-bagnulo-lmap-ipfix-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-bagnulo-lmap-ipfix-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From alessandro.capello@telecomitalia.it Thu Feb 21 09:51:35 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 8E91921F8EC3 for ; Thu, 21 Feb 2013 09:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.881 X-Spam-Level: X-Spam-Status: No, score=0.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 GRC3E9JjZHb9 for ; Thu, 21 Feb 2013 09:51:34 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0553C21F8E84 for ; Thu, 21 Feb 2013 09:51:33 -0800 (PST) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 21 Feb 2013 18:51:29 +0100 Received: from GRFMBX702BA020.griffon.local ([10.188.101.11]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Thu, 21 Feb 2013 18:51:28 +0100 From: Capello Alessandro To: "lmap@ietf.org" Date: Thu, 21 Feb 2013 18:51:27 +0100 Thread-Topic: Inter-domain scenarios Thread-Index: Ac4QXBKUOgYW8pHTQ6a+gG72vXdICQ== Message-ID: <36A93B31228D3B49B691AD31652BCAE9A5ABB09410@GRFMBX702BA020.griffon.local> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] Inter-domain scenarios 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, 21 Feb 2013 17:51:35 -0000 Hi all, there are a couple of inter-domain scenarios that I consider interesting: 1) Measurements between devices managed by different organizations 2) An agreement between two organizations for the exchange of measurement r= equests/data (f.i. at the "controller level" if the controllers are able to= talk to each other; this could be useful also in case a single domain has = multiple controllers for scalability) With regard to inter-domain, the current I-Ds show different points of view= : - draft-boucadair-lmap-considerations seems to not exclude at least the fir= st scenario - draft-eardley-lmap-framework seems to exclude both cases ("...the expecta= tion is that inter-organization coordination is an out-of-band consideratio= n") - draft-linsner-lmap-use-cases seems to consider some inter-domain aspects = ("An operator may also want to monitor the performance of its suppliers, to= check whether they meet their SLA or to compare two suppliers if it is dua= l-sourcing. This could include its transit operator, CDNs, peering, video s= ource, local network provider") In my opinion the LMAP architecture and protocols should be (at least) flex= ible enough to not preclude the possibility to add these inter-domain scena= rios in the future. Regards, Alessandro Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From mlinsner@cisco.com Mon Feb 25 10:55: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 90B9421E80AA for ; Mon, 25 Feb 2013 10:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zecSuPR-hr2q for ; Mon, 25 Feb 2013 10:55:48 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B8BA821F9374 for ; Mon, 25 Feb 2013 10:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1771; q=dns/txt; s=iport; t=1361818548; x=1363028148; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=z1DwDB5vKDZ2rdhkC73u3yeqBrwAhfcwXYdD0CwkAOw=; b=QXF9DnZqVRkBI7yxoQnyi22zMW6DLz/rc0i4fCrKqX68f1NeFPFQXqqv xPZp09BvX23B0LX7i/CfUUTswN+RJqGUYDZH4ud6HyW2kcxj0qM/mi6L0 NvKztvxGeMddp+r2sViHUtwK8t+GINb+DJOuWSb2dNARREhGYoVGz4cbb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAEKyK1GQ/khR/2dsb2JhbABFgzhAvV+BBRZzgh8BAQEEOgIBOg4HCBEDAQJ8AQEFAwYTCYgKBwWeXKB8jwMSBhCDKgOIaY1UgR2EWIpwgyU X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; d="scan'208";a="150912044" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 25 Feb 2013 18:55:45 +0000 Received: from [10.61.97.12] (dhcp-10-61-97-12.cisco.com [10.61.97.12]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1PItiqR011919 for ; Mon, 25 Feb 2013 18:55:44 GMT User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 25 Feb 2013 13:55:42 -0500 From: Marc Linsner To: Message-ID: Thread-Topic: New Version Notification for draft-linsner-lmap-use-cases-02.txt In-Reply-To: <20130225185325.28683.634.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [lmap] FW: New Version Notification for draft-linsner-lmap-use-cases-02.txt 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, 25 Feb 2013 18:55:50 -0000 All, New version posted. Repaired references Added author. Marc, Philip, Trevor -----Original Message----- From: Date: Monday, February 25, 2013 1:53 PM To: Marc Linsner Cc: , Subject: New Version Notification for draft-linsner-lmap-use-cases-02.txt > >A new version of I-D, draft-linsner-lmap-use-cases-02.txt >has been successfully submitted by Marc Linsner and posted to the >IETF repository. > >Filename: draft-linsner-lmap-use-cases >Revision: 02 >Title: Large-Scale Broadband Measurement Use Cases >Creation date: 2013-02-25 >Group: Individual Submission >Number of pages: 15 >URL: >http://www.ietf.org/internet-drafts/draft-linsner-lmap-use-cases-02.txt >Status: >http://datatracker.ietf.org/doc/draft-linsner-lmap-use-cases >Htmlized: >http://tools.ietf.org/html/draft-linsner-lmap-use-cases-02 >Diff: >http://www.ietf.org/rfcdiff?url2=draft-linsner-lmap-use-cases-02 > >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 > From philip.eardley@bt.com Mon Feb 25 12:33: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 86EA921E80B8 for ; Mon, 25 Feb 2013 12:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.077 X-Spam-Level: X-Spam-Status: No, score=-103.077 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_72=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 WYw0iQVucPI1 for ; Mon, 25 Feb 2013 12:33:56 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0A73521E8064 for ; Mon, 25 Feb 2013 12:33:55 -0800 (PST) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 25 Feb 2013 20:33:45 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.59]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Mon, 25 Feb 2013 20:33:53 +0000 From: To: Date: Mon, 25 Feb 2013 20:33:52 +0000 Thread-Topic: New Version Notification for draft-eardley-lmap-framework-01.txt Thread-Index: Ac4Tl0lkODHXgIXoQTKl+XVnXNi0RQAAAhnA Message-ID: <9510D26531EF184D9017DF24659BB87F342ECFC0BE@EMV65-UKRD.domain1.systemhost.net> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [lmap] FW: New Version Notification for draft-eardley-lmap-framework-01.txt 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, 25 Feb 2013 20:33:56 -0000 SSBtYWRlIGEgZmV3IG1pbm9yIHVwZGF0ZXMuIHRoYW5rcyB0byBNZWQsIEp1ZXJnZW4gYW5kIG90 aGVycyBmb3IgdGhlIGNvbW1lbnRzLg0KDQpCZXN0IHdpc2hlcywNCnBoaWwNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiAyNSBGZWJydWFyeSAyMDEzIDIwOjMz DQpUbzogRWFyZGxleSxQTCxQaGlsaXAsVFVCOCBSDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWVhcmRsZXktbG1hcC1mcmFtZXdvcmstMDEudHh0DQoNCg0KQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWVhcmRsZXktbG1hcC1mcmFtZXdvcmstMDEudHh0DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBoaWxpcCBFYXJkbGV5IGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1lYXJkbGV5LWxt YXAtZnJhbWV3b3JrDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBBIGZyYW1ld29yayBmb3IgbGFy Z2Utc2NhbGUgbWVhc3VyZW1lbnRzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wMi0yNQ0KR3JvdXA6 CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDEzDQpVUkw6ICAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWVhcmRsZXkt bG1hcC1mcmFtZXdvcmstMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZWFyZGxleS1sbWFwLWZyYW1ld29yaw0KSHRtbGl6ZWQ6ICAg ICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lYXJkbGV5LWxtYXAtZnJhbWV3 b3JrLTAxDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWVhcmRsZXktbG1hcC1mcmFtZXdvcmstMDENCg0KQWJzdHJhY3Q6DQogICBNZWFzdXJp bmcgYnJvYWRiYW5kIHNlcnZpY2Ugb24gYSBsYXJnZSBzY2FsZSByZXF1aXJlcyBzdGFuZGFyZGlz YXRpb24NCiAgIG9mIHRoZSBsb2dpY2FsIGFyY2hpdGVjdHVyZSBhbmQgYSBkZXNjcmlwdGlvbiBv ZiB0aGUga2V5IHByb3RvY29scw0KICAgdGhhdCBjb29yZGluYXRlIGludGVyYWN0aW9ucyBiZXR3 ZWVuIHRoZSBjb21wb25lbnRzLiAgVGhlIGRvY3VtZW50DQogICBwcmVzZW50cyBhbiBvdmVyYWxs IGZyYW1ld29yayBmb3IgbGFyZ2Utc2NhbGUgbWVhc3VyZW1lbnRzIGFuZA0KICAgZGlzY3Vzc2Vz IHdoaWNoIGVsZW1lbnRzIGNvdWxkIGJlIHN0YW5kYXJkaXNlZCBpbiB0aGUgSUVURi4gIEl0IGlz DQogICBpbnRlbmRlZCB0byBhc3Npc3QgdGhlIGRpc2N1c3Npb25zIGFib3V0IHRoZSBwb3RlbnRp YWwgY3JlYXRpb24gb2YNCiAgIHRoZSBMTUFQIHdvcmtpbmcgZ3JvdXAuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From dromasca@avaya.com Wed Feb 27 10:27:05 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 2293821F88F0 for ; Wed, 27 Feb 2013 10:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.751 X-Spam-Level: X-Spam-Status: No, score=-101.751 tagged_above=-999 required=5 tests=[AWL=-1.452, BAYES_00=-2.599, MANGLED_AVOID=2.3, 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 vokwRctzkg-S for ; Wed, 27 Feb 2013 10:27:01 -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 00DF521F84BE for ; Wed, 27 Feb 2013 10:27:00 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAP0QA1HGmAcF/2dsb2JhbABFgmu7ZxZzgiABAQMSKDgZARUVFEImAQQbEweHbQGdOYQqnHSNGoNEYQOSWolAijuCd4FnPQ X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208";a="50571383" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 27 Feb 2013 13:24:27 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Feb 2013 13:24:39 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Wed, 27 Feb 2013 13:27:27 -0500 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: security considerations for LMAP Thread-Index: Ac4VGAgYeZY94tNfSW+edT4RUeQ0Ew== Date: Wed, 27 Feb 2013 18:27:27 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA099307@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] security considerations for 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, 27 Feb 2013 18:27:05 -0000 Hi, I would like to raise one issue which I believe needs more discussions and = clarifications as we prepare for the LMAP BOF and this is related to the se= curity aspects of the use cases and the security requirements that we shall= need to place on solutions. The use cases I-D (draft-linsner-lmap-use-case= s-02) has a void Security Considerations section, and so does draft-boucada= ir-lmap-considerations-00. This is fine at this point in time but obviously= can't stay like this. Only draft-eardley-lmap-framework-01 deals with part= of the security aspects but more from the perspective of protecting the me= asurement information and storage.=20 The use cases however seem to raise a few potential concerns related to the= information that is being accessed by different entities, who is authorize= d to collect and what in large-scale measurements. I can see three possible= interfaces that can raise such concerns:=20 1. The ISP and Multi-Provider use cases mention the need of one provider ha= ving visibility and access into the measurements of another provider - to d= ebug specific performance problems, to realize benchmarking and competitor = insight, etc. This can be problematic and needs to put in place proper mech= anisms of authorization, as different providers may be in different type of= relations, they would like to control what information is made available t= o competitors and none would accept full visibility of its own internal dat= a 2. The ISP-customer use case: Understanding the quality experienced by cust= omers requires deployment of either software or in some scenarios hardware = probes at the customers sites or on the edge. This raises similar problems = of visibility as in the previous phase, as well as issues related to privac= y protection which may be subject to local or regional (for example Europea= n) laws and regulations on privacy.=20 3. The regulator case: Having regulators gather, store and process broadban= d traffic information in domains owned by ISPs raises also issues of author= ization of access to such information. Hopefully development and enforcemen= t of broadband policies will become part of the regulation and legislation = and these details will be worked eventually out, but until they do and even= afterwards proper mechanisms need to be in place in order to control autho= rization and protect information of the different levels of providers.=20 Thoughts? Opinions?=20 Regards, Dan =20 From mohamed.boucadair@orange.com Wed Feb 27 23:29:19 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 F30D921F85F3 for ; Wed, 27 Feb 2013 23:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_AVOID=2.3, UNPARSEABLE_RELAY=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 pgKz4+vrOsHC for ; Wed, 27 Feb 2013 23:29:17 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 96D0B21F8AF2 for ; Wed, 27 Feb 2013 23:29:09 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id F25F63247B7; Thu, 28 Feb 2013 08:29:07 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D877323806B; Thu, 28 Feb 2013 08:29:07 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 28 Feb 2013 08:29:08 +0100 From: To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Date: Thu, 28 Feb 2013 08:29:06 +0100 Thread-Topic: security considerations for LMAP Thread-Index: Ac4VGAgYeZY94tNfSW+edT4RUeQ0EwAbCWFg Message-ID: <94C682931C08B048B7A8645303FDC9F36EB47D73F4@PUEXCB1B.nanterre.francetelecom.fr> References: <9904FB1B0159DA42B0B887B7FA8119CA099307@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA099307@AZ-FFEXMB04.global.avaya.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.28.45416 Subject: Re: [lmap] security considerations for 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, 28 Feb 2013 07:29:19 -0000 Dear Dan, FWIW, there are some security-related items listed in http://tools.ietf.org= /html/draft-boucadair-lmap-considerations-00: Q10: How to control access to measurement results? How to prevent revealing measurement results to external parties? Q20: How the system is designed to ensure topology hiding? And the following ietm on the impact of policies: Q16: How to make sure measurement data accurately reflect the network performance and not the policies enforced in that network? At this stage, we have only questions ... Cheers, Med=20 >-----Message d'origine----- >De : lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] De=20 >la part de Romascanu, Dan (Dan) >Envoy=E9 : mercredi 27 f=E9vrier 2013 19:27 >=C0 : lmap@ietf.org >Objet : [lmap] security considerations for LMAP > >Hi, > >I would like to raise one issue which I believe needs more=20 >discussions and clarifications as we prepare for the LMAP BOF=20 >and this is related to the security aspects of the use cases=20 >and the security requirements that we shall need to place on=20 >solutions. The use cases I-D (draft-linsner-lmap-use-cases-02)=20 >has a void Security Considerations section, and so does=20 >draft-boucadair-lmap-considerations-00. This is fine at this=20 >point in time but obviously can't stay like this. Only=20 >draft-eardley-lmap-framework-01 deals with part of the=20 >security aspects but more from the perspective of protecting=20 >the measurement information and storage.=20 > >The use cases however seem to raise a few potential concerns=20 >related to the information that is being accessed by different=20 >entities, who is authorized to collect and what in large-scale=20 >measurements. I can see three possible interfaces that can=20 >raise such concerns:=20 > >1. The ISP and Multi-Provider use cases mention the need of=20 >one provider having visibility and access into the=20 >measurements of another provider - to debug specific=20 >performance problems, to realize benchmarking and competitor=20 >insight, etc. This can be problematic and needs to put in=20 >place proper mechanisms of authorization, as different=20 >providers may be in different type of relations, they would=20 >like to control what information is made available to=20 >competitors and none would accept full visibility of its own=20 >internal data >2. The ISP-customer use case: Understanding the quality=20 >experienced by customers requires deployment of either=20 >software or in some scenarios hardware probes at the customers=20 >sites or on the edge. This raises similar problems of=20 >visibility as in the previous phase, as well as issues related=20 >to privacy protection which may be subject to local or=20 >regional (for example European) laws and regulations on privacy.=20 >3. The regulator case: Having regulators gather, store and=20 >process broadband traffic information in domains owned by ISPs=20 >raises also issues of authorization of access to such=20 >information. Hopefully development and enforcement of=20 >broadband policies will become part of the regulation and=20 >legislation and these details will be worked eventually out,=20 >but until they do and even afterwards proper mechanisms need=20 >to be in place in order to control authorization and protect=20 >information of the different levels of providers.=20 > >Thoughts? Opinions?=20 > >Regards, > >Dan >=20 > > > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap >= From dromasca@avaya.com Thu Feb 28 02:56: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 3C13E21F8AA0 for ; Thu, 28 Feb 2013 02:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_00=-2.599, MANGLED_AVOID=2.3, 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 YiqUF9K4cVJL for ; Thu, 28 Feb 2013 02:56:00 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 320D821F84C2 for ; Thu, 28 Feb 2013 02:55:58 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAP0QA1GHCzI1/2dsb2JhbABFgmu7ZxZzgh4BAQEBAwEBAQ9cBAIRBAIBCA0EBAEBCx0HJwsUCQgBAQQBEggTB4dtAQuhWJx0jRqDRGEDiCyKLoRPhHGKO4J3gWc9 X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208";a="345408478" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Feb 2013 05:59:19 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Feb 2013 05:54:42 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Thu, 28 Feb 2013 05:55:53 -0500 From: "Romascanu, Dan (Dan)" To: "mohamed.boucadair@orange.com" , "lmap@ietf.org" Thread-Topic: security considerations for LMAP Thread-Index: Ac4VGAgYeZY94tNfSW+edT4RUeQ0EwAbCWFgAAdPe/A= Date: Thu, 28 Feb 2013 10:55:52 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA09A14F@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA099307@AZ-FFEXMB04.global.avaya.com> <94C682931C08B048B7A8645303FDC9F36EB47D73F4@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB47D73F4@PUEXCB1B.nanterre.francetelecom.fr> 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] security considerations for 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, 28 Feb 2013 10:56:02 -0000 Hi Mohamed, Thanks for pointing these.=20 A quick mapping of the questions to the three interfaces (use cases) I desc= ribed in my mail shows:=20 Q10 - applies to all use cases Q20 especially applies to #1 - my experience is that ISPs consider each the= ir own topology and information about it as an asset to protect and keep co= nfidential and would be very reluctant if large-scale measurement would mak= e this information accessible to competitors Q16 - I confess I understand this one less. I thought measurements would ma= inly reflect (real) network performance Regards, Dan > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Thursday, February 28, 2013 9:29 AM > To: Romascanu, Dan (Dan); lmap@ietf.org > Subject: RE: security considerations for LMAP >=20 > Dear Dan, >=20 > FWIW, there are some security-related items listed in > http://tools.ietf.org/html/draft-boucadair-lmap-considerations-00: >=20 > Q10: How to control access to measurement results? How to prevent > revealing measurement results to external parties? > Q20: How the system is designed to ensure topology hiding? >=20 > And the following ietm on the impact of policies: > Q16: How to make sure measurement data accurately reflect the > network performance and not the policies enforced in that > network? >=20 > At this stage, we have only questions ... >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De : lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] De la part de > >Romascanu, Dan (Dan) Envoy=E9 : mercredi 27 f=E9vrier 2013 19:27 =C0 : > >lmap@ietf.org Objet : [lmap] security considerations for LMAP > > > >Hi, > > > >I would like to raise one issue which I believe needs more discussions > >and clarifications as we prepare for the LMAP BOF and this is related > >to the security aspects of the use cases and the security requirements > >that we shall need to place on solutions. The use cases I-D > >(draft-linsner-lmap-use-cases-02) > >has a void Security Considerations section, and so does > >draft-boucadair-lmap-considerations-00. This is fine at this point in > >time but obviously can't stay like this. Only > >draft-eardley-lmap-framework-01 deals with part of the security aspects > >but more from the perspective of protecting the measurement information > >and storage. > > > >The use cases however seem to raise a few potential concerns related to > >the information that is being accessed by different entities, who is > >authorized to collect and what in large-scale measurements. I can see > >three possible interfaces that can raise such concerns: > > > >1. The ISP and Multi-Provider use cases mention the need of one > >provider having visibility and access into the measurements of another > >provider - to debug specific performance problems, to realize > >benchmarking and competitor insight, etc. This can be problematic and > >needs to put in place proper mechanisms of authorization, as different > >providers may be in different type of relations, they would like to > >control what information is made available to competitors and none > >would accept full visibility of its own internal data 2. The > >ISP-customer use case: Understanding the quality experienced by > >customers requires deployment of either software or in some scenarios > >hardware probes at the customers sites or on the edge. This raises > >similar problems of visibility as in the previous phase, as well as > >issues related to privacy protection which may be subject to local or > >regional (for example European) laws and regulations on privacy. > >3. The regulator case: Having regulators gather, store and process > >broadband traffic information in domains owned by ISPs raises also > >issues of authorization of access to such information. Hopefully > >development and enforcement of broadband policies will become part of > >the regulation and legislation and these details will be worked > >eventually out, but until they do and even afterwards proper mechanisms > >need to be in place in order to control authorization and protect > >information of the different levels of providers. > > > >Thoughts? Opinions? > > > >Regards, > > > >Dan > > > > > > > > > >_______________________________________________ > >lmap mailing list > >lmap@ietf.org > >https://www.ietf.org/mailman/listinfo/lmap > > From mohamed.boucadair@orange.com Thu Feb 28 04:19:27 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 2471C21F88C1 for ; Thu, 28 Feb 2013 04:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.976 X-Spam-Level: X-Spam-Status: No, score=-0.976 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_AVOID=2.3, UNPARSEABLE_RELAY=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 RIfi13Qs-612 for ; Thu, 28 Feb 2013 04:19:26 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3443B21F8751 for ; Thu, 28 Feb 2013 04:19:26 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id A529B18C90C; Thu, 28 Feb 2013 13:19:24 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8B7154C05D; Thu, 28 Feb 2013 13:19:24 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 28 Feb 2013 13:19:24 +0100 From: To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Date: Thu, 28 Feb 2013 13:19:23 +0100 Thread-Topic: security considerations for LMAP Thread-Index: Ac4VGAgYeZY94tNfSW+edT4RUeQ0EwAbCWFgAAdPe/AAArVlgA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EB47D75AD@PUEXCB1B.nanterre.francetelecom.fr> References: <9904FB1B0159DA42B0B887B7FA8119CA099307@AZ-FFEXMB04.global.avaya.com> <94C682931C08B048B7A8645303FDC9F36EB47D73F4@PUEXCB1B.nanterre.francetelecom.fr> <9904FB1B0159DA42B0B887B7FA8119CA09A14F@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA09A14F@AZ-FFEXMB04.global.avaya.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.28.111517 Subject: Re: [lmap] security considerations for 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, 28 Feb 2013 12:19:27 -0000 Re-, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 >Envoy=E9 : jeudi 28 f=E9vrier 2013 11:56 >=C0 : BOUCADAIR Mohamed OLNC/OLN; lmap@ietf.org >Objet : RE: security considerations for LMAP > >Hi Mohamed, > >Thanks for pointing these.=20 > >A quick mapping of the questions to the three interfaces (use=20 >cases) I described in my mail shows:=20 > >Q10 - applies to all use cases >Q20 especially applies to #1 - my experience is that ISPs=20 >consider each their own topology and information about it as=20 >an asset to protect and keep confidential and would be very=20 >reluctant if large-scale measurement would make this=20 >information accessible to competitors Med: Yes, this is one aspect.=20 >Q16 - I confess I understand this one less. I thought=20 >measurements would mainly reflect (real) network performance Med: An example to illustrate the concern raised in Q16 is an LMAP agent no= t controlled by the provider offering IP connectivity. This IP Network Prov= ider may install filters to discard some traffic (e.g., detect active probe= ) or to assign high priority to some flows (e.g., service-sensitive data). = The outcome of the LMAP measurement requests will hit those filters and the= refore won't reflect the actual network performance but will return the out= come of enforcing these policies. A typical example of policies is any CAC = installed at the first IP router.=20 > >Regards, > >Dan > > > > >> -----Original Message----- >> From: mohamed.boucadair@orange.com=20 >[mailto:mohamed.boucadair@orange.com] >> Sent: Thursday, February 28, 2013 9:29 AM >> To: Romascanu, Dan (Dan); lmap@ietf.org >> Subject: RE: security considerations for LMAP >>=20 >> Dear Dan, >>=20 >> FWIW, there are some security-related items listed in >> http://tools.ietf.org/html/draft-boucadair-lmap-considerations-00: >>=20 >> Q10: How to control access to measurement results? How=20 >to prevent >> revealing measurement results to external parties? >> Q20: How the system is designed to ensure topology hiding? >>=20 >> And the following ietm on the impact of policies: >> Q16: How to make sure measurement data accurately reflect the >> network performance and not the policies enforced in that >> network? >>=20 >> At this stage, we have only questions ... >>=20 >> Cheers, >> Med >>=20 >> >-----Message d'origine----- >> >De : lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org]=20 >De la part de >> >Romascanu, Dan (Dan) Envoy=E9 : mercredi 27 f=E9vrier 2013 19:27 =C0 : >> >lmap@ietf.org Objet : [lmap] security considerations for LMAP >> > >> >Hi, >> > >> >I would like to raise one issue which I believe needs more=20 >discussions >> >and clarifications as we prepare for the LMAP BOF and this=20 >is related >> >to the security aspects of the use cases and the security=20 >requirements >> >that we shall need to place on solutions. The use cases I-D >> >(draft-linsner-lmap-use-cases-02) >> >has a void Security Considerations section, and so does >> >draft-boucadair-lmap-considerations-00. This is fine at=20 >this point in >> >time but obviously can't stay like this. Only >> >draft-eardley-lmap-framework-01 deals with part of the=20 >security aspects >> >but more from the perspective of protecting the measurement=20 >information >> >and storage. >> > >> >The use cases however seem to raise a few potential=20 >concerns related to >> >the information that is being accessed by different entities, who is >> >authorized to collect and what in large-scale measurements.=20 >I can see >> >three possible interfaces that can raise such concerns: >> > >> >1. The ISP and Multi-Provider use cases mention the need of one >> >provider having visibility and access into the measurements=20 >of another >> >provider - to debug specific performance problems, to realize >> >benchmarking and competitor insight, etc. This can be=20 >problematic and >> >needs to put in place proper mechanisms of authorization,=20 >as different >> >providers may be in different type of relations, they would like to >> >control what information is made available to competitors and none >> >would accept full visibility of its own internal data 2. The >> >ISP-customer use case: Understanding the quality experienced by >> >customers requires deployment of either software or in some=20 >scenarios >> >hardware probes at the customers sites or on the edge. This raises >> >similar problems of visibility as in the previous phase, as well as >> >issues related to privacy protection which may be subject=20 >to local or >> >regional (for example European) laws and regulations on privacy. >> >3. The regulator case: Having regulators gather, store and process >> >broadband traffic information in domains owned by ISPs raises also >> >issues of authorization of access to such information. Hopefully >> >development and enforcement of broadband policies will=20 >become part of >> >the regulation and legislation and these details will be worked >> >eventually out, but until they do and even afterwards=20 >proper mechanisms >> >need to be in place in order to control authorization and protect >> >information of the different levels of providers. >> > >> >Thoughts? Opinions? >> > >> >Regards, >> > >> >Dan >> > >> > >> > >> > >> >_______________________________________________ >> >lmap mailing list >> >lmap@ietf.org >> >https://www.ietf.org/mailman/listinfo/lmap >> > >= From dromasca@avaya.com Thu Feb 28 04:24: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 069E521F84AF for ; Thu, 28 Feb 2013 04:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.218 X-Spam-Level: X-Spam-Status: No, score=-102.218 tagged_above=-999 required=5 tests=[AWL=-0.919, BAYES_00=-2.599, MANGLED_AVOID=2.3, 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 KhDgpckdooIs for ; Thu, 28 Feb 2013 04:24:00 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id AEC9221F84A9 for ; Thu, 28 Feb 2013 04:23:59 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAP0QA1HGmAcF/2dsb2JhbABFgmu7ZxZzgh4BAQEBAwEBAQ9cBAIRBAIBCA0EBAEBCx0HJwsUCQgBAQQBEggTB4dtAQuhWJx0jRqDRGEDiCyKLoRPhHGKO4J3gWc9 X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208";a="345416676" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Feb 2013 07:27:21 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Feb 2013 07:21:34 -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, 28 Feb 2013 07:23:55 -0500 From: "Romascanu, Dan (Dan)" To: "mohamed.boucadair@orange.com" , "lmap@ietf.org" Thread-Topic: security considerations for LMAP Thread-Index: Ac4VGAgYeZY94tNfSW+edT4RUeQ0EwAbCWFgAAdPe/AAArVlgAAAcH3g Date: Thu, 28 Feb 2013 12:23:54 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA09A20B@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA099307@AZ-FFEXMB04.global.avaya.com> <94C682931C08B048B7A8645303FDC9F36EB47D73F4@PUEXCB1B.nanterre.francetelecom.fr> <9904FB1B0159DA42B0B887B7FA8119CA09A14F@AZ-FFEXMB04.global.avaya.com> <94C682931C08B048B7A8645303FDC9F36EB47D75AD@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB47D75AD@PUEXCB1B.nanterre.francetelecom.fr> 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] security considerations for 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, 28 Feb 2013 12:24:01 -0000 Hi Med, I got it. Makes sense, although I would point that this concern is not nece= ssarily a security concern, or only a security concern. In a broader contex= t the security requirement would be related to the danger of and protection= against the intentional or unintentional mis-configuration of probes, serv= ers or any other entities involved in LMAP.=20 Regards, Dan > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Thursday, February 28, 2013 2:19 PM > To: Romascanu, Dan (Dan); lmap@ietf.org > Subject: RE: security considerations for LMAP >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De : Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Envoy=E9 : jeudi 2= 8 > >f=E9vrier 2013 11:56 =C0 : BOUCADAIR Mohamed OLNC/OLN; lmap@ietf.org Obj= et > >: RE: security considerations for LMAP > > > >Hi Mohamed, > > > >Thanks for pointing these. > > > >A quick mapping of the questions to the three interfaces (use > >cases) I described in my mail shows: > > > >Q10 - applies to all use cases > >Q20 especially applies to #1 - my experience is that ISPs consider each > >their own topology and information about it as an asset to protect and > >keep confidential and would be very reluctant if large-scale > >measurement would make this information accessible to competitors >=20 > Med: Yes, this is one aspect. >=20 > >Q16 - I confess I understand this one less. I thought measurements > >would mainly reflect (real) network performance >=20 > Med: An example to illustrate the concern raised in Q16 is an LMAP agent > not controlled by the provider offering IP connectivity. This IP Network > Provider may install filters to discard some traffic (e.g., detect > active probe) or to assign high priority to some flows (e.g., service- > sensitive data). The outcome of the LMAP measurement requests will hit > those filters and therefore won't reflect the actual network performance > but will return the outcome of enforcing these policies. A typical > example of policies is any CAC installed at the first IP router. >=20 > > > >Regards, > > > >Dan > > > > > > > > > >> -----Original Message----- > >> From: mohamed.boucadair@orange.com > >[mailto:mohamed.boucadair@orange.com] > >> Sent: Thursday, February 28, 2013 9:29 AM > >> To: Romascanu, Dan (Dan); lmap@ietf.org > >> Subject: RE: security considerations for LMAP > >> > >> Dear Dan, > >> > >> FWIW, there are some security-related items listed in > >> http://tools.ietf.org/html/draft-boucadair-lmap-considerations-00: > >> > >> Q10: How to control access to measurement results? How > >to prevent > >> revealing measurement results to external parties? > >> Q20: How the system is designed to ensure topology hiding? > >> > >> And the following ietm on the impact of policies: > >> Q16: How to make sure measurement data accurately reflect the > >> network performance and not the policies enforced in that > >> network? > >> > >> At this stage, we have only questions ... > >> > >> Cheers, > >> Med > >> > >> >-----Message d'origine----- > >> >De : lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] > >De la part de > >> >Romascanu, Dan (Dan) Envoy=E9 : mercredi 27 f=E9vrier 2013 19:27 =C0 = : > >> >lmap@ietf.org Objet : [lmap] security considerations for LMAP > >> > > >> >Hi, > >> > > >> >I would like to raise one issue which I believe needs more > >discussions > >> >and clarifications as we prepare for the LMAP BOF and this > >is related > >> >to the security aspects of the use cases and the security > >requirements > >> >that we shall need to place on solutions. The use cases I-D > >> >(draft-linsner-lmap-use-cases-02) > >> >has a void Security Considerations section, and so does > >> >draft-boucadair-lmap-considerations-00. This is fine at > >this point in > >> >time but obviously can't stay like this. Only > >> >draft-eardley-lmap-framework-01 deals with part of the > >security aspects > >> >but more from the perspective of protecting the measurement > >information > >> >and storage. > >> > > >> >The use cases however seem to raise a few potential > >concerns related to > >> >the information that is being accessed by different entities, who is > >> >authorized to collect and what in large-scale measurements. > >I can see > >> >three possible interfaces that can raise such concerns: > >> > > >> >1. The ISP and Multi-Provider use cases mention the need of one > >> >provider having visibility and access into the measurements > >of another > >> >provider - to debug specific performance problems, to realize > >> >benchmarking and competitor insight, etc. This can be > >problematic and > >> >needs to put in place proper mechanisms of authorization, > >as different > >> >providers may be in different type of relations, they would like to > >> >control what information is made available to competitors and none > >> >would accept full visibility of its own internal data 2. The > >> >ISP-customer use case: Understanding the quality experienced by > >> >customers requires deployment of either software or in some > >scenarios > >> >hardware probes at the customers sites or on the edge. This raises > >> >similar problems of visibility as in the previous phase, as well as > >> >issues related to privacy protection which may be subject > >to local or > >> >regional (for example European) laws and regulations on privacy. > >> >3. The regulator case: Having regulators gather, store and process > >> >broadband traffic information in domains owned by ISPs raises also > >> >issues of authorization of access to such information. Hopefully > >> >development and enforcement of broadband policies will > >become part of > >> >the regulation and legislation and these details will be worked > >> >eventually out, but until they do and even afterwards > >proper mechanisms > >> >need to be in place in order to control authorization and protect > >> >information of the different levels of providers. > >> > > >> >Thoughts? Opinions? > >> > > >> >Regards, > >> > > >> >Dan > >> > > >> > > >> > > >> > > >> >_______________________________________________ > >> >lmap mailing list > >> >lmap@ietf.org > >> >https://www.ietf.org/mailman/listinfo/lmap > >> > > > From acmorton@att.com Thu Feb 28 06:42:47 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 7EA0F21F85DF for ; Thu, 28 Feb 2013 06:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.344 X-Spam-Level: X-Spam-Status: No, score=-105.344 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_00=-2.599, MANGLED_AVOID=2.3, 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 WAh8gYfbQ0RY for ; Thu, 28 Feb 2013 06:42:46 -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 04AD721F8589 for ; Thu, 28 Feb 2013 06:42:45 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 2AC621207D0; Thu, 28 Feb 2013 09:45:19 -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 9FA9AEF6C1; Thu, 28 Feb 2013 09:42:44 -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, 28 Feb 2013 09:42:44 -0500 From: "MORTON JR., ALFRED (AL)" To: "Romascanu, Dan (Dan)" , "mohamed.boucadair@orange.com" , "lmap@ietf.org" Date: Thu, 28 Feb 2013 09:42:42 -0500 Thread-Topic: security considerations for LMAP Thread-Index: Ac4VGAgYeZY94tNfSW+edT4RUeQ0EwAbCWFgAAdPe/AAArVlgAAAcH3gAARlsGA= Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA099307@AZ-FFEXMB04.global.avaya.com> <94C682931C08B048B7A8645303FDC9F36EB47D73F4@PUEXCB1B.nanterre.francetelecom.fr> <9904FB1B0159DA42B0B887B7FA8119CA09A14F@AZ-FFEXMB04.global.avaya.com> <94C682931C08B048B7A8645303FDC9F36EB47D75AD@PUEXCB1B.nanterre.francetelecom.fr> <9904FB1B0159DA42B0B887B7FA8119CA09A20B@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA09A20B@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] security considerations for 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, 28 Feb 2013 14:42:47 -0000 Dan and Med, > > >> Q16: How to make sure measurement data accurately reflect the > > >> network performance and not the policies enforced in that > > >> network? > > >[Dan] Q16 - I confess I understand this one less. I thought measuremen= ts > > >would mainly reflect (real) network performance > > > > Med: An example to illustrate the concern raised in Q16 is an LMAP agen= t > > not controlled by the provider offering IP connectivity. This IP Networ= k > > Provider may install filters to discard some traffic (e.g., detect > > active probe) or to assign high priority to some flows (e.g., service- > > sensitive data). The outcome of the LMAP measurement requests will hit > > those filters and therefore won't reflect the actual network performanc= e > > but will return the outcome of enforcing these policies. A typical > > example of policies is any CAC installed at the first IP router. This question has been the topic of consideration in IPPM literature. For example: http://tools.ietf.org/html/rfc2679#section-6 ... The measurements themselves could be harmed by routers giving measurement traffic a different priority than "normal" traffic, or by an attacker injecting artificial measurement traffic. If routers can recognize measurement traffic and treat it separately, the measurements will not reflect actual user traffic. If an attacker injects artificial traffic that is accepted as legitimate, the loss rate will be artificially lowered. Therefore, the measurement methodologies SHOULD include appropriate techniques to reduce the probability measurement traffic can be distinguished from "normal" traffic. Authentication techniques, such as digital signatures, may be used where appropriate to guard against injected traffic attacks. For more examples, see the Security sections of=20 http://tools.ietf.org/html/rfc3432#section-6.3 http://tools.ietf.org/html/rfc4656#page-38 and finally, the latest appreciation of this topic: http://tools.ietf.org/html/draft-morton-ippm-2330-update-01 There's always some refinement to do, but LMAP work has a reasonable foundation to stand on in this particular area. regards, Al > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Thursday, February 28, 2013 7:24 AM > To: mohamed.boucadair@orange.com; lmap@ietf.org > Subject: Re: [lmap] security considerations for LMAP >=20 > Hi Med, >=20 > I got it. Makes sense, although I would point that this concern is not > necessarily a security concern, or only a security concern. In a broader > context the security requirement would be related to the danger of and > protection against the intentional or unintentional mis-configuration of > probes, servers or any other entities involved in LMAP. >=20 > Regards, >=20 > Dan >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com= ] > > Sent: Thursday, February 28, 2013 2:19 PM > > To: Romascanu, Dan (Dan); lmap@ietf.org > > Subject: RE: security considerations for LMAP > > > > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > >-----Message d'origine----- > > >De : Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Envoy=E9 : jeudi= 28 > > >f=E9vrier 2013 11:56 =C0 : BOUCADAIR Mohamed OLNC/OLN; lmap@ietf.org O= bjet > > >: RE: security considerations for LMAP > > > > > >Hi Mohamed, > > > > > >Thanks for pointing these. > > > > > >A quick mapping of the questions to the three interfaces (use > > >cases) I described in my mail shows: > > > > > >Q10 - applies to all use cases > > >Q20 especially applies to #1 - my experience is that ISPs consider eac= h > > >their own topology and information about it as an asset to protect and > > >keep confidential and would be very reluctant if large-scale > > >measurement would make this information accessible to competitors > > > > Med: Yes, this is one aspect. > > > > >Q16 - I confess I understand this one less. I thought measurements > > >would mainly reflect (real) network performance > > > > Med: An example to illustrate the concern raised in Q16 is an LMAP agen= t > > not controlled by the provider offering IP connectivity. This IP Networ= k > > Provider may install filters to discard some traffic (e.g., detect > > active probe) or to assign high priority to some flows (e.g., service- > > sensitive data). The outcome of the LMAP measurement requests will hit > > those filters and therefore won't reflect the actual network performanc= e > > but will return the outcome of enforcing these policies. A typical > > example of policies is any CAC installed at the first IP router. > > > > > > > >Regards, > > > > > >Dan > > > > > > > > > > > > > > >> -----Original Message----- > > >> From: mohamed.boucadair@orange.com > > >[mailto:mohamed.boucadair@orange.com] > > >> Sent: Thursday, February 28, 2013 9:29 AM > > >> To: Romascanu, Dan (Dan); lmap@ietf.org > > >> Subject: RE: security considerations for LMAP > > >> > > >> Dear Dan, > > >> > > >> FWIW, there are some security-related items listed in > > >> http://tools.ietf.org/html/draft-boucadair-lmap-considerations-00: > > >> > > >> Q10: How to control access to measurement results? How > > >to prevent > > >> revealing measurement results to external parties? > > >> Q20: How the system is designed to ensure topology hiding? > > >> > > >> And the following ietm on the impact of policies: > > >> Q16: How to make sure measurement data accurately reflect the > > >> network performance and not the policies enforced in that > > >> network? > > >> > > >> At this stage, we have only questions ... > > >> > > >> Cheers, > > >> Med > > >> > > >> >-----Message d'origine----- > > >> >De : lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] > > >De la part de > > >> >Romascanu, Dan (Dan) Envoy=E9 : mercredi 27 f=E9vrier 2013 19:27 = =C0 : > > >> >lmap@ietf.org Objet : [lmap] security considerations for LMAP > > >> > > > >> >Hi, > > >> > > > >> >I would like to raise one issue which I believe needs more > > >discussions > > >> >and clarifications as we prepare for the LMAP BOF and this > > >is related > > >> >to the security aspects of the use cases and the security > > >requirements > > >> >that we shall need to place on solutions. The use cases I-D > > >> >(draft-linsner-lmap-use-cases-02) > > >> >has a void Security Considerations section, and so does > > >> >draft-boucadair-lmap-considerations-00. This is fine at > > >this point in > > >> >time but obviously can't stay like this. Only > > >> >draft-eardley-lmap-framework-01 deals with part of the > > >security aspects > > >> >but more from the perspective of protecting the measurement > > >information > > >> >and storage. > > >> > > > >> >The use cases however seem to raise a few potential > > >concerns related to > > >> >the information that is being accessed by different entities, who i= s > > >> >authorized to collect and what in large-scale measurements. > > >I can see > > >> >three possible interfaces that can raise such concerns: > > >> > > > >> >1. The ISP and Multi-Provider use cases mention the need of one > > >> >provider having visibility and access into the measurements > > >of another > > >> >provider - to debug specific performance problems, to realize > > >> >benchmarking and competitor insight, etc. This can be > > >problematic and > > >> >needs to put in place proper mechanisms of authorization, > > >as different > > >> >providers may be in different type of relations, they would like to > > >> >control what information is made available to competitors and none > > >> >would accept full visibility of its own internal data 2. The > > >> >ISP-customer use case: Understanding the quality experienced by > > >> >customers requires deployment of either software or in some > > >scenarios > > >> >hardware probes at the customers sites or on the edge. This raises > > >> >similar problems of visibility as in the previous phase, as well as > > >> >issues related to privacy protection which may be subject > > >to local or > > >> >regional (for example European) laws and regulations on privacy. > > >> >3. The regulator case: Having regulators gather, store and process > > >> >broadband traffic information in domains owned by ISPs raises also > > >> >issues of authorization of access to such information. Hopefully > > >> >development and enforcement of broadband policies will > > >become part of > > >> >the regulation and legislation and these details will be worked > > >> >eventually out, but until they do and even afterwards > > >proper mechanisms > > >> >need to be in place in order to control authorization and protect > > >> >information of the different levels of providers. > > >> > > > >> >Thoughts? Opinions? > > >> > > > >> >Regards, > > >> > > > >> >Dan > > >> > > > >> > > > >> > > > >> > > > >> >_______________________________________________ > > >> >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 mohamed.boucadair@orange.com Thu Feb 28 06:53:19 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 828EE21F87B9 for ; Thu, 28 Feb 2013 06:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.952 X-Spam-Level: X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[AWL=-1.004, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_AVOID=2.3, UNPARSEABLE_RELAY=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 rEIpKq3h22kB for ; Thu, 28 Feb 2013 06:53:18 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD6B21F87D5 for ; Thu, 28 Feb 2013 06:52:30 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4522A22C47C; Thu, 28 Feb 2013 15:52:12 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 16CBA238048; Thu, 28 Feb 2013 15:52:12 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 28 Feb 2013 15:52:12 +0100 From: To: "MORTON JR., ALFRED (AL)" , "Romascanu, Dan (Dan)" , "lmap@ietf.org" Date: Thu, 28 Feb 2013 15:52:10 +0100 Thread-Topic: security considerations for LMAP Thread-Index: Ac4VGAgYeZY94tNfSW+edT4RUeQ0EwAbCWFgAAdPe/AAArVlgAAAcH3gAARlsGAAAKSm8A== Message-ID: <94C682931C08B048B7A8645303FDC9F36EB47D76D7@PUEXCB1B.nanterre.francetelecom.fr> References: <9904FB1B0159DA42B0B887B7FA8119CA099307@AZ-FFEXMB04.global.avaya.com> <94C682931C08B048B7A8645303FDC9F36EB47D73F4@PUEXCB1B.nanterre.francetelecom.fr> <9904FB1B0159DA42B0B887B7FA8119CA09A14F@AZ-FFEXMB04.global.avaya.com> <94C682931C08B048B7A8645303FDC9F36EB47D75AD@PUEXCB1B.nanterre.francetelecom.fr> <9904FB1B0159DA42B0B887B7FA8119CA09A20B@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.19.124517 Subject: Re: [lmap] security considerations for 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, 28 Feb 2013 14:53:19 -0000 Dear Al, Thanks for the pointers.=20 The story may be different for LMAP as the collected data may have some bus= iness impact: a customer running an LMAP agent (not controlled by the netwo= rk provider) may contact the hotline to complain about the quality of the s= ervice as measured using an LMAP-based system (because of the measured data= not because of the delivered service itself). Does it make sense to design the system to detect the presence of such poli= cies and return alarms to the user?=20 Should LMAP steup procedure include a phase to assess whether collected dat= a is not impacted by installed policies (e.g., using some heuristics)? Are these considerations in scope or not? Calling out these considerations in LMAP is useful. Cheers, Med=20 >-----Message d'origine----- >De : MORTON JR., ALFRED (AL) [mailto:acmorton@att.com]=20 >Envoy=E9 : jeudi 28 f=E9vrier 2013 15:43 >=C0 : Romascanu, Dan (Dan); BOUCADAIR Mohamed OLNC/OLN; lmap@ietf.org >Objet : RE: security considerations for LMAP > >Dan and Med, > >> > >> Q16: How to make sure measurement data accurately=20 >reflect the >> > >> network performance and not the policies=20 >enforced in that >> > >> network? > >> > >[Dan] Q16 - I confess I understand this one less. I=20 >thought measurements >> > >would mainly reflect (real) network performance >> > >> > Med: An example to illustrate the concern raised in Q16 is=20 >an LMAP agent >> > not controlled by the provider offering IP connectivity.=20 >This IP Network >> > Provider may install filters to discard some traffic (e.g., detect >> > active probe) or to assign high priority to some flows=20 >(e.g., service- >> > sensitive data). The outcome of the LMAP measurement=20 >requests will hit >> > those filters and therefore won't reflect the actual=20 >network performance >> > but will return the outcome of enforcing these policies. A typical >> > example of policies is any CAC installed at the first IP router. > >This question has been the topic of consideration in IPPM literature. >For example: >http://tools.ietf.org/html/rfc2679#section-6 > >... The measurements themselves could be harmed by routers giving > measurement traffic a different priority than "normal"=20 >traffic, or by > an attacker injecting artificial measurement traffic. If=20 >routers can > recognize measurement traffic and treat it separately, the > measurements will not reflect actual user traffic. If an attacker > injects artificial traffic that is accepted as legitimate, the loss > rate will be artificially lowered. Therefore, the measurement > methodologies SHOULD include appropriate techniques to reduce the > probability measurement traffic can be distinguished from "normal" > traffic. Authentication techniques, such as digital signatures, may > be used where appropriate to guard against injected traffic attacks. > >For more examples, see the Security sections of=20 > >http://tools.ietf.org/html/rfc3432#section-6.3 > >http://tools.ietf.org/html/rfc4656#page-38 > >and finally, the latest appreciation of this topic: >http://tools.ietf.org/html/draft-morton-ippm-2330-update-01 > >There's always some refinement to do, but LMAP work has a reasonable >foundation to stand on in this particular area. > >regards, >Al > >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org]=20 >On Behalf Of >> Romascanu, Dan (Dan) >> Sent: Thursday, February 28, 2013 7:24 AM >> To: mohamed.boucadair@orange.com; lmap@ietf.org >> Subject: Re: [lmap] security considerations for LMAP >>=20 >> Hi Med, >>=20 >> I got it. Makes sense, although I would point that this=20 >concern is not >> necessarily a security concern, or only a security concern.=20 >In a broader >> context the security requirement would be related to the=20 >danger of and >> protection against the intentional or unintentional=20 >mis-configuration of >> probes, servers or any other entities involved in LMAP. >>=20 >> Regards, >>=20 >> Dan >>=20 >>=20 >>=20 >>=20 >> > -----Original Message----- >> > From: mohamed.boucadair@orange.com=20 >[mailto:mohamed.boucadair@orange.com] >> > Sent: Thursday, February 28, 2013 2:19 PM >> > To: Romascanu, Dan (Dan); lmap@ietf.org >> > Subject: RE: security considerations for LMAP >> > >> > Re-, >> > >> > Please see inline. >> > >> > Cheers, >> > Med >> > >> > >-----Message d'origine----- >> > >De : Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 >Envoy=E9 : jeudi 28 >> > >f=E9vrier 2013 11:56 =C0 : BOUCADAIR Mohamed OLNC/OLN;=20 >lmap@ietf.org Objet >> > >: RE: security considerations for LMAP >> > > >> > >Hi Mohamed, >> > > >> > >Thanks for pointing these. >> > > >> > >A quick mapping of the questions to the three interfaces (use >> > >cases) I described in my mail shows: >> > > >> > >Q10 - applies to all use cases >> > >Q20 especially applies to #1 - my experience is that ISPs=20 >consider each >> > >their own topology and information about it as an asset=20 >to protect and >> > >keep confidential and would be very reluctant if large-scale >> > >measurement would make this information accessible to competitors >> > >> > Med: Yes, this is one aspect. >> > >> > >Q16 - I confess I understand this one less. I thought measurements >> > >would mainly reflect (real) network performance >> > >> > Med: An example to illustrate the concern raised in Q16 is=20 >an LMAP agent >> > not controlled by the provider offering IP connectivity.=20 >This IP Network >> > Provider may install filters to discard some traffic (e.g., detect >> > active probe) or to assign high priority to some flows=20 >(e.g., service- >> > sensitive data). The outcome of the LMAP measurement=20 >requests will hit >> > those filters and therefore won't reflect the actual=20 >network performance >> > but will return the outcome of enforcing these policies. A typical >> > example of policies is any CAC installed at the first IP router. >> > >> > > >> > >Regards, >> > > >> > >Dan >> > > >> > > >> > > >> > > >> > >> -----Original Message----- >> > >> From: mohamed.boucadair@orange.com >> > >[mailto:mohamed.boucadair@orange.com] >> > >> Sent: Thursday, February 28, 2013 9:29 AM >> > >> To: Romascanu, Dan (Dan); lmap@ietf.org >> > >> Subject: RE: security considerations for LMAP >> > >> >> > >> Dear Dan, >> > >> >> > >> FWIW, there are some security-related items listed in >> > >>=20 >http://tools.ietf.org/html/draft-boucadair-lmap-considerations-00: >> > >> >> > >> Q10: How to control access to measurement results? How >> > >to prevent >> > >> revealing measurement results to external parties? >> > >> Q20: How the system is designed to ensure topology hiding? >> > >> >> > >> And the following ietm on the impact of policies: >> > >> Q16: How to make sure measurement data accurately=20 >reflect the >> > >> network performance and not the policies=20 >enforced in that >> > >> network? >> > >> >> > >> At this stage, we have only questions ... >> > >> >> > >> Cheers, >> > >> Med >> > >> >> > >> >-----Message d'origine----- >> > >> >De : lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] >> > >De la part de >> > >> >Romascanu, Dan (Dan) Envoy=E9 : mercredi 27 f=E9vrier 2013=20 >19:27 =C0 : >> > >> >lmap@ietf.org Objet : [lmap] security considerations for LMAP >> > >> > >> > >> >Hi, >> > >> > >> > >> >I would like to raise one issue which I believe needs more >> > >discussions >> > >> >and clarifications as we prepare for the LMAP BOF and this >> > >is related >> > >> >to the security aspects of the use cases and the security >> > >requirements >> > >> >that we shall need to place on solutions. The use cases I-D >> > >> >(draft-linsner-lmap-use-cases-02) >> > >> >has a void Security Considerations section, and so does >> > >> >draft-boucadair-lmap-considerations-00. This is fine at >> > >this point in >> > >> >time but obviously can't stay like this. Only >> > >> >draft-eardley-lmap-framework-01 deals with part of the >> > >security aspects >> > >> >but more from the perspective of protecting the measurement >> > >information >> > >> >and storage. >> > >> > >> > >> >The use cases however seem to raise a few potential >> > >concerns related to >> > >> >the information that is being accessed by different=20 >entities, who is >> > >> >authorized to collect and what in large-scale measurements. >> > >I can see >> > >> >three possible interfaces that can raise such concerns: >> > >> > >> > >> >1. The ISP and Multi-Provider use cases mention the need of one >> > >> >provider having visibility and access into the measurements >> > >of another >> > >> >provider - to debug specific performance problems, to realize >> > >> >benchmarking and competitor insight, etc. This can be >> > >problematic and >> > >> >needs to put in place proper mechanisms of authorization, >> > >as different >> > >> >providers may be in different type of relations, they=20 >would like to >> > >> >control what information is made available to=20 >competitors and none >> > >> >would accept full visibility of its own internal data 2. The >> > >> >ISP-customer use case: Understanding the quality experienced by >> > >> >customers requires deployment of either software or in some >> > >scenarios >> > >> >hardware probes at the customers sites or on the edge.=20 >This raises >> > >> >similar problems of visibility as in the previous=20 >phase, as well as >> > >> >issues related to privacy protection which may be subject >> > >to local or >> > >> >regional (for example European) laws and regulations=20 >on privacy. >> > >> >3. The regulator case: Having regulators gather, store=20 >and process >> > >> >broadband traffic information in domains owned by ISPs=20 >raises also >> > >> >issues of authorization of access to such information.=20 >Hopefully >> > >> >development and enforcement of broadband policies will >> > >become part of >> > >> >the regulation and legislation and these details will be worked >> > >> >eventually out, but until they do and even afterwards >> > >proper mechanisms >> > >> >need to be in place in order to control authorization=20 >and protect >> > >> >information of the different levels of providers. >> > >> > >> > >> >Thoughts? Opinions? >> > >> > >> > >> >Regards, >> > >> > >> > >> >Dan >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >_______________________________________________ >> > >> >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 acmorton@att.com Thu Feb 28 07:21:19 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 10A0A21F8589 for ; Thu, 28 Feb 2013 07:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.309 X-Spam-Level: X-Spam-Status: No, score=-105.309 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_00=-2.599, MANGLED_AVOID=2.3, 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 N0SBIicptJGq for ; Thu, 28 Feb 2013 07:21:17 -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 7673E21F8523 for ; Thu, 28 Feb 2013 07:21:17 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id B46891207E9; Thu, 28 Feb 2013 10:23:51 -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 261BCEFC1A; Thu, 28 Feb 2013 10:21:17 -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, 28 Feb 2013 10:21:16 -0500 From: "MORTON JR., ALFRED (AL)" To: "mohamed.boucadair@orange.com" , "Romascanu, Dan (Dan)" , "lmap@ietf.org" Date: Thu, 28 Feb 2013 10:21:15 -0500 Thread-Topic: security considerations for LMAP Thread-Index: Ac4VGAgYeZY94tNfSW+edT4RUeQ0EwAbCWFgAAdPe/AAArVlgAAAcH3gAARlsGAAAKSm8AAAmrlA Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA099307@AZ-FFEXMB04.global.avaya.com> <94C682931C08B048B7A8645303FDC9F36EB47D73F4@PUEXCB1B.nanterre.francetelecom.fr> <9904FB1B0159DA42B0B887B7FA8119CA09A14F@AZ-FFEXMB04.global.avaya.com> <94C682931C08B048B7A8645303FDC9F36EB47D75AD@PUEXCB1B.nanterre.francetelecom.fr> <9904FB1B0159DA42B0B887B7FA8119CA09A20B@AZ-FFEXMB04.global.avaya.com> <94C682931C08B048B7A8645303FDC9F36EB47D76D7@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB47D76D7@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] security considerations for 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, 28 Feb 2013 15:21:19 -0000 Hi Med, Business impact for performance measurements is not new. > [Med said] ...a customer running an LMAP agent (not controlled by the > network provider) may contact the hotline to complain about the quality o= f > the service as measured using an LMAP-based system (because of the > measured data not because of the delivered service itself). remove "LMAP" from the sentence above, and you've described something that happens many times each day, on many different hotlines. > [Med said] Does it make sense to design the system to detect the presence= of such > policies and return alarms to the user? > Should LMAP steup procedure include a phase to assess whether collected > data is not impacted by installed policies (e.g., using some heuristics)? > Are these considerations in scope or not? Both the detection of policies and methods to assess them can be useful, but the LMAP activity as described in the BoF proposal would look to others (possibly IPPM) to design the metrics and methods of measurement. The tests that are actually run might described in a regional characterizat= ion plan, again this plan would be prepared outside the specific LMAP work prop= osed. So, yes, possibly, and no (for LMAP as currently described) are the answers= , IMO. >=20 > Calling out these considerations in LMAP is useful. Of course, so the information is not overlooked by others. hope this helps, Al > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Thursday, February 28, 2013 9:52 AM > To: MORTON JR., ALFRED (AL); Romascanu, Dan (Dan); lmap@ietf.org > Subject: RE: security considerations for LMAP >=20 > Dear Al, >=20 > Thanks for the pointers. >=20 > The story may be different for LMAP as the collected data may have some > business impact: a customer running an LMAP agent (not controlled by the > network provider) may contact the hotline to complain about the quality o= f > the service as measured using an LMAP-based system (because of the > measured data not because of the delivered service itself). >=20 > Does it make sense to design the system to detect the presence of such > policies and return alarms to the user? > Should LMAP steup procedure include a phase to assess whether collected > data is not impacted by installed policies (e.g., using some heuristics)? > Are these considerations in scope or not? >=20 > Calling out these considerations in LMAP is useful. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De : MORTON JR., ALFRED (AL) [mailto:acmorton@att.com] > >Envoy=E9 : jeudi 28 f=E9vrier 2013 15:43 > >=C0 : Romascanu, Dan (Dan); BOUCADAIR Mohamed OLNC/OLN; lmap@ietf.org > >Objet : RE: security considerations for LMAP > > > >Dan and Med, > > > >> > >> Q16: How to make sure measurement data accurately > >reflect the > >> > >> network performance and not the policies > >enforced in that > >> > >> network? > > > >> > >[Dan] Q16 - I confess I understand this one less. I > >thought measurements > >> > >would mainly reflect (real) network performance > >> > > >> > Med: An example to illustrate the concern raised in Q16 is > >an LMAP agent > >> > not controlled by the provider offering IP connectivity. > >This IP Network > >> > Provider may install filters to discard some traffic (e.g., detect > >> > active probe) or to assign high priority to some flows > >(e.g., service- > >> > sensitive data). The outcome of the LMAP measurement > >requests will hit > >> > those filters and therefore won't reflect the actual > >network performance > >> > but will return the outcome of enforcing these policies. A typical > >> > example of policies is any CAC installed at the first IP router. > > > >This question has been the topic of consideration in IPPM literature. > >For example: > >http://tools.ietf.org/html/rfc2679#section-6 > > > >... The measurements themselves could be harmed by routers giving > > measurement traffic a different priority than "normal" > >traffic, or by > > an attacker injecting artificial measurement traffic. If > >routers can > > recognize measurement traffic and treat it separately, the > > measurements will not reflect actual user traffic. If an attacker > > injects artificial traffic that is accepted as legitimate, the loss > > rate will be artificially lowered. Therefore, the measurement > > methodologies SHOULD include appropriate techniques to reduce the > > probability measurement traffic can be distinguished from "normal" > > traffic. Authentication techniques, such as digital signatures, may > > be used where appropriate to guard against injected traffic attacks. > > > >For more examples, see the Security sections of > > > >http://tools.ietf.org/html/rfc3432#section-6.3 > > > >http://tools.ietf.org/html/rfc4656#page-38 > > > >and finally, the latest appreciation of this topic: > >http://tools.ietf.org/html/draft-morton-ippm-2330-update-01 > > > >There's always some refinement to do, but LMAP work has a reasonable > >foundation to stand on in this particular area. > > > >regards, > >Al > > > >> -----Original Message----- > >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] > >On Behalf Of > >> Romascanu, Dan (Dan) > >> Sent: Thursday, February 28, 2013 7:24 AM > >> To: mohamed.boucadair@orange.com; lmap@ietf.org > >> Subject: Re: [lmap] security considerations for LMAP > >> > >> Hi Med, > >> > >> I got it. Makes sense, although I would point that this > >concern is not > >> necessarily a security concern, or only a security concern. > >In a broader > >> context the security requirement would be related to the > >danger of and > >> protection against the intentional or unintentional > >mis-configuration of > >> probes, servers or any other entities involved in LMAP. > >> > >> Regards, > >> > >> Dan > >> > >> > >> > >> > >> > -----Original Message----- > >> > From: mohamed.boucadair@orange.com > >[mailto:mohamed.boucadair@orange.com] > >> > Sent: Thursday, February 28, 2013 2:19 PM > >> > To: Romascanu, Dan (Dan); lmap@ietf.org > >> > Subject: RE: security considerations for LMAP > >> > > >> > Re-, > >> > > >> > Please see inline. > >> > > >> > Cheers, > >> > Med > >> > > >> > >-----Message d'origine----- > >> > >De : Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > >Envoy=E9 : jeudi 28 > >> > >f=E9vrier 2013 11:56 =C0 : BOUCADAIR Mohamed OLNC/OLN; > >lmap@ietf.org Objet > >> > >: RE: security considerations for LMAP > >> > > > >> > >Hi Mohamed, > >> > > > >> > >Thanks for pointing these. > >> > > > >> > >A quick mapping of the questions to the three interfaces (use > >> > >cases) I described in my mail shows: > >> > > > >> > >Q10 - applies to all use cases > >> > >Q20 especially applies to #1 - my experience is that ISPs > >consider each > >> > >their own topology and information about it as an asset > >to protect and > >> > >keep confidential and would be very reluctant if large-scale > >> > >measurement would make this information accessible to competitors > >> > > >> > Med: Yes, this is one aspect. > >> > > >> > >Q16 - I confess I understand this one less. I thought measurements > >> > >would mainly reflect (real) network performance > >> > > >> > Med: An example to illustrate the concern raised in Q16 is > >an LMAP agent > >> > not controlled by the provider offering IP connectivity. > >This IP Network > >> > Provider may install filters to discard some traffic (e.g., detect > >> > active probe) or to assign high priority to some flows > >(e.g., service- > >> > sensitive data). The outcome of the LMAP measurement > >requests will hit > >> > those filters and therefore won't reflect the actual > >network performance > >> > but will return the outcome of enforcing these policies. A typical > >> > example of policies is any CAC installed at the first IP router. > >> > > >> > > > >> > >Regards, > >> > > > >> > >Dan > >> > > > >> > > > >> > > > >> > > > >> > >> -----Original Message----- > >> > >> From: mohamed.boucadair@orange.com > >> > >[mailto:mohamed.boucadair@orange.com] > >> > >> Sent: Thursday, February 28, 2013 9:29 AM > >> > >> To: Romascanu, Dan (Dan); lmap@ietf.org > >> > >> Subject: RE: security considerations for LMAP > >> > >> > >> > >> Dear Dan, > >> > >> > >> > >> FWIW, there are some security-related items listed in > >> > >> > >http://tools.ietf.org/html/draft-boucadair-lmap-considerations-00: > >> > >> > >> > >> Q10: How to control access to measurement results? How > >> > >to prevent > >> > >> revealing measurement results to external parties? > >> > >> Q20: How the system is designed to ensure topology hiding? > >> > >> > >> > >> And the following ietm on the impact of policies: > >> > >> Q16: How to make sure measurement data accurately > >reflect the > >> > >> network performance and not the policies > >enforced in that > >> > >> network? > >> > >> > >> > >> At this stage, we have only questions ... > >> > >> > >> > >> Cheers, > >> > >> Med > >> > >> > >> > >> >-----Message d'origine----- > >> > >> >De : lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] > >> > >De la part de > >> > >> >Romascanu, Dan (Dan) Envoy=E9 : mercredi 27 f=E9vrier 2013 > >19:27 =C0 : > >> > >> >lmap@ietf.org Objet : [lmap] security considerations for LMAP > >> > >> > > >> > >> >Hi, > >> > >> > > >> > >> >I would like to raise one issue which I believe needs more > >> > >discussions > >> > >> >and clarifications as we prepare for the LMAP BOF and this > >> > >is related > >> > >> >to the security aspects of the use cases and the security > >> > >requirements > >> > >> >that we shall need to place on solutions. The use cases I-D > >> > >> >(draft-linsner-lmap-use-cases-02) > >> > >> >has a void Security Considerations section, and so does > >> > >> >draft-boucadair-lmap-considerations-00. This is fine at > >> > >this point in > >> > >> >time but obviously can't stay like this. Only > >> > >> >draft-eardley-lmap-framework-01 deals with part of the > >> > >security aspects > >> > >> >but more from the perspective of protecting the measurement > >> > >information > >> > >> >and storage. > >> > >> > > >> > >> >The use cases however seem to raise a few potential > >> > >concerns related to > >> > >> >the information that is being accessed by different > >entities, who is > >> > >> >authorized to collect and what in large-scale measurements. > >> > >I can see > >> > >> >three possible interfaces that can raise such concerns: > >> > >> > > >> > >> >1. The ISP and Multi-Provider use cases mention the need of one > >> > >> >provider having visibility and access into the measurements > >> > >of another > >> > >> >provider - to debug specific performance problems, to realize > >> > >> >benchmarking and competitor insight, etc. This can be > >> > >problematic and > >> > >> >needs to put in place proper mechanisms of authorization, > >> > >as different > >> > >> >providers may be in different type of relations, they > >would like to > >> > >> >control what information is made available to > >competitors and none > >> > >> >would accept full visibility of its own internal data 2. The > >> > >> >ISP-customer use case: Understanding the quality experienced by > >> > >> >customers requires deployment of either software or in some > >> > >scenarios > >> > >> >hardware probes at the customers sites or on the edge. > >This raises > >> > >> >similar problems of visibility as in the previous > >phase, as well as > >> > >> >issues related to privacy protection which may be subject > >> > >to local or > >> > >> >regional (for example European) laws and regulations > >on privacy. > >> > >> >3. The regulator case: Having regulators gather, store > >and process > >> > >> >broadband traffic information in domains owned by ISPs > >raises also > >> > >> >issues of authorization of access to such information. > >Hopefully > >> > >> >development and enforcement of broadband policies will > >> > >become part of > >> > >> >the regulation and legislation and these details will be worked > >> > >> >eventually out, but until they do and even afterwards > >> > >proper mechanisms > >> > >> >need to be in place in order to control authorization > >and protect > >> > >> >information of the different levels of providers. > >> > >> > > >> > >> >Thoughts? Opinions? > >> > >> > > >> > >> >Regards, > >> > >> > > >> > >> >Dan > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> >_______________________________________________ > >> > >> >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 acmorton@att.com Thu Feb 28 16:06: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 A77BA21F89C7 for ; Thu, 28 Feb 2013 16:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.426 X-Spam-Level: X-Spam-Status: No, score=-106.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 E0r4yu6WbmzT for ; Thu, 28 Feb 2013 16:06:49 -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 1CFB821F892C for ; Thu, 28 Feb 2013 16:06:49 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 188FA1206C2; Thu, 28 Feb 2013 19:09:24 -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 A7638F00EA; Thu, 28 Feb 2013 19:06:48 -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, 28 Feb 2013 19:06:48 -0500 From: "MORTON JR., ALFRED (AL)" To: "lmap@ietf.org" , "j.schoenwaelder@jacobs-university.de" Date: Thu, 28 Feb 2013 19:06:47 -0500 Thread-Topic: Question on draft-schoenw-lmap-netconf-00.txt Thread-Index: AQHOFhCq8vL6xALA9UOXtGygvA88iA== Message-ID: 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 Subject: [lmap] Question on draft-schoenw-lmap-netconf-00.txt 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 Mar 2013 00:06:49 -0000 Hi Juergen, A question on your draft, which otherwise presents a clear examination of NETCONF applicability to the LMAP MA-Controller-Collector communications= . 4.4. Pushing of Measurement Results NETCONF has not been designed as a data push protocol. While a NETCONF extension [RFC5277] provides support for event notifications, this mechanism requires in its simplest form that a NETCONF client first subscribes to an event stream and that the session used to carry event notification stays open. This is not scalable in the LMAP scenario. ...< short description of an alternative snipped > ... That said, if close to soft real-time pushing of measurement results form the MA to the collector is required, then NETCONF likely is not the right choice. This last sentence left me wondering. What about the demands of=20 near-real-time reporting would be difficult for NETCONF ? We might still look at NETCONF's ability relative to other existing protocols, unless you believe it should be ruled= -out. This near-real-time-push capability would be important for some use cases, such as the subscriber call to the SP hotline mentioned earlier today.=20 regards, Al From j.schoenwaelder@jacobs-university.de Thu Feb 28 23:39: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 5808C21F8833 for ; Thu, 28 Feb 2013 23:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 B+j1Uf+Wgy7p for ; Thu, 28 Feb 2013 23:39:35 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4716721F87EA for ; Thu, 28 Feb 2013 23:39:35 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E64320BD5; Fri, 1 Mar 2013 08:39:34 +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 eXCvHQLn8bWU; Fri, 1 Mar 2013 08:39:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AAB8820A6D; Fri, 1 Mar 2013 08:39:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9F85524C67A6; Fri, 1 Mar 2013 08:39:43 +0100 (CET) Date: Fri, 1 Mar 2013 08:39:43 +0100 From: Juergen Schoenwaelder To: "MORTON JR., ALFRED (AL)" Message-ID: <20130301073943.GA87466@elstar.local> Mail-Followup-To: "MORTON JR., ALFRED (AL)" , "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] Question on draft-schoenw-lmap-netconf-00.txt 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: Fri, 01 Mar 2013 07:39:36 -0000 On Thu, Feb 28, 2013 at 07:06:47PM -0500, MORTON JR., ALFRED (AL) wrote: > Hi Juergen, > > A question on your draft, which otherwise presents a clear examination > of NETCONF applicability to the LMAP MA-Controller-Collector communications. > > 4.4. Pushing of Measurement Results > > NETCONF has not been designed as a data push protocol. While a > NETCONF extension [RFC5277] provides support for event notifications, > this mechanism requires in its simplest form that a NETCONF client > first subscribes to an event stream and that the session used to > carry event notification stays open. This is not scalable in the > LMAP scenario. > ...< short description of an alternative snipped > ... > > That said, if close to soft real-time pushing of measurement results > form the MA to the collector is required, then NETCONF likely is not > the right choice. > > This last sentence left me wondering. What about the demands of > near-real-time reporting would be difficult for NETCONF ? > > We might still look at NETCONF's ability > relative to other existing protocols, unless you believe it should be ruled-out. > This near-real-time-push capability would be important for some use cases, > such as the subscriber call to the SP hotline mentioned earlier today. I think there are two options: 1) Test results are recorded in the data model maintained by the NETCONF server and a NETCONF client pulls the results. 2) Test results are pushed asynchronously as notifications towards the NETCONF client. If there is a decent call-home solution, then both can likely be made to work, perhaps even combinations like notification triffered pulls. For the use case you have in mind, a single protocol like NETCONF would likely even provide benefits - you could define a new NETCONF operation that runs a test and returns the results. Again, the challenge is the call home mechanism - if the MA is behind a NAT, how do you establish a connection to it when the subscriber calls? I think the sentence that left you wondering should probably not given too much weight. The question really is whether under normal operation soft real-time pushing is needed or even desirable. It seems certain MAs tend to collect results locally and then send results in batches, which makes a lot of sence. This kind of batch delivery seems feasible with NETCONF. Constant streaming is likely undesirable regardless choice of the protocol since keeping a large number of transports open (including security state) all the time seems not scalable. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103