From nobody Sat Nov 1 03:09:51 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CE41A6F57 for ; Sat, 1 Nov 2014 03:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UELqk09mMBnc for ; Sat, 1 Nov 2014 03:09:45 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.249]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5B71A6F3C for ; Sat, 1 Nov 2014 03:09:44 -0700 (PDT) Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 5A/46-24532-561B4545; Sat, 01 Nov 2014 10:09:41 +0000 X-Env-Sender: frode.sorensen@npt.no X-Msg-Ref: server-16.tower-21.messagelabs.com!1414836580!8629858!1 X-Originating-IP: [213.225.64.154] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25277 invoked from network); 1 Nov 2014 10:09:41 -0000 Received: from unknown (HELO EXCAS.npta.no) (213.225.64.154) by server-16.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 1 Nov 2014 10:09:41 -0000 Received: from EXMBX01.npta.no ([10.10.2.97]) by EXCAS.npta.no ([fe80::b007:5474:dccd:c4dd%11]) with mapi id 14.02.0387.000; Sat, 1 Nov 2014 11:09:40 +0100 From: =?utf-8?B?U8O4cmVuc2VuLCBGcm9kZQ==?= To: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= , "lmap@ietf.org" Thread-Topic: [lmap] FW: New Version Notification for draft-deng-lmap-collaboration-02.txt Thread-Index: Ac/1utWjINTTdAcSSryyeelLQlIT1A== Date: Sat, 1 Nov 2014 10:09:39 +0000 Message-ID: <793D91975B99224DA9777562FF192808A472225F@exmbx01> Accept-Language: nb-NO, en-US Content-Language: nb-NO X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.2.44] x-tm-as-product-ver: SMEX-11.0.0.1251-7.500.1018-21066.003 x-tm-as-result: No--43.483700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/57i-c-ofg-fwrpfl2vTDCb7eCvI Cc: "'Huangyihong \(Rachel\)'" , 'duan' Subject: Re: [lmap] FW: New Version Notification for draft-deng-lmap-collaboration-02.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 10:09:49 -0000 RGVhciBMaW5nbGkgJiBSYWNoZWwgJiBTaGlodWksIGRlYXIgYWxsLA0KDQpUaGFua3MgZm9yIGFu IHVwZGF0ZWQgb2YgdGhlIExNQVAgY29sbGFib3JhdGlvbiBkcmFmdCEgQmVsb3cgeW91IGZpbmQg YSBmZXcgY29tbWVudHMgb2YgbWluZSB0cnlpbmcgdG8gY2xhcmlmeSB0aGUgZGlzdGluY3Rpb24g YmV0d2VlbiByZWd1bGF0b3IncyBhbmQgSVNQJ3MgcmVzcG9uc2liaWxpdGllcy4gSSBob3BlIHlv dSdsbCBmaW5kIHRoZXNlIHN1Z2dlc3Rpb25zIGhlbHBmdWwuIA0KDQpGcm9kZQ0KDQoNClNlY3Rp b24gMSwgbGFzdCBwYXJhZ3JhcGgNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU3Vn Z2VzdGVkIG5ldyB3b3JkaW5nOg0KDQpUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyB0aGUgbW90aXZh dGlvbiBhbmQgdXNlLWNhc2VzIGZvciBjb2xsYWJvcmF0aXZlIExNQVAgcHJhY3RpY2VzLCB3aGVy ZSBtdWx0aXBsZSBhdXRvbm9tb3VzIG1lYXN1cmVtZW50IHN5c3RlbXMgY29sbGFib3JhdGUgdG9n ZXRoZXIgdG8gYXNzaXN0IHdpdGggZW5oYW5jaW5nIFFvRSBieSBJQ1BzLCBtb25pdG9yaW5nIG5l dHdvcmsgcGVyZm9ybWFuY2UgdG8gZ3VpZGUgSVNQcycgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBw bGFubmluZywgcGVyZm9ybWluZyBjcm9zcy1ib3VuZGFyeSB0cm91Ymxlc2hvb3RpbmcgZm9yIFNM QSBjb21wbGFpbnRzIGZyb20gZW5kIGNvbnN1bWVycywgYXMgd2VsbCBhcyBwZXJmb3JtaW5nIHJl Z3VsYXRvcnkgc3VwZXJ2aXNpb24gYnkgbmF0aW9uYWwgcmVndWxhdG9ycy4NCg0KDQpTZWN0aW9u IDMsIGZpcnN0IHBhcmFncmFwaA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTdWdn ZXN0ZWQgbmV3IHdvcmRpbmc6DQoNCkVuZC10by1lbmQgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQg YW5kIHRyb3VibGUgc2hvb3RpbmcgaXMgaW1wb3J0YW50IGZvciBzb2x2aW5nIGVuZCB1c2VyJ3Mg UW9FIGlzc3VlcywgbWFuYWdpbmcgYW5kIG9wdGltaXppbmcgdGhlIG5ldHdvcmsgb2YgSW50ZXJu ZXQgU2VydmljZSBQcm92aWRlcnMsIGltcHJvdmluZyBzZXJ2aWNlIGxvZ2ljIGFuZCBhcHBsaWNh dGlvbiBkZXNpZ24gZm9yIEludGVybmV0IENvbnRlbnQgUHJvdmlkZXJzLCBleGFtaW5pbmcgdGhl IHN0YXR1cyBvZiBhbmQgZ3VpZGluZyBmdXR1cmUgcmVndWxhdGlvbiBmb3IgcmVndWxhdG9ycy4N Cg0KDQpTZWN0aW9uIDMsIHBhcmFncmFwaCBzdGFydGluZyB3aXRoICJPbiBvbmUgaGFuZCwgZm9y IHRoZSByZWd1bGF0b3IsIg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTdWdnZXN0 IGNoYW5naW5nICAiaXMgZXhwZWN0ZWQgdG8iICB0byAgIm1heSINCg0KVGhlIHBhcmFncmFwaCB3 aWxsIHRoZW4gbG9vayBsaWtlIHRoaXM6DQoNCk9uIG9uZSBoYW5kLCBmb3IgdGhlIHJlZ3VsYXRv ciwgaW4gb3JkZXIgdG8gc3RpbXVsYXRlIGxvY2FsIG5ldHdvcmsgDQpkZXZlbG9wbWVudCwgaXQg aXMgbmVjZXNzYXJ5IHRvIGhhdmUgYSBjbGVhciBwaWN0dXJlIG9mIGxvY2FsIElTUHMnDQpwZWVy aW5nIHBlcmZvcm1hbmNlIGZvciBpbnRlcndvcmtpbmcgcG9pbnRzIGFzIHdlbGwgYXMgdGhlaXIg b3duDQpuZXR3b3JrIGNvbnN0cnVjdGlvbi4gQ29uc2lkZXJpbmcgdGhlIHByb2hpYml0aXZlIGNv c3Qgb2YgYSB1bmlmaWVkDQp0aGlyZC1wYXJ0eSBkZXBsb3ltZW50IGZvciBMTUFQIE1BcyBhdCB2 YXJpb3VzIGludGVyd29ya2luZyBwb2ludHMNCmZvciBhIGxhcmdlIGdlb2dyYXBoaWMgYXJlYSwg aXQgbWF5IGJlIG1vcmUgcHJhY3RpY2FsIHRvDQptYWtlIHVzZSBvZiBJU1BzJyBhdXRvbm9tb3Vz IExNQVAgc3lzdGVtcyBmb3IgY29sbGFib3JhdGlvbi4NCg0KDQpTZWN0aW9uIDQuMi4xLCBmaXJz dCBwYXJhZ3JhcGggKyBuZXh0IHNlbnRlbmNlDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpTdWdnZXN0ZWQgbW9kaWZpZWQgdGl0bGU6IFRoZSBjdXJyZW50IHNpdHVhdGlvbiBv ZiBpdHMgb3duIHJlZ2lvbiANCg0KU3VnZ2VzdGVkIG5ldyB3b3JkaW5nOg0KDQpVbmRlcnN0YW5k aW5nIHRoZSBjdXJyZW50IHNpdHVhdGlvbiBvZiBpdHMgb3duIHJlZ2lvbiBpcyBuZWNlc3Nhcnkg Zm9yIGEgcmVndWxhdG9yIHRvIGZvcm0gZ3VpZGluZyBwb2xpY2llcyBmb3Igc3RpbXVsYXRpbmcg ZnVydGhlciBncm93dGggaW4gaGlnaC1zcGVlZCBuZXR3b3JrIGRldmVsb3BtZW50LiBJbiBvcmRl ciB0byBnZXQgYSBjbGVhciBwaWN0dXJlIG9mIGEgbGFyZ2UgZ2VvZ3JhcGhpYyBhcmVhLCBpdCBt YXkgYmUgcHJvaGliaXRpdmUgZm9yIHRoZSByZWd1bGF0b3IgdG8gZGVwbG95IGEgZGVkaWNhdGVk IExNQVAgc3lzdGVtIG9uIGl0cyBvd24sIHdoaWxlIGl0J3MgbmVjZXNzYXJ5IHRvIGRlcGxveSBh IGxhcmdlIG51bWJlciBvZiBNQXMuIEZvciBhIHNtYWxsIHJlZ2lvbiwgdGhlIGRlcGxveW1lbnQg Y29zdCBpcyBhY2NlcHRhYmxlLCBidXQgZm9yIGEgbGFyZ2UgcmVnaW9uLCB0aGUgY29zdCBpcyB2 ZXJ5IGV4cGVuc2l2ZSBhbmQgbWF5IGJlY29tZSB1bmFjY2VwdGFibGUuIFRoZSByZWd1bGF0b3Ig bWF5IGFjaGlldmUgdGhpcyBnb2FsIGJ5IG1lYW5zIG9mIHRoZSBJU1AncyBMTUFQIGFuZCB0aGUg dGhpcmQtcGFydHkgTE1BUHMuIA0KDQpUaGVyZWZvcmUsIGl0IGlzIHByZWZlcmFibGUgdGhhdCBt dWx0aXBsZSBvcmdhbml6YXRpb25zIHdvdWxkLi4uDQoNCg0KU2VjdGlvbiA0LjIuMiwgZmlyc3Qg cGFyYWdyYXBoDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTdWdnZXN0ZWQg bmV3IHdvcmRpbmc6DQoNCkxvdyBwZXJmb3JtYW5jZSBvZiBwZWVyaW5nIGxpbmtzIGJldHdlZW4g ZGlmZmVyZW50IElTUHMgbm90IG9ubHkgaGFzIGdyZWF0IGltcGFjdCBvbiBJQ1Agc2VydmljZXMs IGJ1dCBhbHNvIG9uIGEgbG9jYWwgYWNjZXNzIElTUHMgcmVseWluZyBvbiBvdGhlciB0cmFuc2l0 IElTUHMgZm9yIGludGVybmV0IGNvbm5lY3Rpdml0eS4gRm9yIGV4YW1wbGUsIGEgbW9iaWxlDQpv cGVyYXRvciBsYWNraW5nIGFjY2VzcyB0byBhbiBpbnRlcm5ldCByZXNvdXJjZSB3aWxsIGhhdmUg dG8gcGF5IGludGVyY29ubmVjdGlvbnMgdG8gb3RoZXIgb3BlcmF0b3JzLiBUaGUgUmVndWxhdG9y IG1heSBmb3JtdWxhdGUgcG9saWNpZXMgdG8gcHJvbW90ZSBpbmZvcm1hdGlvbiBleGNoYW5nZSBi ZXR3ZWVuIElTUHMgYW5kIGludmVzdGlnYXRlIHRoZSB1c2VyIFFvRSBwcm9ibGVtIGJ5IHVuZGVy c3RhbmRpbmcgdGhlIGludGVyY29ubmVjdGlvbiBwZXJmb3JtYW5jZS4gRm9yIHRoZSBzYW1lIHJl YXNvbiwgYW4gSVNQL0lDUCBjYW4gYWxzbyBiZW5lZml0IGZyb20gYSBtb3JlIGNsZWFyIHVuZGVy c3RhbmRpbmcgb2YgdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBJbnRlcmNvbm5lY3Rpb24uDQoNCg0K DQoNCi0tLS0tT3BwcmlubmVsaWcgbWVsZGluZy0tLS0tDQpGcmE6IGxtYXAgW21haWx0bzpsbWFw LWJvdW5jZXNAaWV0Zi5vcmddIFDDpSB2ZWduZSBhdiA/Pz8vTGluZ2xpIERlbmcNClNlbmR0OiAx LiBzZXB0ZW1iZXIgMjAxNCAxMDoyNg0KVGlsOiBsbWFwQGlldGYub3JnDQpLb3BpOiAnSHVhbmd5 aWhvbmcgKFJhY2hlbCknOyAnZHVhbicNCkVtbmU6IFtsbWFwXSBGVzogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1kZW5nLWxtYXAtY29sbGFib3JhdGlvbi0wMi50eHQNCg0KSGkg YWxsLA0KDQpBIG5ldyByZXZpc2lvbiBvbiB0aGUgY29sbGFib3JhdGl2ZSBMTUFQIHVzZS1jYXNl cyBhcmUgdXBsb2FkZWQuDQoNCj4gVVJMOiANCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtZGVuZy1sbWFwLWNvbGxhYm9yYXRpb24tMDIudA0KPiB4dA0KPiBTdGF0 dXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRlbmctbG1hcC1j b2xsYWJvcmF0aW9uLw0KPiBIdG1saXplZDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZGVuZy1sbWFwLWNvbGxhYm9yYXRpb24tMDINCj4gRGlmZjoNCj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZGVuZy1sbWFwLWNvbGxhYm9yYXRpb24tMDINCg0K SW4gdGhpcyB2ZXJzaW9uLCBhIG5ldyB1c2UtY2FzZSBmb3IgY29sbGFib3JhdGlvbiBiZXR3ZWVu IG11bHRpcGxlIENvbnRyb2xsZXJzIHdpdGhpbiBhIHNpbmdsZSBkb21haW4gaXMgYWRkZWQuDQpU aGUgcmVxdWlyZW1lbnRzIHNlY3Rpb25zIGlzIHJlc3RydWN0dXJlZCwgYWZ0ZXIgYSBsaXN0IG9m IGJhc2ljIHJlcXVpcmVtZW50cywgcG90ZW50aWFsIHdheXMgb2YgaW1wbGVtZW50aW5nIGNvbGxh Ym9yYXRpdmUgTE1BUCBieSBleHRlbmRpbmcgdGhlIGN1cnJlbnQgZnJhbWV3b3JrIGFyZSBicmll Zmx5IGRpc2N1c3NlZC4NCg0KWW91ciByZXZpZXcgYW5kIGNvbW1lbnRzIHdvdWxkIGJlIGhpZ2hs eSBhcHByZWNpYXRlZC4NCg0KTGluZ2xpJlJhY2hlbCZTaGlodWkNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDAxLCAy MDE0IDQ6MTggUE0NCj4gVG86IFJhY2hlbCBIdWFuZzsgRGVuZyBMaW5nbGk7IFNoaWh1aSBEdWFu OyBTaGlodWkgRHVhbjsgTGluZ2xpIERlbmc7IA0KPiBSYWNoZWwgSHVhbmcNCj4gU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4gZHJhZnQtZGVuZy1sbWFwLWNvbGxhYm9y YXRpb24tMDIudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRlbmct bG1hcC1jb2xsYWJvcmF0aW9uLTAyLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IExpbmdsaSBEZW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgDQo+IHJlcG9zaXRvcnku DQo+IA0KPiBOYW1lOgkJZHJhZnQtZGVuZy1sbWFwLWNvbGxhYm9yYXRpb24NCj4gUmV2aXNpb246 CTAyDQo+IFRpdGxlOgkJVXNlLWNhc2VzIGZvciBDb2xsYWJvcmF0aXZlIExNQVANCj4gRG9jdW1l bnQgZGF0ZToJMjAxNC0wOS0wMQ0KPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQ YWdlczoJCTE1DQo+IFVSTDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtZGVuZy1sbWFwLWNvbGxhYm9yYXRpb24tMDIudA0KPiB4dA0KPiBTdGF0dXM6DQo+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRlbmctbG1hcC1jb2xsYWJvcmF0 aW9uLw0KPiBIdG1saXplZDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGVu Zy1sbWFwLWNvbGxhYm9yYXRpb24tMDINCj4gRGlmZjoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtZGVuZy1sbWFwLWNvbGxhYm9yYXRpb24tMDINCj4gDQo+IEFic3Ry YWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyB0aGUgbW90aXZhdGlvbiBhbmQgdXNl LWNhc2VzIGZvcg0KPiAgICBjb2xsYWJvcmF0aXZlIExNQVAgcHJhY3RpY2VzLCB3aGVyZSBtdWx0 aXBsZSBhdXRvbm9tb3VzIG1lYXN1cmVtZW50DQo+ICAgIHN5c3RlbXMgY29sbGFib3JhdGUgdG9n ZXRoZXIgdG8gaGVscCB3aXRoIFFvRSBlbmhhbmNlbWVudCBieSBJQ1BzLA0KPiAgICBuZXR3b3Jr IHBlcmZvcm1hbmNlIG1vbml0b3J5IHRvIGd1aWRlIElTUC9SZWd1bGF0b3IgY29vcmRpbmF0aW9u DQo+ICAgIGJldHdlZW4gYXV0b25vbW91cyBuZXR3b3JrIGRvbWFpbnMgYW5kL29yIHJlZ3VsYXRv cnkgcG9saWNpZXMgYW5kDQo+ICAgIGNyb3NzLWJvdW5kYXJ5IHRyb3VibGVzaG9vdGluZyBmb3Ig Y29tcGxhaW50cyBmcm9tIGVuZCBjb25zdW1lcnMuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2YgDQo+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCANCj4gdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNy ZXRhcmlhdA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KbG1hcCBtYWlsaW5nIGxpc3QNCmxtYXBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1hcA0K From nobody Sat Nov 1 03:21:38 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B251A6FE8 for ; Sat, 1 Nov 2014 03:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ea12pnWNolJA for ; Sat, 1 Nov 2014 03:21:35 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8E11A701B for ; Sat, 1 Nov 2014 03:21:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9C3F8F5F; Sat, 1 Nov 2014 11:21:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GIb4i7sknVYh; Sat, 1 Nov 2014 11:21:01 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 1 Nov 2014 11:21:33 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0D0220038; Sat, 1 Nov 2014 11:21:32 +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 95pd3nlV_pGY; Sat, 1 Nov 2014 11:21:32 +0100 (CET) Received: from exchange.jacobs-university.de (shubcas02.jacobs.jacobs-university.de [10.70.0.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 6CA5720035; Sat, 1 Nov 2014 11:21:32 +0100 (CET) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS02.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0210.002; Sat, 1 Nov 2014 11:21:32 +0100 From: "Bajpai, Vaibhav" To: Dan Romascanu Thread-Topic: [lmap] final IETF-91 agenda due Monday 11/3! Thread-Index: Ac/1UgnOn1jyZe5hS5+LcChJWm6kKgAYy8eA Date: Sat, 1 Nov 2014 10:21:32 +0000 Message-ID: <52D77DD6-C822-4D00-866F-DAE76EAE8F60@jacobs-university.de> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8E6D8F@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8E6D8F@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.203.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <380E82B683806241B42A9D9713B850B3@jacobs.jacobs-university.de> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/pkcifxNwW48-DRub9gCcqqa-sz4 Cc: "Bajpai, Vaibhav" , "lmap@ietf.org" Subject: Re: [lmap] final IETF-91 agenda due Monday 11/3! X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 10:21:37 -0000 Dear Dan, > On 31 Oct 2014, at 22:31, Romascanu, Dan (Dan) wrote= : >=20 > The preliminary agenda of the meeting at IETF-91 is available at https://= datatracker.ietf.org/meeting/91/agenda/lmap/. The final agenda is > due Monday 11/3. Please let us know if there are any missing items or > changes you want to bring to the agenda.=20 I would like to remotely present our draft: draft-bagnulo-lmap-http https://datatracker.ietf.org/doc/draft-bagnulo-lmap-http Thanks. Best, Vaibhav =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Vaibhav Bajpai Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D= From nobody Sat Nov 1 16:39:12 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218DB1A1B9E; Sat, 1 Nov 2014 16:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dwwyGHD-e50; Sat, 1 Nov 2014 16:39:08 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79DF01A1B9A; Sat, 1 Nov 2014 16:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3846; q=dns/txt; s=iport; t=1414885148; x=1416094748; h=from:to:cc:subject:date:message-id:references: mime-version; bh=EmFLKmClMAt9rTBESYkyn7GhnkGkijf9Dodnp2VVIIg=; b=ZEeTfB96e33srKyVo7dic2HD7KpdPllizPw8q2p3naGX3M7eyno1ovdI Sp53yYrSeWhoqnhYwERcwWHmSD4jJXsSD00U5eo7XaGDik43Am3LPZHBN HoPGGsZmQSah1nQakQk4mfhD2YME6hJFs1bRCeKKeosy0p0zMLe5t88/o M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAPFtVVStJV2Z/2dsb2JhbABcgw5UWATNNAqHTYEWFgEBAQEBcguEAgEBAQMBAQEBaAMLBQsCARkDAQIBLicLFAcCCAIEDgUOiCoJDckJAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSQfxENgyeBHgWPe4IfghWBUogAllCDeGyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="asc'?scan'208";a="368518100" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 01 Nov 2014 23:39:07 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sA1Nd7pD025895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 1 Nov 2014 23:39:07 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.248]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Sat, 1 Nov 2014 18:39:07 -0500 From: "Fred Baker (fred)" To: "lmap@ietf.org" Thread-Topic: [aqm] draft-ksubram-lmap-router-buffer-sizes Thread-Index: AQHP9i0GOo11WYZuaUOx9de98mDs+Q== Date: Sat, 1 Nov 2014 23:39:06 +0000 Message-ID: References: <5453CEFB.8090203@rogers.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.120] Content-Type: multipart/signed; boundary="Apple-Mail=_76B7CC69-EDFF-4FA4-9421-065092CD5AAD"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9Q9psKQdsKF6F_-wI4m6_6x7ze4 Cc: "aqm@ietf.org" Subject: [lmap] Fwd: [aqm] draft-ksubram-lmap-router-buffer-sizes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 23:39:11 -0000 --Apple-Mail=_76B7CC69-EDFF-4FA4-9421-065092CD5AAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Forwarded comments from AQM. Begin forwarded message: > From: David Collier-Brown > Subject: Re: [aqm] draft-ksubram-lmap-router-buffer-sizes > Date: October 31, 2014 at 11:03:39 AM PDT > To: > Reply-To: >=20 > It's OK, we just need to write it up as informational material and = cite it a lot. Maybe as an appendix to a congestion-related rfc, maybe = as a little bitty one on it's own. >=20 > Having said that, I guess I've just volunteered to write it. >=20 > Therefor: If someone says where it should go, so people will find it = when looking for the expected behaviour, I'll compose a draft and help = make it fit. >=20 > --dave >=20 > On 10/31/2014 10:58 AM, Daniel Havey wrote: >> Yeah, I have encountered this type of problem in many forms. It = seems that there are fundamental misunderstandings of the problem. This = seems prevalent in expert networking communities from people who have = the knowledge, but, perhaps have not thought the problem through = thoroughly. >>=20 >> I guess we are just working at cross-purposes with other communities. = Perhaps there is no cure for this problem and maybe we just have to = accept and embrace it. >>=20 >>=20 >> ...Daniel >>=20 >> On Thursday, October 30, 2014 7:00 PM, David Collier-Brown = wrote: >>=20 >>=20 >>=20 >> Yup: author makes a classic, and I fear common, wrong assumption = about tradeoffs in queuing systems. >>=20 >> Latency is minimized throughout the operating range if a queue is not = allowed to form. TCP consciously sees a queue as congestion and avoids = having it. >>=20 >> Bufferboat causes queuing, and degrades both (low) latency and >> throughput, trying to drive the link toward congestive = collapse. >> The worst of all possible worlds! >>=20 >> In this case it also tries to drive Dave Taht's circulation system >> into collapse, which is doubly ungood. >>=20 >> --dave >>=20 >>=20 >>=20 >> On 10/30/2014 09:49 AM, Dave Taht wrote: >>=20 >> I didn't get past the first sentence. "The question boils down to = quantify buffer sizes and yet achieve 100% >> utilization on links with maximum throughput at a feasible cost. " My = goal has always been to have minimal induced latency and reasonable >> utilization, and also to keep my blood pressure low. Reading further >> strikes me as damaging to both goals. On Thu, Oct 30, 2014 at 5:12 = AM, Fred Baker (fred) wrote: >>> Folks from AQM may be interested to comment on = draft-ksubram-lmap-router-buffer-sizes on the lmap list. = _______________________________________________ >> aqm mailing list aqm@ietf.org = https://www.ietf.org/mailman/listinfo/aqm >>=20 >>=20 >=20 >=20 > --=20 > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the rest > davecb@spamcop.net | -- Mark Twain >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm --Apple-Mail=_76B7CC69-EDFF-4FA4-9421-065092CD5AAD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUVW7xbjEdbHIsm0MRArzMAKD6zSSV+2VNpZusTGB73nCSMLY8CQCgh+q0 YFPeiVARcY+2QYsl/t2EYCw= =oEr5 -----END PGP SIGNATURE----- --Apple-Mail=_76B7CC69-EDFF-4FA4-9421-065092CD5AAD-- From nobody Wed Nov 5 05:57:11 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696781A8911 for ; Wed, 5 Nov 2014 05:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.594 X-Spam-Level: X-Spam-Status: No, score=-5.594 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fir-MnzsJehf for ; Wed, 5 Nov 2014 05:57:07 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24FFA1A010A for ; Wed, 5 Nov 2014 05:57:06 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMLAAMsWlTGmAcV/2dsb2JhbABcgkgjI1RduT8GmyICgRYWAQEBAQEBcQuEBAEBAxIbXgEVFVYmAQQbGogfAaRNhHGgIYY4iiiDZYEeBZIhhxeGCYNMgyCKL4QJg3iCNIEDAQEB X-IronPort-AV: E=Sophos; i="5.07,320,1413259200"; d="scan'208,217"; a="79457621" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Nov 2014 08:57:04 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 05 Nov 2014 08:57:03 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Wed, 5 Nov 2014 08:57:02 -0500 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: WANTED - note takers and jabber scribes for the meeting next week Thread-Index: Ac/5AF8+dWPBmfqqT0eeJ8Br6ML85g== Date: Wed, 5 Nov 2014 13:57:01 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8F67A5@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: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8F67A5AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/MOmBEs4wQLEQNeRHb_89XM4LAsU Subject: [lmap] WANTED - note takers and jabber scribes for the meeting next week X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 13:57:10 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8F67A5AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I order to start in time and to makes the best use of the time in the meeti= ng next week, I would like for volunteers to step up for the following impo= rtant tasks: - Taking notes in the meeting which will be used for the meeting m= inutes - we need two note takers - Scribing on Jabber - mostly with the purpose of getting question= s and comments from people who are remote - we need one Jabber scribe, it's= a very important task at this meeting, as we estimate that there will be a= higher rate than usual of remote participants. We cannot start the meeting without these three people in the room! Please volunteer - your support will be appreciated. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8F67A5AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I order to start in time and to makes the best use o= f the time in the meeting next week, I would like for volunteers to step up= for the following important tasks:

 

-     &= nbsp;    Taking notes in the meetin= g which will be used for the meeting minutes – we need two note taker= s

-     &= nbsp;    Scribing on Jabber –= mostly with the purpose of getting questions and comments from people who = are remote – we need one Jabber scribe, it’s a very important t= ask at this meeting, as we estimate that there will be a higher rate than usual of remote participants.

 

We cannot start the meeting without these three peop= le in the room!

 

Please volunteer – your support will be apprec= iated.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8F67A5AZFFEXMB04globa_-- From nobody Wed Nov 5 05:59:51 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138F41A891C for ; Wed, 5 Nov 2014 05:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.493 X-Spam-Level: X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f52d1R55Rkfm for ; Wed, 5 Nov 2014 05:59:48 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9881A8909 for ; Wed, 5 Nov 2014 05:59:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMLAAMsWlTGmAcV/2dsb2JhbABcgkgjI1RduT8GmyICgRYWAQEBAQEBcQuEBAEBAxIbXgEVFVYmAQQbGogfAaRNhHGgIYY4iiiDZYEeBZIhhxeGCYNMgyCKL4QJg3iCNIEDAQEB X-IronPort-AV: E=Sophos; i="5.07,320,1413259200"; d="scan'208,217"; a="79457985" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Nov 2014 08:59:45 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 05 Nov 2014 08:59:45 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Wed, 5 Nov 2014 08:59:44 -0500 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: WANTED - note takers and jabber scribes for the meeting next week Thread-Index: Ac/5AK4HMOAEqGJKTA6nhG8/fq2TcA== Date: Wed, 5 Nov 2014 13:59:13 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8F67F1@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: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8F67F1AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/RSrEROWgGjjnVQQb_uOdn4vRtQk Subject: [lmap] WANTED - note takers and jabber scribes for the meeting next week X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 13:59:50 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8F67F1AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In order to start in time and to make the best use of the time in the meeti= ng next week, I would like to ask for volunteers to step up for the followi= ng important tasks: - Taking notes in the meeting which will be used for the meeting m= inutes - we need two note takers - Scribing on Jabber - mostly with the purpose of getting question= s and comments from people who are remote - we need one Jabber scribe, it's= a very important task at this meeting, as we estimate that there will be a= higher rate than usual of remote participants. We cannot start the meeting without these three people in the room! Please volunteer - your support will be appreciated. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8F67F1AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In order to start in time and to make the best use o= f the time in the meeting next week, I would like to ask for volunteers to = step up for the following important tasks:

 

-     &= nbsp;    Taking notes in the meetin= g which will be used for the meeting minutes – we need two note taker= s

-     &= nbsp;    Scribing on Jabber –= mostly with the purpose of getting questions and comments from people who = are remote – we need one Jabber scribe, it’s a very important t= ask at this meeting, as we estimate that there will be a higher rate than usual of remote participants.

 

We cannot start the meeting without these three peop= le in the room!

 

Please volunteer – your support will be apprec= iated.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8F67F1AZFFEXMB04globa_-- From nobody Wed Nov 5 12:21:21 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D511ACD36 for ; Wed, 5 Nov 2014 12:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.422 X-Spam-Level: X-Spam-Status: No, score=0.422 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmOFuzfe51G3 for ; Wed, 5 Nov 2014 12:21:15 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C621A6FCB for ; Wed, 5 Nov 2014 12:18:33 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id n15so1334235lbi.4 for ; Wed, 05 Nov 2014 12:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ppY3IBU82w3E8PX/7Rc9H+JvC6oLekJEMTK0lIrd0dw=; b=laGTVAoDoBggVyTFkDTu0uspW9UFFhFAGsfaC1IlGKPv+eq6HirZjo5MoZ5p0MtzKa 3mgx4vICEOIkJLZF9dUyFtBXnTaQ9n+wyR6TQNveg0L+SXWqeP2pCYI5PzKgbw1OsJrj yuwzaO0QxOT8qxpAMLImtcEFL/7dZKLvh8nChi5CqE01q2UYKGDRoV90LdhmAJ8JgPdU EzHCTlpBk0tABgjhfsn2R0urO7quPEt1OIH3k5VPO1dZmHX+rC5hKo1Q8JJdMz05TUr/ 0fCn+qSEm2sJWwibZ+VOb8rGFH8ZfGOC9i7Tk8xj7wtiXTNc5vPdEP8of4cdryN4/rJK 1gUg== MIME-Version: 1.0 X-Received: by 10.112.200.34 with SMTP id jp2mr70707405lbc.1.1415218712254; Wed, 05 Nov 2014 12:18:32 -0800 (PST) Sender: jeferson.nobre@gmail.com Received: by 10.112.18.136 with HTTP; Wed, 5 Nov 2014 12:18:32 -0800 (PST) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8F67A5@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8F67A5@AZ-FFEXMB04.global.avaya.com> Date: Wed, 5 Nov 2014 18:18:32 -0200 X-Google-Sender-Auth: 8z_EAzwj0xnMw1WRRAhza1K804o Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9oGxSCGnmpIadcUpohw7beNBO7U Cc: "lmap@ietf.org" Subject: Re: [lmap] WANTED - note takers and jabber scribes for the meeting next week X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 20:21:17 -0000 Hi Dan. I volunteer as Jabber scribe. Cheers. J=C3=A9ferson Campos Nobre PhD Student Computer Networks Group - Institute of Informatics Federal University of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre On Wed, Nov 5, 2014 at 11:57 AM, Romascanu, Dan (Dan) wrote: > Hi, > > > > I order to start in time and to makes the best use of the time in the > meeting next week, I would like for volunteers to step up for the followi= ng > important tasks: > > > > - Taking notes in the meeting which will be used for the meeting > minutes =E2=80=93 we need two note takers > > - Scribing on Jabber =E2=80=93 mostly with the purpose of gettin= g questions > and comments from people who are remote =E2=80=93 we need one Jabber scri= be, it=E2=80=99s a > very important task at this meeting, as we estimate that there will be a > higher rate than usual of remote participants. > > > > We cannot start the meeting without these three people in the room! > > > > Please volunteer =E2=80=93 your support will be appreciated. > > > > Thanks and Regards, > > > > Dan > > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > From nobody Sat Nov 8 04:18:16 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFF71A6FEE for ; Sat, 8 Nov 2014 04:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.493 X-Spam-Level: X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHbN-bEPFUIm for ; Sat, 8 Nov 2014 04:18:10 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BE91A6FE4 for ; Sat, 8 Nov 2014 04:18:00 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjELAJMJXlTGmAcV/2dsb2JhbABbgkgjI1RZBLgIAQEBAQEBBpMaCB0BCYZ6VQKBGxYBAQEBAQFxC4QCAQEBAQMBAQEPG0EdAQgNBAQBAQsdCSULFAcBAQUEAQQTCAYUiB8BDKhyhHGgFQEBAQEBAQEDAQEBAQEBAQEWBIY4iXcRAR8tCoMugR4FhGqNPYIZgVJphEqEB4NOgyCOPIN5bIEPOYEDAQEB X-IronPort-AV: E=Sophos;i="5.07,340,1413259200"; d="txt'?scan'208,217";a="93781346" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 08 Nov 2014 07:17:40 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 08 Nov 2014 07:17:29 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Sat, 8 Nov 2014 07:17:28 -0500 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [91attendees] New draft offers suggestions/guidance for Jabber scribes... Thread-Index: Ac/7Te78vh6tH+Z4R1WLfgfNo+kqJw== Date: Sat, 8 Nov 2014 12:17:27 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8FA0C3@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/mixed; boundary="_004_9904FB1B0159DA42B0B887B7FA8119CA5C8FA0C3AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/-_hc0l1ItLWd0fSz-hvVaQBLYf4 Subject: [lmap] FW: [91attendees] New draft offers suggestions/guidance for Jabber scribes... X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 12:18:13 -0000 --_004_9904FB1B0159DA42B0B887B7FA8119CA5C8FA0C3AZFFEXMB04globa_ Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8FA0C3AZFFEXMB04globa_" --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8FA0C3AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Recommendations for the brave volunteer who will support the meeting this w= eek is taking jabber notes. It's an even more important mission this time as we expect a higher than us= ual rate of remote attendees at this meeting. Thanks and Regards, Dan From: 91attendees [mailto:91attendees-bounces@ietf.org] On Behalf Of Dan Yo= rk Sent: Friday, November 07, 2014 6:14 PM To: 91attendees@ietf.org Subject: [91attendees] New draft offers suggestions/guidance for Jabber scr= ibes... IETF 91 attendees, If you are going to serve as a "Jabber scribe" in meetings next week at IET= F 91 (or wind up being asked to do that), Peter St. Andre and I tried to ca= pture some of the experiences we and others have had as Jabber scribes and = advice we've received from others in a new draft: https://tools.ietf.org/html/draft-saintandre-chatroom-relay-02 Our hope is that this can be helpful to people who might get tasked with pe= rforming this role that is so VERY critical for remote attendees. I'd also encourage folks who haven't considered it to volunteer as jabber s= cribes. I do it often because I've been a remote attendee and know how muc= h I came to rely on the scribe relay... and also because it's a great way t= o learn the names of people involved with a working group and to get involv= ed with helping out with the IETF processes. (And also quite frankly becau= se it forces me to pay attention to what's happening in the room instead of= wandering off into email or something...) Anyway... the draft is out there and we would welcome any feedback that peo= ple have. If you are doing jabber scribing (or what we called "chatroom re= lay" to be product-neutral) next week at IETF 91 and come up with any addit= ional tips or tricks, please do let us know. The goal is to help provide s= uggestions that can make this role work smoother and easier and through tha= t to help improve the experience for remote attendees. Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8FA0C3AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Recommendations for the b= rave volunteer who will support the meeting this week is taking jabber note= s.

 <= /p>

It’s an even more i= mportant mission this time as we expect a higher than usual rate of remote = attendees at this meeting.

 <= /p>

Thanks and Regards,<= /o:p>

 <= /p>

Dan

 <= /p>

 <= /p>

From: 91attend= ees [mailto:91attendees-bounces@ietf.org] On Behalf Of Dan York
Sent: Friday, November 07, 2014 6:14 PM
To: 91attendees@ietf.org
Subject: [91attendees] New draft offers suggestions/guidance for Jab= ber scribes...

 

IETF 91 attendees,

 

If you are going to serve as a "Jabber scribe&q= uot; in meetings next week at IETF 91 (or wind up being asked to do that), = Peter St. Andre and I tried to capture some of the experiences we and other= s have had as Jabber scribes and advice we've received from others in a new draft:

 

 

Our hope is that this can be helpful to people who m= ight get tasked with performing this role that is so VERY critical for remo= te attendees.

 

I'd also encourage folks who haven't considered it t= o volunteer as jabber scribes.  I do it often because I've been a remo= te attendee and know how much I came to rely on the scribe relay... and als= o because it's a great way to learn the names of people involved with a working group and to get involved with hel= ping out with the IETF processes.  (And also quite frankly because it = forces me to pay attention to what's happening in the room instead of wande= ring off into email or something...)

 

Anyway... the draft is out there and we would welcom= e any feedback that people have.  If you are doing jabber scribing (or= what we called "chatroom relay" to be product-neutral) next week= at IETF 91 and come up with any additional tips or tricks, please do let us know.  The goal is to help provide sugges= tions that can make this role work smoother and easier and through that to = help improve the experience for remote attendees.

 

Dan

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8FA0C3AZFFEXMB04globa_-- --_004_9904FB1B0159DA42B0B887B7FA8119CA5C8FA0C3AZFFEXMB04globa_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=148; creation-date="Fri, 07 Nov 2014 16:14:40 GMT"; modification-date="Fri, 07 Nov 2014 16:14:40 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCjkxYXR0ZW5k ZWVzIG1haWxpbmcgbGlzdA0KOTFhdHRlbmRlZXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vOTFhdHRlbmRlZXMNCg== --_004_9904FB1B0159DA42B0B887B7FA8119CA5C8FA0C3AZFFEXMB04globa_-- From nobody Sat Nov 8 05:00:25 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E021A7034 for ; Sat, 8 Nov 2014 05:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.493 X-Spam-Level: X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzUyXPpWTsxB for ; Sat, 8 Nov 2014 05:00:17 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA9F1A6FEE for ; Sat, 8 Nov 2014 05:00:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhULAFkTXlTGmAcV/2dsb2JhbABbgkgjI1RduAcBAQEBAQEGmxgCgRsWAQEBAQEBcQuEBAEBAxIbXgEMCRVWJgEEGxqIHwGpA4RxoBMMAR+GOIoLHYNlgR4FkieNJYNOgyCOPIN5gjSBAwEBAQ X-IronPort-AV: E=Sophos; i="5.07,340,1413259200"; d="scan'208,217"; a="79887011" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Nov 2014 08:00:14 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 08 Nov 2014 08:00:14 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Sat, 8 Nov 2014 14:00:12 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: please send presentations in advance! Thread-Index: Ac/7U+4OYhEHt4DTT3mqlqs6LzfE2Q== Date: Sat, 8 Nov 2014 13:00:12 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8FA717@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: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8FA717AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/8mgcOh0qcuBgSFiXK419uSFy1Ss Subject: [lmap] please send presentations in advance! X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 13:00:21 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8FA717AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you own agenda items in the meeting at IETF-91 and you plan to use any p= ower-point (or like) presentation, please sent it before the meeting, so th= at it can be made available for the remote participants. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8FA717AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you own agenda items in the meeting at IETF-91 an= d you plan to use any power-point (or like) presentation, please sent it be= fore the meeting, so that it can be made available for the remote participa= nts.

 

Thanks and Regards,

 

Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8FA717AZFFEXMB04globa_-- From nobody Sat Nov 8 23:43:15 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36301A1A13 for ; Sat, 8 Nov 2014 23:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.394 X-Spam-Level: X-Spam-Status: No, score=-12.394 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F5t3BwdV0Ur for ; Sat, 8 Nov 2014 23:43:06 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1914D1A1A10 for ; Sat, 8 Nov 2014 23:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28396; q=dns/txt; s=iport; t=1415518986; x=1416728586; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=V+fga4nkBwRG3yd7wwUyV//4QQV1kNpuSXWVCIERERM=; b=V0/4IDRbQ7S0tv3OjB/4VXjmLMYn62G64oSR5XqAIVmNAihektSd/l04 KXiwIgMj0y5M4IrDJnSQntRLOdAoKJ/9KxfIPP5RPBiBE+0F0yiZ8PiZY Uoiq1v8zVPFYfhU08vnYXiPFli9hgQ/Ssx7XBy288TCtK9nJlXpeFQUU4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAN8ZX1StJV2T/2dsb2JhbABbgw5UWQHCIolHh00CgRMWAQEBAQF9hAMBAQQaDUsGARAsFg8JAwIBAgFFBgEJAwEHAQGIPQ3MewEBAQEBAQEBAQEBAQEBAQEBAQEBAReRFQeESwWGOolUhnZXgXCEWoE0PYYJhzOHM4QeGTCCSgEBAQ X-IronPort-AV: E=Sophos;i="5.07,345,1413244800"; d="scan'208,217";a="370628210" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-3.cisco.com with ESMTP; 09 Nov 2014 07:43:04 +0000 Received: from [10.21.92.188] (sjc-vpn5-1212.cisco.com [10.21.92.188]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sA97h3a9009427; Sun, 9 Nov 2014 07:43:03 GMT Message-ID: <545F1B06.1090204@cisco.com> Date: Sat, 08 Nov 2014 21:43:02 -1000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "lmap@ietf.org" , draft-ietf-lmap-framework@tools.ietf.org References: <5451EFD9.1080702@cisco.com> In-Reply-To: <5451EFD9.1080702@cisco.com> X-Forwarded-Message-Id: <5451EFD9.1080702@cisco.com> Content-Type: multipart/alternative; boundary="------------070907050202010102050600" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/gcrXhVldEOZxxwie3NU8tc10T-g Cc: Paul Aitken , Aamer Akhter Subject: [lmap] draft-ietf-lmap-framework-08: AD review - part 1 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 07:43:11 -0000 This is a multi-part message in MIME format. --------------070907050202010102050600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is my AD review. Note: I haven't reviewed yet the section 7 "security considerations" and section 8 "privacy considerations", but thought I should anyway send this before the meeting this week. Note2: if some points were discussed already, don't hesitate to let me know. A first impression is that there are some repetitions in the draft. It seems like some sections, written by different persons, were glued together. Reading this draft again with a fresh mind would highlight this. One important issue, which I mentioned already during the interim meeting: the lack of passive monitoring aspects in the draft. Section 2 The MA may generate Measurement Traffic and measure some metric associated with its transfer, or the MA may observe existing traffic, or there may be some kind of hybrid of these two possibilities. So the document speaks a little bit about active and passive monitoring. Good, because this is mentioned in the charter: Both active and passive measurements are in scope, although there may be differences in their applicability to specific use cases, or in the security measures needed according to the threats specific to each measurement category. LMAP will not standardize performance metrics. I recall the charter discussion. I specifically asked: "do you want to have passive monitoring in the charter? Do you understand all the consequences (for example, traffic filters, for observed packet/flow, which may imply RFC6728)?". Both answers were "yes". So, the draft clearly misses the passive monitoring aspects, starting with the primary figure in this framework, figure 1, which only covers the active monitoring Some other issues, simply listed in order - These devices could be software based agents on PCs, embedded agents in consumer devices (e.g. Blu-ray players), Does a blu-ray player need a broadband test? - o Diversity - a measurement system should handle different types of Measurement Agents - for example Measurement Agents may come from different vendors, be in wired and wireless networks, be able to execute different sorts of Measurement Task and be on devices with IPv4 or IPv6 addresses. Is "different types" the right term? You have introduced the term "capabilities" - It is also useful to define a registry for commonly-used Metrics [I-D.manyfolks-ippm-metric-registry ] so that a Metric with its associated Measurement Method can be referred to simply by its identifier in the registry. The new draft is http://tools.ietf.org/html/draft-ietf-ippm-metric-registry - OLD: Finally we introduce several components that are outside the scope of initial LMAP work and will be provided through existing protocols or applications. NEW: Finally we introduce several components that are outside the scope of initial LMAP work (see in figure 1 "out of scope" and will be provided through existing protocols or applications. Then I would list four bullet points for the next paragraph. Otherwise it's not obvious which components you speak about - figure 1 * Since the above mentions the Results repository (The data analysis tools receive the results from the Collector or via the Results repository. ), the figure should replace repository by Results repository * "IPPM scope" is wrong (see my first remark) * Mention the Control Protocol and Report Protocol, or Control Channel/Report Channel. Note: if you replace Instruction by Control Protocol, then the arrow must be bidirectional (according to the Control Protocol definition) - Control Channel: A Channel between a Controller and a MA over which Instruction Messages and Capabilities, Failure and Logging Information are sent. Control Protocol: The protocol delivering Instruction(s) from a Controller to a Measurement Agent. It also delivers Capabilities, Failure and Logging Information from the Measurement Agent to the Controller. It can also be used to update the MA's Configuration. Do you want to mention that the Control Protocol runs on the Control Channel? - Measurement Method: The process for assessing the value of a Metric; the process of measuring some performance or reliability parameter associated with the transfer of traffic; where this process involves multiple MAs or MPs, each may perform different roles. I don't understand what "where this process involves multiple MAs or MPs, each may perform different roles." adds to the def. - Report Channel: A Channel between a Collector and a MA over which Report messages are sent. Report messages -> Report Messages - 4.2 An operator may have several Controllers, perhaps with a Controller for different types of MA (home gateways, tablets) or location (Ipswich, Edinburgh). BT specific, maybe? :-) - Section 5. Here is yet another example of repetition (see the last 3 bullets below. Why do you have to repeat what the Control Protocol does) An LMAP system goes through the following phases: o a Bootstrapping process before the MA can take part in the other three phases o a Control Protocol, which delivers Instruction Messages from a Controller to a MA, detailing what Measurement Tasks the MA should perform and when, and how it should report the Measurement Results. It also delivers Capabilities, Failure and logging Information from a MA to its Controller. Finally, it allows the Controller to update the MA's Configuration. o the actual Measurement Tasks, which measure some performance or reliability parameter(s) associated with the transfer of packets. The LMAP work does not define Metrics and Measurement Methods, these are defined elsewhere (e.g. IPPM). o a Report Protocol, which delivers Reports from a MA to a Collector. The Report contains the Measurement Results. - Would be nice to have "measurement system" in the terminology section. It's mentioned so many times in the draft - 5.2. Control Protocol The primary purpose of the Control Protocol is to allow the Controller to configure a Measurement Agent with an Instruction about what Measurement Tasks to do, when to do them, and how to report the Measurement Results (Section 5.2.2). The Measurement Agent then acts on the Instruction autonomously. The Control Protocol also enables the MA to inform the Controller about its Capabilities and any Failure and Logging Information (Section 5.2.2). Finally, the Control Protocol allows the Controller to update the MA's Configuration. Another example of repetition. From the terminology: Control Protocol: The protocol delivering Instruction(s) from a Controller to a Measurement Agent. It also delivers Capabilities, Failure and Logging Information from the Measurement Agent to the Controller. It can also be used to update the MA's Configuration. - section 5.2.2 Instruction: -> [(Measurement Task configuration( [Input Parameter], (interface), (Cycle-ID))), (Report Channel), (Schedule), (Suppression information)] <- Response(details) It seems from the above that "Measurement Task configuration" takes 3 arguments. I'm surprised not to see the Metric (which is described in the section btw) above. According to the Input Parameter def., I understand that the Metric is NOT part of the Input Parameter. - 5.2.2.1. Suppression The Instruction may include Suppression information. The purpose of Suppression is to enable the Controller to instruct the MA not to perform Measurement Tasks. It is used if the measurement system wants to eliminate inessential traffic, because there is some unexpected network issue for example. Again, "eliminate inessential traffic". This is an active probing only view. Same remark with o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Measurement Traffic, then it may only want to suppress the second. - 5.3.1. Starting and Stopping Measurement Tasks That's typical section completely dedicated to active probing: _Before sending Measurement Traffic_ the MA may run a pre-check. (The pre-check could be defined as a separate, preceding Task or as the first part of a larger Task.) Action could include: o_the MA checking that there is no cross-traffic_. In other words, a check that the end-user isn't already sending traffic; For passive monitoring, you typically want to check that there is traffic of interest... - 5.4.1. Reporting of Subscriber's service parameters The charter says: Service parameters, such as product category, can be useful to decide which measurements to run and how to interpret the results. These parameters are already gathered and stored by existing operations systems. Discovering the service parameters on the MAs or sharing the service parameters between MAs are out of the scope. However, if the service parameters are available to the MAs, they could be reported with the measurement results in the Report Protocol. The key sentence is: "if the service parameters are available to the MAs" I don't find back this concept in section 5.4.1 - section 5.5 It is also possible that a different choice is made for the Control and Report Protocols, for example NETCONF-YANG and IPFIX (Internet Protocol Flow Information Export) respectively. Missing references - For example, there could be different Controllers for different types of MA (home gateways, tablets) or locations (Ipswich, Edinburgh), for load balancing or to cope with failure of one Controller. Another example of repetition. - section 6.1 The measurement system also needs to consider carefully how to interpret missing Results; for example, if the missing Results are ignored and the lack of a Report is caused by its broadband being broken, then the estimate of overall performance, averaged across all MAs, would be too optimistic. The correct interpretation may depend on the specifics of the Measurement Task and Measurement Schedule. What do you mean by "missing Results"? Missing from a measurement or reporting point of view? And if it relates to measurement, it's completely different from a passive monitoring or active probing point of view. - Appendix A: One more example that there is some repetition, why do you need this: The LMAP framework defines two types of components involved in the actual measurement task, namely the Measurement Agent (MA) and the Measurement Peer (MP). The fundamental difference conveyed in the definition of these terms is that the MA has a interface with the Controller/Collector while the MP does not. The MP is broadly defined as a function that assists the MA in the Measurement Task but has no interface with the Controller/Collector. There are many elements in the network that can fall into this broad definition of MP. We believe that the MP terminology is useful to allow us to refer an element of the network that plays a role that is conceptually important to understand and describe the measurement task being performed. We next illustrate these concepts by describing several deployment scenarios. - Appendix Figure 2. OLD: +----------------+ OWAMP +----------------+ ^ | OWAMP |<--control--->| MP: | | | control-client |>test-traffic>| OWAMP server & | IPPM NEW: +----------------+ OWAMP +----------------+ ^ | OWAMP |<--control--->| MP: | | | control-client |-test-traffic>| OWAMP server & | IPPM - Appendix: figure A4 +-----+ +----------------+ +------+ ^ | MP | | MA: Monitor | | MP | IPPM | |<--|----------------|---traffic--->| | Scope +-----+ | | +------+ | .......|................|.........................v........... You mentioned in relation to this figure "Next, we consider Measurement Methods that measure user traffic." So "IPPM scope" is wrong. This might be IPFIX/PSAMP - Appendix: figure A4 I don't understand this sentence: if packets are not forwarded, the measurement task will not work. - Also, related to the previous comment. What about a remote span to the probe? Is this in scope or not? Regards, Benoit --------------070907050202010102050600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Here is my AD review.
Note: I haven't reviewed yet the section 7 "security considerations" and section 8 "privacy considerations", but thought I should anyway send this before the meeting this week.
Note2: if some points were discussed already, don't hesitate to let me know.

A first impression is that there are some repetitions in the draft. It seems like some sections, written by different persons, were glued together. Reading this draft again with a fresh mind would highlight this.

One important issue, which I mentioned already during the interim meeting: the lack of passive monitoring aspects in the draft.
   Section 2

   The MA may
   generate Measurement Traffic and measure some metric associated with
   its transfer, or the MA may observe existing traffic, or there may be
   some kind of hybrid of these two possibilities.
So the document speaks a little bit about active and passive monitoring. Good, because this is mentioned in the charter:
Both active and passive measurements are in scope, although there may be differences in their applicability to specific use cases, or in the security measures needed according to the threats specific to each measurement category. LMAP will not standardize performance metrics.
I recall the charter discussion. I specifically asked: "do you want to have passive monitoring in the charter? Do you understand all the consequences (for example, traffic filters, for observed packet/flow, which may imply RFC6728)?". Both answers were "yes".
So, the draft clearly misses the passive monitoring aspects, starting with the primary figure in this framework, figure 1, which only covers the active monitoring



Some other issues, simply listed in order
-
   These devices could be software based
   agents on PCs, embedded agents in consumer devices (e.g.  Blu-ray
   players),

Does a blu-ray player need a broadband test?

- 
 o  Diversity - a measurement system should handle different types of
      Measurement Agents - for example Measurement Agents may come from
      different vendors, be in wired and wireless networks, be able to
      execute different sorts of Measurement Task and be on devices with
      IPv4 or IPv6 addresses.

Is "different types" the right term? 
You have introduced the term "capabilities"

- 
   It is also useful to define a registry
   for commonly-used Metrics [I-D.manyfolks-ippm-metric-registry] so
   that a Metric with its associated Measurement Method can be referred
   to simply by its identifier in the registry.
The new draft is http://tools.ietf.org/html/draft-ietf-ippm-metric-registry

-
OLD:
   Finally we introduce several components that are outside the scope of
   initial LMAP work and will be provided through existing protocols or
   applications.
NEW:
   Finally we introduce several components that are outside the scope of
   initial LMAP work (see in figure 1 "out of scope" and will be provided 
   through existing protocols or applications.
Then I would list four bullet points for the next paragraph.
Otherwise it's not obvious which components you speak about

- figure 1
    * Since the above mentions the Results repository  (The data analysis tools receive the results from the Collector or via the Results repository. ), the figure should replace repository by Results repository
    * "IPPM scope" is wrong (see my first remark)
    * Mention the Control Protocol and Report Protocol, or Control Channel/Report Channel. Note: if you replace Instruction by Control Protocol, then the arrow must be bidirectional (according to the Control Protocol definition)

- 

   Control Channel: A Channel between a Controller and a MA over which
   Instruction Messages and Capabilities, Failure and Logging
   Information are sent.

   Control Protocol: The protocol delivering Instruction(s) from a
   Controller to a Measurement Agent.  It also delivers Capabilities,
   Failure and Logging Information from the Measurement Agent to the
   Controller.  It can also be used to update the MA's Configuration.

Do you want to mention that the Control Protocol runs on the Control Channel?

- 
   Measurement Method: The process for assessing the value of a Metric;
   the process of measuring some performance or reliability parameter
   associated with the transfer of traffic; where this process involves
   multiple MAs or MPs, each may perform different roles.

I don't understand what "where this process involves multiple MAs or MPs, each may perform different roles." adds to the def.

-
  Report Channel: A Channel between a Collector and a MA over which
   Report messages are sent.

Report messages -> Report Messages


-
4.2
 An operator may have several Controllers, perhaps with a Controller
   for different types of MA (home gateways, tablets) or location
   (Ipswich, Edinburgh).

BT specific, maybe? :-)


- Section 5.
Here is yet another example of repetition (see the last 3 bullets below. Why do you have to repeat what the Control Protocol does)

   An LMAP system goes through the following phases:

   o  a Bootstrapping process before the MA can take part in the other
      three phases

   o  a Control Protocol, which delivers Instruction Messages from a
      Controller to a MA, detailing what Measurement Tasks the MA should
      perform and when, and how it should report the Measurement
      Results.  It also delivers Capabilities, Failure and logging
      Information from a MA to its Controller.  Finally, it allows the
      Controller to update the MA's Configuration.

   o  the actual Measurement Tasks, which measure some performance or
      reliability parameter(s) associated with the transfer of packets.

      The LMAP work does not define Metrics and Measurement Methods,
      these are defined elsewhere (e.g.  IPPM).

   o  a Report Protocol, which delivers Reports from a MA to a
      Collector.  The Report contains the Measurement Results.


- 
Would be nice to have "measurement system" in the terminology section.
It's mentioned so many times in the draft


- 
5.2.  Control Protocol

   The primary purpose of the Control Protocol is to allow the
   Controller to configure a Measurement Agent with an Instruction about
   what Measurement Tasks to do, when to do them, and how to report the
   Measurement Results (Section 5.2.2).  The Measurement Agent then acts
   on the Instruction autonomously.  The Control Protocol also enables
   the MA to inform the Controller about its Capabilities and any
   Failure and Logging Information (Section 5.2.2).  Finally, the
   Control Protocol allows the Controller to update the MA's
   Configuration.

Another example of repetition.
>From the terminology:
   Control Protocol: The protocol delivering Instruction(s) from a
   Controller to a Measurement Agent.  It also delivers Capabilities,
   Failure and Logging Information from the Measurement Agent to the
   Controller.  It can also be used to update the MA's Configuration.


- 
section 5.2.2
Instruction:                            ->
[(Measurement Task configuration(
   [Input Parameter],
   (interface),
   (Cycle-ID))),
 (Report Channel),
 (Schedule),
 (Suppression information)]
                                         <-          Response(details)


It seems from the above that "Measurement Task configuration" takes 3 arguments. 
I'm surprised not to see the Metric (which is described in the section btw) above. 
According to the Input Parameter def., I understand that the Metric is NOT part of the Input Parameter.


- 
5.2.2.1.  Suppression

   The Instruction may include Suppression information.  The purpose of
   Suppression is to enable the Controller to instruct the MA not to
   perform Measurement Tasks.  It is used if the measurement system
   wants to eliminate inessential traffic, because there is some
   unexpected network issue for example.


Again, "eliminate inessential traffic". This is an active probing only view.
Same remark with
   o  a set of Measurement Schedules to suppress; the others are not
      suppressed.  For example, suppose the measurement system has
      defined two Schedules, one with the most critical Measurement
      Tasks and the other with less critical ones that create a lot of
      Measurement Traffic, then it may only want to suppress the second.


- 
5.3.1.  Starting and Stopping Measurement Tasks

That's typical section completely dedicated to active probing:
   Before sending Measurement Traffic the MA may run a pre-check.  (The
   pre-check could be defined as a separate, preceding Task or as the
   first part of a larger Task.)  Action could include:

   o  the MA checking that there is no cross-traffic.  In other words, a
      check that the end-user isn't already sending traffic;

For passive monitoring, you typically want to check that there is traffic of interest...


- 
5.4.1.  Reporting of Subscriber's service parameters

The charter says:
Service parameters, such as product category, can be useful to decide 
which measurements to run and how to interpret the results. These 
parameters are already gathered and stored by existing operations 
systems. 
Discovering the service parameters on the MAs or sharing 
the service parameters between MAs are out of the scope. However, if the
 service parameters are available to the MAs, they could be reported 
with the measurement results in the Report Protocol.


The key sentence is: "if the service parameters are available to the MAs"
I don't find back this concept in section 5.4.1

-
section 5.5

   It is also possible that a different choice is made for the
   Control and Report Protocols, for example NETCONF-YANG and IPFIX
   (Internet Protocol Flow Information Export) respectively.
 
Missing references


-
   For example, there
   could be different Controllers for different types of MA (home
   gateways, tablets) or locations (Ipswich, Edinburgh), for load
   balancing or to cope with failure of one Controller.

Another example of repetition.

- 
section 6.1

   The measurement system also needs to consider carefully how to
   interpret missing Results; for example, if the missing Results are
   ignored and the lack of a Report is caused by its broadband being
   broken, then the estimate of overall performance, averaged across all
   MAs, would be too optimistic.  The correct interpretation may depend
   on the specifics of the Measurement Task and Measurement Schedule.

What do you mean by "missing Results"?
Missing from a measurement or reporting point of view?
And if it relates to measurement, it's completely different from a passive monitoring or active probing point of view.





- Appendix A:

One more example that there is some repetition, why do you need this:

   The LMAP framework defines two types of components involved in the
   actual measurement task, namely the Measurement Agent (MA) and the
   Measurement Peer (MP).  The fundamental difference conveyed in the
   definition of these terms is that the MA has a interface with the
   Controller/Collector while the MP does not.  The MP is broadly
   defined as a function that assists the MA in the Measurement Task but
   has no interface with the Controller/Collector.  There are many
   elements in the network that can fall into this broad definition of
   MP.  We believe that the MP terminology is useful to allow us to
   refer an element of the network that plays a role that is
   conceptually important to understand and describe the measurement
   task being performed.  We next illustrate these concepts by
   describing several deployment scenarios.


- Appendix Figure 2.

OLD:
      +----------------+    OWAMP     +----------------+    ^
      | OWAMP          |<--control--->| MP:            |    |
      | control-client |>test-traffic>| OWAMP server & |   IPPM


NEW:
      +----------------+    OWAMP     +----------------+    ^
      | OWAMP          |<--control--->| MP:            |    |
      | control-client |-test-traffic>| OWAMP server & |   IPPM
- Appendix: figure A4
   +-----+   +----------------+              +------+   ^
   | MP  |   |  MA: Monitor   |              | MP   | IPPM
   |     |<--|----------------|---traffic--->|      | Scope
   +-----+   |                |              +------+   |
      .......|................|.........................v...........


You mentioned in relation to this figure "Next, we consider Measurement Methods that measure user traffic."
So "IPPM scope" is wrong. This might be IPFIX/PSAMP

- Appendix: figure A4
I don't understand this sentence: 
   if packets are not forwarded, the measurement task
   will not work.

- Also, related to the previous comment. What about a remote span to the probe? Is this in scope or not?

Regards, Benoit



--------------070907050202010102050600-- From nobody Sun Nov 9 08:18:23 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CAD1A1AFC for ; Sun, 9 Nov 2014 08:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.094 X-Spam-Level: X-Spam-Status: No, score=-10.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNZQbUxUVyK8 for ; Sun, 9 Nov 2014 08:18:19 -0800 (PST) Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57071A1AE5 for ; Sun, 9 Nov 2014 08:18:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1564; q=dns/txt; s=iport; t=1415549899; x=1416759499; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=lsuVV6pn6Wfc1W0cfMcy68xpS3nJF2c/u1Fth+qSPqs=; b=IJf17UoOUI5RZ60i3Ta6Fxh1PKEcwhax+RjjuQO0YpxgOD+tQ82qc0bm Kb8rUAS8+X50SXXqrjmA6yV9qNn7+X9BS9s7hZFnN0LfT3+HQJd63t6P5 kk3Xkc3ZyvKwJyACrncax96Dhd4Ugw3xUu/NTLAl0WjL3b/UVtFCzXOwi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAEuTX1RIo8UY/2dsb2JhbABbjRzHOoMgAoEkAQEBAQF9g3kKAQEEeAEQCwMBFAkWDwkDAgECAUUGAQwBBwEBiD3MfAEBAQEBAQEBAQEBAQEBAQEBAQEBAReRFQeESwEEniWHeo5mhB4ZgnoBAQE X-IronPort-AV: E=Sophos; i="5.07,346,1413244800"; d="scan'208,217"; a="16856263" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP; 09 Nov 2014 16:18:16 +0000 Received: from [10.21.125.74] (sjc-vpn6-1354.cisco.com [10.21.125.74]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sA9GIC2d019108; Sun, 9 Nov 2014 16:18:13 GMT Message-ID: <545F93C3.6010106@cisco.com> Date: Sun, 09 Nov 2014 06:18:11 -1000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "lmap@ietf.org" , draft-ietf-lmap-framework@tools.ietf.org References: <5451EFD9.1080702@cisco.com> <545F1B06.1090204@cisco.com> In-Reply-To: <545F1B06.1090204@cisco.com> Content-Type: multipart/alternative; boundary="------------030106060608020802000808" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/k5Nb0PE-aKMcDj_8BballsQ-pjY Cc: Paul Aitken , Aamer Akhter Subject: Re: [lmap] draft-ietf-lmap-framework-08: AD review - part 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 16:18:21 -0000 This is a multi-part message in MIME format. --------------030106060608020802000808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/11/2014 21:43, Benoit Claise wrote: > Dear all, > > Here is my AD review. > Note: I haven't reviewed yet the section 7 "security considerations" > and section 8 "privacy considerations", but thought I should anyway > send this before the meeting this week. For this part, I have requested an early review by the security directorate. Regards, Benoit --------------030106060608020802000808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 08/11/2014 21:43, Benoit Claise wrote:
Dear all,

Here is my AD review.
Note: I haven't reviewed yet the section 7 "security considerations" and section 8 "privacy considerations", but thought I should anyway send this before the meeting this week.
For this part, I have requested an early review by the security directorate.

Regards, Benoit
--------------030106060608020802000808-- From nobody Sun Nov 9 12:05:51 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F911A700B for ; Sun, 9 Nov 2014 12:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.493 X-Spam-Level: X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJ5u_eK1FOrl for ; Sun, 9 Nov 2014 12:05:41 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E5A1A7002 for ; Sun, 9 Nov 2014 12:05:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApILAEDIX1SHCzIm/2dsb2JhbABbgkgjI1RZBLgRBpFjgXCHTQKBDxYBAQEBAQF8hAIBAQEBAxIIDQZFBxACAQgNAQMEAQELFgEGBzIUCQgCBAEJBAUIGogfAQytEZ9pAQEBAQEBAQMBAQEBAQEBAQEBAReGOooqMQYBgy2BHgWGOolUgiOEU1eBcIYOPYMSgyCHCoczg3psAYFHgQMBAQE X-IronPort-AV: E=Sophos; i="5.07,347,1413259200"; d="scan'208,217"; a="79944786" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Nov 2014 15:05:35 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 09 Nov 2014 15:05:34 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Sun, 9 Nov 2014 21:05:32 +0100 From: "Romascanu, Dan (Dan)" To: Benoit Claise , "lmap@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Thread-Topic: [lmap] draft-ietf-lmap-framework-08: AD review - part 1 Thread-Index: AQHP+/DVkjRtpzP3sEuhtAKAwO7cT5xYuMjg Date: Sun, 9 Nov 2014 20:05:31 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8FB294@AZ-FFEXMB04.global.avaya.com> References: <5451EFD9.1080702@cisco.com> <545F1B06.1090204@cisco.com> In-Reply-To: <545F1B06.1090204@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8FB294AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ctURSCTeKJGNnwYacYAgCGspX7U Cc: Paul Aitken , Aamer Akhter Subject: Re: [lmap] draft-ietf-lmap-framework-08: AD review - part 1 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 20:05:50 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8FB294AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Benoit! Dear authors - please review and address this if possible before the meeti= ng on Thursday. At the meeting we should discuss the open issues. Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Sunday, November 09, 2014 9:43 AM To: lmap@ietf.org; draft-ietf-lmap-framework@tools.ietf.org Cc: Paul Aitken; Aamer Akhter Subject: [lmap] draft-ietf-lmap-framework-08: AD review - part 1 Dear all, Here is my AD review. Note: I haven't reviewed yet the section 7 "security considerations" and se= ction 8 "privacy considerations", but thought I should anyway send this bef= ore the meeting this week. Note2: if some points were discussed already, don't hesitate to let me know= . A first impression is that there are some repetitions in the draft. It seem= s like some sections, written by different persons, were glued together. Re= ading this draft again with a fresh mind would highlight this. One important issue, which I mentioned already during the interim meeting: = the lack of passive monitoring aspects in the draft. Section 2 The MA may generate Measurement Traffic and measure some metric associated with its transfer, or the MA may observe existing traffic, or there may be some kind of hybrid of these two possibilities. So the document speaks a little bit about active and passive monitoring. Go= od, because this is mentioned in the charter: Both active and passive measurements are in scope, although there may be di= fferences in their applicability to specific use cases, or in the security = measures needed according to the threats specific to each measurement categ= ory. LMAP will not standardize performance metrics. I recall the charter discussion. I specifically asked: "do you want to have= passive monitoring in the charter? Do you understand all the consequences = (for example, traffic filters, for observed packet/flow, which may imply RF= C6728)?". Both answers were "yes". So, the draft clearly misses the passive monitoring aspects, starting with = the primary figure in this framework, figure 1, which only covers the activ= e monitoring Some other issues, simply listed in order - These devices could be software based agents on PCs, embedded agents in consumer devices (e.g. Blu-ray players), Does a blu-ray player need a broadband test? - o Diversity - a measurement system should handle different types of Measurement Agents - for example Measurement Agents may come from different vendors, be in wired and wireless networks, be able to execute different sorts of Measurement Task and be on devices with IPv4 or IPv6 addresses. Is "different types" the right term? You have introduced the term "capabilities" - It is also useful to define a registry for commonly-used Metrics [I-D.manyfolks-ippm-metric-registry] so that a Metric with its associated Measurement Method can be referred to simply by its identifier in the registry. The new draft is http://tools.ietf.org/html/draft-ietf-ippm-metric-registry - OLD: Finally we introduce several components that are outside the scope of initial LMAP work and will be provided through existing protocols or applications. NEW: Finally we introduce several components that are outside the scope of initial LMAP work (see in figure 1 "out of scope" and will be provided through existing protocols or applications. Then I would list four bullet points for the next paragraph. Otherwise it's not obvious which components you speak about - figure 1 * Since the above mentions the Results repository (The data analysis t= ools receive the results from the Collector or via the Results repository. = ), the figure should replace repository by Results repository * "IPPM scope" is wrong (see my first remark) * Mention the Control Protocol and Report Protocol, or Control Channel/= Report Channel. Note: if you replace Instruction by Control Protocol, then = the arrow must be bidirectional (according to the Control Protocol definiti= on) - Control Channel: A Channel between a Controller and a MA over which Instruction Messages and Capabilities, Failure and Logging Information are sent. Control Protocol: The protocol delivering Instruction(s) from a Controller to a Measurement Agent. It also delivers Capabilities, Failure and Logging Information from the Measurement Agent to the Controller. It can also be used to update the MA's Configuration. Do you want to mention that the Control Protocol runs on the Control Channe= l? - Measurement Method: The process for assessing the value of a Metric; the process of measuring some performance or reliability parameter associated with the transfer of traffic; where this process involves multiple MAs or MPs, each may perform different roles. I don't understand what "where this process involves multiple MAs or MPs, e= ach may perform different roles." adds to the def. - Report Channel: A Channel between a Collector and a MA over which Report messages are sent. Report messages -> Report Messages - 4.2 An operator may have several Controllers, perhaps with a Controller for different types of MA (home gateways, tablets) or location (Ipswich, Edinburgh). BT specific, maybe? :-) - Section 5. Here is yet another example of repetition (see the last 3 bullets below. Wh= y do you have to repeat what the Control Protocol does) An LMAP system goes through the following phases: o a Bootstrapping process before the MA can take part in the other three phases o a Control Protocol, which delivers Instruction Messages from a Controller to a MA, detailing what Measurement Tasks the MA should perform and when, and how it should report the Measurement Results. It also delivers Capabilities, Failure and logging Information from a MA to its Controller. Finally, it allows the Controller to update the MA's Configuration. o the actual Measurement Tasks, which measure some performance or reliability parameter(s) associated with the transfer of packets. The LMAP work does not define Metrics and Measurement Methods, these are defined elsewhere (e.g. IPPM). o a Report Protocol, which delivers Reports from a MA to a Collector. The Report contains the Measurement Results. - Would be nice to have "measurement system" in the terminology section. It's mentioned so many times in the draft - 5.2. Control Protocol The primary purpose of the Control Protocol is to allow the Controller to configure a Measurement Agent with an Instruction about what Measurement Tasks to do, when to do them, and how to report the Measurement Results (Section 5.2.2). The Measurement Agent then acts on the Instruction autonomously. The Control Protocol also enables the MA to inform the Controller about its Capabilities and any Failure and Logging Information (Section 5.2.2). Finally, the Control Protocol allows the Controller to update the MA's Configuration. Another example of repetition. >From the terminology: Control Protocol: The protocol delivering Instruction(s) from a Controller to a Measurement Agent. It also delivers Capabilities, Failure and Logging Information from the Measurement Agent to the Controller. It can also be used to update the MA's Configuration. - section 5.2.2 Instruction: -> [(Measurement Task configuration( [Input Parameter], (interface), (Cycle-ID))), (Report Channel), (Schedule), (Suppression information)] <- Response(details) It seems from the above that "Measurement Task configuration" takes 3 argum= ents. I'm surprised not to see the Metric (which is described in the section btw)= above. According to the Input Parameter def., I understand that the Metric is NOT = part of the Input Parameter. - 5.2.2.1. Suppression The Instruction may include Suppression information. The purpose of Suppression is to enable the Controller to instruct the MA not to perform Measurement Tasks. It is used if the measurement system wants to eliminate inessential traffic, because there is some unexpected network issue for example. Again, "eliminate inessential traffic". This is an active probing only view= . Same remark with o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Measurement Traffic, then it may only want to suppress the second. - 5.3.1. Starting and Stopping Measurement Tasks That's typical section completely dedicated to active probing: Before sending Measurement Traffic the MA may run a pre-check. (The pre-check could be defined as a separate, preceding Task or as the first part of a larger Task.) Action could include: o the MA checking that there is no cross-traffic. In other words, a check that the end-user isn't already sending traffic; For passive monitoring, you typically want to check that there is traffic o= f interest... - 5.4.1. Reporting of Subscriber's service parameters The charter says: Service parameters, such as product category, can be useful to decide which measurements to run and how to interpret the results. These parameters are already gathered and stored by existing operations systems. Discovering the service parameters on the MAs or sharing the service parameters between MAs are out of the scope. However, if the service parameters are available to the MAs, they could be reported with the measurement results in the Report Protocol. The key sentence is: "if the service parameters are available to the MAs" I don't find back this concept in section 5.4.1 - section 5.5 It is also possible that a different choice is made for the Control and Report Protocols, for example NETCONF-YANG and IPFIX (Internet Protocol Flow Information Export) respectively. Missing references - For example, there could be different Controllers for different types of MA (home gateways, tablets) or locations (Ipswich, Edinburgh), for load balancing or to cope with failure of one Controller. Another example of repetition. - section 6.1 The measurement system also needs to consider carefully how to interpret missing Results; for example, if the missing Results are ignored and the lack of a Report is caused by its broadband being broken, then the estimate of overall performance, averaged across all MAs, would be too optimistic. The correct interpretation may depend on the specifics of the Measurement Task and Measurement Schedule. What do you mean by "missing Results"? Missing from a measurement or reporting point of view? And if it relates to measurement, it's completely different from a passive = monitoring or active probing point of view. - Appendix A: One more example that there is some repetition, why do you need this: The LMAP framework defines two types of components involved in the actual measurement task, namely the Measurement Agent (MA) and the Measurement Peer (MP). The fundamental difference conveyed in the definition of these terms is that the MA has a interface with the Controller/Collector while the MP does not. The MP is broadly defined as a function that assists the MA in the Measurement Task but has no interface with the Controller/Collector. There are many elements in the network that can fall into this broad definition of MP. We believe that the MP terminology is useful to allow us to refer an element of the network that plays a role that is conceptually important to understand and describe the measurement task being performed. We next illustrate these concepts by describing several deployment scenarios. - Appendix Figure 2. OLD: +----------------+ OWAMP +----------------+ ^ | OWAMP |<--control--->| MP: | | | control-client |>test-traffic>| OWAMP server & | IPPM NEW: +----------------+ OWAMP +----------------+ ^ | OWAMP |<--control--->| MP: | | | control-client |-test-traffic>| OWAMP server & | IPPM - Appendix: figure A4 +-----+ +----------------+ +------+ ^ | MP | | MA: Monitor | | MP | IPPM | |<--|----------------|---traffic--->| | Scope +-----+ | | +------+ | .......|................|.........................v........... You mentioned in relation to this figure "Next, we consider Measurement Met= hods that measure user traffic." So "IPPM scope" is wrong. This might be IPFIX/PSAMP - Appendix: figure A4 I don't understand this sentence: if packets are not forwarded, the measurement task will not work. - Also, related to the previous comment. What about a remote span to the pr= obe? Is this in scope or not? Regards, Benoit --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8FB294AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Benoit!

 <= /p>

Dear authors – plea= se review and address this if possible  before the meeting on Thursday= . At the meeting we should discuss the open issues.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Sunday, November 09, 2014 9:43 AM
To: lmap@ietf.org; draft-ietf-lmap-framework@tools.ietf.org
Cc: Paul Aitken; Aamer Akhter
Subject: [lmap] draft-ietf-lmap-framework-08: AD review - part 1

 

Dear all,

Here is my AD review.
Note: I haven't reviewed yet the section 7 "security considerations&qu= ot; and section 8 "privacy considerations", but thought I should = anyway send this before the meeting this week.
Note2: if some points were discussed already, don't hesitate to let me know= .


A first impression is that there are some repetitions in the draft. It seem= s like some sections, written by different persons, were glued together. Re= ading this draft again with a fresh mind would highlight this.

One important issue, which I mentioned already during the interim meeting: = the lack of passive monitoring aspects in the draft.

   Section 2
 
   The MA may
   generate Measurement Traffic and measure some metric asso=
ciated with
   its transfer, or the MA may observe existing traffic, or =
there may be
   some kind of hybrid of these two possibilities.  
 

So the document speaks a little bit about active and= passive monitoring. Good, because this is mentioned in the charter:

Both active and passive measurements are in scope, a= lthough there may be differences in their applicability to specific use cas= es, or in the security measures needed according to the threats specific to= each measurement category. LMAP will not standardize performance metrics.

I recall the charter discussion. I specifically aske= d: "do you want to have passive monitoring in the charter? Do you unde= rstand all the consequences (for example, traffic filters, for observed pac= ket/flow, which may imply RFC6728)?". Both answers were "yes".
So, the draft clearly misses the passive monitoring aspects, starting with = the primary figure in this framework, figure 1, which only covers the activ= e monitoring



Some other issues, simply listed in order
-

   These devices could be software based
   agents on PCs, embedded agents in consumer devices (e.g.&=
nbsp; Blu-ray
   players),
 
Does a blu-ray player need a broadband test?
 
- 
 o  Diversity - a measurement system should handle different=
 types of
      Measurement Agents - for example Measur=
ement Agents may come from
      different vendors, be in wired and wire=
less networks, be able to
      execute different sorts of Measurement =
Task and be on devices with
      IPv4 or IPv6 addresses.

 


Is "different types" the right term? 


You have introduced the term "capabilities"   




- 


   It is also useful to define a registry

   for commonly-used Metrics [The new draft is 
http://tools.ietf.org/html/draft-ietf-ippm-metric-registry



-

OLD:


   Finally we introduce several components that are outside =
the scope of


   initial LMAP work and will be provided through existing p=
rotocols or


   applications.  


NEW:


   Finally we introduce several components that are outside =
the scope of


   initial LMAP work (see in figure 1 "out of scope&quo=
t; and will be provided 


   through existing protocols or applications.  


Then I would list fou=
r bullet points for the next paragraph.

Otherwise it's not obvious which components you speak about



- figure 1

    * Since the above mentions the Results repository  =
(The data analysis tools receive the results from the Collector or via the =
Results repository. ), the figure should replace repository by Results repo=
sitory

    * "IPPM scope" is wrong (see my first remark)<=
br>
    * Mention the Control Protocol and Report Protocol, or C=
ontrol Channel/Report Channel. Note: if you replace Instruction by Control =
Protocol, then the arrow must be bidirectional (according to the Control Pr=
otocol definition)



- 


   Control Channel: A Channel between a Controller and =
a MA over which


   Instruction Messages and Capabilities, Failure and Loggin=
g


   Information are sent.


 


   Control Protocol: The protocol delivering Instruction(s) =
from a


   Controller to a Measurement Agent.  It also delivers=
 Capabilities,


   Failure and Logging Information from the Measurement Agen=
t to the


   Controller.  It can also be used to update the MA's =
Configuration.


 


Do you want to mention that the Control Protocol runs on the Control C=
hannel?


 


- 


   Measurement Method: The process for assessing the va=
lue of a Metric;


   the process of measuring some performance or reliability =
parameter


   associated with the transfer of traffic; where this proce=
ss involves


   multiple MAs or MPs, each may perform different roles.


 


I don't understand what "where this process involves multiple MAs=
 or MPs, each may perform different roles." adds to the def.


 


-


  Report Channel: A Channel between a Collector and a MA over whi=
ch


   Report messages are sent.


 


Report messages -> Report Messages


 


 


-


4.2


 An operator may have several Controllers, perhaps with a Controller


   for different types of MA (home gateways, tablets) or loc=
ation


   (Ipswich, Edinburgh).


 


BT specific, maybe? :-)


 


 


- Section 5.


Here is yet another example of repetition (see the last 3 bullets belo=
w. Why do you have to repeat what the Control Protocol does)

 


   An LMAP system goes through the following phases:


 


   o  a Bootstrapping process before the MA can take pa=
rt in the other


      three phases


 


   o  a Control Protocol, which delivers Instruction Me=
ssages from a


      Controller to a MA, detailing what Meas=
urement Tasks the MA should


      perform and when, and how it should rep=
ort the Measurement


      Results.  It also delivers Capabil=
ities, Failure and logging


      Information from a MA to its Controller=
.  Finally, it allows the


      Controller to update the MA's Configura=
tion.


 


   o  the actual Measurement Tasks, which measure some =
performance or


      reliability parameter(s) associated wit=
h the transfer of packets.


 


      The LMAP work does not define Metrics a=
nd Measurement Methods,


      these are defined elsewhere (e.g. =
 IPPM).


 


   o  a Report Protocol, which delivers Reports from a =
MA to a


      Collector.  The Report contains th=
e Measurement Results.


 


 


- 


Would be nice to have "measurement system" in the terminolog=
y section.


It's mentioned so many times in the draft


 


 


- 


5.2.  Control Protocol


 


   The primary purpose of the Control Protocol is to allow t=
he


   Controller to configure a Measurement Agent with an Instr=
uction about


   what Measurement Tasks to do, when to do them, and how to=
 report the


   Measurement Results (Section 5.2.2).  The Measuremen=
t Agent then acts


   on the Instruction autonomously.  The Control Protoc=
ol also enables


   the MA to inform the Controller about its Capabilities an=
d any


   Failure and Logging Information (Section 5.2.2).  Fi=
nally, the


   Control Protocol allows the Controller to update the MA's=



   Configuration.


 


Another example of repetition.


>From the terminology:


   Control Protocol: The protocol delivering Instruction(s) =
from a


   Controller to a Measurement Agent.  It also delivers=
 Capabilities,


   Failure and Logging Information from the Measurement Agen=
t to the


   Controller.  It can also be used to update the MA's =
Configuration.


 


 


- 


section 5.2.2


Instruction:         &nbs=
p;            &=
nbsp;     ->


[(Measurement Task configuration(


   [Input Parameter],


   (interface),


   (Cycle-ID))),


 (Report Channel),


 (Schedule),


 (Suppression information)]


           &nbs=
p;            &=
nbsp;           &nbs=
p;    <-        &=
nbsp; Response(details)


 


 


It seems from the above that "Measurement Task configuration"=
; takes 3 arguments. 


I'm surprised not to see the Metric (which is described in the section=
 btw) above. 


According to the Input Parameter def., I understand that the Metric is=
 NOT part of the Input Parameter.


 


 


- 


5.2.2.1.  Suppression


 


   The Instruction may include Suppression information. =
; The purpose of


   Suppression is to enable the Controller to instruct the M=
A not to


   perform Measurement Tasks.  It is used if the measur=
ement system


   wants to eliminate inessential traffic, because there is =
some


   unexpected network issue for example.


 


 


Again, "eliminate inessential traffic". This is an active pr=
obing only view.


Same remark with


   o  a set of Measurement Schedules to suppress; the o=
thers are not


      suppressed.  For example, suppose =
the measurement system has


      defined two Schedules, one with the mos=
t critical Measurement


      Tasks and the other with less critical =
ones that create a lot of


      Measurement Traffic, then it may only w=
ant to suppress the second.


 


 


- 


5.3.1.  Starting and Stopping Measurement Tasks


 


That's typical section completely dedicated to active probing:


   Before sending Measurement Traffic the MA may run =
a pre-check.  (The


   pre-check could be defined as a separate, preceding Task =
or as the


   first part of a larger Task.)  Action could include:=



 


   o  the MA checking that there is no cross-traffic=
.  In other words, a


      check that the end-user isn't already s=
ending traffic;


 


For passive monitoring, you typically want to check that there is traf=
fic of interest...


 


 


- 


5.4.1.  Reporting of Subscriber's service parameters

 


The charter says:


Service parameters, such as product category, can be useful to decide =



which measurements to run and how to interpret the results. These 


parameters are already gathered and stored by existing operations 


systems. 


Discovering the service parameters on the MAs or sharing 

the service parameters between MAs are out of the scope. However, if t=
he


 service parameters are available to the MAs, they could be reported <=
o:p>


with the measurement results in the Report Protocol.


 


 


The key sentence is: "if the service parameters are available to =
the MAs"


I don't find back this concept in section 5.4.1


 


-


section 5.5


 


   It is also possible that a different choice is made for t=
he


   Control and Report Protocols, for example NETCONF-YANG an=
d IPFIX


   (Internet Protocol Flow Information Export) respectively.=



 


Missing references


 


 


-


   For example, there


   could be different Controllers for different types of MA =
(home


   gateways, tablets) or locations (Ipswich, Edinburgh), for=
 load


   balancing or to cope with failure of one Controller.=



 


Another example of repetition.


 


- 


section 6.1


 


   The measurement system also needs to consider carefully h=
ow to


   interpret missing Results; for example, if the missing Re=
sults are


   ignored and the lack of a Report is caused by its broadba=
nd being


   broken, then the estimate of overall performance, average=
d across all


   MAs, would be too optimistic.  The correct interpret=
ation may depend


   on the specifics of the Measurement Task and Measurement =
Schedule.


 


What do you mean by "missing Results"?


Missing from a measurement or reporting point of view?

And if it relates to measurement, it's completely different from a pas=
sive monitoring or active probing point of view.


 


 


 


 


 


- Appendix A:


 


One more example that there is some repetition, why do you need this:<=
o:p>


 


   The LMAP framework defines two types of components involv=
ed in the


   actual measurement task, namely the Measurement Agent (MA=
) and the


   Measurement Peer (MP).  The fundamental difference c=
onveyed in the


   definition of these terms is that the MA has a interface =
with the


   Controller/Collector while the MP does not.  The MP =
is broadly


   defined as a function that assists the MA in the Measurem=
ent Task but


   has no interface with the Controller/Collector.  The=
re are many


   elements in the network that can fall into this broad def=
inition of


   MP.  We believe that the MP terminology is useful to=
 allow us to


   refer an element of the network that plays a role that is=



   conceptually important to understand and describe the mea=
surement


   task being performed.  We next illustrate these conc=
epts by


   describing several deployment scenarios.


 


 


- Appendix Figure 2.


 


OLD:


      +----------------+  &=
nbsp; OWAMP     +----------------+  &=
nbsp; ^


      | OWAMP     &n=
bsp;    |<--control--->| MP:    &n=
bsp;       |    |

      | control-client |>test-traffic>|=
 OWAMP server & |   IPPM


 


 


NEW:


      +----------------+  &=
nbsp; OWAMP     +----------------+  &=
nbsp; ^


      | OWAMP     &n=
bsp;    |<--control--->| MP:    &n=
bsp;       |    |

      | control-client |-test-traffic>| OW=
AMP server & |   IPPM


 


 


 


- Appendix: figure A4


   +-----+   +----------------+&nb=
sp;            =
 +------+   ^


   | MP  |   |  MA: Monitor   =
|            &n=
bsp; | MP   | IPPM


   |     |<--|----------------|---tra=
ffic--->|      | Scope


   +-----+   |    &nbs=
p;           |  =
;            +--=
----+   |


      .......|................|..............=
...........v...........


 


 


You mentioned in relation to this figure "Next, we consider Measu=
rement Methods that measure user traffic."


So "IPPM scope" is wrong. This might be IP=
FIX/PSAMP 



- Appendix: figure A4

I don't understand this sentence: 


   if packets are not forwarded, the measurement task


   will not work.




- Also, related to the previous comment. What about a remote span to the pr=
obe? Is this in scope or not?



Regards, Benoit

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8FB294AZFFEXMB04globa_-- From nobody Sun Nov 9 12:40:34 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEF21A86EC for ; Sun, 9 Nov 2014 12:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GessKZFltXh8 for ; Sun, 9 Nov 2014 12:40:26 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3B41A01AA for ; Sun, 9 Nov 2014 12:40:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwPAADQX1TGmAcV/2dsb2JhbABYA4JrI1RZBLgRBgWTICIKhnpVAoEPFgEBAQEBAXELhAIBAQEBAwEBAQ8oDyUXAgQBCAcGBAQBAQsUCSIMCxQHAQEFBAEEEwgBEgeIHwEMqB2EcZ9pAQEBAQEFAQEBAQEBAQEBGQSGNol5EQEfIRILC4IlUySBHgWGOot3hFOIVYNPgyCOPYN6bAGBDjmBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,347,1413259200"; d="scan'208";a="91293788" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Nov 2014 15:40:24 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 09 Nov 2014 15:40:25 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Sun, 9 Nov 2014 21:40:23 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [Recentattendees] Attending IETF 91 Remotely Thread-Index: Ac/8XWDTjLCtHsQxRvSuqlDjtMW+5g== Date: Sun, 9 Nov 2014 20:40:22 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8FB521@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/NLeINUni8S66fSI4YkD5h4E2S1k Subject: [lmap] FW: [Recentattendees] Attending IETF 91 Remotely X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 20:40:32 -0000 Important information for the remote participants.=20 Regards, Dan > -----Original Message----- > From: Recentattendees [mailto:recentattendees-bounces@ietf.org] On > Behalf Of Alexa Morris > Sent: Sunday, November 09, 2014 10:28 PM > To: ietf-announce@ietf.org; 91all@ietf.org; recentattendees@ietf.org > Subject: [Recentattendees] Attending IETF 91 Remotely >=20 > Welcome to IETF 91! You can remotely attend all IETF 91 sessions, plenari= es > and tutorials using Meetecho. >=20 > Please register as a remote attendee (there is no cost) here: > http://www.ietf.org/meeting/register.html. >=20 > Meetecho live streaming schedule and session archives links are at: > http://www.ietf.org/meeting/91/remote-participation.html#Meetecho. >=20 > Download meeting materials here: > https://datatracker.ietf.org/meeting/91/materials.html. >=20 > If you want to present remotely, please send email to ietf- > team@meetecho.com and the Meetecho Team will do their best to > accommodate you. >=20 > More information on remote participation can be found at > http://www.ietf.org/meeting/91/remote-participation.html. >=20 > Regards, > Alexa >=20 > ---------- > Alexa Morris / Executive Director / IETF > 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 > Phone: +1.510.492.4089 / Fax: +1.510.492.4001 > Email: amorris@amsl.com >=20 > Managed by Association Management Solutions (AMS) Forum Management, > Meeting and Event Planning www.amsl.com >=20 > _______________________________________________ > Recentattendees mailing list > Recentattendees@ietf.org > https://www.ietf.org/mailman/listinfo/recentattendees From nobody Sun Nov 9 13:29:06 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B351A8736 for ; Sun, 9 Nov 2014 13:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUqP4lCP8xsT for ; Sun, 9 Nov 2014 13:29:02 -0800 (PST) Received: from imta-36.everyone.net (sitemail2.everyone.net [216.200.145.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C96D1A014E for ; Sun, 9 Nov 2014 13:29:02 -0800 (PST) Received: from pps.filterd (omta005.sj2.proofpoint.com [127.0.0.1]) by imta-38.everyone.net (8.14.5/8.14.5) with SMTP id sA9LSw3Y013470; Sun, 9 Nov 2014 13:28:58 -0800 X-Eon-Dm: dm0103 Received: by m0005311.mta.everyone.net (EON-PICKUP) id m0005311.545a5b0f.6996; Sun, 9 Nov 2014 13:28:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Message-Id: <20141109132858.80F37685@m0005311.ppops.net> Date: Sun, 9 Nov 2014 13:28:58 -0800 From: "Scott Weeks" To: , X-Eon-Sig: AQLAznNUX9yaIRWMZAEAAAAC,a6cfbb51c539c92068d9fbe46cbf0586 X-Originating-Ip: 31.133.163.37 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-11-09_03:2014-11-07,2014-11-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=21 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411090203 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/RMH6luLz-5SG7jjrlGSqi5x-daE Subject: Re: [lmap] draft-ietf-lmap-framework-08: AD review - part 1 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: surfer@mauigateway.com List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 21:29:04 -0000 Hello, I was asked to send this to the list. ----------------------------------------------------- OLD: Finally we introduce several components that are outside the scope of initial LMAP work and will be provided through existing protocols or applications. NEW: Finally we introduce several components that are outside the scope of initial LMAP work (see in figure 1 "out of scope" and will be provided through existing protocols or applications. ------------------------------------------------------- very small correction: "...initial LMAP work (see in figure 1 "out of scope") and will be provided.." scott _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Nov 10 06:32:53 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36551A8A60; Mon, 10 Nov 2014 06:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4n6qUCyIf9qJ; Mon, 10 Nov 2014 06:32:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC3F1A8BB5; Mon, 10 Nov 2014 06:32:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141110143245.21102.70830.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 06:32:45 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/dnAVlNuAUbIc_L6TOFcgOFYDGlw Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-use-cases-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 14:32:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance Working Group of the IETF. Title : Large-Scale Broadband Measurement Use Cases Authors : Marc Linsner Philip Eardley Trevor Burbridge Frode Sorensen Filename : draft-ietf-lmap-use-cases-05.txt Pages : 17 Date : 2014-11-10 Abstract: Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well as for public policy. Understanding the various scenarios and users of measuring broadband performance is essential to development of the Large-scale Measurement of Broadband Performance (LMAP) framework, information model and protocol. This document details two use cases that can assist to developing that framework. The details of the measurement metrics themselves are beyond the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-use-cases-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-use-cases-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 10 12:06:45 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561B61ACD6B for ; Mon, 10 Nov 2014 12:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIjdl8bRD4DG for ; Mon, 10 Nov 2014 12:06:36 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:797]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04C11ACDB6 for ; Mon, 10 Nov 2014 12:06:27 -0800 (PST) Received: from CY1PR0301MB0633.namprd03.prod.outlook.com (25.160.158.139) by CY1PR0301MB0635.namprd03.prod.outlook.com (25.160.158.141) with Microsoft SMTP Server (TLS) id 15.1.11.14; Mon, 10 Nov 2014 20:06:05 +0000 Received: from CY1PR0301MB0633.namprd03.prod.outlook.com ([25.160.158.139]) by CY1PR0301MB0633.namprd03.prod.outlook.com ([25.160.158.139]) with mapi id 15.01.0011.000; Mon, 10 Nov 2014 20:06:05 +0000 From: Kamala Subramaniam To: "lmap@ietf.org" Thread-Topic: draft-ksubram-lmap-router-buffer-sizes-00 Thread-Index: Ac/9IIXhaghu935KTUSEb734GjxF2Q== Date: Mon, 10 Nov 2014 20:06:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [31.133.179.85] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0635; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0635; x-forefront-prvs: 039178EF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(46034005)(4396001)(19625215002)(99286002)(120916001)(76576001)(107886001)(46102003)(99396003)(101416001)(15975445006)(19300405004)(2501002)(97736003)(108616004)(107046002)(229853001)(95666004)(2351001)(230783001)(106356001)(105586002)(2656002)(74316001)(40100003)(21056001)(15202345003)(33646002)(64706001)(50986999)(110136001)(20776003)(19580395003)(54356999)(16236675004)(87936001)(86612001)(122556002)(92566001)(77156002)(62966003)(86362001)(77096003)(450100001)(66066001)(31966008)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0635; H:CY1PR0301MB0633.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_f471f76bae06499a8cac9bc3b9c66c16CY1PR0301MB0633namprd03_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/wwW_I4ix7f_JewSZqmTz01krtsQ Subject: [lmap] draft-ksubram-lmap-router-buffer-sizes-00 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:06:41 -0000 --_000_f471f76bae06499a8cac9bc3b9c66c16CY1PR0301MB0633namprd03_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear LMAP WG, We have submitted a draft "Router Buffer Sizes in the WAN". It will be pres= ented this Thursday. I wanted to take this opportunity to introduce this dr= aft, and get some feedback. This draft has received some input from the AQM= WG. The lmap-use-cases draft is what initiated the request to be presented in t= he LMAP WG. Let me get more in to the details by elaborating the issue wit= h each of the 4 subsections in this ISP use case. Before that, maybe listing the goals would give a better idea: * Drive down the unit cost in $/GB by building efficient but cheaper= networks. Do our networks really need the buffers we deal with today at hi= gh costs? * Maximize throughput in the backbone by always keeping the links bu= sy so that the router buffers never underflow and the router does not lose = throughput. * To take into consideration variables such as {short Vs long flows,= packet sizes, queue depth/model, traffic classes, etc.} as factors while r= educing the whistles, bells, and knobs to keep it simple to configure as we= ll as manage. Now, for the subsections: * Identifying, isolating and fixing problems: we observe that there = are numerous issues at different layers that have an effect (directly or in= directly) on the sizing of router buffers. Could this be solved by high lay= er optimizations (ECN, tweaking TCP flows), or something like just a diffe= rent queuing model. Studying the nature of the traffic that exists in an IS= P world today is an important way to determine this. Where really is this p= roblem? Is it the way we design our networks for example by not taking into= consideration how scavenger class really affects us? * Design and planning: One the problem has been identified it become= s easier to design and plan the networks. Perhaps all we need are small siz= e buffers driving down the cost. * Understanding the quality experienced by customers: again a huge c= hunk of the study would have packet discards (WAN facing/ outgoing egress i= nterface perhaps?). Do the new methods involved in this study work better f= or QoS? * Understanding the impact and operation of new devices and technolo= gy: let's say that the conclusion of this study is that we do not need larg= e size buffers (we are talking 125MB per port), then can we convince the ve= ndors (switch/router/chip) to go down that path. There have been many studies which provide theories to what the size should= be. However, most of these are theoretical in nature and do not take into = account any empirical data. While we continue to mine the big data availabl= e to us to further study this, we'd also like to start a draft which would = in the minimum entail a problem statement, get an idea of the amount of int= erest, and hopefully lead to some collaboration. Regards, Kamala --_000_f471f76bae06499a8cac9bc3b9c66c16CY1PR0301MB0633namprd03_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear LMAP WG,

 

We have submitted a dr= aft “Router Buffer Sizes in the WAN”. It will be presented this= Thursday. I wanted to take this opportunity to introduce this draft, and g= et some feedback. This draft has received some input from the AQM WG.

 

The lmap-use-cases dra= ft is what initiated the request to be presented in the LMAP WG.  Let = me get more in to the details by elaborating the issue with each of the 4 s= ubsections in this ISP use case.

 

Before that, maybe lis= ting the goals would give a better idea:

·    &n= bsp;   Drive down the unit cost in $/GB by building efficient = but cheaper networks. Do our networks really need the buffers we deal with = today at high costs?

·    &n= bsp;   Maximize throughput in the backbone by always keeping t= he links busy so that the router buffers never underflow and the router doe= s not lose throughput.

·    &n= bsp;   To take into consideration variables such as {short Vs = long flows, packet sizes, queue depth/model, traffic classes, etc.} as fact= ors while reducing the whistles, bells, and knobs to keep it simple to configure as well as manage.

Now, for the subsectio= ns:

·    &n= bsp;   Identifying, isolating and fixing problems: we observe = that there are numerous issues at different layers that have an effect (dir= ectly or indirectly) on the sizing of router buffers. Could this be solved by high layer optimizations (ECN, = tweaking TCP flows),  or something like just a different queuing model= . Studying the nature of the traffic that exists in an ISP world today is a= n important way to determine this. Where really is this problem? Is it the way we design our networks for example b= y not taking into consideration how scavenger class really affects us?=

·    &n= bsp;   Design and planning: One the problem has been identifie= d it becomes easier to design and plan the networks. Perhaps all we need ar= e small size buffers driving down the cost.

·    &n= bsp;   Understanding the quality experienced by customers: aga= in a huge chunk of the study would have packet discards (WAN facing/ outgoi= ng egress interface perhaps?). Do the new methods involved in this study work better for QoS?

·    &n= bsp;   Understanding the impact and operation of new devices a= nd technology: let’s say that the conclusion of this study is that we= do not need large size buffers (we are talking 125MB per port), then can we convince the vendors (switch/router/c= hip) to go down that path.

There have been many s= tudies which provide theories to what the size should be. However, most of = these are theoretical in nature and do not take into account any empirical = data. While we continue to mine the big data available to us to further study this, we’d also like to st= art a draft which would in the minimum entail a problem statement, get an i= dea of the amount of interest, and hopefully lead to some collaboration.

 

Regards,

Kamala

 

--_000_f471f76bae06499a8cac9bc3b9c66c16CY1PR0301MB0633namprd03_-- From nobody Tue Nov 11 08:51:56 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F2F1A0065 for ; Tue, 11 Nov 2014 08:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuPx87qTfQUA for ; Tue, 11 Nov 2014 08:51:31 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7511A0059 for ; Tue, 11 Nov 2014 08:51:19 -0800 (PST) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 11 Nov 2014 16:51:20 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.213]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Tue, 11 Nov 2014 16:51:12 +0000 From: To: , , Date: Tue, 11 Nov 2014 16:51:10 +0000 Thread-Topic: [lmap] draft-ietf-lmap-framework-08: AD review - part 1 Thread-Index: Ac/78NWGnXs8k7huRn6lj8UQheyD/QByu8ww Message-ID: References: <5451EFD9.1080702@cisco.com> <545F1B06.1090204@cisco.com> In-Reply-To: <545F1B06.1090204@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A6DF88DEMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/72XyhDmRZ6aNSnmEl2nruwrVYcw Cc: pjaitken@gmail.com, aakhter@gmail.com Subject: Re: [lmap] draft-ietf-lmap-framework-08: AD review - part 1 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 16:51:50 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A6DF88DEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Benoit, Thanks very much for the review - some comments in line Best wishes phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Benoit Claise Sent: 09 November 2014 07:43 To: lmap@ietf.org; draft-ietf-lmap-framework@tools.ietf.org Cc: Paul Aitken; Aamer Akhter Subject: [lmap] draft-ietf-lmap-framework-08: AD review - part 1 Dear all, Here is my AD review. Note: I haven't reviewed yet the section 7 "security considerations" and se= ction 8 "privacy considerations", but thought I should anyway send this bef= ore the meeting this week. Note2: if some points were discussed already, don't hesitate to let me know= . A first impression is that there are some repetitions in the draft. It seem= s like some sections, written by different persons, were glued together. Re= ading this draft again with a fresh mind would highlight this. [phil] ok will try to reduce. I think some redundancy is OK. for example, I= think there should be some repetition between S1 & 2 (trying to provide an= introduction, for people who want to read no further or haven't come acros= s measurement stuff before); S3 (summarises terminology) and S5 (details th= e protocol model). One important issue, which I mentioned already during the interim meeting: = the lack of passive monitoring aspects in the draft. Section 2 The MA may generate Measurement Traffic and measure some metric associated with its transfer, or the MA may observe existing traffic, or there may be some kind of hybrid of these two possibilities. So the document speaks a little bit about active and passive monitoring. Go= od, because this is mentioned in the charter: Both active and passive measurements are in scope, although there may be di= fferences in their applicability to specific use cases, or in the security = measures needed according to the threats specific to each measurement categ= ory. LMAP will not standardize performance metrics. I recall the charter discussion. I specifically asked: "do you want to have= passive monitoring in the charter? Do you understand all the consequences = (for example, traffic filters, for observed packet/flow, which may imply RF= C6728)?". Both answers were "yes". So, the draft clearly misses the passive monitoring aspects, starting with = the primary figure in this framework, figure 1, which only covers the activ= e monitoring [phil] I'll mainly leave Paul & Aamer to handle this comment. In terms of Figure 1, I can add a pointer to Appendix A4 which shows a pass= ive monitoring case. We can think about how to show passive monitoring in Fig 1 (not trivial - i= t doesn't show all active monitoring cases either, as doesn't show the scen= ario with a second MA instead of a M Peer). Some other issues, simply listed in order - These devices could be software based agents on PCs, embedded agents in consumer devices (e.g. Blu-ray players), Does a blu-ray player need a broadband test? [phil[ >tablets? - o Diversity - a measurement system should handle different types of Measurement Agents - for example Measurement Agents may come from different vendors, be in wired and wireless networks, be able to execute different sorts of Measurement Task and be on devices with IPv4 or IPv6 addresses. Is "different types" the right term? You have introduced the term "capabilities" [phil] don't mind. (The term capabilities hasn't yet been introduced) - It is also useful to define a registry for commonly-used Metrics [I-D.manyfolks-ippm-metric-registry] so that a Metric with its associated Measurement Method can be referred to simply by its identifier in the registry. The new draft is http://tools.ietf.org/html/draft-ietf-ippm-metric-registry - OLD: Finally we introduce several components that are outside the scope of initial LMAP work and will be provided through existing protocols or applications. NEW: Finally we introduce several components that are outside the scope of initial LMAP work (see in figure 1 "out of scope" and will be provided through existing protocols or applications. Then I would list four bullet points for the next paragraph. Otherwise it's not obvious which components you speak about [phil] ok - figure 1 * Since the above mentions the Results repository (The data analysis t= ools receive the results from the Collector or via the Results repository. = ), the figure should replace repository by Results repository * "IPPM scope" is wrong (see my first remark) [phil] sorry, I don't understand. Would you prefer something like "Scope of= eg IPPM"? * Mention the Control Protocol and Report Protocol, or Control Channel/= Report Channel. Note: if you replace Instruction by Control Protocol, then = the arrow must be bidirectional (according to the Control Protocol definiti= on) [phil] Prefer to keep a mention of instruction and report. Suggested change: to "Instruction (over Control Channel)" and "Report (over= Report Channel)" and keep the arrows uni-directional. - Control Channel: A Channel between a Controller and a MA over which Instruction Messages and Capabilities, Failure and Logging Information are sent. Control Protocol: The protocol delivering Instruction(s) from a Controller to a Measurement Agent. It also delivers Capabilities, Failure and Logging Information from the Measurement Agent to the Controller. It can also be used to update the MA's Configuration. Do you want to mention that the Control Protocol runs on the Control Channe= l? - Measurement Method: The process for assessing the value of a Metric; the process of measuring some performance or reliability parameter associated with the transfer of traffic; where this process involves multiple MAs or MPs, each may perform different roles. I don't understand what "where this process involves multiple MAs or MPs, e= ach may perform different roles." adds to the def. [phil] ok. - Report Channel: A Channel between a Collector and a MA over which Report messages are sent. Report messages -> Report Messages - 4.2 An operator may have several Controllers, perhaps with a Controller for different types of MA (home gateways, tablets) or location (Ipswich, Edinburgh). BT specific, maybe? :-) [phil] I'll add Diegem! - Section 5. Here is yet another example of repetition [phil] ok, will shorten these (they're basically introducing the sub-sectio= ns of S5) (see the last 3 bullets below. Why do you have to repeat what the Control P= rotocol does) An LMAP system goes through the following phases: o a Bootstrapping process before the MA can take part in the other three phases o a Control Protocol, which delivers Instruction Messages from a Controller to a MA, detailing what Measurement Tasks the MA should perform and when, and how it should report the Measurement Results. It also delivers Capabilities, Failure and logging Information from a MA to its Controller. Finally, it allows the Controller to update the MA's Configuration. o the actual Measurement Tasks, which measure some performance or reliability parameter(s) associated with the transfer of packets. The LMAP work does not define Metrics and Measurement Methods, these are defined elsewhere (e.g. IPPM). o a Report Protocol, which delivers Reports from a MA to a Collector. The Report contains the Measurement Results. - Would be nice to have "measurement system" in the terminology section. It's mentioned so many times in the draft [phil] with trepidation... since terminology always provokes excitement... Measurement System: the set of LMAP-defined and related components that are= operated by a single organisation, for the purpose of measuring performanc= e aspects of the network. - 5.2. Control Protocol The primary purpose of the Control Protocol is to allow the Controller to configure a Measurement Agent with an Instruction about what Measurement Tasks to do, when to do them, and how to report the Measurement Results (Section 5.2.2). The Measurement Agent then acts on the Instruction autonomously. The Control Protocol also enables the MA to inform the Controller about its Capabilities and any Failure and Logging Information (Section 5.2.2). Finally, the Control Protocol allows the Controller to update the MA's Configuration. Another example of repetition. >From the terminology: Control Protocol: The protocol delivering Instruction(s) from a Controller to a Measurement Agent. It also delivers Capabilities, Failure and Logging Information from the Measurement Agent to the Controller. It can also be used to update the MA's Configuration. [phil] personally I think this repetition is ok. Section 5 is providing the= protocol model, so needs to describe what the control protocol does. - section 5.2.2 Instruction: -> [(Measurement Task configuration( [Input Parameter], (interface), (Cycle-ID))), (Report Channel), (Schedule), (Suppression information)] <- Response(details) It seems from the above that "Measurement Task configuration" takes 3 argum= ents. I'm surprised not to see the Metric (which is described in the section btw)= above. According to the Input Parameter def., I understand that the Metric is NOT = part of the Input Parameter. [phil] good spot, thanks. - 5.2.2.1. Suppression The Instruction may include Suppression information. The purpose of Suppression is to enable the Controller to instruct the MA not to perform Measurement Tasks. It is used if the measurement system wants to eliminate inessential traffic, because there is some unexpected network issue for example. Again, "eliminate inessential traffic". This is an active probing only view= . [phil] does adding something like this solve the issue? "or inessential processing by a networking component" Same remark with o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Measurement Traffic, then it may only want to suppress the second. [phil] Paul, Aamer - please suggest some text - don't know what's appropria= te for passive tasks - 5.3.1. Starting and Stopping Measurement Tasks That's typical section completely dedicated to active probing: Before sending Measurement Traffic the MA may run a pre-check. (The pre-check could be defined as a separate, preceding Task or as the first part of a larger Task.) Action could include: o the MA checking that there is no cross-traffic. In other words, a check that the end-user isn't already sending traffic; For passive monitoring, you typically want to check that there is traffic o= f interest... [phil] ok. will expand the list. - 5.4.1. Reporting of Subscriber's service parameters The charter says: Service parameters, such as product category, can be useful to decide which measurements to run and how to interpret the results. These parameters are already gathered and stored by existing operations systems. Discovering the service parameters on the MAs or sharing the service parameters between MAs are out of the scope. However, if the service parameters are available to the MAs, they could be reported with the measurement results in the Report Protocol. The key sentence is: "if the service parameters are available to the MAs" I don't find back this concept in section 5.4.1 [phil] I think S5.4.1 does mention this: The information could be transferred directly from the Subscriber parameter database to the data analysis tools. It may also be possible to transfer the information via the MA. How (and if) the MA knows such information is likely to depend on the device type. The MA could either include the information in a Measurement Report or separately. - section 5.5 It is also possible that a different choice is made for the Control and Report Protocols, for example NETCONF-YANG and IPFIX (Internet Protocol Flow Information Export) respectively. Missing references - For example, there could be different Controllers for different types of MA (home gateways, tablets) or locations (Ipswich, Edinburgh), for load balancing or to cope with failure of one Controller. Another example of repetition. [phil] ok, will delete this paragraph - section 6.1 The measurement system also needs to consider carefully how to interpret missing Results; for example, if the missing Results are ignored and the lack of a Report is caused by its broadband being broken, then the estimate of overall performance, averaged across all MAs, would be too optimistic. The correct interpretation may depend on the specifics of the Measurement Task and Measurement Schedule. What do you mean by "missing Results"? Missing from a measurement or reporting point of view? And if it relates to measurement, it's completely different from a passive = monitoring or active probing point of view. [phil] How about: The measurement system also needs to consider carefully how to interpret missing Results. The correct interpretation depends on why the Results are missing, and potentially on the specifics of the = Measurement Task and Measurement Schedule. - Appendix A: One more example that there is some repetition, why do you need this: The LMAP framework defines two types of components involved in the actual measurement task, namely the Measurement Agent (MA) and the Measurement Peer (MP). The fundamental difference conveyed in the definition of these terms is that the MA has a interface with the Controller/Collector while the MP does not. The MP is broadly defined as a function that assists the MA in the Measurement Task but has no interface with the Controller/Collector. There are many elements in the network that can fall into this broad definition of MP. We believe that the MP terminology is useful to allow us to refer an element of the network that plays a role that is conceptually important to understand and describe the measurement task being performed. We next illustrate these concepts by describing several deployment scenarios. [phil] ok. will delete. - Appendix Figure 2. OLD: +----------------+ OWAMP +----------------+ ^ | OWAMP |<--control--->| MP: | | | control-client |>test-traffic>| OWAMP server & | IPPM NEW: +----------------+ OWAMP +----------------+ ^ | OWAMP |<--control--->| MP: | | | control-client |-test-traffic>| OWAMP server & | IPPM - Appendix: figure A4 +-----+ +----------------+ +------+ ^ | MP | | MA: Monitor | | MP | IPPM | |<--|----------------|---traffic--->| | Scope +-----+ | | +------+ | .......|................|.........................v........... You mentioned in relation to this figure "Next, we consider Measurement Met= hods that measure user traffic." So "IPPM scope" is wrong. This might be IPFIX/PSAMP [phil] ok, will replace with "IPFX/PSAMP/IPPM Scope" - Appendix: figure A4 I don't understand this sentence: if packets are not forwarded, the measurement task will not work. - Also, related to the previous comment. What about a remote span to the pr= obe? Is this in scope or not? [phil] I'd be ok to delete the whole of the last paragraph. Regards, Benoit --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A6DF88DEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Benoit,

Thanks very much for the review – some comments i= n line

Best wishes

ph= il

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Benoi= t Claise
Sent: 09 November 2014 07:43
To: lmap@ietf.org= ; draft-ietf-lmap-framework@tools.ietf.org
Cc: Paul Aitken; Aamer= Akhter
Subject: [lmap] draft-ietf-lmap-framework-08: AD review -= part 1

 

Dear all,

Here is my AD review.
Not= e: I haven't reviewed yet the section 7 "security considerations"= and section 8 "privacy considerations", but thought I should any= way send this before the meeting this week.
Note2: if some points were d= iscussed already, don't hesitate to let me know.


A first impression is that there are some repetitions in = the draft. It seems like some sections, written by different persons, were = glued together. Reading this draft again with a fresh mind would highlight = this.

=  

[phil] ok will try to reduce. I think some redundancy is= OK. for example, I think there should be some repetition between S1 & = 2 (trying to provide an introduction, for people who want to read no furthe= r or haven’t come across measurement stuff before); S3 (summarises te= rminology) and S5 (details the protocol model).



One important issue, which I mentioned already durin= g the interim meeting: the lack of passive monitoring aspects in the draft.= 

   Section 2
 =

   The MA may
   =
generate Measurement Traffic and measure some metric associated with
   its transfer, or the MA may observe existing tr=
affic, or there may be
   some kind of hybri=
d of these two possibilities.  
 =

So the document speaks a little bit about active= and passive monitoring. Good, because this is mentioned in the charter:

Both active and passive measurements are i= n scope, although there may be differences in their applicability to specif= ic use cases, or in the security measures needed according to the threats s= pecific to each measurement category. LMAP will not standardize performance= metrics.

I recall the charter discussio= n. I specifically asked: "do you want to have passive monitoring in th= e charter? Do you understand all the consequences (for example, traffic fil= ters, for observed packet/flow, which may imply RFC6728)?". Both answe= rs were "yes".
So, the draft clearly misses the passive monit= oring aspects, starting with the primary figure in this framework, figure 1= , which only covers the active monitoring

[phil] I’ll mainly leave Paul & Aame= r to handle this comment.

In terms of Figure 1, = I can add a pointer to Appendix A4 which shows a passive monitoring case.

We can think about how to show passive monitoring= in Fig 1 (not trivial – it doesn’t show all active monitoring = cases either, as doesn’t show the scenario with a second MA instead o= f a M Peer).




Some ot= her issues, simply listed in order
-

   The=
se devices could be software based
   agents=
 on PCs, embedded agents in consumer devices (e.g.  Blu-ray=

   players),
 
Does a blu-ray player need a broadband test?
<=
span style=3D'font-size:12.0pt;font-family:"Arial","sans-serif";color:blue'=
> 
[phil[ >tablets?=

 
- 
 o =
; Diversity - a measurement system should handle different types of
      Measurement Agents - for examp=
le Measurement Agents may come from
   =
   different vendors, be in wired and wireless networks, be able =
to
      execute different so=
rts of Measurement Task and be on devices with
 &=
nbsp;    IPv4 or IPv6 addresses.
&=
nbsp;
Is "different types" the right term? <=
/o:p>
You have introduced the term "capabilities" =
  
 
[phil] don’t mind. (The term capabilit=
ies hasn’t yet been introduced)

- 
   It is also useful to defin=
e a registry
   for commonly-used Metrics [<=
a href=3D"http://tools.ietf.org/html/draft-ietf-lmap-framework-08#ref-I-D.m=
anyfolks-ippm-metric-registry">I-D.manyfolks-ippm-metric-registry] so
   that a Metric with its associated Measurem=
ent Method can be referred
   to simply by i=
ts identifier in the registry. 
 
The new draft is http://tools.ietf.org/html/draft-ietf-ip=
pm-metric-registry

-
OLD:
   Fin=
ally we introduce several components that are outside the scope of
   initial LMAP work and will be provided through ex=
isting protocols or
   applications.  <=
o:p>
NEW:
   F=
inally we introduce several components that are outside the scope of
   initial LMAP work (see in figure 1 "out of=
 scope" and will be provided 
   t=
hrough existing protocols or applications.  
Then I would list four bullet p=
oints for the next paragraph.
Otherwise it's not obvious which component=
s you speak about
[phil] ok

- figure 1
    * Since the above mentio=
ns the Results repository  (The data analysis tools receive the result=
s from the Collector or via the Results repository. ), the figure should re=
place repository by Results repository
    * "IPPM s=
cope" is wrong (see my first remark)
[phil] sorry, I donR=
17;t understand. Would you prefer something like “Scope of eg IPPM=
221;?

    * Mention the Control Protocol and Report Protoc=
ol, or Control Channel/Report Channel. Note: if you replace Instruction by =
Control Protocol, then the arrow must be bidirectional (according to the Co=
ntrol Protocol definition)
=

 [phil] Prefer to keep a mention of in=
struction and report. 
Suggested change: to “Instruction (over Control Channel)”=
 and “Report (over Report Channel)” and keep the arrows uni-dir=
ectional.
- 
   Control Channel: A Chan=
nel between a Controller and a MA over which
 &nb=
sp; Instruction Messages and Capabilities, Failure and Logging
   Information are sent.
 =
;
   Control Protocol: The protocol delivering In=
struction(s) from a
   Controller to a Measu=
rement Agent.  It also delivers Capabilities,
&nb=
sp;  Failure and Logging Information from the Measurement Agent to the=

   Controller.  It can also be used to=
 update the MA's Configuration.
 
Do you want to mention that the Control Protocol runs on the Control =
Channel?
 
- 
   Measurement Method: The process for assessing the =
value of a Metric;
   the process of measuri=
ng some performance or reliability parameter
 &nb=
sp; associated with the transfer of traffic; where this process involves
   multiple MAs or MPs, each may perform diffe=
rent roles.
 
I don't unders=
tand what "where this process involves multiple MAs or MPs, each may p=
erform different roles." adds to the def.
[phil=
] ok. 
 
-=

  Report Channel: A Channel between a Collector and a MA ov=
er which
   Report messages are sent.
 
Report messages -> Report Mes=
sages
 
 
-
4.2
 An operator may ha=
ve several Controllers, perhaps with a Controller
&nbs=
p;  for different types of MA (home gateways, tablets) or location
   (Ipswich, Edinburgh).
<=
o:p> 
BT specific, maybe? :-)
[phil] I’ll add Diegem!
 
- Section 5.
Here i=
s yet another example of repetition <=
/span>
[phil] ok, will shorten these (they’re basically i=
ntroducing the sub-sections of S5)
(see the las=
t 3 bullets below. Why do you have to repeat what the Control Protocol does=
)
 
   An LMAP sys=
tem goes through the following phases:
 
   o  a Bootstrapping process before the MA can=
 take part in the other
     =
 three phases
 
  =
 o  a Control Protocol, which delivers Instruction Messages from a
      Controller to a MA, detail=
ing what Measurement Tasks the MA should
  &=
nbsp;   perform and when, and how it should report the Measuremen=
t
      Results.  It als=
o delivers Capabilities, Failure and logging
 &nb=
sp;    Information from a MA to its Controller.  Finall=
y, it allows the
      Contro=
ller to update the MA's Configuration.
 
   o  the actual Measurement Tasks, which measu=
re some performance or
      =
reliability parameter(s) associated with the transfer of packets.
 
      The =
LMAP work does not define Metrics and Measurement Methods,
=

      these are defined elsewhere (e.g. =
 IPPM).
 
   o&nbs=
p; a Report Protocol, which delivers Reports from a MA to a
      Collector.  The Report contains t=
he Measurement Results.
 
 
- 
Would be nice to have &qu=
ot;measurement system" in the terminology section.
It's mentioned so many times in the draft=

 
[phil] with trepidation… since terminology always provok=
es excitement…
Measurement System: the =
set of LMAP-defined and related components that are operated by a single or=
ganisation, for the purpose of measuring performance aspects of the network=
. 
 
 
- 
5.2.  Control Protocol<=
/pre>
 
   The primary purpose of t=
he Control Protocol is to allow the
   Contr=
oller to configure a Measurement Agent with an Instruction about=

   what Measurement Tasks to do, when to do them, and =
how to report the
   Measurement Results (Se=
ction 5.2.2).  The Measurement Agent then acts
&n=
bsp;  on the Instruction autonomously.  The Control Protocol also=
 enables
   the MA to inform the Controller =
about its Capabilities and any
   Failure an=
d Logging Information (Section 5.2.2).  Finally, the
<=
pre>   Control Protocol allows the Controller to update the MA's<=
o:p>
   Configuration.
=
 
Another example of repetition.
=
>From the terminology:
   Control Protoco=
l: The protocol delivering Instruction(s) from a
 =
;  Controller to a Measurement Agent.  It also delivers Capabilit=
ies,
   Failure and Logging Information from=
 the Measurement Agent to the
   Controller.=
  It can also be used to update the MA's Configuration.
 
[phil] person=
ally I think this repetition is ok. Section 5 is providing the protocol mod=
el, so needs to describe what the control protocol does.<=
/pre>
- 
section 5.2.2
Instru=
ction:           &nb=
sp;            =
    ->
[(Measurement Task configurat=
ion(
   [Input Parameter],
<=
pre>   (interface),
   (Cycle-ID))=
),
 (Report Channel),
 (Schedule)=
,
 (Suppression information)]
&nb=
sp;            =
            &nb=
sp;            =
   <-          Re=
sponse(details)
 
 =
;
It seems from the above that "Measurement Task confi=
guration" takes 3 arguments. 
I'm surprised not t=
o see the Metric (which is described in the section btw) above. =

According to the Input Parameter def., I understand that the Met=
ric is NOT part of the Input Parameter.
 
[phil] good spot, thanks.=
 
 
- 
5.2.2.1.  Suppression
 
   The Instruction may include Suppression information.&n=
bsp; The purpose of
   Suppression is to ena=
ble the Controller to instruct the MA not to
 &nb=
sp; perform Measurement Tasks.  It is used if the measurement system
   wants to eliminate inessential traffic, be=
cause there is some
   unexpected network is=
sue for example.
 
&nbs=
p;
Again, "eliminate inessential traffic". This i=
s an active probing only view.
[phil] does adding so=
mething like this solve the issue?
“or=
 inessential processing by a networking component”<=
/pre>
Same remark with
   o  a set =
of Measurement Schedules to suppress; the others are not
      suppressed.  For example, suppose th=
e measurement system has
     =
; defined two Schedules, one with the most critical Measurement<=
/pre>
      Tasks and the other with less crit=
ical ones that create a lot of
    =
;  Measurement Traffic, then it may only want to suppress the second.<=
o:p>
[phil] Paul, Aamer – =
please suggest some text – don’t know what’s appropriate =
for passive tasks
 
-=
 
5.3.1.  Starting and Stopping Measurement Tasks=

 
That's typical section co=
mpletely dedicated to active probing:
   =
Before sending Measurement Traffic the MA may run a pre-check.  (T=
he
   pre-check could be defined as a separa=
te, preceding Task or as the
   first part o=
f a larger Task.)  Action could include:
&nb=
sp;
   o  the MA checking that there is n=
o cross-traffic.  In other words, a
 &nb=
sp;    check that the end-user isn't already sending traffic=
;
 
For passive monitoring, =
you typically want to check that there is traffic of interest...=

 
[phil] ok=
. will expand the list. 
- 
5.4.1.  Reporting of Subscriber's service parameters
 
The charter says:
Se=
rvice parameters, such as product category, can be useful to decide 
which measurements to run and how to interpret the results. =
These 
parameters are already gathered and stored by e=
xisting operations 
systems. 
Dis=
covering the service parameters on the MAs or sharing 
the service parameters between MAs are out of the scope. However, if the
 service parameters are available to the MAs, they coul=
d be reported 
with the measurement results in the Rep=
ort Protocol.
 
 <=
/o:p>
The key sentence is: "if the service parameters are av=
ailable to the MAs"
I don't find back this concep=
t in section 5.4.1
&nb=
sp;
[phil] I think S5.4.1 does mention this:<=
/o:p>
The information could be transferred directly f=
rom the Subscriber
   parameter da=
tabase to the data analysis tools.  It may also be
   possible to transfer the information via the MA.&n=
bsp; How (and if) the MA
   knows =
such information is likely to depend on the device type.  The
   MA could either include the information=
 in a Measurement Report or
   sep=
arately.
 
<=
o:p> 
-
section 5.5
 
   It is also possible=
 that a different choice is made for the
   =
Control and Report Protocols, for example NETCONF-YANG and IPFIX=

   (Internet Protocol Flow Information Export) respect=
ively.
 
Missing references<=
o:p>
 
 
-
   For example, there
   could be different Controllers for different types of MA (h=
ome
   gateways, tablets) or locations (Ipsw=
ich, Edinburgh), for load
   balancing or to=
 cope with failure of one Controller.
 
Another example of repetition.
[phil] ok, will delete this paragraph
 
- 
section=
 6.1
 
   The meas=
urement system also needs to consider carefully how to
   interpret missing Results; for example, if the missing Result=
s are
   ignored and the lack of a Report is=
 caused by its broadband being
   broken, th=
en the estimate of overall performance, averaged across all
   MAs, would be too optimistic.  The correct interpre=
tation may depend
   on the specifics of the=
 Measurement Task and Measurement Schedule.
 =
;
What do you mean by "missing Results"?
Missing from a measurement or reporting point of view?
And if it relates to measurement, it's completely different f=
rom a passive monitoring or active probing point of view.
<=
pre>[phil] How about:
 The measurement system also needs to c=
onsider carefully how to
   interpret missin=
g Results. The correct interpretation depends
 &n=
bsp; on why the Results are missing, and potentially on the specifics of th=
e Measurement Task and Measurement Schedule.
&nbs=
p;
 
- Appendix A:
 
One more example that there is some repe=
tition, why do you need this:
 
<=
pre>   The LMAP framework defines two types of components involve=
d in the
   actual measurement task, namely =
the Measurement Agent (MA) and the
   Measur=
ement Peer (MP).  The fundamental difference conveyed in the
   definition of these terms is that the MA has a int=
erface with the
   Controller/Collector whil=
e the MP does not.  The MP is broadly
  =
; defined as a function that assists the MA in the Measurement Task but
   has no interface with the Controller/Collect=
or.  There are many
   elements in the =
network that can fall into this broad definition of
&n=
bsp;  MP.  We believe that the MP terminology is useful to allow =
us to
   refer an element of the network tha=
t plays a role that is
   conceptually impor=
tant to understand and describe the measurement
 =
  task being performed.  We next illustrate these concepts by
   describing several deployment scenarios.
 
[p=
hil] ok. will delete.
 
- Appendix Figure 2.
 
OLD:
      +----------=
------+    OWAMP     +----------------+&=
nbsp;   ^
      | O=
WAMP          |<--control--=
->| MP:           =
; |    |
     =
 | control-client |>test-traffic>| OWAMP server & |   I=
PPM
 
 
NEW:
      +-----------=
-----+    OWAMP     +----------------+&n=
bsp;   ^
      | OW=
AMP          |<--control---=
>| MP:           =
 |    |
      =
| control-client |-test-traffic>| OWAMP server & |   IPPM<=
o:p>
 
 
 
- Appendix: figure A4
   +-----+   +----------------+   =
;           +------+ =
;  ^
   | MP  |   | =
; MA: Monitor   |        =
      | MP   | IPPM
   |     |<--|----------------|---traffic=
--->|      | Scope
 &=
nbsp; +-----+   |        =
        |     &=
nbsp;        +------+   |=

      .......|................|..=
.......................v...........
 <=
/pre>
 
You mentioned in relation to this fig=
ure "Next, we consider Measurement Methods that measure user traffic.&=
quot;
So "IPPM scope" is wro=
ng. This might be IPFIX/PSAMP =

[phil] ok, will replace with “IPFX/PSAMP/IPPM Scope̶=
1;


- Appendix: figure A4<=
br>I don't understand this sentence: 
   =
if packets are not forwarded, the measurement task
&nb=
sp;  will not work.

- Also, related to the previous comment. What about a=
 remote span to the probe? Is this in scope or not?
[phil] I̵=
7;d be ok to delete the whole of the last paragraph. 
=



Regards, Benoit=

 

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A6DF88DEMV67UKRDdoma_-- From nobody Tue Nov 11 08:51:57 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FB11A0062 for ; Tue, 11 Nov 2014 08:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUqEqiTNOysO for ; Tue, 11 Nov 2014 08:51:51 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53D91A0040 for ; Tue, 11 Nov 2014 08:51:40 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 11 Nov 2014 16:51:42 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.213]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Tue, 11 Nov 2014 16:51:30 +0000 From: To: Date: Tue, 11 Nov 2014 16:51:28 +0000 Thread-Topic: Framework changes Thread-Index: Ac/9y1FzSK5wOY5UQ1mKp+Ni6foYQQ== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A6DF88EEMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9cHOjlKGGa6npJkSuj_vuQM5acA Subject: [lmap] Framework changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 16:51:53 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A6DF88EEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As well as Benoit's comments, I have a couple of other things that came up = (I think in the Dublin interim): * As well as Capabilities, Failure and Logging Information, the MA = can tell the Controller what Instruction it has (and the Controller could r= equest for the MA to send it). This could be useful if the Controller think= s something has gone wrong, and wants to check what Instruction the MA is u= sing. * It was suggested to add a bit of guidance about what to do if the= MA re-boots or has been off-line for some time (so its instruction may be = fail). For instance, assess how stale the Instruction is (assuming the MA i= s behind a NAT, it will periodically pull a new instruction or at least che= ck for an update); re-set the clock before re-starting measurements; be car= eful about how re-start measurements after suppression ends (as t; anything= else? I think the best place to add text is Section 6. * Mention that it's device-specific what the MA should do if it run= s out of storage space for results or if it can't contact the controller. A= gain S6 seems best place Hope these are ok Best wishes phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A6DF88EEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As well as Benoit’s= comments, I have a couple of other things that came up (I think in the Dub= lin interim):

&m= iddot;    =      As well as Capabilities, Fai= lure and Logging Information, the MA can tell the Controller what Instructi= on it has (and the Controller could request for the MA to send it). This co= uld be useful if the Controller thinks something has gone wrong, and wants = to check what Instruction the MA is using.

·         <= ![endif]>= It was suggested to add a bit of guidance about what to do if the MA re-boo= ts or has been off-line for some time (so its instruction may be fail). For= instance, assess how stale the Instruction is (assuming the MA is behind a= NAT, it will periodically pull a new instruction or at least check for an = update); re-set the clock before re-starting measurements; be careful about= how re-start measurements after suppression ends (as t; anything else? I t= hink the best place to add text is Section 6.

<= ![if !supportLists]>·         Mention that it’s device-specific what the MA should do if it runs= out of storage space for results or if it can’t contact the controll= er. Again S6 seems best place

 <= /o:p>

Hope these are ok

Best wishes

phil

=
= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A6DF88EEMV67UKRDdoma_-- From nobody Tue Nov 11 09:35:49 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071731A00F2 for ; Tue, 11 Nov 2014 09:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vjUf-BQjOc0 for ; Tue, 11 Nov 2014 09:35:46 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B151A0143 for ; Tue, 11 Nov 2014 09:35:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 724B8F9D; Tue, 11 Nov 2014 18:35:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ev3VH9GGsN7R; Tue, 11 Nov 2014 18:35:34 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 11 Nov 2014 18:35:43 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC00320013; Tue, 11 Nov 2014 18:35:43 +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 LC6uPvOqd3QM; Tue, 11 Nov 2014 18:33:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E70020017; Tue, 11 Nov 2014 18:35:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1A7042F7BE9A; Tue, 11 Nov 2014 18:35:42 +0100 (CET) Date: Tue, 11 Nov 2014 18:35:41 +0100 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20141111173541.GD51325@elstar.local> Mail-Followup-To: philip.eardley@bt.com, bclaise@cisco.com, lmap@ietf.org, draft-ietf-lmap-framework@tools.ietf.org, pjaitken@gmail.com, aakhter@gmail.com References: <5451EFD9.1080702@cisco.com> <545F1B06.1090204@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/kyp-G8n2psx2AkKHIRVY9oLHy9o Cc: bclaise@cisco.com, draft-ietf-lmap-framework@tools.ietf.org, pjaitken@gmail.com, aakhter@gmail.com, lmap@ietf.org Subject: Re: [lmap] draft-ietf-lmap-framework-08: AD review - part 1 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 17:35:48 -0000 On Tue, Nov 11, 2014 at 04:51:10PM +0000, philip.eardley@bt.com wrote: > Some other issues, simply listed in order > - > > These devices could be software based > agents on PCs, embedded agents in consumer devices (e.g. Blu-ray > players), > > Does a blu-ray player need a broadband test? > > > [phil[ >tablets? > I suggest "TV" since TVs are consumer real devices that are morphing into Internet video playing engines. And yes, since I mention it, "gaming consoles" can perhaps be mentioned as well. Gamers really care about latency. So my proposal would be to replace the parenthesis with '(e.g., TVs or gaming consoles)'. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Nov 11 17:37:28 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A262A1AC39A for ; Tue, 11 Nov 2014 17:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, GB_I_INVITATION=-2, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPxSDJE4ra10 for ; Tue, 11 Nov 2014 17:37:24 -0800 (PST) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 89D151A8792 for ; Tue, 11 Nov 2014 17:37:17 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.07,365,1413259200"; d="ics'217?scan'217,208,217";a="173467187" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 11 Nov 2014 20:35:13 -0500 Received: from PRVPEXVS06.corp.twcable.com ([10.136.163.32]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 11 Nov 2014 20:37:16 -0500 From: "Weil, Jason" To: "lmap@ietf.org" Date: Tue, 11 Nov 2014 20:37:14 -0500 Thread-Topic: WebEx meeting invitation: LMAP Thread-Index: Ac/+GTC0g+ucxCtuRy6JG17xsuq2jg== Message-ID: References: <212016122.7699.1415658005945.JavaMail.nobody@jva2tc106.webex.com> In-Reply-To: <212016122.7699.1415658005945.JavaMail.nobody@jva2tc106.webex.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_D088231D396A3jasonweiltwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/xXQc8CSl0sXCp08w5XcGN-tXPV4 Subject: [lmap] FW: WebEx meeting invitation: LMAP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 01:37:26 -0000 --_004_D088231D396A3jasonweiltwcablecom_ Content-Type: multipart/alternative; boundary="_000_D088231D396A3jasonweiltwcablecom_" --_000_D088231D396A3jasonweiltwcablecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable LMAP, We now have a WebEx session setup for remote presenters to as needed for Th= ursday=92s meeting. The information for the Webex session is provided below= . Jason =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D LMAP Thursday, November 13, 2014 9:00 am | Hawaii Time (Honolulu, GMT-10:00) | 2 hr 30 min Join WebEx meeting Meeting number: 642 954 960 Meeting password: 1234 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 642 954 960 Toll-free calling restrictions Add this meeting to your calendar. Can't join the meeting? Contact support. IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. By joining this session, you automatically consent = to such recordings. If you do not consent to being recorded, discuss your c= oncerns with the host or do not join the session. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_D088231D396A3jasonweiltwcablecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
LMAP, 

We now have a WebEx session setup for remote presenters to as needed f= or Thursday=92s meeting. The information for the Webex session is provided = below.

Jason

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
LMAP
Thursday, November 13, 2014
9:00 am  |  Hawaii Time (Honolulu, GMT-10:00) =  |  2 hr 30 min
 
Join WebEx meeting
Meeting number: 642 954 960
Meeting password: 1234
 
Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 642 954 960
Toll-free calling rest= rictions
 
Add this meeting to your calendar.
 
Can't join= the meeting? Contact support.
 
IMPORTANT NOTICE: Please note = that this WebEx service allows audio and other information sent during the = session to be recorded, which may be discoverable in a legal matter. By joi= ning this session, you automatically consent to such recordings. If you do not consent to being recorded, discu= ss your concerns with the host or do not join the session.

This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_D088231D396A3jasonweiltwcablecom_-- --_004_D088231D396A3jasonweiltwcablecom_ Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Description: WebEx_Meeting.ics Content-Disposition: attachment; filename="WebEx_Meeting.ics"; size=3563; creation-date="Wed, 12 Nov 2014 01:37:16 GMT"; modification-date="Wed, 12 Nov 2014 01:37:16 GMT" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpIYXdhaWkgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTExMjAxVDAwMDAw MApUWk9GRlNFVEZST006LTEwMDAKVFpPRkZTRVRUTzotMTAwMApUWk5BTUU6U3RhbmRhcmQgVGlt ZQpFTkQ6U1RBTkRBUkQKRU5EOlZUSU1FWk9ORQpCRUdJTjpWRVZFTlQKQVRURU5ERUU7Q049IiI7 Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1UUlVFOk1BSUxUTzpqYXNvbi53ZWlsQHR3Y2FibGUu Y29tCk9SR0FOSVpFUjtDTj0iQW15IFZlenphIjpNQUlMVE86YXZlenphQGFtc2wuY29tCkRUU1RB UlQ7VFpJRD0iSGF3YWlpIFRpbWUiOjIwMTQxMTEzVDA5MDAwMApEVEVORDtUWklEPSJIYXdhaWkg VGltZSI6MjAxNDExMTNUMTEzMDAwCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 ZgpUUkFOU1A6T1BBUVVFClNFUVVFTkNFOjEKVUlEOldFQkVYLU1FRVRJTkcgQ0VOVEVSLTYuMDQ1 NjY4MC0zMDg4NTUxMzItU1U9aWV0ZgpEVFNUQU1QOjIwMTQxMTEzVDE5MDAwMFoKREVTQ1JJUFRJ T046XG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYv ai5waHA/TVRJRD1tYTA2ZjgzM2VmNGNiNjExZTFjNjI3NjJiYmMzNmQwMzBcbk1lZXRpbmcgbnVt YmVyOiA2NDIgOTU0IDk2MFxuTWVldGluZyBwYXNzd29yZDogMTIzNFxuXG5cbkpPSU4gQlkgUEhP TkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSBc bjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcbkFjY2VzcyBj b2RlOiA2NDIgOTU0IDk2MFxuXG5Ub2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IFxuaHR0 cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5cbkNh bid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOlxuaHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhh dCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBz ZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2Nv dmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBh dXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNv bnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBo b3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0 L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+IDxGT05UIFNJWkU9 IjQiIEZBQ0U9IkFSSUFMIj4JCTxhCQkJCQlocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2ll dGYvai5waHA/TVRJRD1tYTA2ZjgzM2VmNGNiNjExZTFjNjI3NjJiYmMzNmQwMzAiPjxGT05UIFNJ WkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9G T05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyOjwvRk9OVD4JCQkJCTwv dGQ+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj42NDIgOTU0IDk2MDwvRk9OVD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4JCQk8 dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi Pk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPjEyMzQ8L0ZPTlQ+PC90ZD48L3RyPjwvdGFibGU+CQk8L0ZP TlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05U PjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2 NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpF PSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS04NzctNjY4LTQ0OTM8 L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxz dHJvbmc+MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVyIChV Uy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogNjQyIDk1NCA5NjA8L0ZPTlQ+Jm5ic3A7IDxCUj48 YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBk ZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFsIj5Ub2xsLWZyZWUg Y2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJSPjwvRk9OVD48QlI+PEJS PgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+ CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVmPSJodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0i QXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJzcDs8QlI+Jm5ic3A7PEJSPjxG T05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlhbCI+SU1QT1JUQU5UIE5PVElD RTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBv dGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwg d2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0 aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdz LiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBj b25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLjwvRk9OVD48 L0ZPTlQ+ClNVTU1BUlk6TE1BUApQUklPUklUWTo1CkNMQVNTOlBVQkxJQwpCRUdJTjpWQUxBUk0K VFJJR0dFUjotUFQ1TQpBQ1RJT046RElTUExBWQpERVNDUklQVElPTjpSZW1pbmRlcgpFTkQ6VkFM QVJNCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo= --_004_D088231D396A3jasonweiltwcablecom_-- From nobody Thu Nov 13 13:49:52 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3D11ADDB2 for ; Thu, 13 Nov 2014 13:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqQe77Qgqcle for ; Thu, 13 Nov 2014 13:49:46 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD0C1AD592 for ; Thu, 13 Nov 2014 13:49:45 -0800 (PST) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 13 Nov 2014 21:49:44 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.213]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Thu, 13 Nov 2014 21:49:43 +0000 From: To: , Date: Thu, 13 Nov 2014 21:49:41 +0000 Thread-Topic: draft-ksubram-lmap-router-buffer-sizes-00 Thread-Index: Ac/9IIXhaghu935KTUSEb734GjxF2QCaUm+w Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A6E010EEMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/7ytM56gJa1ATMhnlQn4q5IR4k7k Subject: Re: [lmap] draft-ksubram-lmap-router-buffer-sizes-00 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 21:49:50 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A6E010EEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kamala, I was listening in remotely. I agree that buffer sizes are important, and especially the efforts to ensu= re that the queue is almost always as short as possible. I think the draft is about requirements for a particular measurement task. = To me, this sounds more like an ippm activity than lmap. Best wishes phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Kamala Subramaniam Sent: 10 November 2014 20:06 To: lmap@ietf.org Subject: [lmap] draft-ksubram-lmap-router-buffer-sizes-00 Dear LMAP WG, We have submitted a draft "Router Buffer Sizes in the WAN". It will be pres= ented this Thursday. I wanted to take this opportunity to introduce this dr= aft, and get some feedback. This draft has received some input from the AQM= WG. The lmap-use-cases draft is what initiated the request to be presented in t= he LMAP WG. Let me get more in to the details by elaborating the issue wit= h each of the 4 subsections in this ISP use case. Before that, maybe listing the goals would give a better idea: * Drive down the unit cost in $/GB by building efficient but cheaper= networks. Do our networks really need the buffers we deal with today at hi= gh costs? * Maximize throughput in the backbone by always keeping the links bu= sy so that the router buffers never underflow and the router does not lose = throughput. * To take into consideration variables such as {short Vs long flows,= packet sizes, queue depth/model, traffic classes, etc.} as factors while r= educing the whistles, bells, and knobs to keep it simple to configure as we= ll as manage. Now, for the subsections: * Identifying, isolating and fixing problems: we observe that there = are numerous issues at different layers that have an effect (directly or in= directly) on the sizing of router buffers. Could this be solved by high lay= er optimizations (ECN, tweaking TCP flows), or something like just a diffe= rent queuing model. Studying the nature of the traffic that exists in an IS= P world today is an important way to determine this. Where really is this p= roblem? Is it the way we design our networks for example by not taking into= consideration how scavenger class really affects us? * Design and planning: One the problem has been identified it become= s easier to design and plan the networks. Perhaps all we need are small siz= e buffers driving down the cost. * Understanding the quality experienced by customers: again a huge c= hunk of the study would have packet discards (WAN facing/ outgoing egress i= nterface perhaps?). Do the new methods involved in this study work better f= or QoS? * Understanding the impact and operation of new devices and technolo= gy: let's say that the conclusion of this study is that we do not need larg= e size buffers (we are talking 125MB per port), then can we convince the ve= ndors (switch/router/chip) to go down that path. There have been many studies which provide theories to what the size should= be. However, most of these are theoretical in nature and do not take into = account any empirical data. While we continue to mine the big data availabl= e to us to further study this, we'd also like to start a draft which would = in the minimum entail a problem statement, get an idea of the amount of int= erest, and hopefully lead to some collaboration. Regards, Kamala --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A6E010EEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kam= ala,

I was listening in remotel= y.

I agree that buffer sizes ar= e important, and especially the efforts to ensure that the queue is almost = always as short as possible.

 

I think the draft is about= requirements for a particular measurement task. To me, this sounds more li= ke an ippm activity than lmap.

=  

Best wishes

phil

 

From: lmap [mailto:lmap-bounces@ietf.org] On Be= half Of Kamala Subramaniam
Sent: 10 November 2014 20:06
To: lmap@ietf.org
Subject: [lmap] draft-ksubram-lmap-router-= buffer-sizes-00

=  

Dear LMAP WG,

 

We have submitted a draft = 220;Router Buffer Sizes in the WAN”. It will be presented this Thursd= ay. I wanted to take this opportunity to introduce this draft, and get some= feedback. This draft has received some input from the AQM WG. <= /span>

<= o:p> 

The lmap-use-cases draft is what initiated the request to b= e presented in the LMAP WG.  Let me get more in to the details by elab= orating the issue with each of the 4 subsections in this ISP use case.=

 

Before that, maybe listing the goals would give a be= tter idea:

· &nbs= p;      Drive down the unit cost in $/GB = by building efficient but cheaper networks. Do our networks really need the= buffers we deal with today at high costs?

·        Ma= ximize throughput in the backbone by always keeping the links busy so that = the router buffers never underflow and the router does not lose throughput.=

&= middot;   &nbs= p;    To take into consideration variables such as = {short Vs long flows, packet sizes, queue depth/model, traffic classes, etc= .} as factors while reducing the whistles, bells, and knobs to keep it simp= le to configure as well as manage.

Now, for the subsections:

·        Identifying, = isolating and fixing problems: we observe that there are numerous issues at= different layers that have an effect (directly or indirectly) on the sizin= g of router buffers. Could this be solved by high layer optimizations (ECN,= tweaking TCP flows),  or something like just a different queuing mode= l. Studying the nature of the traffic that exists in an ISP world today is = an important way to determine this. Where really is this problem? Is it the= way we design our networks for example by not taking into consideration ho= w scavenger class really affects us?

&mi= ddot;    =     Design and planning: One the problem has been i= dentified it becomes easier to design and plan the networks. Perhaps all we= need are small size buffers driving down the cost.

· &nb= sp;      Understanding the quality experi= enced by customers: again a huge chunk of the study would have packet disca= rds (WAN facing/ outgoing egress interface perhaps?). Do the new methods in= volved in this study work better for QoS?

= ·   &nb= sp;    Understanding the impact and operation of ne= w devices and technology: let’s say that the conclusion of this study= is that we do not need large size buffers (we are talking 125MB per port),= then can we convince the vendors (switch/router/chip) to go down that path= .

There have been many studies which provide theories to what the= size should be. However, most of these are theoretical in nature and do no= t take into account any empirical data. While we continue to mine the big d= ata available to us to further study this, we’d also like to start a = draft which would in the minimum entail a problem statement, get an idea of= the amount of interest, and hopefully lead to some collaboration.

 

Regards,

Kamala

 

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A6E010EEMV67UKRDdoma_-- From nobody Thu Nov 13 14:21:31 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32C51AE014 for ; Thu, 13 Nov 2014 14:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0ZHqaWRJpis for ; Thu, 13 Nov 2014 14:21:25 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0746.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:746]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178DB1AE00C for ; Thu, 13 Nov 2014 14:21:20 -0800 (PST) Received: from CY1PR0301MB0633.namprd03.prod.outlook.com (25.160.158.139) by CY1PR0301MB0633.namprd03.prod.outlook.com (25.160.158.139) with Microsoft SMTP Server (TLS) id 15.1.16.15; Thu, 13 Nov 2014 22:20:58 +0000 Received: from CY1PR0301MB0633.namprd03.prod.outlook.com ([25.160.158.139]) by CY1PR0301MB0633.namprd03.prod.outlook.com ([25.160.158.139]) with mapi id 15.01.0016.006; Thu, 13 Nov 2014 22:20:58 +0000 From: Kamala Subramaniam To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: draft-ksubram-lmap-router-buffer-sizes-00 Thread-Index: Ac/9IIXhaghu935KTUSEb734GjxF2QCaUm+wAAGEDeA= Date: Thu, 13 Nov 2014 22:20:57 +0000 Message-ID: <788db2d64d6348b6b2e9d7ec9dba5340@CY1PR0301MB0633.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.179.85] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0633; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0633; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(377454003)(46034005)(199003)(97736003)(19580395003)(19580405001)(15975445006)(77156002)(95666004)(2501002)(77096003)(99286002)(120916001)(106356001)(40100003)(107886001)(122556002)(107046002)(230783001)(66066001)(62966003)(20776003)(64706001)(86362001)(108616004)(105586002)(33646002)(50986999)(76176999)(54356999)(46102003)(16236675004)(21056001)(76576001)(87936001)(92566001)(19625215002)(2656002)(15202345003)(101416001)(74316001)(31966008)(4396001)(19300405004)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0633; H:CY1PR0301MB0633.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_788db2d64d6348b6b2e9d7ec9dba5340CY1PR0301MB0633namprd03_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/4wav8jCaVaRyEexo0jW8nmsDGSM Subject: Re: [lmap] draft-ksubram-lmap-router-buffer-sizes-00 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 22:21:30 -0000 --_000_788db2d64d6348b6b2e9d7ec9dba5340CY1PR0301MB0633namprd03_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Phil, Thank you for your feedback. The draft actually mainly points to a lack of = a method to collect, compare, and analyze empirical data today more than th= e metrics themselves. I can understand how the metrics can be misleading. Regards, Kamala From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Thursday, November 13, 2014 1:50 PM To: Kamala Subramaniam; lmap@ietf.org Subject: RE: draft-ksubram-lmap-router-buffer-sizes-00 Hi Kamala, I was listening in remotely. I agree that buffer sizes are important, and especially the efforts to ensu= re that the queue is almost always as short as possible. I think the draft is about requirements for a particular measurement task. = To me, this sounds more like an ippm activity than lmap. Best wishes phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Kamala Subramaniam Sent: 10 November 2014 20:06 To: lmap@ietf.org Subject: [lmap] draft-ksubram-lmap-router-buffer-sizes-00 Dear LMAP WG, We have submitted a draft "Router Buffer Sizes in the WAN". It will be pres= ented this Thursday. I wanted to take this opportunity to introduce this dr= aft, and get some feedback. This draft has received some input from the AQM= WG. The lmap-use-cases draft is what initiated the request to be presented in t= he LMAP WG. Let me get more in to the details by elaborating the issue wit= h each of the 4 subsections in this ISP use case. Before that, maybe listing the goals would give a better idea: * Drive down the unit cost in $/GB by building efficient but cheaper= networks. Do our networks really need the buffers we deal with today at hi= gh costs? * Maximize throughput in the backbone by always keeping the links bu= sy so that the router buffers never underflow and the router does not lose = throughput. * To take into consideration variables such as {short Vs long flows,= packet sizes, queue depth/model, traffic classes, etc.} as factors while r= educing the whistles, bells, and knobs to keep it simple to configure as we= ll as manage. Now, for the subsections: * Identifying, isolating and fixing problems: we observe that there = are numerous issues at different layers that have an effect (directly or in= directly) on the sizing of router buffers. Could this be solved by high lay= er optimizations (ECN, tweaking TCP flows), or something like just a diffe= rent queuing model. Studying the nature of the traffic that exists in an IS= P world today is an important way to determine this. Where really is this p= roblem? Is it the way we design our networks for example by not taking into= consideration how scavenger class really affects us? * Design and planning: One the problem has been identified it become= s easier to design and plan the networks. Perhaps all we need are small siz= e buffers driving down the cost. * Understanding the quality experienced by customers: again a huge c= hunk of the study would have packet discards (WAN facing/ outgoing egress i= nterface perhaps?). Do the new methods involved in this study work better f= or QoS? * Understanding the impact and operation of new devices and technolo= gy: let's say that the conclusion of this study is that we do not need larg= e size buffers (we are talking 125MB per port), then can we convince the ve= ndors (switch/router/chip) to go down that path. There have been many studies which provide theories to what the size should= be. However, most of these are theoretical in nature and do not take into = account any empirical data. While we continue to mine the big data availabl= e to us to further study this, we'd also like to start a draft which would = in the minimum entail a problem statement, get an idea of the amount of int= erest, and hopefully lead to some collaboration. Regards, Kamala --_000_788db2d64d6348b6b2e9d7ec9dba5340CY1PR0301MB0633namprd03_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Phil,

 

Thank you for your fee= dback. The draft actually mainly points to a lack of a method to collect, c= ompare, and analyze empirical data today more than the metrics themselves. = I can understand how the metrics can be misleading.

 

Regards,

Kamala

 

From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com]
Sent: Thursday, November 13, 2014 1:50 PM
To: Kamala Subramaniam; lmap@ietf.org
Subject: RE: draft-ksubram-lmap-router-buffer-sizes-00

 

Hi Kamala,

I was listening in remotely= .

I agree that buffer sizes a= re important, and especially the efforts to ensure that the queue is almost= always as short as possible.

 

I think the draft is about = requirements for a particular measurement task. To me, this sounds more lik= e an ippm activity than lmap.

 

Best wishes

phil

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Kamala Subramaniam
Sent: 10 November 2014 20:06
To: lmap@ietf.org
Subject: [lmap] draft-ksubram-lmap-router-buffer-sizes-00=

 

Dear LMAP WG,

 

We have submitted a dr= aft “Router Buffer Sizes in the WAN”. It will be presented this= Thursday. I wanted to take this opportunity to introduce this draft, and g= et some feedback. This draft has received some input from the AQM WG.

 

The lmap-use-cases dra= ft is what initiated the request to be presented in the LMAP WG.  Let = me get more in to the details by elaborating the issue with each of the 4 s= ubsections in this ISP use case.

 

Before that, maybe lis= ting the goals would give a better idea:

·   =      Driv= e down the unit cost in $/GB by building efficient but cheaper networks. Do= our networks really need the buffers we deal with today at high costs?

·   =      Maxi= mize throughput in the backbone by always keeping the links busy so that th= e router buffers never underflow and the router does not lose throughput.

·   =      To t= ake into consideration variables such as {short Vs long flows, packet sizes= , queue depth/model, traffic classes, etc.} as factors while reducing the w= histles, bells, and knobs to keep it simple to configure as well as manage.

Now, for the subsectio= ns:

·    &= nbsp;   Iden= tifying, isolating and fixing problems: we observe that there are numerous = issues at different layers that have an effect (directly or indirectly) on = the sizing of router buffers. Could this be solved by high layer optimizations (ECN, tweaking TCP flows), &nbs= p;or something like just a different queuing model. Studying the nature of = the traffic that exists in an ISP world today is an important way to determ= ine this. Where really is this problem? Is it the way we design our networks for example by not taking into consid= eration how scavenger class really affects us?

·    =     Desi= gn and planning: One the problem has been identified it becomes easier to d= esign and plan the networks. Perhaps all we need are small size buffers dri= ving down the cost.

·    =     Unde= rstanding the quality experienced by customers: again a huge chunk of the s= tudy would have packet discards (WAN facing/ outgoing egress interface perh= aps?). Do the new methods involved in this study work better for QoS?

= ·    &n= bsp;   Unde= rstanding the impact and operation of new devices and technology: let’= ;s say that the conclusion of this study is that we do not need large size = buffers (we are talking 125MB per port), then can we convince the vendors (switch/router/chip) to go down that path= .

There have been many s= tudies which provide theories to what the size should be. However, most of = these are theoretical in nature and do not take into account any empirical = data. While we continue to mine the big data available to us to further study this, we’d also like to st= art a draft which would in the minimum entail a problem statement, get an i= dea of the amount of interest, and hopefully lead to some collaboration.

 

Regards,

Kamala

 

--_000_788db2d64d6348b6b2e9d7ec9dba5340CY1PR0301MB0633namprd03_-- From nobody Fri Nov 14 23:36:41 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584B71A1B38 for ; Fri, 14 Nov 2014 23:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.784 X-Spam-Level: X-Spam-Status: No, score=-6.784 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPi76NE_tKEB for ; Fri, 14 Nov 2014 23:36:36 -0800 (PST) Received: from worker1.doodle.com (worker1.doodle.com [188.92.145.81]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 401001A1AA6 for ; Fri, 14 Nov 2014 23:36:35 -0800 (PST) Received: from worker1.doodle.com (localhost [127.0.0.1]) by worker1.doodle.com (Postfix) with ESMTP id 5CB69104E185 for ; Sat, 15 Nov 2014 08:36:33 +0100 (CET) Date: Sat, 15 Nov 2014 08:36:33 +0100 (CET) From: "Dan Romascanu (via Doodle)" To: Message-ID: <2081524655.293807.1416036993377.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE.doodle@worker1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_293806_504049940.1416036993377" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/0MDtpVr3MA0GC7LH9PodpVOtxVw Subject: [lmap] LMAP December 2014 Virtual Interim Meeting X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Dan Romascanu List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 07:36:39 -0000 ------=_Part_293806_504049940.1416036993377 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi there, Dan Romascanu (dromasca@avaya.com) invites you to participate in the Doodle poll "LMAP December 2014 Virtual Interim Meeting". Dan Romascanu says: Virtual Interim Meeting of the IETF LMAP WG - as per the discussions at IETF-91 Participate now https://doodle.com/fu42xnzk475ke8z7?tmail=3Dpoll_invitecontact_participant_= invitation_with_message&tlink=3Dpollbtn What is Doodle? Doodle is a web service that helps Dan Romascanu to find a suitable date for meeting with a group of people. Learn more about how Doodle works. (https://doodle.com/main.html?tlink=3DcheckOutLink&tmail=3Dpoll_inviteconta= ct_participant_invitation_with_message) ---------------------------------------------------------------------- You have received this e-mail because "Dan Romascanu" has invited you to participate in the Doodle poll "LMAP December 2014 Virtual Interim Meeting." ---- Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich ------=_Part_293806_504049940.1416036993377 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =
=09
Dan Romascanu invites you t= o participate in the Doodle poll "LMAP December 2014 Virtual Interim M= eeting."
=09
=09 =09 =09
=09 =09=09 =09=09 =09=09=09=09=09=09=09 =09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09
=09=09 =09=09=09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09=09=09 =09=09 =09=09 =09=09 =09=09 =09 =09=09 =09=09
=09=09 =09 =09=09 =09 =09=09=09 =09 =09=09=09
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =20 =20 =09=09=09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
"LMAP Decembe= r 2014 Virtual Interim Meeting". =09=09=09=09=09=09
=09=09=09=09=09
=09=09 =09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09Dan Romascanu says: =09=09=09=09=09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09Virtual Interim Meeting of the IETF LMAP WG - as per t= he discussions at IETF-91 =09=09=09=09=09=09
=09=09=09=09=09
=20 =09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=
=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09=09=09Participate now =09=09=09=09=09=09=09
=09=09=09=09=09
=
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09
=20 =09=09=09=09=09=09=09 What is Doodle? Doodle is a web service that helps Dan Romascanu to find a suitable date= for meeting with a group of people. Learn more about how Doodle works.
=20 =09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09=09 =20 =09=09
=09=09 =09You have received this e-mail because "Dan Romascanu&= quot; has invited you to participate in the Doodle poll "LMAP December= 2014 Virtual Interim Meeting." =09=09
=09
=20
Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich

------=_Part_293806_504049940.1416036993377-- From nobody Tue Nov 18 06:31:37 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181AC1A03FF for ; Tue, 18 Nov 2014 06:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.584 X-Spam-Level: X-Spam-Status: No, score=-7.584 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOdYuvq4waH3 for ; Tue, 18 Nov 2014 06:31:32 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21541A0687 for ; Tue, 18 Nov 2014 06:31:32 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikPAAhXa1TGmAcV/2dsb2JhbABbgkgjI1VZBIMCtVGTIx0BCIdKAhxwFgEBAQEBAXyEAgEBAQEDEhEKXAIBCA0EBAEBCx0DAgICMBQJCAIEEwgaiB8BDK8YilaWZAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBRIFigxOGf4MfLQoBgjZBEiSBHgWST4RdiF09gxiDIoRbhWuECYN7bQEBgUaBAwEBAQ X-IronPort-AV: E=Sophos; i="5.07,410,1413259200"; d="scan'208,217"; a="92626923" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Nov 2014 09:31:31 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 18 Nov 2014 09:31:30 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Tue, 18 Nov 2014 15:31:28 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [lmap] LMAP December 2014 Virtual Interim Meeting Thread-Index: AQHQAKbpe2A/+E9nuEm8JsIpf/tLNpxmdsLQ Date: Tue, 18 Nov 2014 14:31:26 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C90892A@AZ-FFEXMB04.global.avaya.com> References: <2081524655.293807.1416036993377.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE.doodle@worker1> In-Reply-To: <2081524655.293807.1416036993377.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE.doodle@worker1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C90892AAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/QSBjAYOGopvb146eyCj8-bW1F8I Subject: Re: [lmap] LMAP December 2014 Virtual Interim Meeting X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 14:31:36 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C90892AAZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhIHJlbWluZGVyIGZvciBhbGwgTE1BUCBwYXJ0aWNpcGFudHMgdG8gcmVzcG9uZCB0 byB0aGUgRG9vZGxlIHBvbGwgY29uY2VybmluZyB0aGUgTE1BUCBEZWNlbWJlciAyMDE0IHZpcnR1 YWwgaW50ZXJpbSBtZWV0aW5nIGRhdGUuIFBsZWFzZSBleHByZXNzIHlvdXIgcHJlZmVyZW5jZXMs IHNvIHRoYXQgd2UgY2FuIGRlY2lkZSBhYm91dCB0aGUgZXhhY3QgZGF0ZSBhbmQgdGltZSBvZiB0 aGUgbWVldGluZyBieSB0aGUgZW5kIG9mIHRoaXMgd2Vlay4NCg0KVGhhbmtzIGFuZCBSZWdhcmRz LA0KDQpEYW4NCg0KDQpGcm9tOiBsbWFwIFttYWlsdG86bG1hcC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgRGFuIFJvbWFzY2FudSAodmlhIERvb2RsZSkNClNlbnQ6IFNhdHVyZGF5LCBO b3ZlbWJlciAxNSwgMjAxNCA5OjM3IEFNDQpUbzogbG1hcEBpZXRmLm9yZw0KU3ViamVjdDogW2xt YXBdIExNQVAgRGVjZW1iZXIgMjAxNCBWaXJ0dWFsIEludGVyaW0gTWVldGluZw0KDQpEYW4gUm9t YXNjYW51IGludml0ZXMgeW91IHRvIHBhcnRpY2lwYXRlIGluIHRoZSBEb29kbGUgcG9sbCAiTE1B UCBEZWNlbWJlciAyMDE0IFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nLiINCg0KDQoNCltodHRwczov L2Rvb2RsZS5jb20vZ3JhcGhpY3MvbWFpbHMwL2xvZ28ucG5nP3RtYWlsPXBvbGxfaW52aXRlY29u dGFjdF9wYXJ0aWNpcGFudF9pbnZpdGF0aW9uX3dpdGhfbWVzc2FnZSZ0bGluaz1vcGVuZWRdPGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZG9vZGxl LmNvbV8tM0Z0bWFpbC0zRHBvbGwtNUZpbnZpdGVjb250YWN0LTVGcGFydGljaXBhbnQtNUZpbnZp dGF0aW9uLTVGd2l0aC01Rm1lc3NhZ2UtMjZ0bGluay0zRGxvZ28mZD1BQU1GYVEmYz1CRnBXUXc4 YnN1S3BsMVNnaVpINjRRJnI9STRkekd4UjMxT2NOWENKZlF6dmxzaUxRZnVjQlhSdWNQdmRycGhw QnNGQSZtPW5hdml3dnJJR0x4VmFPajRQSGlnRjJRZV9ndk5VWS1VSUhuWDJOQzhMNzgmcz1ZZk1y ZEdCNWRvYmV0QTFOTThJemM3RFlUOUhfY01oVFNhQW8xZ2NoV2hRJmU9Pg0KDQoNCg0KSGkgdGhl cmUsDQoNCg0KDQoNCg0KRGFuIFJvbWFzY2FudSAoZHJvbWFzY2FAYXZheWEuY29tPG1haWx0bzpk cm9tYXNjYUBhdmF5YS5jb20+KSBpbnZpdGVzIHlvdSB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgRG9v ZGxlIHBvbGwgIkxNQVAgRGVjZW1iZXIgMjAxNCBWaXJ0dWFsIEludGVyaW0gTWVldGluZyIuDQoN Cg0KRGFuIFJvbWFzY2FudSBzYXlzOg0KVmlydHVhbCBJbnRlcmltIE1lZXRpbmcgb2YgdGhlIElF VEYgTE1BUCBXRyAtIGFzIHBlciB0aGUgZGlzY3Vzc2lvbnMgYXQgSUVURi05MQ0KDQoNCg0KUGFy dGljaXBhdGUgbm93PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fZG9vZGxlLmNvbV9mdTQyeG56azQ3NWtlOHo3LTNGdG1haWwtM0Rwb2xsLTVGaW52 aXRlY29udGFjdC01RnBhcnRpY2lwYW50LTVGaW52aXRhdGlvbi01RndpdGgtNUZtZXNzYWdlLTI2 dGxpbmstM0Rwb2xsYnRuJmQ9QUFNRmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPUk0ZHpH eFIzMU9jTlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBocEJzRkEmbT1uYXZpd3ZySUdMeFZhT2o0 UEhpZ0YyUWVfZ3ZOVVktVUlIblgyTkM4TDc4JnM9dTBleVRwRnpTTG5md2NoQUZGMXgtMGotUFRa dkVHNU92RHc0X1VVVm5EcyZlPT4NCg0KDQoNCg0KW2h0dHA6Ly9kb29kbGUuY29tL2dyYXBoaWNz L21haWxzMC9pbmZvLnBuZ10NCg0KV2hhdCBpcyBEb29kbGU/IERvb2RsZSBpcyBhIHdlYiBzZXJ2 aWNlIHRoYXQgaGVscHMgRGFuIFJvbWFzY2FudSB0byBmaW5kIGEgc3VpdGFibGUgZGF0ZSBmb3Ig bWVldGluZyB3aXRoIGEgZ3JvdXAgb2YgcGVvcGxlLiBMZWFybiBtb3JlIGFib3V0IGhvdyBEb29k bGUgd29ya3MuPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fZG9vZGxlLmNvbV9tYWluLmh0bWwtM0Z0bGluay0zRGNoZWNrT3V0TGluay0yNnRtYWls LTNEcG9sbC01Rmludml0ZWNvbnRhY3QtNUZwYXJ0aWNpcGFudC01Rmludml0YXRpb24tNUZ3aXRo LTVGbWVzc2FnZSZkPUFBTUZhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1JNGR6R3hSMzFP Y05YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09bmF2aXd2cklHTHhWYU9qNFBIaWdG MlFlX2d2TlVZLVVJSG5YMk5DOEw3OCZzPWJ3RFROdFExYVpNUk5MbXJyNXZGY3VkTUEtR0lSR2Rj S2x4OTRETGxEcUUmZT0+DQoNCg0KDQpZb3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBiZWNh dXNlICJEYW4gUm9tYXNjYW51IiBoYXMgaW52aXRlZCB5b3UgdG8gcGFydGljaXBhdGUgaW4gdGhl IERvb2RsZSBwb2xsICJMTUFQIERlY2VtYmVyIDIwMTQgVmlydHVhbCBJbnRlcmltIE1lZXRpbmcu Ig0KDQoNCg0KRG9vZGxlIEFHLCBXZXJkc3RyYXNzZSAyMSwgODAyMSBaw7xyaWNoDQoNCg0KDQoN Cg== --_000_9904FB1B0159DA42B0B887B7FA8119CA5C90892AAZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQoJcGFub3NlLTE6MiA3IDQgOSAyIDIgNSAyIDQgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQoJcGFub3NlLTE6MiA3IDQgOSAy IDIgNSAyIDQgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhv bWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGlzIGlzIGEgcmVtaW5kZXIgZm9yIGFsbCBMTUFQIHBhcnRpY2lwYW50 cyB0byByZXNwb25kIHRvIHRoZSBEb29kbGUgcG9sbCBjb25jZXJuaW5nIHRoZSBMTUFQIERlY2Vt YmVyIDIwMTQgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcgZGF0ZS4gUGxlYXNlIGV4cHJlc3MgeW91 cg0KIHByZWZlcmVuY2VzLCBzbyB0aGF0IHdlIGNhbiBkZWNpZGUgYWJvdXQgdGhlIGV4YWN0IGRh dGUgYW5kIHRpbWUgb2YgdGhlIG1lZXRpbmcgYnkgdGhlIGVuZCBvZiB0aGlzIHdlZWsuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRoYW5rcyBhbmQgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRhbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gbG1hcCBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+RGFuIFJvbWFzY2FudSAodmlhIERvb2RsZSk8YnI+DQo8Yj5TZW50OjwvYj4gU2F0 dXJkYXksIE5vdmVtYmVyIDE1LCAyMDE0IDk6MzcgQU08YnI+DQo8Yj5Ubzo8L2I+IGxtYXBAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2xtYXBdIExNQVAgRGVjZW1iZXIgMjAxNCBWaXJ0 dWFsIEludGVyaW0gTWVldGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkRhbiBSb21h c2NhbnUgaW52aXRlcyB5b3UgdG8gcGFydGljaXBhdGUgaW4gdGhlIERvb2RsZSBwb2xsICZxdW90 O0xNQVAgRGVjZW1iZXIgMjAxNCBWaXJ0dWFsIEludGVyaW0gTWVldGluZy4mcXVvdDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBhbGlnbj0iY2VudGVyIj4NCjx0YWJsZSBjbGFzcz0iTXNv Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJTtiYWNrZ3JvdW5kOndoaXRlO2hlaWdodDox MDAlIWltcG9ydGFudDt3aWR0aDoxMDAlIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQg dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8ZGl2IGFsaWdu PSJjZW50ZXIiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs c3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI0ODAiIHN0eWxlPSJ3aWR0aDozNjAu MHB0O2JhY2tncm91bmQ6d2hpdGUiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MjEuMHB0 Ij4NCjx0ZCBjb2xzcGFuPSI0IiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0 OjIxLjBwdCI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAw Y20gMGNtIj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNw YWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNDgwIiBzdHlsZT0id2lkdGg6MzYwLjBw dDtiYWNrZ3JvdW5kOndoaXRlIiBpZD0idGVtcGxhdGVIZWFkZXIiPg0KPHRib2R5Pg0KPHRyIHN0 eWxlPSJoZWlnaHQ6MjEuMHB0Ij4NCjx0ZCBjb2xzcGFuPSI0IiBzdHlsZT0icGFkZGluZzowY20g MGNtIDBjbSAwY207aGVpZ2h0OjIxLjBwdCI+PC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdo dDoxOS41cHQiPg0KPHRkIHdpZHRoPSIxNSIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDox MS4yNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxOS41cHQiPg0KPC90ZD4NCjx0 ZCB3aWR0aD0iMTIwIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjkwLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTkuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fZG9vZGxlLmNvbV8tM0Z0bWFpbC0zRHBvbGwtNUZpbnZpdGVjb250YWN0LTVGcGFydGljaXBh bnQtNUZpbnZpdGF0aW9uLTVGd2l0aC01Rm1lc3NhZ2UtMjZ0bGluay0zRGxvZ28mYW1wO2Q9QUFN RmFRJmFtcDtjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmYW1wO3I9STRkekd4UjMxT2NOWENKZlF6 dmxzaUxRZnVjQlhSdWNQdmRycGhwQnNGQSZhbXA7bT1uYXZpd3ZySUdMeFZhT2o0UEhpZ0YyUWVf Z3ZOVVktVUlIblgyTkM4TDc4JmFtcDtzPVlmTXJkR0I1ZG9iZXRBMU5NOEl6YzdEWVQ5SF9jTWhU U2FBbzFnY2hXaFEmYW1wO2U9Ij48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxp bWcgYm9yZGVyPSIwIiBoZWlnaHQ9IjI2IiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8v ZG9vZGxlLmNvbS9ncmFwaGljcy9tYWlsczAvbG9nby5wbmc/dG1haWw9cG9sbF9pbnZpdGVjb250 YWN0X3BhcnRpY2lwYW50X2ludml0YXRpb25fd2l0aF9tZXNzYWdlJmFtcDt0bGluaz1vcGVuZWQi Pjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIzMzAiIHZhbGln bj0iYm90dG9tIiBzdHlsZT0id2lkdGg6MjQ3LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTto ZWlnaHQ6MTkuNXB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1IiB2YWxpZ249ImJvdHRvbSIgc3R5 bGU9IndpZHRoOjExLjI1cHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjE5LjVwdCI+ DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjkuMHB0Ij4NCjx0ZCBjb2xzcGFuPSI0 IiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjkuMHB0Ij48L3RkPg0KPC90 cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNt IDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3Rk Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjwvdHI+DQo8dHI+ DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MEU3RjAgMS4wcHQ7YmFja2dyb3VuZDojRjVGOUZEO3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4N Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAi IGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJv ZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjE1LjBwdCAxMS4yNXB0 IDBjbSAxMS4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox OC43NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5IaSB0aGVyZSwNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzow Y20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNt Ij48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJhY2tncm91bmQ6 I0Y1RjlGRDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1h bFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9 IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzowY20gMTEuMjVwdCAwY20gMTEuMjVwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTc1 NzU3Ij4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9k eT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+ PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxp Z249InRvcCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y1RjlGRDtwYWRkaW5nOjBjbSAxMS4yNXB0IDE1 LjBwdCAxMS4yNXB0Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRo OjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTguNzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzU3NTc1NyI+RGFuIFJvbWFzY2FudSAoPGEgaHJl Zj0ibWFpbHRvOmRyb21hc2NhQGF2YXlhLmNvbSI+ZHJvbWFzY2FAYXZheWEuY29tPC9hPikgaW52 aXRlcyB5b3UgdG8gcGFydGljaXBhdGUgaW4gdGhlIERvb2RsZSBwb2xsDQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzIyMjIyMiI+JnF1b3Q7TE1BUCBEZWNlbWJlciAyMDE0IFZpcnR1YWwgSW50ZXJp bSBNZWV0aW5nJnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1NzU3NTciPi4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0K PHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFk ZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAw Y20gMGNtIj48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJhY2tn cm91bmQ6I0Y1RjlGRDtwYWRkaW5nOjBjbSAxMS4yNXB0IDEzLjVwdCAxMS4yNXB0Ij4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxw YWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjRDBFM0ZCIDIuMjVwdDtwYWRkaW5nOjYuMHB0IDBjbSA2LjBwdCAxMC41cHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE2LjVwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjojMjIyMjIyIj5EYW4gUm9t YXNjYW51IHNheXM6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTYuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOiM1NzU3NTciPlZpcnR1YWwgSW50ZXJpbSBNZWV0 aW5nIG9mIHRoZSBJRVRGIExNQVAgV0cgLSBhcyBwZXIgdGhlIGRpc2N1c3Npb25zIGF0IElFVEYt OTENCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFi bGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0 ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRp bmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0iYmFja2dy b3VuZDojREZFQ0ZDO3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjx0YWJsZSBjbGFzcz0iTXNv Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9Imhl aWdodDo3LjVwdCI+DQo8dGQgd2lkdGg9IjE1IiBjb2xzcGFuPSIzIiB2YWxpZ249InRvcCIgc3R5 bGU9IndpZHRoOjExLjI1cHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjcuNXB0Ij4N CjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTti b3gtc2hhZG93OiAwcHggMHB4IDJweCAwIHJnYigwLCAwLCAwLjI4KTtib3JkZXItcmFkaXVzOiAz cHgiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGlu Zz0iMCIgc3R5bGU9ImJvcmRlci1zcGFjaW5nOiAxNHB4IDBweCI+DQo8dGJvZHk+DQo8dHI+DQo8 dGQgc3R5bGU9ImJhY2tncm91bmQ6IzAwNjZERDtwYWRkaW5nOjMuMHB0IDUuMjVwdCAzLjBwdCA1 LjI1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDow Y207bWFyZ2luLXJpZ2h0OjIuMjVwdDttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDoxMy41 cHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0O2xpbmUtaGVpZ2h0OjEzLjVwdCI+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2Rvb2RsZS5jb21fZnU0Mnhuems0NzVrZTh6Ny0zRnRt YWlsLTNEcG9sbC01Rmludml0ZWNvbnRhY3QtNUZwYXJ0aWNpcGFudC01Rmludml0YXRpb24tNUZ3 aXRoLTVGbWVzc2FnZS0yNnRsaW5rLTNEcG9sbGJ0biZhbXA7ZD1BQU1GYVEmYW1wO2M9QkZwV1F3 OGJzdUtwbDFTZ2laSDY0USZhbXA7cj1JNGR6R3hSMzFPY05YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2 ZHJwaHBCc0ZBJmFtcDttPW5hdml3dnJJR0x4VmFPajRQSGlnRjJRZV9ndk5VWS1VSUhuWDJOQzhM NzgmYW1wO3M9dTBleVRwRnpTTG5md2NoQUZGMXgtMGotUFRadkVHNU92RHc0X1VVVm5EcyZhbXA7 ZT0iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aGl0ZTt0ZXh0LWRlY29yYXRpb246bm9uZSI+UGFydGlj aXBhdGUmbmJzcDtub3c8L3NwYW4+PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw Y20iPjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6Ny41cHQiPg0KPHRkIHdpZHRoPSIx NSIgY29sc3Bhbj0iMyIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMS4yNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gMGNtO2hlaWdodDo3LjVwdCI+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8 L3RhYmxlPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+ DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPHRkIHN0eWxlPSJw YWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0 b3AiIHN0eWxlPSJib3JkZXI6c29saWQgI0RGRUNGQyAxLjBwdDtwYWRkaW5nOjExLjI1cHQgMTEu MjVwdCAxMS4yNXB0IDExLjI1cHQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y ZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHls ZT0id2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB3aWR0aD0iMzUiIHZhbGlnbj0i dG9wIiBzdHlsZT0id2lkdGg6MjYuMjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyNiIgc3JjPSJo dHRwOi8vZG9vZGxlLmNvbS9ncmFwaGljcy9tYWlsczAvaW5mby5wbmciPjxvOnA+PC9vOnA+PC9w Pg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNt Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTYuNXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+V2hhdCBpcyBEb29kbGU/ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTc1NzU3Ij4gRG9vZGxlIGlz IGEgd2ViIHNlcnZpY2UgdGhhdCBoZWxwcw0KIERhbiBSb21hc2NhbnUgdG8gZmluZCBhIHN1aXRh YmxlIGRhdGUgZm9yIG1lZXRpbmcgd2l0aCBhIGdyb3VwIG9mIHBlb3BsZS4gPGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kb29kbGUu Y29tX21haW4uaHRtbC0zRnRsaW5rLTNEY2hlY2tPdXRMaW5rLTI2dG1haWwtM0Rwb2xsLTVGaW52 aXRlY29udGFjdC01RnBhcnRpY2lwYW50LTVGaW52aXRhdGlvbi01RndpdGgtNUZtZXNzYWdlJmFt cDtkPUFBTUZhUSZhbXA7Yz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJmFtcDtyPUk0ZHpHeFIzMU9j TlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBocEJzRkEmYW1wO209bmF2aXd2cklHTHhWYU9qNFBI aWdGMlFlX2d2TlVZLVVJSG5YMk5DOEw3OCZhbXA7cz1id0RUTnRRMWFaTVJOTG1ycjV2RmN1ZE1B LUdJUkdkY0tseDk0RExsRHFFJmFtcDtlPSI+DQpMZWFybiBtb3JlIGFib3V0IGhvdyBEb29kbGUg d29ya3MuPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20g MGNtIj48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0 ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRk IHZhbGlnbj0idG9wIiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRjVGOUZE IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxkaXYgYWxpZ249ImNlbnRlciI+DQo8 dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBj ZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC4wcHQiPg0KPHRk IHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTguMHB0Ij48L3RkPg0KPC90 cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDExLjI1cHQgNi43 NXB0IDExLjI1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEy LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5OTk5OTkiPllvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZS1tYWlsIGJlY2F1c2UgJnF1b3Q7RGFuIFJvbWFzY2FudSZxdW90OyBoYXMg aW52aXRlZCB5b3UgdG8gcGFydGljaXBhdGUgaW4gdGhlIERvb2RsZSBwb2xsICZxdW90O0xNQVAg RGVjZW1iZXIgMjAxNCBWaXJ0dWFsDQogSW50ZXJpbSBNZWV0aW5nLiZxdW90OyA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjkuMHB0Ij4NCjx0 ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjkuMHB0Ij48L3RkPg0KPC90 cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9kaXY+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw Y20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPC90 cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0RERERERCAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8dGFibGUgY2xh c3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGlu Zz0iMCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0K PHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzo5LjBwdCAxMS4yNXB0IDE1LjBwdCAxMS4y NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMi43NXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk5OTk5OSI+RG9vZGxlIEFHLCBXZXJkc3Ry YXNzZSAyMSwgODAyMSBaw7xyaWNoDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90 cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNt IDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3Rk Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9904FB1B0159DA42B0B887B7FA8119CA5C90892AAZFFEXMB04globa_-- From nobody Thu Nov 20 03:53:43 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829061A0174 for ; Thu, 20 Nov 2014 03:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.483 X-Spam-Level: X-Spam-Status: No, score=-9.483 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymW31H28Uco2 for ; Thu, 20 Nov 2014 03:53:37 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCD01A0110 for ; Thu, 20 Nov 2014 03:53:36 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4YADbVbVTGmAcV/2dsb2JhbABagkgjI1VZBIMCtDEBAQEBCJNuHQEIh0oCHG0WAQEBAQEBcQuEAgEBAQEDEhEKXAIBCA0EBAEBCxYHAwICAjAUCQgCBBMIGogfAQyyVIpWlnIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgUSBYoMThn+DHy0KAYI2QRIkgR4FkleEXohfPYMYgyKEW4VthAmDe20BAYFGgQMBAQE X-IronPort-AV: E=Sophos; i="5.07,423,1413259200"; d="scan'208,217"; a="95536005" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 20 Nov 2014 06:53:34 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 20 Nov 2014 06:53:19 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Thu, 20 Nov 2014 12:53:17 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [lmap] LMAP December 2014 Virtual Interim Meeting Thread-Index: AQHQAKbpe2A/+E9nuEm8JsIpf/tLNpxmdsLQgAL4yTA= Date: Thu, 20 Nov 2014 11:53:16 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C90B166@AZ-FFEXMB04.global.avaya.com> References: <2081524655.293807.1416036993377.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE.doodle@worker1> <9904FB1B0159DA42B0B887B7FA8119CA5C90892A@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C90892A@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: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C90B166AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/eYAHQHHy147ixwVrx6WU9UDeTeo Subject: Re: [lmap] LMAP December 2014 Virtual Interim Meeting X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 11:53:39 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C90B166AZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIG1vcmUgcmVtaW5kZXIgYWJvdXQgdGhlIGRvb2RsZSBwb2xsIGZvciB0aGUgdmlydHVhbCBp bnRlcmltIG9mIExNQVAuDQoNClBsZWFzZSBleHByZXNzIHlvdXIgcHJlZmVyZW5jZSBpZiB5b3Ug ZGlkIG5vdCBkbyBpdCB5ZXQgYmVmb3JlIHRoZSBlbmQgb2YgdGhpcyB3ZWVrLg0KDQpUaGFua3Mg YW5kIFJlZ2FyZHMsDQoNCkRhbg0KDQoNCkZyb206IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb21hc2NhbnUsIERhbiAoRGFuKQ0KU2VudDogVHVlc2Rh eSwgTm92ZW1iZXIgMTgsIDIwMTQgNDozMSBQTQ0KVG86IGxtYXBAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbbG1hcF0gTE1BUCBEZWNlbWJlciAyMDE0IFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nDQoN ClRoaXMgaXMgYSByZW1pbmRlciBmb3IgYWxsIExNQVAgcGFydGljaXBhbnRzIHRvIHJlc3BvbmQg dG8gdGhlIERvb2RsZSBwb2xsIGNvbmNlcm5pbmcgdGhlIExNQVAgRGVjZW1iZXIgMjAxNCB2aXJ0 dWFsIGludGVyaW0gbWVldGluZyBkYXRlLiBQbGVhc2UgZXhwcmVzcyB5b3VyIHByZWZlcmVuY2Vz LCBzbyB0aGF0IHdlIGNhbiBkZWNpZGUgYWJvdXQgdGhlIGV4YWN0IGRhdGUgYW5kIHRpbWUgb2Yg dGhlIG1lZXRpbmcgYnkgdGhlIGVuZCBvZiB0aGlzIHdlZWsuDQoNClRoYW5rcyBhbmQgUmVnYXJk cywNCg0KRGFuDQoNCg0KRnJvbTogbG1hcCBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIERhbiBSb21hc2NhbnUgKHZpYSBEb29kbGUpDQpTZW50OiBTYXR1cmRheSwg Tm92ZW1iZXIgMTUsIDIwMTQgOTozNyBBTQ0KVG86IGxtYXBAaWV0Zi5vcmc8bWFpbHRvOmxtYXBA aWV0Zi5vcmc+DQpTdWJqZWN0OiBbbG1hcF0gTE1BUCBEZWNlbWJlciAyMDE0IFZpcnR1YWwgSW50 ZXJpbSBNZWV0aW5nDQoNCkRhbiBSb21hc2NhbnUgaW52aXRlcyB5b3UgdG8gcGFydGljaXBhdGUg aW4gdGhlIERvb2RsZSBwb2xsICJMTUFQIERlY2VtYmVyIDIwMTQgVmlydHVhbCBJbnRlcmltIE1l ZXRpbmcuIg0KDQoNCg0KW2h0dHBzOi8vZG9vZGxlLmNvbS9ncmFwaGljcy9tYWlsczAvbG9nby5w bmc/dG1haWw9cG9sbF9pbnZpdGVjb250YWN0X3BhcnRpY2lwYW50X2ludml0YXRpb25fd2l0aF9t ZXNzYWdlJnRsaW5rPW9wZW5lZF08aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX19kb29kbGUuY29tXy0zRnRtYWlsLTNEcG9sbC01Rmludml0ZWNvbnRh Y3QtNUZwYXJ0aWNpcGFudC01Rmludml0YXRpb24tNUZ3aXRoLTVGbWVzc2FnZS0yNnRsaW5rLTNE bG9nbyZkPUFBTUZhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1JNGR6R3hSMzFPY05YQ0pm UXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09bmF2aXd2cklHTHhWYU9qNFBIaWdGMlFlX2d2 TlVZLVVJSG5YMk5DOEw3OCZzPVlmTXJkR0I1ZG9iZXRBMU5NOEl6YzdEWVQ5SF9jTWhUU2FBbzFn Y2hXaFEmZT0+DQoNCg0KDQpIaSB0aGVyZSwNCg0KDQoNCg0KDQpEYW4gUm9tYXNjYW51IChkcm9t YXNjYUBhdmF5YS5jb208bWFpbHRvOmRyb21hc2NhQGF2YXlhLmNvbT4pIGludml0ZXMgeW91IHRv IHBhcnRpY2lwYXRlIGluIHRoZSBEb29kbGUgcG9sbCAiTE1BUCBEZWNlbWJlciAyMDE0IFZpcnR1 YWwgSW50ZXJpbSBNZWV0aW5nIi4NCg0KDQpEYW4gUm9tYXNjYW51IHNheXM6DQpWaXJ0dWFsIElu dGVyaW0gTWVldGluZyBvZiB0aGUgSUVURiBMTUFQIFdHIC0gYXMgcGVyIHRoZSBkaXNjdXNzaW9u cyBhdCBJRVRGLTkxDQoNCg0KDQpQYXJ0aWNpcGF0ZSBub3c8aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kb29kbGUuY29tX2Z1NDJ4bnprNDc1a2U4 ejctM0Z0bWFpbC0zRHBvbGwtNUZpbnZpdGVjb250YWN0LTVGcGFydGljaXBhbnQtNUZpbnZpdGF0 aW9uLTVGd2l0aC01Rm1lc3NhZ2UtMjZ0bGluay0zRHBvbGxidG4mZD1BQU1GYVEmYz1CRnBXUXc4 YnN1S3BsMVNnaVpINjRRJnI9STRkekd4UjMxT2NOWENKZlF6dmxzaUxRZnVjQlhSdWNQdmRycGhw QnNGQSZtPW5hdml3dnJJR0x4VmFPajRQSGlnRjJRZV9ndk5VWS1VSUhuWDJOQzhMNzgmcz11MGV5 VHBGelNMbmZ3Y2hBRkYxeC0wai1QVFp2RUc1T3ZEdzRfVVVWbkRzJmU9Pg0KDQoNCg0KDQpbaHR0 cDovL2Rvb2RsZS5jb20vZ3JhcGhpY3MvbWFpbHMwL2luZm8ucG5nXQ0KDQpXaGF0IGlzIERvb2Rs ZT8gRG9vZGxlIGlzIGEgd2ViIHNlcnZpY2UgdGhhdCBoZWxwcyBEYW4gUm9tYXNjYW51IHRvIGZp bmQgYSBzdWl0YWJsZSBkYXRlIGZvciBtZWV0aW5nIHdpdGggYSBncm91cCBvZiBwZW9wbGUuIExl YXJuIG1vcmUgYWJvdXQgaG93IERvb2RsZSB3b3Jrcy48aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kb29kbGUuY29tX21haW4uaHRtbC0zRnRsaW5r LTNEY2hlY2tPdXRMaW5rLTI2dG1haWwtM0Rwb2xsLTVGaW52aXRlY29udGFjdC01RnBhcnRpY2lw YW50LTVGaW52aXRhdGlvbi01RndpdGgtNUZtZXNzYWdlJmQ9QUFNRmFRJmM9QkZwV1F3OGJzdUtw bDFTZ2laSDY0USZyPUk0ZHpHeFIzMU9jTlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBocEJzRkEm bT1uYXZpd3ZySUdMeFZhT2o0UEhpZ0YyUWVfZ3ZOVVktVUlIblgyTkM4TDc4JnM9YndEVE50UTFh Wk1STkxtcnI1dkZjdWRNQS1HSVJHZGNLbHg5NERMbERxRSZlPT4NCg0KDQoNCllvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZS1tYWlsIGJlY2F1c2UgIkRhbiBSb21hc2NhbnUiIGhhcyBpbnZpdGVkIHlv dSB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgRG9vZGxlIHBvbGwgIkxNQVAgRGVjZW1iZXIgMjAxNCBW aXJ0dWFsIEludGVyaW0gTWVldGluZy4iDQoNCg0KDQpEb29kbGUgQUcsIFdlcmRzdHJhc3NlIDIx LCA4MDIxIFrDvHJpY2gNCg0KDQoNCg0K --_000_9904FB1B0159DA42B0B887B7FA8119CA5C90B166AZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQoJcGFub3NlLTE6MiA3IDQgOSAyIDIgNSAyIDQgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQoJcGFub3NlLTE6MiA3IDQgOSAy IDIgNSAyIDQgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhv bWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbmUgbW9yZSByZW1pbmRlciBhYm91dCB0aGUgZG9vZGxl IHBvbGwgZm9yIHRoZSB2aXJ0dWFsIGludGVyaW0gb2YgTE1BUC4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNl IGV4cHJlc3MgeW91ciBwcmVmZXJlbmNlIGlmIHlvdSBkaWQgbm90IGRvIGl0IHlldCBiZWZvcmUg dGhlIGVuZCBvZiB0aGlzIHdlZWsuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBhbmQgUmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkRhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbG1hcCBbbWFpbHRvOmxtYXAtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9tYXNjYW51LCBEYW4gKERhbik8 YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92ZW1iZXIgMTgsIDIwMTQgNDozMSBQTTxicj4N CjxiPlRvOjwvYj4gbG1hcEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2xtYXBd IExNQVAgRGVjZW1iZXIgMjAxNCBWaXJ0dWFsIEludGVyaW0gTWVldGluZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGlzIGEgcmVtaW5kZXIgZm9yIGFsbCBMTUFQIHBhcnRp Y2lwYW50cyB0byByZXNwb25kIHRvIHRoZSBEb29kbGUgcG9sbCBjb25jZXJuaW5nIHRoZSBMTUFQ IERlY2VtYmVyIDIwMTQgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcgZGF0ZS4gUGxlYXNlIGV4cHJl c3MgeW91cg0KIHByZWZlcmVuY2VzLCBzbyB0aGF0IHdlIGNhbiBkZWNpZGUgYWJvdXQgdGhlIGV4 YWN0IGRhdGUgYW5kIHRpbWUgb2YgdGhlIG1lZXRpbmcgYnkgdGhlIGVuZCBvZiB0aGlzIHdlZWsu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoYW5rcyBhbmQgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRhbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gbG1hcCBbPGEgaHJlZj0ibWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9y ZyI+bWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PkRhbiBSb21hc2NhbnUgKHZpYSBEb29kbGUpPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBO b3ZlbWJlciAxNSwgMjAxNCA5OjM3IEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86 bG1hcEBpZXRmLm9yZyI+bG1hcEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2xt YXBdIExNQVAgRGVjZW1iZXIgMjAxNCBWaXJ0dWFsIEludGVyaW0gTWVldGluZzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPkRhbiBSb21hc2NhbnUgaW52aXRlcyB5b3UgdG8gcGFydGljaXBh dGUgaW4gdGhlIERvb2RsZSBwb2xsICZxdW90O0xNQVAgRGVjZW1iZXIgMjAxNCBWaXJ0dWFsIElu dGVyaW0gTWVldGluZy4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBhbGlnbj0i Y2VudGVyIj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNw YWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4w JTtiYWNrZ3JvdW5kOndoaXRlO2hlaWdodDoxMDAlIWltcG9ydGFudDt3aWR0aDoxMDAlIWltcG9y dGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBj bSAwY20gMGNtIDBjbSI+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPg0KPHRhYmxlIGNsYXNzPSJNc29O b3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdp ZHRoPSI0ODAiIHN0eWxlPSJ3aWR0aDozNjAuMHB0O2JhY2tncm91bmQ6d2hpdGUiPg0KPHRib2R5 Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MjEuMHB0Ij4NCjx0ZCBjb2xzcGFuPSI0IiBzdHlsZT0icGFk ZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjIxLjBwdCI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9y bWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iNDgwIiBzdHlsZT0id2lkdGg6MzYwLjBwdDtiYWNrZ3JvdW5kOndoaXRlIiBpZD0idGVtcGxh dGVIZWFkZXIiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MjEuMHB0Ij4NCjx0ZCBjb2xz cGFuPSI0IiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjIxLjBwdCI+PC90 ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOS41cHQiPg0KPHRkIHdpZHRoPSIxNSIgdmFs aWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDoxMS4yNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNt O2hlaWdodDoxOS41cHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTIwIiB2YWxpZ249ImJvdHRvbSIg c3R5bGU9IndpZHRoOjkwLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTkuNXB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZG9vZGxlLmNvbV8tM0Z0bWFpbC0zRHBvbGwt NUZpbnZpdGVjb250YWN0LTVGcGFydGljaXBhbnQtNUZpbnZpdGF0aW9uLTVGd2l0aC01Rm1lc3Nh Z2UtMjZ0bGluay0zRGxvZ28mYW1wO2Q9QUFNRmFRJmFtcDtjPUJGcFdRdzhic3VLcGwxU2dpWkg2 NFEmYW1wO3I9STRkekd4UjMxT2NOWENKZlF6dmxzaUxRZnVjQlhSdWNQdmRycGhwQnNGQSZhbXA7 bT1uYXZpd3ZySUdMeFZhT2o0UEhpZ0YyUWVfZ3ZOVVktVUlIblgyTkM4TDc4JmFtcDtzPVlmTXJk R0I1ZG9iZXRBMU5NOEl6YzdEWVQ5SF9jTWhUU2FBbzFnY2hXaFEmYW1wO2U9Ij48c3BhbiBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiBoZWlnaHQ9IjI2IiBpZD0i X3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vZG9vZGxlLmNvbS9ncmFwaGljcy9tYWlsczAvbG9n by5wbmc/dG1haWw9cG9sbF9pbnZpdGVjb250YWN0X3BhcnRpY2lwYW50X2ludml0YXRpb25fd2l0 aF9tZXNzYWdlJmFtcDt0bGluaz1vcGVuZWQiPjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8 L3RkPg0KPHRkIHdpZHRoPSIzMzAiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6MjQ3LjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTkuNXB0Ij4NCjwvdGQ+DQo8dGQgd2lk dGg9IjE1IiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjExLjI1cHQ7cGFkZGluZzowY20g MGNtIDBjbSAwY207aGVpZ2h0OjE5LjVwdCI+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVp Z2h0OjkuMHB0Ij4NCjx0ZCBjb2xzcGFuPSI0IiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw Y207aGVpZ2h0OjkuMHB0Ij48L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4N Cjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBh ZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20g MGNtIDBjbSI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMEU3RjAgMS4wcHQ7YmFja2dyb3VuZDojRjVGOUZE O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUi IGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIg c3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0 eWxlPSJwYWRkaW5nOjE1LjBwdCAxMS4yNXB0IDBjbSAxMS4yNXB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxOC43NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIy Ij5IaSB0aGVyZSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9k eT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+ PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxp Z249InRvcCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y1RjlGRDtwYWRkaW5nOjBjbSAwY20gMGNtIDBj bSI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5n PSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0K PHRib2R5Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMTEuMjVw dCAwY20gMTEuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTMuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTc1NzU3Ij4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20g MGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y1 RjlGRDtwYWRkaW5nOjBjbSAxMS4yNXB0IDE1LjBwdCAxMS4yNXB0Ij4NCjx0YWJsZSBjbGFzcz0i TXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIw IiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQg dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTguNzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzU3 NTc1NyI+RGFuIFJvbWFzY2FudSAoPGEgaHJlZj0ibWFpbHRvOmRyb21hc2NhQGF2YXlhLmNvbSI+ ZHJvbWFzY2FAYXZheWEuY29tPC9hPikgaW52aXRlcyB5b3UgdG8gcGFydGljaXBhdGUgaW4gdGhl IERvb2RsZSBwb2xsDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+JnF1b3Q7TE1BUCBE ZWNlbWJlciAyMDE0IFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nJnF1b3Q7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM1NzU3NTciPi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt IDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPC90cj4NCjx0cj4NCjx0 ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y1RjlGRDtwYWRkaW5nOjBjbSAxMS4y NXB0IDEzLjVwdCAxMS4yNXB0Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRl cj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9 IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjRDBFM0ZCIDIuMjVwdDtwYWRkaW5nOjYuMHB0 IDBjbSA2LjBwdCAxMC41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE2LjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6Q291 cmllcjtjb2xvcjojMjIyMjIyIj5EYW4gUm9tYXNjYW51IHNheXM6DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTYuNXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOiM1 NzU3NTciPlZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nIG9mIHRoZSBJRVRGIExNQVAgV0cgLSBhcyBw ZXIgdGhlIGRpc2N1c3Npb25zIGF0IElFVEYtOTENCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw Y20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPC90 cj4NCjx0cj4NCjx0ZCBzdHlsZT0iYmFja2dyb3VuZDojREZFQ0ZDO3BhZGRpbmc6MGNtIDBjbSAw Y20gMGNtIj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNw YWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4w JSI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDo3LjVwdCI+DQo8dGQgd2lkdGg9IjE1IiBj b2xzcGFuPSIzIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExLjI1cHQ7cGFkZGluZzowY20g MGNtIDBjbSAwY207aGVpZ2h0OjcuNXB0Ij4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtib3gtc2hhZG93OiAwcHggMHB4IDJweCAwIHJnYigw LCAwLCAwLjI4KTtib3JkZXItcmFkaXVzOiAzcHgiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxU YWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9ImJvcmRlci1zcGFjaW5nOiAx NHB4IDBweCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJhY2tncm91bmQ6IzAwNjZERDtw YWRkaW5nOjMuMHB0IDUuMjVwdCAzLjBwdCA1LjI1cHQ7Ym9yZGVyLXNwYWNpbmc6IDE0cHggMHB4 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21h cmdpbi1yaWdodDoyLjI1cHQ7bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6MTMuNXB0O21h cmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDoxMy41cHQiPg0KPGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX19kb29kbGUuY29tX2Z1NDJ4bnprNDc1a2U4ejctM0Z0bWFpbC0z RHBvbGwtNUZpbnZpdGVjb250YWN0LTVGcGFydGljaXBhbnQtNUZpbnZpdGF0aW9uLTVGd2l0aC01 Rm1lc3NhZ2UtMjZ0bGluay0zRHBvbGxidG4mYW1wO2Q9QUFNRmFRJmFtcDtjPUJGcFdRdzhic3VL cGwxU2dpWkg2NFEmYW1wO3I9STRkekd4UjMxT2NOWENKZlF6dmxzaUxRZnVjQlhSdWNQdmRycGhw QnNGQSZhbXA7bT1uYXZpd3ZySUdMeFZhT2o0UEhpZ0YyUWVfZ3ZOVVktVUlIblgyTkM4TDc4JmFt cDtzPXUwZXlUcEZ6U0xuZndjaEFGRjF4LTBqLVBUWnZFRzVPdkR3NF9VVVZuRHMmYW1wO2U9Ij48 c3BhbiBzdHlsZT0iY29sb3I6d2hpdGU7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPlBhcnRpY2lwYXRl Jm5ic3A7bm93PC9zcGFuPjwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0K PC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20g MGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48 L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjcuNXB0Ij4NCjx0ZCB3aWR0aD0iMTUiIGNv bHNwYW49IjMiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTEuMjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDBjbTtoZWlnaHQ6Ny41cHQiPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJs ZT4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPHRk IHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGlu ZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBz dHlsZT0iYm9yZGVyOnNvbGlkICNERkVDRkMgMS4wcHQ7cGFkZGluZzoxMS4yNXB0IDExLjI1cHQg MTEuMjVwdCAxMS4yNXB0Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0i MCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9Indp ZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9IjM1IiB2YWxpZ249InRvcCIg c3R5bGU9IndpZHRoOjI2LjI1cHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGltZyBib3JkZXI9IjAiIGlkPSJfeDAwMDBfaTEwMjYiIHNyYz0iaHR0cDov L2Rvb2RsZS5jb20vZ3JhcGhpY3MvbWFpbHMwL2luZm8ucG5nIj48bzpwPjwvbzpwPjwvcD4NCjwv dGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE2LjVwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPldoYXQgaXMgRG9vZGxlPzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzU3NTc1NyI+IERvb2RsZSBpcyBhIHdl YiBzZXJ2aWNlIHRoYXQgaGVscHMNCiBEYW4gUm9tYXNjYW51IHRvIGZpbmQgYSBzdWl0YWJsZSBk YXRlIGZvciBtZWV0aW5nIHdpdGggYSBncm91cCBvZiBwZW9wbGUuIDxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZG9vZGxlLmNvbV9t YWluLmh0bWwtM0Z0bGluay0zRGNoZWNrT3V0TGluay0yNnRtYWlsLTNEcG9sbC01Rmludml0ZWNv bnRhY3QtNUZwYXJ0aWNpcGFudC01Rmludml0YXRpb24tNUZ3aXRoLTVGbWVzc2FnZSZhbXA7ZD1B QU1GYVEmYW1wO2M9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZhbXA7cj1JNGR6R3hSMzFPY05YQ0pm UXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJmFtcDttPW5hdml3dnJJR0x4VmFPajRQSGlnRjJR ZV9ndk5VWS1VSUhuWDJOQzhMNzgmYW1wO3M9YndEVE50UTFhWk1STkxtcnI1dkZjdWRNQS1HSVJH ZGNLbHg5NERMbERxRSZhbXA7ZT0iPg0KTGVhcm4gbW9yZSBhYm91dCBob3cgRG9vZGxlIHdvcmtz LjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9k eT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+ PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxp Z249InRvcCIgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Y1RjlGRCAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPg0KPHRhYmxl IGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBh ZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguMHB0Ij4NCjx0ZCBzdHls ZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjE4LjBwdCI+PC90ZD4NCjwvdHI+DQo8 dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAxMS4yNXB0IDYuNzVwdCAx MS4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTk5OTk5Ij5Zb3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGUtbWFpbCBiZWNhdXNlICZxdW90O0RhbiBSb21hc2NhbnUmcXVvdDsgaGFzIGludml0 ZWQgeW91IHRvIHBhcnRpY2lwYXRlIGluIHRoZSBEb29kbGUgcG9sbCAmcXVvdDtMTUFQIERlY2Vt YmVyIDIwMTQgVmlydHVhbA0KIEludGVyaW0gTWVldGluZy4mcXVvdDsgPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDo5LjBwdCI+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDo5LjBwdCI+PC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjwvZGl2Pg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20g MGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48 L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjwvdHI+DQo8 dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNEREREREQgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHRhYmxlIGNsYXNzPSJN c29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAi IHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2 YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6OS4wcHQgMTEuMjVwdCAxNS4wcHQgMTEuMjVwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIuNzVwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5OTk5OTkiPkRvb2RsZSBBRywgV2VyZHN0cmFzc2Ug MjEsIDgwMjEgWsO8cmljaA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20g MGNtIj48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0 ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9904FB1B0159DA42B0B887B7FA8119CA5C90B166AZFFEXMB04globa_-- From nobody Thu Nov 20 08:14:01 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D591A1AC7 for ; Thu, 20 Nov 2014 08:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMclvq1XViIi for ; Thu, 20 Nov 2014 08:13:35 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C931A1A65 for ; Thu, 20 Nov 2014 08:13:34 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 20 Nov 2014 16:13:36 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.111]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Thu, 20 Nov 2014 16:13:06 +0000 From: To: , Date: Thu, 20 Nov 2014 16:13:04 +0000 Thread-Topic: Secdir review of draft-ietf-lmap-framework-08 Thread-Index: AQHQAvIx8O0/SNtxIEiOh1J4I8qnj5xmpMqAgAMJ+yCAAATFEA== Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C90BD8B@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C90BD8B@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413B0591FBEMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Eojfn2TmYqoTEDmm1cqp1LkkgPM Subject: Re: [lmap] Secdir review of draft-ietf-lmap-framework-08 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 16:13:45 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413B0591FBEMV67UKRDdoma_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2ZpIOKAkw0KRGFuLCB0aGFua3MgZm9yIG5vdGljaW5nIHRoZSBsbWFwIFdHIGxpc3Qgd2FzIG1p c3NpbmcNCg0KcGhpbA0KDQpGcm9tOiBSb21hc2NhbnUsIERhbiAoRGFuKSBbbWFpbHRvOmRyb21h c2NhQGF2YXlhLmNvbV0NClNlbnQ6IDIwIE5vdmVtYmVyIDIwMTQgMTU6NTcNClRvOiBFYXJkbGV5 LFBMLFBoaWxpcCxUVUI4IFI7IHJhZGlhcGVybG1hbkBnbWFpbC5jb207IHNlY2RpckBpZXRmLm9y ZzsgaWVzZ0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay5hbGxAdG9vbHMuaWV0 Zi5vcmcNClN1YmplY3Q6IFJFOiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbG1hcC1mcmFt ZXdvcmstMDgNCg0KVGhhbmtzIHRvIFJhZGlhIGZvciB0aGUgdmFsdWFibGUgcmV2aWV3LiBUaGV5 IGRlc2VydmUgZGlzY3Vzc2lvbiBhbmQgZWRpdHMuDQoNClBoaWwsIHNvbWUgb2YgeW91ciBxdWVz dGlvbnMgc2VlbSB0byBiZSBhZGRyZXNzZWQgdG8gdGhlIExNQVAgY29tbXVuaXR5LiBBbSBJIHdy b25nPyBUaGUgTE1BUCBXRyBsaXN0IGlzIG5vdCBjb3BpZWQgb24gdGhlIHJlc3BvbnNlLg0KDQpS ZWdhcmRzLA0KDQpEYW4NCg0KDQpGcm9tOiBwaGlsaXAuZWFyZGxleUBidC5jb20gW21haWx0bzpw aGlsaXAuZWFyZGxleUBidC5jb21dDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxOCwgMjAxNCAy OjMwIFBNDQpUbzogcmFkaWFwZXJsbWFuQGdtYWlsLmNvbTsgc2VjZGlyQGlldGYub3JnOyBpZXNn QGlldGYub3JnOyBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLmFsbEB0b29scy5pZXRmLm9yZw0K U3ViamVjdDogUkU6IFNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0w OA0KDQpSYWRpYSwNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2aWV3Lg0KU29tZSBj b21tZW50cyBpbi1saW5lDQoNCkJlc3Qgd2lzaGVzLA0KUGhpbA0KDQotLS0tLS0NCkZyb206IFJh ZGlhIFBlcmxtYW4gW21haWx0bzpyYWRpYXBlcmxtYW5AZ21haWwuY29tXQ0KU2VudDogMTggTm92 ZW1iZXIgMjAxNCAwNTozOQ0KVG86IHNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYu b3JnPjsgVGhlIElFU0c7IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmsuYWxsQHRvb2xzLmlldGYu b3JnPG1haWx0bzpkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLmFsbEB0b29scy5pZXRmLm9yZz4N ClN1YmplY3Q6IFNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wOA0K DQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBk aXJlY3RvcmF0ZSdzIG9uZ29pbmcNCmVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRz IGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIERvY3VtZW50DQplZGl0b3JzIGFuZCBXRyBj aGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFz dA0KY2FsbCBjb21tZW50cy4NCg0KU3VtbWFyeTogSXQncyBmaW5lLCB0aG91Z2ggSSBjb3VsZG4n dCByZXNpc3QgbWFraW5nIGEgZmV3IHN1Z2dlc3Rpb25zLg0KDQpMTUFQIGlzIGFwcGFyZW50bHkg YSBzdHJhaW5lZCBhY3JvbnltIGZvciAiTGFyZ2Utc2NhbGUgTWVhc3VyZW1lbnQgb2YgQWNjZXNz DQpuZXR3b3JrIFBlcmZvcm1hbmNlIiwNCltwaGlsXSBzdHJhaW5lZCBpbmRlZWQuIEJ1dCB0b28g bGF0ZSB0byBjaGFuZ2UgdGhlIGFjcm9ueW0hDQoNCmEgY29sbGVjdGlvbiBvZiBwcm90b2NvbHMg ZGVzaWduZWQgZm9yIG1lYXN1cmluZyB0aGUNCmNhcGFjaXR5IGFuZCByZXNwb25zaXZlbmVzcyBv ZiBjb25uZWN0aXZpdHkgcHJvdmlkZWQgYnkgYnJvYWRiYW5kIElTUHMsDQp0aG91Z2ggdGhlcmUg bWF5IGhhdmUgYmVlbiBzb21lIGZlYXR1cmUgY3JlZXAgYXMgdGhlIHByb3RvY29scyBhcmUNCnN1 ZmZpY2llbnRseSBnZW5lcmFsIHRvIGJlIHVzZWQgZm9yIG90aGVyIHRoaW5ncy4gVGhpcyBkb2N1 bWVudCBpcyBhDQpmcmFtZXdvcmsgZG9jdW1lbnQgZGVmaW5pbmcgdGVybXMgYW5kIHByb3ZpZGlu ZyBhbiBvdmVydmlldyBvZiB0aGUgaW50ZW5kZWQNCmRlcGxveW1lbnQgbW9kZWwgKGFuZCBpbnRl bmRlZCB0byBiZSBJTkZPUk1BVElPTkFMKS4gVGhlcmUgYXJlIGNvbXBhbmlvbg0KSS1EcyBzcGVj aWZ5aW5nIGluZGl2aWR1YWwgcHJvdG9jb2xzIGluIG1vcmUgZGV0YWlsLiBBcyBzdWNoLCBtb3N0 IG9mIHRoZQ0Kc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd291bGQgYmUgZGlzY3Vzc2VkIGluIHRo b3NlIGRvY3VtZW50cywgdGhvdWdoIHRoaXMNCm92ZXJ2aWV3IGRvY3VtZW50IHByb3ZpZGVzIGFu IG92ZXJ2aWV3IG9mIHRoZSB0eXBlcyBvZiBzZWN1cml0eQ0KY29uc2lkZXJhdGlvbnMgdG8gYmUg ZGlzY3Vzc2VkIGluIHRob3NlIGRvY3VtZW50cy4NCg0KVGhlIG1ham9yIGNvbXBvbmVudHMgb2Yg TE1BUCBhcmUgYSBNZWFzdXJlbWVudCBBZ2VudCAoTUEpIHVzdWFsbHkgcmVzaWRpbmcNCm9uIGN1 c3RvbWVyIHByZW1pc2VzIHRoYXQgcnVucyBwZXJpb2RpYyBwZXJmb3JtYW5jZSB0ZXN0cyBhbmQg cmVwb3J0cw0KcmVzdWx0cywgYSBDb250cm9sbGVyIHVzdWFsbHkgcmVzaWRpbmcgb2ZmLWN1c3Rv bWVyLXByZW1pc2VzIHRoYXQgY29uZmlndXJlcw0Kc29tZSBsYXJnZSBjb2xsZWN0aW9uIG9mIE1l YXN1cmVtZW50IEFnZW50cywgYW5kIGEgQ29sbGVjdG9yIHVzdWFsbHkNCnJlc2lkaW5nIG9mZi1j dXN0b21lci1wcmVtaXNlcyB0aGF0IHJlY2VpdmVzIGFuZCByZWNvcmRzIHJlcG9ydHMgZnJvbSB0 aGUNCk1lYXN1cmVtZW50IEFnZW50cy4gVGhvc2UgcmVwb3J0cyBtYXkgY29udGFpbiBzdGF0aXN0 aWNhbCBkYXRhIGNvbmNlcm5pbmcNCm5vcm1hbCBvcGVyYXRpb24gb2YgdGhlIE1BJ3MgcGxhdGZv cm0gYXMgd2VsbCBhcyB0aGUgcmVzdWx0cyBvZiBzcGVjaWZpYw0KdGVzdHMuIEl0IGlzIHRoZSBD b250cm9sbGVyIHRvIE1BIGFuZCBNQSB0byBDb2xsZWN0b3IgcHJvdG9jb2xzIHRoYXQgd2lsbA0K cmVxdWlyZSByaWdvcm91cyBzZWN1cml0eSBhbmFseXNpcyBhbmQgd2hpY2ggYXJlIHNwZWNpZmll ZCBpbiBkaWZmZXJlbnQNCmRvY3VtZW50cyB3aXRoaW4gTE1BUC4NCltwaGlsXSB0byBub3RlIGlu IHBhc3NpbmcsIHRoZXkgbWF5IGJlIHRoZSBzYW1lIG9yIGRpZmZlcmVudCBwcm90b2NvbCAodGhp cyBpcyB0byBiZSBkZWNpZGVkKQ0KDQpUaGUgcHJvdG9jb2xzIHdob3NlIHBlcmZvcm1hbmNlIGlz IG1lYXN1cmVkIG1heSBhbHNvDQpyZXF1aXJlIGEgcmlnb3JvdXMgc2VjdXJpdHkgYW5hbHlzaXMs IGJ1dCB0aGV5IGFyZSBkZWZpbmVkIG91dHNpZGUgb2YgTE1BUC4NCg0KVGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIHNlY3Rpb24gbGlzdHMgdGhlIHNvcnRzIG9mIGlzc3VlcyB0aGF0IHdpbGwg bmVlZA0KdG8gYmUgZGVhbHQgd2l0aCBpbiB0aGUgb3RoZXIgZG9jdW1lbnRzLiBJdCBkb2VzIG5v dCBnbyBpbnRvIGhvdyB0aG9zZQ0KaXNzdWVzIGFyZSBhZGRyZXNzZWQ7IHByZXN1bWFibHkgdGhl IGNvbXBhbmlvbiBkb2N1bWVudHMgZG8uDQpbcGhpbF0gY29ycmVjdCwgdGhlIHByb3RvY29sIGRv YyhzKSB3aWxsIGhhdmUgdG8gY292ZXIgdGhpcw0KDQpUaGVyZSBpcyBhIG11Y2gNCmxvbmdlciBw cml2YWN5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gdGhhdCBlbnVtZXJhdGVzIGFuIGludGltaWRh dGluZyBzZXQgb2YNCnBvdGVudGlhbCBwcml2YWN5IGFidXNlcyB0aGF0IG5lZWQgdG8gYmUgbWl0 aWdhdGVkLg0KDQpBbiBpbXBvcnRhbnQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiB0aGF0IEkgZGlk bid0IHNlZSB3YXMgZGVhbGluZyB3aXRoIHRoZQ0KY2FzZSBvZiBhIGNvcnJ1cHRlZCBNQSB0aGF0 IHJlcG9ydHMgZmFsc2lmaWVkIGluZm9ybWF0aW9uIHRvIHRoZSBjb2xsZWN0b3IuDQpUaGlzIG1p Z2h0IG9jY3VyIGluIHRoZSBjYXNlIHdoZXJlIGEgY3VzdG9tZXIgd2FudHMgaXQgdG8gYXBwZWFy IHRoYXQgdGhlDQpJU1AgaXMgbm90IG1lZXRpbmcgaXRzIGNvbW1pdG1lbnRzIHdoZW4gaW4gZmFj dCB0aGUgSVNQIGlzLiBXaGV0aGVyIHRoaXMgY2FuDQpiZSBlZmZlY3RpdmVseSBtaXRpZ2F0ZWQg ZGVwZW5kcyBvbiB0aGUgcGxhdGZvcm0gb24gd2hpY2ggdGhlIE1BIGlzDQpkZXBsb3llZCwgYnV0 IHdoZXJlIHRoZSBNQSBpcyBkZXBsb3llZCBvbiBhIGN1c3RvbWVyLWNvbnRyb2xsZWQgcGxhdGZv cm0gaXQNCm11c3QgYmUgcmVjb2duaXplZCB0aGF0IHRoZSBkYXRhIGNvbGxlY3RlZCBpcyB0byBz b21lIGRlZ3JlZSBpbmhlcmVudGx5DQp1bnRydXN0d29ydGh5LiBUaGlzIG1lYW5zLCBmb3IgZXhh bXBsZSwgdGhhdCBpbiBzdWNoIGNvbmZpZ3VyYXRpb25zIHRoZSBkYXRhDQpzaG91bGQgbm90IGJl IHVzZWQgYXMgdGhlIGJhc2lzIGZvciBhIGN1c3RvbWVyIHRvIGdldCByZWZ1bmRzIG9mDQpzdWJz Y3JpcHRpb24gZmVlcy4NCg0KW3BoaWxdIEdvb2QgcG9pbnQuIEV2ZW4gaWYgc29tZWhvdyB0aGUg TUEgaXMgcHJldmVudGVkIGZyb20gaW5qZWN0aW5nIGZhbHNpZmllZCByZXBvcnRzLCBhIHNvcGhp c3RpY2F0ZWQgY3VzdG9tZXIgY291bGQgZGlzdG9ydCB0aGUgbWVhc3VyZW1lbnRzIChlZyBhZGQg Ym94IHRoYXQgZHJvcHMgcGFja2V0cykNCkkgd2lsbCBhZGQgc29tZXRoaW5nIGFib3V0IHRoaXMu IHRoYW5rcy4NCg0KDQpJIHNhdyB0d28gcXVlc3Rpb25hYmxlIGFzcGVjdHMgb2YgdGhlIGRlc2ln biAoYXQgdGhpcyBsZXZlbCBvZiBhYnN0cmFjdGlvbikuDQoNClRoZSBmaXJzdCBoYXMgdG8gZG8g d2l0aCB3aG8gaW5pdGlhdGVzIHRoZSBDb250cm9sbGVyIHRvIE1BIGNvbm5lY3Rpb24uIFRoaXMN CnNwZWMgc2VlbXMgdG8gaW1wbHkgdGhhdCB0aGUgY29ubmVjdGlvbiBjYW4gYmUgaW5pdGlhdGVk IGZyb20gZWl0aGVyIGVuZC4uLg0KdGhlIENvbnRyb2xsZXIgY2FuIGluaXRpYXRlIGEgY29ubmVj dGlvbiB0byB0aGUgTUEgd2hlbiBpdCB3YW50cyB0byB1cGRhdGUNCnRoZSBNQSdzIGNvbmZpZ3Vy YXRpb24gYW5kIHRoZSBNQSBhbmQgaW5pdGlhdGUgYSBjb25uZWN0aW9uIHRvIHRoZQ0KY29udHJv bGxlciB0byByZXBvcnQgZXJyb3JzIGFuZCBsb2cgZGVidWdnaW5nIGluZm9ybWF0aW9uLiBUaGlz IGlzDQpwcm9ibGVtYXRpYyBmb3Igc2V2ZXJhbCByZWFzb25zLiBNb3N0IGltcG9ydGFudGx5LCBp biBtYW55IHNjZW5hcmlvcyB0aGUgTUENCm1pZ2h0IG1vdmUgYXJvdW5kIGFuZCB0aGVyZWZvcmUg YmUgZGlmZmljdWx0IGZvciB0aGUgQ29udHJvbGxlciB0byBmaW5kOyBvcg0KaXQgbWlnaHQgYmUg YmVoaW5kIGEgTkFUIG9yIG90aGVyIGZpcmV3YWxsIGFuZCBtaWdodCBub3QgYmUgY2FwYWJsZSBv Zg0KYWNjZXB0aW5nIGluY29taW5nIGNvbm5lY3Rpb25zIChhdCBsZWFzdCBub3Qgd2l0aG91dCBh IGxvdCBvZiBhZGRpdGlvbmFsDQplZmZvcnQpLiBJZiBhbGwgc3VjaCBjb25uZWN0aW9ucyB3ZXJl IGluaXRpYXRlZCBieSB0aGUgTUEsIGluY2x1ZGluZyBhDQpwb2xsaW5nIGludGVydmFsIGNvbmZp Z3VyZWQgYnkgdGhlIGNvbnRyb2xsZXIsIHN1Y2ggY29uZmlndXJhdGlvbiBpc3N1ZXMgZ28NCmF3 YXkuDQoNCkFsdGVybmF0ZWx5LCBpZiB0aGUgQ29udHJvbGxlciBpbml0aWF0ZWQgYWxsIGNvbm5l Y3Rpb25zLCBpdCBiZWNvbWVzIG11Y2gNCmVhc2llciB0byBwcm90ZWN0IHRoZSBDb250cm9sbGVy IGZyb20gRG9TIGF0dGFja3MsIHNpbmNlIGl0IGlzIGdlbmVyYWxseQ0KbXVjaCBlYXNpZXIgdG8g YXR0YWNrIGEgc2VydmVyIHRoYW4gYSBjbGllbnQuIEJ1dCBoYXZpbmcgY29ubmVjdGlvbnMgYmVp bmcNCmluaXRpYXRlZCBmcm9tIGJvdGggZGlyZWN0aW9ucyBnaXZlcyB0aGUgd29yc3Qgb2YgYm90 aCB3b3JsZHMuDQoNCltwaGlsXSAgV2XigJl2ZSBkaXNjdXNzZWQgdGhpcyBhIGJpdCAoZm9yIGV4 YW1wbGUsIG5lYXIgdGhlIGVuZCBvZiB0aGUgRHVibGluIGludGVyaW0pLiBJIHRoaW5rIHBlb3Bs ZSBmYXZvdXIgdGhlIGZvcm1lciBhcHByb2FjaCDigJMgdGhlIE1BIHJlZ3VsYXJseSBjYWxscyBp biB0byBjaGVjayBpZiB0aGUgY29uZmlnIC9pbnN0cnVjdGlvbiBoYXMgY2hhbmdlZC4NCg0KSeKA mW0gbm90IHN1cmUgd2hldGhlciB0aGlzIGRvYyBzaG91bGQgc3RhdGUgdGhhdCwgb3IgZ2l2ZSB0 aGUgcHJvcyBhbmQgY29ucyAoeW91ciB0ZXh0IGFib3ZlKSDigJMgdGhlIGxhdHRlciB3b3VsZCBi ZSB0aGUgZGVmYXVsdCwgdGhvdWdoIHBlcnNvbmFsbHkgSSB3b3VsZG7igJl0IG1pbmQgaWYgd2Ug c2FpZCB0aGUgZm9ybWVyLiBXaGF0IGFwcHJvYWNoIGRvIHBlb3BsZSBwcmVmZXI/DQoNCg0KVGhl IHNlY29uZCBoYXMgdG8gZG8gd2l0aCB0aGUgTUEgc2VuZGluZyBlcnJvciBhbmQgbG9nIHJlcG9y dHMgdG8gdGhlDQpDb250cm9sbGVyLiBXaGlsZSBpdCBtYWtlcyBzZW5zZSBmb3IgdGhlIE1BIHRv IHJlcG9ydCBlcnJvcnMgdGhhdCBvY2N1ciBpbg0KcHJvY2Vzc2luZyBDb250cm9sbGVyIEluc3Ry dWN0aW9ucyBpbiB0aGUgcmVzcG9uc2VzIHRvIHRob3NlIGNvbW1hbmRzLA0KZXJyb3JzIGFuZCBs b2dnZWQgZXZlbnRzIHRoYXQgb2NjdXIgYXN5bmNocm9ub3VzbHkgd291bGQgc2VlbSAodG8gbWUg YW55d2F5KQ0KYXMgbW9yZSBuYXR1cmFsbHkgYmVpbmcgc2VudCB0byB0aGUgQ29sbGVjdG9yLCBz aW5jZSBpdHMgam9iIGlzIHRvIGhhcnZlc3QNCm1hc3NpdmUgYW1vdW50cyBvZiBpbmZvcm1hdGlv biBmcm9tIGxvdHMgb2YgTUFzLiBJdCBpcyBsaWtlbHkgdG8gYmUgbW9yZQ0KaGlnaGx5IHJlcGxp Y2F0ZWQgYW5kIGxvYWQgYmFsYW5jZWQgdGhhbiB0aGUgQ29udHJvbGxlciwgYW5kIHRodXMgbW9y ZQ0KY2FwYWJsZSBvZiBoYW5kbGluZyBidXJzdHkgbG9hZHMuIEJ1dCB0aGlzIGhhcyBsaXR0bGUg dG8gZG8gd2l0aCBzZWN1cml0eSwNCmFuZCBJIHRocm93IGl0IG91dCBvbmx5IGZvciB5b3VyIGNv bnNpZGVyYXRpb24uDQoNCltwaGlsXSBJIGd1ZXNzIGl0IGRlcGVuZHMgaG93IG11Y2ggdHJhZmZp YyBpcyBnZW5lcmF0ZWQg4oCTIGluIGdlbmVyYWwgSSBkb27igJl0IHRoaW5rIHRoZXJl4oCZbGwg YmUgbXVjaCwgc28gSeKAmW0gaW5jbGluZWQgdG8gZGlzYWdyZWUuDQpOb3RlIGlmIHRoZSBDb2xs ZWN0b3IgZGlkIGdldCB0aGlzIGluZm9ybWF0aW9uLCB0aGUgQ29udHJvbGxlciB3b3VsZCBoYXZl IHRvIGJlIHRvbGQgYXQgbGVhc3QgYSBzdW1tYXJ5LCBzbyBpdCBjb3VsZCBtb2RpZnkgdGhlIGlu c3RydWN0aW9ucyBhcyBhcHByb3ByaWF0ZS4gKEEgY29udHJvbGxlci1jb2xsZWN0b3IgaW50ZXJm YWNlIGlzIG91dCBvZiBzY29wZSwgYXQgdGhpcyBzdGFnZS4pDQpBbnkgdGhvdWdodHM/DQoNClJh ZGlhDQoNCg== --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413B0591FBEMV67UKRDdoma_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjpibHVlOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxl Om5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjpibHVlOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1h bDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ PC9oZWFkPjxib2R5IGxhbmc9RU4tR0IgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNz PVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPkNmaSDigJMgPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+RGFuLCB0aGFua3MgZm9yIG5vdGljaW5nIHRoZSBs bWFwIFdHIGxpc3Qgd2FzIG1pc3NpbmcgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+ cGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gUm9tYXNjYW51LCBEYW4gKERhbikgW21h aWx0bzpkcm9tYXNjYUBhdmF5YS5jb21dIDxicj48Yj5TZW50OjwvYj4gMjAgTm92ZW1iZXIgMjAx NCAxNTo1Nzxicj48Yj5Ubzo8L2I+IEVhcmRsZXksUEwsUGhpbGlwLFRVQjggUjsgcmFkaWFwZXJs bWFuQGdtYWlsLmNvbTsgc2VjZGlyQGlldGYub3JnOyBpZXNnQGlldGYub3JnOyBkcmFmdC1pZXRm LWxtYXAtZnJhbWV3b3JrLmFsbEB0b29scy5pZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gUkU6 IFNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wODxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5UaGFua3MgdG8gUmFkaWEgZm9yIHRoZSB2YWx1YWJsZSByZXZpZXcuIFRoZXkgZGVzZXJ2ZSBk aXNjdXNzaW9uIGFuZCBlZGl0cy4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+UGhpbCwgc29tZSBvZiB5b3VyIHF1ZXN0aW9ucyBzZWVtIHRvIGJlIGFkZHJlc3NlZCB0 byB0aGUgTE1BUCBjb21tdW5pdHkuIEFtIEkgd3Jvbmc/IFRoZSBMTUFQIFdHIGxpc3QgaXMgbm90 IGNvcGllZCBvbiB0aGUgcmVzcG9uc2UuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+RGFuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxl PSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBwaGlsaXAuZWFyZGxleUBidC5jb20g W21haWx0bzpwaGlsaXAuZWFyZGxleUBidC5jb21dIDxicj48Yj5TZW50OjwvYj4gVHVlc2RheSwg Tm92ZW1iZXIgMTgsIDIwMTQgMjozMCBQTTxicj48Yj5Ubzo8L2I+IHJhZGlhcGVybG1hbkBnbWFp bC5jb207IHNlY2RpckBpZXRmLm9yZzsgaWVzZ0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1sbWFwLWZy YW1ld29yay5hbGxAdG9vbHMuaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBTZWNkaXIg cmV2aWV3IG9mIGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDg8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IGlk PSI6M3hlIj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+UmFkaWEsPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciByZXZp ZXcuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+U29tZSBjb21tZW50 cyBpbi1saW5lIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPkJlc3Qgd2lzaGVzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPlBoaWw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjpibHVlJz4tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPiBSYWRpYSBQZXJsbWFuIFs8YSBocmVmPSJtYWlsdG86cmFkaWFwZXJsbWFuQGdt YWlsLmNvbSI+bWFpbHRvOnJhZGlhcGVybG1hbkBnbWFpbC5jb208L2E+XSA8YnI+PGI+U2VudDo8 L2I+IDE4IE5vdmVtYmVyIDIwMTQgMDU6Mzk8YnI+PGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86 c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+OyBUaGUgSUVTRzsgPGEgaHJlZj0i bWFpbHRvOmRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmsuYWxsQHRvb2xzLmlldGYub3JnIj5kcmFm dC1pZXRmLWxtYXAtZnJhbWV3b3JrLmFsbEB0b29scy5pZXRmLm9yZzwvYT48YnI+PGI+U3ViamVj dDo8L2I+IFNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wODxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFz IHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZzxicj5lZmZvcnQgdG8g cmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuJm5i c3A7IERvY3VtZW50PGJyPmVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2Ug Y29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0PGJyPmNhbGwgY29tbWVudHMuPGJyPjxi cj5TdW1tYXJ5OiBJdCdzIGZpbmUsIHRob3VnaCBJIGNvdWxkbid0IHJlc2lzdCBtYWtpbmcgYSBm ZXcgc3VnZ2VzdGlvbnMuPGJyPjxicj5MTUFQIGlzIGFwcGFyZW50bHkgYSBzdHJhaW5lZCBhY3Jv bnltIGZvciAmcXVvdDtMYXJnZS1zY2FsZSBNZWFzdXJlbWVudCBvZiBBY2Nlc3M8YnI+bmV0d29y ayBQZXJmb3JtYW5jZSZxdW90OywgPHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPjxvOnA+PC9vOnA+ PC9zcGFuPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5bcGhpbF0gc3RyYWluZWQgaW5k ZWVkLiBCdXQgdG9vIGxhdGUgdG8gY2hhbmdlIHRoZSBhY3JvbnltITxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIic+YSBjb2xsZWN0aW9uIG9mIHByb3RvY29scyBkZXNpZ25lZCBm b3IgbWVhc3VyaW5nIHRoZTxicj5jYXBhY2l0eSBhbmQgcmVzcG9uc2l2ZW5lc3Mgb2YgY29ubmVj dGl2aXR5IHByb3ZpZGVkIGJ5IGJyb2FkYmFuZCBJU1BzLDxicj50aG91Z2ggdGhlcmUgbWF5IGhh dmUgYmVlbiBzb21lIGZlYXR1cmUgY3JlZXAgYXMgdGhlIHByb3RvY29scyBhcmU8YnI+c3VmZmlj aWVudGx5IGdlbmVyYWwgdG8gYmUgdXNlZCBmb3Igb3RoZXIgdGhpbmdzLiBUaGlzIGRvY3VtZW50 IGlzIGE8YnI+ZnJhbWV3b3JrIGRvY3VtZW50IGRlZmluaW5nIHRlcm1zIGFuZCBwcm92aWRpbmcg YW4gb3ZlcnZpZXcgb2YgdGhlIGludGVuZGVkPGJyPmRlcGxveW1lbnQgbW9kZWwgKGFuZCBpbnRl bmRlZCB0byBiZSBJTkZPUk1BVElPTkFMKS4gVGhlcmUgYXJlIGNvbXBhbmlvbjxicj5JLURzIHNw ZWNpZnlpbmcgaW5kaXZpZHVhbCBwcm90b2NvbHMgaW4gbW9yZSBkZXRhaWwuIEFzIHN1Y2gsIG1v c3Qgb2YgdGhlPGJyPnNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdvdWxkIGJlIGRpc2N1c3NlZCBp biB0aG9zZSBkb2N1bWVudHMsIHRob3VnaCB0aGlzPGJyPm92ZXJ2aWV3IGRvY3VtZW50IHByb3Zp ZGVzIGFuIG92ZXJ2aWV3IG9mIHRoZSB0eXBlcyBvZiBzZWN1cml0eTxicj5jb25zaWRlcmF0aW9u cyB0byBiZSBkaXNjdXNzZWQgaW4gdGhvc2UgZG9jdW1lbnRzLjxicj48YnI+VGhlIG1ham9yIGNv bXBvbmVudHMgb2YgTE1BUCBhcmUgYSBNZWFzdXJlbWVudCBBZ2VudCAoTUEpIHVzdWFsbHkgcmVz aWRpbmc8YnI+b24gY3VzdG9tZXIgcHJlbWlzZXMgdGhhdCBydW5zIHBlcmlvZGljIHBlcmZvcm1h bmNlIHRlc3RzIGFuZCByZXBvcnRzPGJyPnJlc3VsdHMsIGEgQ29udHJvbGxlciB1c3VhbGx5IHJl c2lkaW5nIG9mZi1jdXN0b21lci1wcmVtaXNlcyB0aGF0IGNvbmZpZ3VyZXM8YnI+c29tZSBsYXJn ZSBjb2xsZWN0aW9uIG9mIE1lYXN1cmVtZW50IEFnZW50cywgYW5kIGEgQ29sbGVjdG9yIHVzdWFs bHk8YnI+cmVzaWRpbmcgb2ZmLWN1c3RvbWVyLXByZW1pc2VzIHRoYXQgcmVjZWl2ZXMgYW5kIHJl Y29yZHMgcmVwb3J0cyBmcm9tIHRoZTxicj5NZWFzdXJlbWVudCBBZ2VudHMuIFRob3NlIHJlcG9y dHMgbWF5IGNvbnRhaW4gc3RhdGlzdGljYWwgZGF0YSBjb25jZXJuaW5nPGJyPm5vcm1hbCBvcGVy YXRpb24gb2YgdGhlIE1BJ3MgcGxhdGZvcm0gYXMgd2VsbCBhcyB0aGUgcmVzdWx0cyBvZiBzcGVj aWZpYzxicj50ZXN0cy4gSXQgaXMgdGhlIENvbnRyb2xsZXIgdG8gTUEgYW5kIE1BIHRvIENvbGxl Y3RvciBwcm90b2NvbHMgdGhhdCB3aWxsPGJyPnJlcXVpcmUgcmlnb3JvdXMgc2VjdXJpdHkgYW5h bHlzaXMgYW5kIHdoaWNoIGFyZSBzcGVjaWZpZWQgaW4gZGlmZmVyZW50PGJyPmRvY3VtZW50cyB3 aXRoaW4gTE1BUC4gPHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPjxvOnA+PC9vOnA+PC9zcGFuPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5bcGhpbF0gdG8gbm90ZSBpbiBwYXNzaW5nLCB0 aGV5IG1heSBiZSB0aGUgc2FtZSBvciBkaWZmZXJlbnQgcHJvdG9jb2wgKHRoaXMgaXMgdG8gYmUg ZGVjaWRlZCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlRoZSBwcm90b2Nv bHMgd2hvc2UgcGVyZm9ybWFuY2UgaXMgbWVhc3VyZWQgbWF5IGFsc288YnI+cmVxdWlyZSBhIHJp Z29yb3VzIHNlY3VyaXR5IGFuYWx5c2lzLCBidXQgdGhleSBhcmUgZGVmaW5lZCBvdXRzaWRlIG9m IExNQVAuPGJyPjxicj5UaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBsaXN0cyB0 aGUgc29ydHMgb2YgaXNzdWVzIHRoYXQgd2lsbCBuZWVkPGJyPnRvIGJlIGRlYWx0IHdpdGggaW4g dGhlIG90aGVyIGRvY3VtZW50cy4gSXQgZG9lcyBub3QgZ28gaW50byBob3cgdGhvc2U8YnI+aXNz dWVzIGFyZSBhZGRyZXNzZWQ7IHByZXN1bWFibHkgdGhlIGNvbXBhbmlvbiBkb2N1bWVudHMgZG8u IDxzcGFuIHN0eWxlPSdjb2xvcjpibHVlJz48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6Ymx1ZSc+W3BoaWxdIGNvcnJlY3QsIHRoZSBwcm90b2NvbCBkb2Mocykgd2ls bCBoYXZlIHRvIGNvdmVyIHRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpi bHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiIn PlRoZXJlIGlzIGEgbXVjaDxicj5sb25nZXIgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBzZWN0aW9u IHRoYXQgZW51bWVyYXRlcyBhbiBpbnRpbWlkYXRpbmcgc2V0IG9mPGJyPnBvdGVudGlhbCBwcml2 YWN5IGFidXNlcyB0aGF0IG5lZWQgdG8gYmUgbWl0aWdhdGVkLjxicj48YnI+QW4gaW1wb3J0YW50 IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gdGhhdCBJIGRpZG4ndCBzZWUgd2FzIGRlYWxpbmcgd2l0 aCB0aGU8YnI+Y2FzZSBvZiBhIGNvcnJ1cHRlZCBNQSB0aGF0IHJlcG9ydHMgZmFsc2lmaWVkIGlu Zm9ybWF0aW9uIHRvIHRoZSBjb2xsZWN0b3IuPGJyPlRoaXMgbWlnaHQgb2NjdXIgaW4gdGhlIGNh c2Ugd2hlcmUgYSBjdXN0b21lciB3YW50cyBpdCB0byBhcHBlYXIgdGhhdCB0aGU8YnI+SVNQIGlz IG5vdCBtZWV0aW5nIGl0cyBjb21taXRtZW50cyB3aGVuIGluIGZhY3QgdGhlIElTUCBpcy4gV2hl dGhlciB0aGlzIGNhbjxicj5iZSBlZmZlY3RpdmVseSBtaXRpZ2F0ZWQgZGVwZW5kcyBvbiB0aGUg cGxhdGZvcm0gb24gd2hpY2ggdGhlIE1BIGlzPGJyPmRlcGxveWVkLCBidXQgd2hlcmUgdGhlIE1B IGlzIGRlcGxveWVkIG9uIGEgY3VzdG9tZXItY29udHJvbGxlZCBwbGF0Zm9ybSBpdDxicj5tdXN0 IGJlIHJlY29nbml6ZWQgdGhhdCB0aGUgZGF0YSBjb2xsZWN0ZWQgaXMgdG8gc29tZSBkZWdyZWUg aW5oZXJlbnRseTxicj51bnRydXN0d29ydGh5LiBUaGlzIG1lYW5zLCBmb3IgZXhhbXBsZSwgdGhh dCBpbiBzdWNoIGNvbmZpZ3VyYXRpb25zIHRoZSBkYXRhPGJyPnNob3VsZCBub3QgYmUgdXNlZCBh cyB0aGUgYmFzaXMgZm9yIGEgY3VzdG9tZXIgdG8gZ2V0IHJlZnVuZHMgb2Y8YnI+c3Vic2NyaXB0 aW9uIGZlZXMuPHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjpibHVlJz5bcGhpbF0gR29vZCBwb2ludC4gRXZlbiBpZiBzb21laG93IHRoZSBN QSBpcyBwcmV2ZW50ZWQgZnJvbSBpbmplY3RpbmcgZmFsc2lmaWVkIHJlcG9ydHMsIGEgc29waGlz dGljYXRlZCBjdXN0b21lciBjb3VsZCBkaXN0b3J0IHRoZSBtZWFzdXJlbWVudHMgKGVnIGFkZCBi b3ggdGhhdCBkcm9wcyBwYWNrZXRzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OmJsdWUnPkkgd2lsbCBhZGQgc29tZXRoaW5nIGFib3V0IHRoaXMuIHRoYW5rcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS41 cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxicj48YnI+SSBzYXcgdHdvIHF1 ZXN0aW9uYWJsZSBhc3BlY3RzIG9mIHRoZSBkZXNpZ24gKGF0IHRoaXMgbGV2ZWwgb2YgYWJzdHJh Y3Rpb24pLjxicj48YnI+VGhlIGZpcnN0IGhhcyB0byBkbyB3aXRoIHdobyBpbml0aWF0ZXMgdGhl IENvbnRyb2xsZXIgdG8gTUEgY29ubmVjdGlvbi4gVGhpczxicj5zcGVjIHNlZW1zIHRvIGltcGx5 IHRoYXQgdGhlIGNvbm5lY3Rpb24gY2FuIGJlIGluaXRpYXRlZCBmcm9tIGVpdGhlciBlbmQuLi48 YnI+dGhlIENvbnRyb2xsZXIgY2FuIGluaXRpYXRlIGEgY29ubmVjdGlvbiB0byB0aGUgTUEgd2hl biBpdCB3YW50cyB0byB1cGRhdGU8YnI+dGhlIE1BJ3MgY29uZmlndXJhdGlvbiBhbmQgdGhlIE1B IGFuZCBpbml0aWF0ZSBhIGNvbm5lY3Rpb24gdG8gdGhlPGJyPmNvbnRyb2xsZXIgdG8gcmVwb3J0 IGVycm9ycyBhbmQgbG9nIGRlYnVnZ2luZyBpbmZvcm1hdGlvbi4gVGhpcyBpczxicj5wcm9ibGVt YXRpYyBmb3Igc2V2ZXJhbCByZWFzb25zLiBNb3N0IGltcG9ydGFudGx5LCBpbiBtYW55IHNjZW5h cmlvcyB0aGUgTUE8YnI+bWlnaHQgbW92ZSBhcm91bmQgYW5kIHRoZXJlZm9yZSBiZSBkaWZmaWN1 bHQgZm9yIHRoZSBDb250cm9sbGVyIHRvIGZpbmQ7IG9yPGJyPml0IG1pZ2h0IGJlIGJlaGluZCBh IE5BVCBvciBvdGhlciBmaXJld2FsbCBhbmQgbWlnaHQgbm90IGJlIGNhcGFibGUgb2Y8YnI+YWNj ZXB0aW5nIGluY29taW5nIGNvbm5lY3Rpb25zIChhdCBsZWFzdCBub3Qgd2l0aG91dCBhIGxvdCBv ZiBhZGRpdGlvbmFsPGJyPmVmZm9ydCkuIElmIGFsbCBzdWNoIGNvbm5lY3Rpb25zIHdlcmUgaW5p dGlhdGVkIGJ5IHRoZSBNQSwgaW5jbHVkaW5nIGE8YnI+cG9sbGluZyBpbnRlcnZhbCBjb25maWd1 cmVkIGJ5IHRoZSBjb250cm9sbGVyLCBzdWNoIGNvbmZpZ3VyYXRpb24gaXNzdWVzIGdvPGJyPmF3 YXkuPGJyPjxicj5BbHRlcm5hdGVseSwgaWYgdGhlIENvbnRyb2xsZXIgaW5pdGlhdGVkIGFsbCBj b25uZWN0aW9ucywgaXQgYmVjb21lcyBtdWNoPGJyPmVhc2llciB0byBwcm90ZWN0IHRoZSBDb250 cm9sbGVyIGZyb20gRG9TIGF0dGFja3MsIHNpbmNlIGl0IGlzIGdlbmVyYWxseTxicj5tdWNoIGVh c2llciB0byBhdHRhY2sgYSBzZXJ2ZXIgdGhhbiBhIGNsaWVudC4gQnV0IGhhdmluZyBjb25uZWN0 aW9ucyBiZWluZzxicj5pbml0aWF0ZWQgZnJvbSBib3RoIGRpcmVjdGlvbnMgZ2l2ZXMgdGhlIHdv cnN0IG9mIGJvdGggd29ybGRzLjxzcGFuIHN0eWxlPSdjb2xvcjpibHVlJz48bzpwPjwvbzpwPjwv c3Bhbj48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+W3BoaWxdJm5ic3A7IFdl4oCZdmUgZGlzY3Vzc2Vk IHRoaXMgYSBiaXQgKGZvciBleGFtcGxlLCBuZWFyIHRoZSBlbmQgb2YgdGhlIER1YmxpbiBpbnRl cmltKS4gSSB0aGluayBwZW9wbGUgZmF2b3VyIHRoZSBmb3JtZXIgYXBwcm9hY2gg4oCTIHRoZSBN QSByZWd1bGFybHkgY2FsbHMgaW4gdG8gY2hlY2sgaWYgdGhlIGNvbmZpZyAvaW5zdHJ1Y3Rpb24g aGFzIGNoYW5nZWQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPknigJltIG5vdCBz dXJlIHdoZXRoZXIgdGhpcyBkb2Mgc2hvdWxkIHN0YXRlIHRoYXQsIG9yIGdpdmUgdGhlIHByb3Mg YW5kIGNvbnMgKHlvdXIgdGV4dCBhYm92ZSkg4oCTIHRoZSBsYXR0ZXIgd291bGQgYmUgdGhlIGRl ZmF1bHQsIHRob3VnaCBwZXJzb25hbGx5IEkgd291bGRu4oCZdCBtaW5kIGlmIHdlIHNhaWQgdGhl IGZvcm1lci4gV2hhdCBhcHByb2FjaCBkbyBwZW9wbGUgcHJlZmVyPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPjxicj5UaGUgc2Vjb25kIGhhcyB0byBk byB3aXRoIHRoZSBNQSBzZW5kaW5nIGVycm9yIGFuZCBsb2cgcmVwb3J0cyB0byB0aGU8YnI+Q29u dHJvbGxlci4gV2hpbGUgaXQgbWFrZXMgc2Vuc2UgZm9yIHRoZSBNQSB0byByZXBvcnQgZXJyb3Jz IHRoYXQgb2NjdXIgaW48YnI+cHJvY2Vzc2luZyBDb250cm9sbGVyIEluc3RydWN0aW9ucyBpbiB0 aGUgcmVzcG9uc2VzIHRvIHRob3NlIGNvbW1hbmRzLDxicj5lcnJvcnMgYW5kIGxvZ2dlZCBldmVu dHMgdGhhdCBvY2N1ciBhc3luY2hyb25vdXNseSB3b3VsZCBzZWVtICh0byBtZSBhbnl3YXkpPGJy PmFzIG1vcmUgbmF0dXJhbGx5IGJlaW5nIHNlbnQgdG8gdGhlIENvbGxlY3Rvciwgc2luY2UgaXRz IGpvYiBpcyB0byBoYXJ2ZXN0PGJyPm1hc3NpdmUgYW1vdW50cyBvZiBpbmZvcm1hdGlvbiBmcm9t IGxvdHMgb2YgTUFzLiBJdCBpcyBsaWtlbHkgdG8gYmUgbW9yZTxicj5oaWdobHkgcmVwbGljYXRl ZCBhbmQgbG9hZCBiYWxhbmNlZCB0aGFuIHRoZSBDb250cm9sbGVyLCBhbmQgdGh1cyBtb3JlPGJy PmNhcGFibGUgb2YgaGFuZGxpbmcgYnVyc3R5IGxvYWRzLiBCdXQgdGhpcyBoYXMgbGl0dGxlIHRv IGRvIHdpdGggc2VjdXJpdHksPGJyPmFuZCBJIHRocm93IGl0IG91dCBvbmx5IGZvciB5b3VyIGNv bnNpZGVyYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJs dWUnPltwaGlsXSBJIGd1ZXNzIGl0IGRlcGVuZHMgaG93IG11Y2ggdHJhZmZpYyBpcyBnZW5lcmF0 ZWQg4oCTIGluIGdlbmVyYWwgSSBkb27igJl0IHRoaW5rIHRoZXJl4oCZbGwgYmUgbXVjaCwgc28g SeKAmW0gaW5jbGluZWQgdG8gZGlzYWdyZWUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6Ymx1ZSc+Tm90ZSBpZiB0aGUgQ29sbGVjdG9yIGRpZCBnZXQgdGhpcyBpbmZvcm1hdGlv biwgdGhlIENvbnRyb2xsZXIgd291bGQgaGF2ZSB0byBiZSB0b2xkIGF0IGxlYXN0IGEgc3VtbWFy eSwgc28gaXQgY291bGQgbW9kaWZ5IHRoZSBpbnN0cnVjdGlvbnMgYXMgYXBwcm9wcmlhdGUuIChB IGNvbnRyb2xsZXItY29sbGVjdG9yIGludGVyZmFjZSBpcyBvdXQgb2Ygc2NvcGUsIGF0IHRoaXMg c3RhZ2UuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPkFueSB0aG91 Z2h0cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6OS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlJhZGlhPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0 bWw+ --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413B0591FBEMV67UKRDdoma_-- From nobody Thu Nov 20 09:25:32 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725251A1BCA for ; Thu, 20 Nov 2014 09:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqWk2BMeMisf for ; Thu, 20 Nov 2014 09:25:26 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C6A1A1BC8 for ; Thu, 20 Nov 2014 09:25:23 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 20 Nov 2014 17:25:31 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.152]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Thu, 20 Nov 2014 17:25:22 +0000 From: To: Date: Thu, 20 Nov 2014 17:25:21 +0000 Thread-Topic: Information Model proposed changes for version 03 Thread-Index: AdAE5vYufWe1zeeRQZ6O+cJSyxgy9w== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/k9aswQQQd765RglBZIVO3CqkdNc Subject: [lmap] Information Model proposed changes for version 03 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 17:25:29 -0000 For anyone not at the LMAP session in Honolulu, please see the proposed cha= nges that were suggested to the LMAP Information Model: http://www.ietf.org/proceedings/91/slides/slides-91-lmap-1.pptx If I do not hear any objections I will start to implement the changes and i= ssue version 03. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Research & Innovation Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000=20 From nobody Mon Nov 24 04:43:54 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484E81A1B3D for ; Mon, 24 Nov 2014 04:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gc07yclvqnd for ; Mon, 24 Nov 2014 04:43:42 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293F21A6EF3 for ; Mon, 24 Nov 2014 04:43:41 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcGAK8mc1TGmAcV/2dsb2JhbABbgkgjI1Vdtk0EBgWbJAKBIxYBAQEBAQF8hAQBAQMSG14BDAkVViYBBBsaiB8BqRqEeKA3DAEfhjqKIINngR8FkmiNTYNZgyaKXYQKg32CQIEDAQEB X-IronPort-AV: E=Sophos; i="5.07,448,1413259200"; d="scan'208,217"; a="81821042" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Nov 2014 07:43:39 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 24 Nov 2014 07:43:17 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 24 Nov 2014 13:43:15 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP Virtual Interim - Monday 12/15, at noon EST Thread-Index: AdAH5Da28KBa3mZ4SraeAfxp2wwLKQ== Date: Mon, 24 Nov 2014 12:43:15 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C90F73F@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: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C90F73FAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/i0BrC4tA_c6kOx80t569A3aq3lM Subject: [lmap] LMAP Virtual Interim - Monday 12/15, at noon EST X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 12:43:44 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C90F73FAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Doodle has spoken and the date that was selected by the majority of the par= ticipants in the poll is Monday 12/15, starting at noon PM, for a duration = of 3 hours. Please mark this date and time in your calendars. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C90F73FAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Doodle has spoken and the date that was selected by = the majority of the participants in the poll is Monday 12/15, starting at n= oon PM, for a duration of 3 hours.

 

Please mark this date and time in your calendars.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C90F73FAZFFEXMB04globa_-- From nobody Mon Nov 24 09:06:35 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C871A6EED; Mon, 24 Nov 2014 09:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIfqfDU0ll_j; Mon, 24 Nov 2014 09:06:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C86AC1A8741; Mon, 24 Nov 2014 09:06:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141124170627.6401.13882.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 09:06:27 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/k9MOB83sYQS1XrrryuS2ySqco6k Cc: lmap@ietf.org Subject: [lmap] LMAP WG Virtual Interim Meeting: December 15, 2014 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@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: Mon, 24 Nov 2014 17:06:33 -0000 The LMAP WG decided to hold 2 or 3 interim meetings between IETF-91 and IETF-92. The first meeting will be on Monday, December 15, starting at noon EST, for a duration of 3 hours. WebEx details are below: LMAP Monday, December 15, 2014 9:00 am | Pacific Standard Time (San Francisco, GMT-08:00) | 3 hr Join WebEx meeting: https://ietf.webex.com/ietf/j.php?MTID=mc477babd9eef5bedb78f11a9855d98b7 Meeting number: 648 675 238 Meeting password: 1234 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 648 675 238