From nobody Mon Sep 1 01:26: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 EE8151A0180 for ; Mon, 1 Sep 2014 01:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.668, 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 IPn4o-6tr7mJ for ; Mon, 1 Sep 2014 01:25:57 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with SMTP id C17071A01E4 for ; Mon, 1 Sep 2014 01:25:46 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app05-12005 (RichMail) with SMTP id 2ee554042d7e640-3476e; Mon, 01 Sep 2014 16:25:34 +0800 (CST) X-RM-TRANSID: 2ee554042d7e640-3476e X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[183.244.174.66]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee354042d7d02f-8f30f; Mon, 01 Sep 2014 16:25:34 +0800 (CST) X-RM-TRANSID: 2ee354042d7d02f-8f30f From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: Date: Mon, 1 Sep 2014 16:25:37 +0800 Message-ID: <011301cfc5be$4f386db0$eda94910$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/FvT2ZopM+cn23QQyal+KH7fxgMQAAD/Bw Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/3kdCqOJ5irS9q5m-5vUB8FzV3lE Cc: "'Huangyihong \(Rachel\)'" , 'duan' Subject: [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: Mon, 01 Sep 2014 08:25:59 -0000 Hi all, A new revision on the collaborative LMAP use-cases are uploaded. > URL:=20 > = http://www.ietf.org/internet-drafts/draft-deng-lmap-collaboration-02.txt > Status: > https://datatracker.ietf.org/doc/draft-deng-lmap-collaboration/ > Htmlized: > http://tools.ietf.org/html/draft-deng-lmap-collaboration-02 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-deng-lmap-collaboration-02 In this version, a new use-case for collaboration between multiple = Controllers within a single domain is added. The requirements sections is restructured, after a list of basic = requirements, potential ways of implementing collaborative LMAP by = extending the current framework are briefly discussed. Your review and comments would be highly appreciated. Lingli&Rachel&Shihui > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, September 01, 2014 4:18 PM > To: Rachel Huang; Deng Lingli; Shihui Duan; Shihui Duan; Lingli Deng; > Rachel Huang > Subject: New Version Notification for = draft-deng-lmap-collaboration-02.txt >=20 >=20 > A new version of I-D, draft-deng-lmap-collaboration-02.txt > has been successfully submitted by Lingli Deng and posted to the > IETF repository. >=20 > Name: draft-deng-lmap-collaboration > Revision: 02 > Title: Use-cases for Collaborative LMAP > Document date: 2014-09-01 > Group: Individual Submission > Pages: 15 > URL: > = http://www.ietf.org/internet-drafts/draft-deng-lmap-collaboration-02.txt > Status: > https://datatracker.ietf.org/doc/draft-deng-lmap-collaboration/ > Htmlized: > http://tools.ietf.org/html/draft-deng-lmap-collaboration-02 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-deng-lmap-collaboration-02 >=20 > Abstract: > This document discusses the motivation and use-cases for > collaborative LMAP practices, where multiple autonomous > measurement > systems collaborate together to help with QoE enhancement by ICPs, > network performance monitory to guide ISP/Regulator coordination > between autonomous network domains and/or regulatory policies and > cross-boundary troubleshooting for complaints from end consumers. >=20 >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat From nobody Mon Sep 1 01:40:39 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 57F341A01AF for ; Mon, 1 Sep 2014 01:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FfHKi0zAAbTo for ; Mon, 1 Sep 2014 01:40:35 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D221A019B for ; Mon, 1 Sep 2014 01:40:34 -0700 (PDT) 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; Mon, 1 Sep 2014 09:40:16 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.205]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Mon, 1 Sep 2014 09:40:32 +0100 From: To: , , Date: Mon, 1 Sep 2014 09:40:31 +0100 Thread-Topic: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) Thread-Index: Ac/BRKYtnn+Vlv70S1io/c4SvgSgDQASgcFgABaVdwAAMEkT0AAGrpQQAB2NzNAAoUQfIA== Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> <003401cfc18e$f87b2310$e9716930$@cn> <9904FB1B0159DA42B0B887B7FA8119CA5C87E8C4@AZ-FFEXMB04.global.avaya.com> <002c01cfc2c4$fbd91440$f38b3cc0$@cn> <004c01cfc33b$345d99f0$9d18cdd0$@com> In-Reply-To: <004c01cfc33b$345d99f0$9d18cdd0$@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: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/z5SQIFV_mP4YlvrNhPtZpMFSLqI Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 08:40:37 -0000 SSBoYXZlIHRoZSBjb3JyZWN0ZWQgSlNPTiBhbmQgaW50ZW5kIHRvIGNvcnJlY3Qgd2l0aCB0aGUg bmV4dCBlZGl0IC0gSSBkb24ndCBzZWUgYW55IHByb2JsZW0gaGVyZS4gVGhlIEpTT04gd2FzIGFk ZGVkIGJlY2F1c2UgYSBzdWJzdGFudGlhbCBhbW91bnQgb2YgcGVvcGxlIHdhbnRlZCBhbiBleGFt cGxlIHRvIGFpZCB1bmRlcnN0YW5kaW5nLg0KDQpUcmV2b3IgQnVyYnJpZGdlDQoNCj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiA/Pz8vTGluZ2xpIERlbmcNCj5TZW50OiAyOSBBdWd1c3QgMjAx NCAwNDo0Mg0KPlRvOiAnTGl1LFNodUBDQVRSJzsgbG1hcEBpZXRmLm9yZw0KPlN1YmplY3Q6IFJl OiBbbG1hcF0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1sbWFwLWluZm9ybWF0aW9uLW1vZGVsLTAyIChj b3JyZWN0ZWQNCj5kYXRlKQ0KPg0KPkkgZWNobyBWYWliaGF2IGluIHJlbW92aW5nIHRoZSBKU09O IGJsb2NrcyBmcm9tIHRoaXMgZG9jdW1lbnQsIGZvciB0aGV5IGFyZQ0KPm5laXRoZXIgcmVxdWly ZWQgdG8gdW5kZXJzdGFuZCB0aGUgdGV4dCBub3IgaGVscGluZyB3aXRoIHRoZSBjYWxsLg0KPg0K PkxpbmdsaQ0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGxtYXAg W21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMaXUsU2h1QENBVFIN Cj4+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjgsIDIwMTQgOTozNiBQTQ0KPj4gVG86IGxtYXBA aWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbbG1hcF0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1sbWFw LWluZm9ybWF0aW9uLW1vZGVsLTAyDQo+PiAoY29ycmVjdGVkIGRhdGUpDQo+Pg0KPj4gSSBjb3Vs ZG4ndCBhZ3JlZSBtb3JlLg0KPj4NCj4+IEFuZHkNCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4gRnJvbTogUm9tYXNjYW51LCBEYW4gKERhbikgW21haWx0bzpkcm9tYXNjYUBh dmF5YS5jb21dDQo+PiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDI4LCAyMDE0IDY6MjUgUE0NCj4+ IFRvOiBCYWpwYWksIFZhaWJoYXY7IDxsbWFwQGlldGYub3JnPg0KPj4gQ2M6IExpdSxTaHVAQ0FU Ug0KPj4gU3ViamVjdDogUkU6IFtsbWFwXSBXR0xDIGZvciBkcmFmdC1pZXRmLWxtYXAtaW5mb3Jt YXRpb24tbW9kZWwtMDINCj4+IChjb3JyZWN0ZWQgZGF0ZSkNCj4+DQo+PiBIaSwNCj4+DQo+PiBJ ZiB3ZSBkZWNpZGUgdG8ga2VlcCB0aGVtLCB0aGUgZXhhbXBsZXMgc2hvdWxkIGJlIGFzIGNsZWFu DQo+PiBzeW50YWN0aWNhbGx5IGFzIHdlIGNhbiBtYWtlIHRoZW0uIChldmVuIGlmIGluY2x1ZGVk IGluIGFuIGFwcGVuZGl4KQ0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gRGFuDQo+Pg0KPj4NCj4+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4gRnJvbTogQmFqcGFpLCBWYWliaGF2 IFttYWlsdG86di5iYWpwYWlAamFjb2JzLXVuaXZlcnNpdHkuZGVdDQo+PiA+IFNlbnQ6IFdlZG5l c2RheSwgQXVndXN0IDI3LCAyMDE0IDQ6MjEgUE0NCj4+ID4gVG86IDxsbWFwQGlldGYub3JnPg0K Pj4gPiBDYzogQmFqcGFpLCBWYWliaGF2OyBSb21hc2NhbnUsIERhbiAoRGFuKTsgTGl1LFNodUBD QVRSDQo+PiA+IFN1YmplY3Q6IFJlOiBbbG1hcF0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1sbWFwLWlu Zm9ybWF0aW9uLW1vZGVsLTAyDQo+PiA+IChjb3JyZWN0ZWQgZGF0ZSkNCj4+ID4NCj4+ID4gKiog TE1BUA0KPj4gPg0KPj4gPiA+IE9uIDI3IEF1ZyAyMDE0LCBhdCAwMjozNiwgTGl1LFNodUBDQVRS IDxsaXVzaHVAY2F0ci5jbj4gd3JvdGU6DQo+PiA+ID4NCj4+ID4gPiBUaGUgSlNPTiBibG9ja3Mg aGF2ZSBhIGxvdCBvZiBzeW50YXggZXJyb3JzLCBJIHNlbnQgdGhlIHBhcnNhYmxlDQo+PiA+ID4g YmxvY2tzIHRvIFRyZXZvciwgc2luY2UgdGhlIGxpc3QgZGlkIG5vdCBhbGxvdyBtZSB0byBwb3N0 IGl0Lg0KPj4gPg0KPj4gPiBBRkFJSywgdGhlIEpTT04gZXhhbXBsZSBpcyBpbiB0aGUgYXBwZW5k aXggZm9yIGEgcmVhc29uLiBJdCBpcyBvbmx5DQo+PiA+IG1lYW50IHRvIHByb3ZpZGUgYSBfaGlu dF8gb24gaG93IHRvIHRyYW5zbGF0ZSB0aGUgYWJzdHJhY3Qgb2JqZWN0cw0KPj4gPiBpbnRvIGEg Y29uY3JldGUgZGF0YSBtb2RlbC4gQXMgc3VjaCwgdGhlIGV4YW1wbGUgc2hvdWxkIG5vdCBiZSB1 c2VkDQo+PiA+IGJ5IGltcGxlbWVudGF0aW9ucyBhbnl3YXkuDQo+PiA+DQo+PiA+IEluIG9yZGVy IHRvIGF2b2lkIGRpZ3Jlc3Npbmcgb3Vyc2VsdmVzIGludG8gdGhlIEpTT04gZXhhbXBsZSwgSQ0K Pj4gPiBwcm9wb3NlIHRvIHJlbW92ZSB0aGUgSlNPTiBmcmFnbWVudHMgZnJvbSB0aGlzIGRvY3Vt ZW50Lg0KPj4gPg0KPj4gPiBCZXN0LCBWYWliaGF2DQo+PiA+DQo+PiA+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiA+IFZhaWJoYXYgQmFq cGFpDQo+PiA+DQo+PiA+IFJlc2VhcmNoIEksIFJvb20gOTENCj4+ID4gQ29tcHV0ZXIgTmV0d29y a3MgYW5kIERpc3RyaWJ1dGVkIFN5c3RlbXMgIChDTkRTKSBMYWIgU2Nob29sIG9mDQo+PiA+IEVu Z2luZWVyaW5nIGFuZCBTY2llbmNlcyBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4sIEdlcm1hbnkN Cj4+ID4NCj4+ID4gd3d3LnZhaWJoYXZiYWpwYWkuY29tDQo+Pg0KPj4NCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBsbWFwIG1haWxpbmcgbGlz dA0KPj4gbG1hcEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9sbWFwDQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5sbWFwIG1haWxpbmcgbGlzdA0KPmxtYXBAaWV0Zi5vcmcNCj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXANCg== From nobody Mon Sep 1 04:43:59 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 618901A028E for ; Mon, 1 Sep 2014 04:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 7y4f67wEb2XJ for ; Mon, 1 Sep 2014 04:43:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A7A1A0278 for ; Mon, 1 Sep 2014 04:43:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 10C711390; Mon, 1 Sep 2014 13:43:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rrDRHfUlrRHN; Mon, 1 Sep 2014 13:43:50 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 1 Sep 2014 13:43:52 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62E2720035; Mon, 1 Sep 2014 13:43:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id f5U3v9nCVfNF; Mon, 1 Sep 2014 13:43:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A467620033; Mon, 1 Sep 2014 13:43:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8B6EA2E55C3E; Mon, 1 Sep 2014 13:43:49 +0200 (CEST) Date: Mon, 1 Sep 2014 13:43:49 +0200 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20140901114349.GB71754@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, denglingli@chinamobile.com, liushu@catr.cn, lmap@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> <003401cfc18e$f87b2310$e9716930$@cn> <9904FB1B0159DA42B0B887B7FA8119CA5C87E8C4@AZ-FFEXMB04.global.avaya.com> <002c01cfc2c4$fbd91440$f38b3cc0$@cn> <004c01cfc33b$345d99f0$9d18cdd0$@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/-Mcxndw8uFpxr_qTIAwCt_XC76k Cc: lmap@ietf.org, denglingli@chinamobile.com, liushu@catr.cn Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 11:43:57 -0000 On Mon, Sep 01, 2014 at 09:40:31AM +0100, trevor.burbridge@bt.com wrote: > I have the corrected JSON and intend to correct with the next edit - > I don't see any problem here. The JSON was added because a > substantial amount of people wanted an example to aid understanding. Yes, but the information model at the end needs to be clear and I am sharing Vaibhav's concern that people may mistakenly think they can implement the JSON structures. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Sep 1 07:34:08 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 85DC91A8545 for ; Mon, 1 Sep 2014 07:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.468 X-Spam-Level: X-Spam-Status: No, score=-12.468 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.668, 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 Nxh-HBUJVZc8 for ; Mon, 1 Sep 2014 07:34:04 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4050B1A6F72 for ; Mon, 1 Sep 2014 07:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5495; q=dns/txt; s=iport; t=1409580680; x=1410790280; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=SdPFUjxx4hSj0+BGsWIolBUiJ94fxo++IkSe0ArfwAw=; b=Dr1lwNxwyMkLVgsF60iBZco9pj84nCqy2d+yghPd4gEUtYX7ItfV2r1f 6TuUnLtyL8Bp8bnaajFesF9k5RadTd9RNhJkv5svvU7SHMfcMK30WDrES JKsc19vZMf/HZp4oMPSYWLjZsv3lGAP/kij9xmqRqv4iOUaJKa1sCrFwe 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0HAI19BFStJssW/2dsb2JhbABZgkeBGVeIV78iAQmHTAGBJneEAwEBAQQBAQFrBAYRCxgJFg8JAwIBAgEVMAYBDAYCAQGIPg25cwETBI9IDIRMAQSGFIkJjT+HN41ng2M7L4JPAQEB X-IronPort-AV: E=Sophos;i="5.04,442,1406592000"; d="scan'208,217";a="161276688" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 01 Sep 2014 14:11:18 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s81EBHEn028762; Mon, 1 Sep 2014 14:11:18 GMT Message-ID: <54047E85.2050405@cisco.com> Date: Mon, 01 Sep 2014 16:11:17 +0200 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: "Weil, Jason" , "lmap@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070803060703090001030800" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/GmgSKhY2kh3eORvCvnthaqkiaKI Subject: Re: [lmap] RSVP List for LMAP Interim Meeting - Deadline September 2nd X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 14:34:06 -0000 This is a multi-part message in MIME format. --------------070803060703090001030800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 26/08/2014 16:21, Weil, Jason wrote: > LMAP WG, > > Below is the current current RSVP list for the LMAP Interim meeting on > September 15th in Dublin, Ireland. If you have sent an RSVP and I > don't have you on this list please let know. For others thinking of > attending, this is a reminder that the registration deadline is > September 2nd. We have room for 30 in the session so if you are able > to attend we have room and would appreciate your input. > > 1. Jason Weil > 2. Stephen Farrell (Maybe) > 3. Marcelo Bagnulo Braun > 4. Ken Ko > 5. Philip Eardley > 6. Timothy Carey > 7. Juergen Schoenwaelder > 8. Valibhav Bajpai > I will be present. Regards, Benoit > Thanks, > > Jason > > ------------------------------------------------------------------------ > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject > to copyright belonging to Time Warner Cable. This E-mail is intended > solely for the use of the individual or entity to which it is > addressed. If you are not the intended recipient of this E-mail, you > are hereby notified that any dissemination, distribution, copying, or > action taken in relation to the contents of and attachments to this > E-mail is strictly prohibited and may be unlawful. If you have > received this E-mail in error, please notify the sender immediately > and permanently delete the original and any copy of this E-mail and > any printout. > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --------------070803060703090001030800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 26/08/2014 16:21, Weil, Jason wrote:
LMAP WG,

Below is the current current RSVP list for the LMAP Interim meeting on September 15th in Dublin, Ireland. If you have sent an RSVP and I don’t have you on this list please let know. For others thinking of attending, this is a reminder that the registration deadline is September 2nd. We have room for 30 in the session so if you are able to attend we have room and would appreciate your input. 
  1. Jason Weil
  2. Stephen Farrell (Maybe)
  3. Marcelo Bagnulo Braun
  4. Ken Ko
  5. Philip Eardley
  6. Timothy Carey
  7. Juergen Schoenwaelder
  8. Valibhav Bajpai
I will be present.

Regards, Benoit
Thanks,

Jason

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
 

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

--------------070803060703090001030800-- From nobody Mon Sep 1 13:28:13 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 759A41A06F6 for ; Mon, 1 Sep 2014 13:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] 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 MDbjI7i7dR61 for ; Mon, 1 Sep 2014 13:28:06 -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 04EB41A06F2 for ; Mon, 1 Sep 2014 13:28:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9BB57F8E; Mon, 1 Sep 2014 22:28:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yRa1ISg0Ns7n; Mon, 1 Sep 2014 22:28:00 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 1 Sep 2014 22:28:04 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E8BD20036; Mon, 1 Sep 2014 22:28:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gOTBQP4bMje0; Mon, 1 Sep 2014 22:28:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B00E320033; Mon, 1 Sep 2014 22:28:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AA7DC2E568E2; Mon, 1 Sep 2014 22:28:01 +0200 (CEST) Date: Mon, 1 Sep 2014 22:28:01 +0200 From: Juergen Schoenwaelder To: =?utf-8?B?6YKT54G16I6JL0xpbmdsaQ==?= Deng Message-ID: <20140901202801.GA74827@elstar.local> Mail-Followup-To: =?utf-8?B?6YKT54G16I6JL0xpbmdsaQ==?= Deng , marcelo@it.uc3m.es, "'Romascanu, Dan (Dan)'" , trevor.burbridge@bt.com, philip.eardley@bt.com, lmap@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CEDB@AZ-FFEXMB04.global.avaya.com> <003b01cfc33a$704d7e40$50e87ac0$@com> <20140829081714.GB63622@elstar.local> <00f701cfc373$c91cffd0$5b56ff70$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <00f701cfc373$c91cffd0$5b56ff70$@com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/D6gIzfTgDCGmk-2nE_M9vZRZnvY Cc: marcelo@it.uc3m.es, "'Romascanu, Dan \(Dan\)'" , trevor.burbridge@bt.com, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 20:28:11 -0000 On Fri, Aug 29, 2014 at 06:27:07PM +0800, 邓灵莉/Lingli Deng wrote: > > [邓灵莉/Lingli Deng] Point taken. So the schedule for the > measurement task, even the one contained a reporting task > description (as one of the downstream task) is not intended to set > schedule for the reporting task., right? What about a measurement > task that requires instant reporting after each round? Does one > still need another independent schedule for the reporting task? I had a more detailed look at the relevant text today and I agree that it is unclear and leads to a number of questions. /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 Sep 2 01:10: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 228B91A010F for ; Tue, 2 Sep 2014 01:10:34 -0700 (PDT) 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_91=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 V-HzzVm3yHuT for ; Tue, 2 Sep 2014 01:10:30 -0700 (PDT) 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 339CA1A00F5 for ; Tue, 2 Sep 2014 01:10:29 -0700 (PDT) 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, 2 Sep 2014 09:10:32 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.205]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Tue, 2 Sep 2014 09:10:27 +0100 From: To: , Date: Tue, 2 Sep 2014 09:10:26 +0100 Thread-Topic: [lmap] WGLC for draft-ietf-lmap-information-model-02 Thread-Index: Ac/GIzzr2JFEjf8lR/Kj5vrwk6lfRQAYd1NA Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CEDB@AZ-FFEXMB04.global.avaya.com> <003b01cfc33a$704d7e40$50e87ac0$@com> <20140829081714.GB63622@elstar.local> <00f701cfc373$c91cffd0$5b56ff70$@com> <20140901202801.GA74827@elstar.local> In-Reply-To: <20140901202801.GA74827@elstar.local> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ec1FDmuHV2zf1WF0b6eobJV_MQQ Cc: marcelo@it.uc3m.es, dromasca@avaya.com, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 08:10:34 -0000 SWYgaW5zdGFudCByZXBvcnRpbmcgaXMgcmVxdWlyZWQgYSBtZWFzdXJlbWVudCB0YXNrIGFuZCBy ZXBvcnRpbmcgdGFzayBjYW4gYmUgaW5jbHVkZWQgaW4gdGhlIHNhbWUgc2NoZWR1bGUuIFRoZSBk cmFmdCBzdGF0ZXMgdGhhdCBzdWNoIGFzIHNlcXVlbmNlIG9mIHRhc2tzIHNob3VsZCBiZSBleGVj dXRlZCB3aXRoIG1pbmltYWwgZ2Fwcy4gSSBob3BlZCBpdCB3YXMgY2xlYXIgdGhhdCBldmVyeXRo aW5nIGlzIGEgdGFzayBhbmQgdGhhdCBhbGwgdGFza3MgYXJlIHRyZWF0ZWQgZXF1YWxseSAtIHRo ZXJlZm9yZSB5b3UgY2FuIG1peCBtZWFzdXJlbWVudCBhbmQgb3RoZXIgdGFza3MgZnJlZWx5IHdp dGhpbiBhIHNpbmdsZSBzY2hlZHVsZS4NCg0KDQpUcmV2b3IgQnVyYnJpZGdlDQoNCj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBbbWFpbHRv Omouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0NCj5TZW50OiAwMSBTZXB0ZW1i ZXIgMjAxNCAyMToyOA0KPlRvOiDpgpPngbXojokvTGluZ2xpIERlbmcNCj5DYzogbWFyY2Vsb0Bp dC51YzNtLmVzOyAnUm9tYXNjYW51LCBEYW4gKERhbiknOyBCdXJicmlkZ2UsVCxUcmV2b3IsVFVC OCBSOw0KPkVhcmRsZXksUEwsUGhpbGlwLFRVQjggUjsgbG1hcEBpZXRmLm9yZw0KPlN1YmplY3Q6 IFJlOiBbbG1hcF0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1sbWFwLWluZm9ybWF0aW9uLW1vZGVsLTAy DQo+DQo+T24gRnJpLCBBdWcgMjksIDIwMTQgYXQgMDY6Mjc6MDdQTSArMDgwMCwg6YKT54G16I6J L0xpbmdsaSBEZW5nIHdyb3RlOg0KPj4NCj4+IFvpgpPngbXojokvTGluZ2xpIERlbmddIFBvaW50 IHRha2VuLiBTbyB0aGUgc2NoZWR1bGUgZm9yIHRoZQ0KPj4gbWVhc3VyZW1lbnQgdGFzaywgZXZl biB0aGUgb25lIGNvbnRhaW5lZCBhIHJlcG9ydGluZyB0YXNrDQo+PiBkZXNjcmlwdGlvbiAoYXMg b25lIG9mIHRoZSBkb3duc3RyZWFtIHRhc2spIGlzIG5vdCBpbnRlbmRlZCB0byBzZXQNCj4+IHNj aGVkdWxlIGZvciB0aGUgcmVwb3J0aW5nIHRhc2suLCByaWdodD8gIFdoYXQgYWJvdXQgYSBtZWFz dXJlbWVudA0KPj4gdGFzayB0aGF0IHJlcXVpcmVzIGluc3RhbnQgcmVwb3J0aW5nIGFmdGVyIGVh Y2ggcm91bmQ/IERvZXMgb25lDQo+PiBzdGlsbCBuZWVkIGFub3RoZXIgaW5kZXBlbmRlbnQgc2No ZWR1bGUgZm9yIHRoZSByZXBvcnRpbmcgdGFzaz8NCj4NCj5JIGhhZCBhIG1vcmUgZGV0YWlsZWQg bG9vayBhdCB0aGUgcmVsZXZhbnQgdGV4dCB0b2RheSBhbmQgSSBhZ3JlZSB0aGF0DQo+aXQgaXMg dW5jbGVhciBhbmQgbGVhZHMgdG8gYSBudW1iZXIgb2YgcXVlc3Rpb25zLg0KPg0KPi9qcw0KPg0K Pi0tDQo+SnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBC cmVtZW4gZ0dtYkgNCj5QaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5n IDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueQ0KPkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAg ICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K From nobody Tue Sep 2 04:07:29 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 37C2C1A008F for ; Tue, 2 Sep 2014 04:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_91=0.6, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.668, 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 Yl9QTYjIng0M for ; Tue, 2 Sep 2014 04:07:19 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with SMTP id 105A81A00A5 for ; Tue, 2 Sep 2014 04:07:16 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.7]) by rmmx-syy-dmz-app11-12011 (RichMail) with SMTP id 2eeb5405a4e2a57-64ba9; Tue, 02 Sep 2014 19:07:15 +0800 (CST) X-RM-TRANSID: 2eeb5405a4e2a57-64ba9 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[10.2.43.66]) by rmsmtp-syy-appsvr04-12004 (RichMail) with SMTP id 2ee45405a4e29ad-d39cb; Tue, 02 Sep 2014 19:07:15 +0800 (CST) X-RM-TRANSID: 2ee45405a4e29ad-d39cb From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: , References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CEDB@AZ-FFEXMB04.global.avaya.com> <003b01cfc33a$704d7e40$50e87ac0$@com> <20140829081714.GB63622@elstar.local> <00f701cfc373$c91cffd0$5b56ff70$@com> <20140901202801.GA74827@elstar.local> In-Reply-To: Date: Tue, 2 Sep 2014 19:07:17 +0800 Message-ID: <017c01cfc69e$0f693800$2e3ba800$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/GIzzr2JFEjf8lR/Kj5vrwk6lfRQAYd1NAAATGgUA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/B2jCLZ1HTaYE-4DssxKMIUxzE1A Cc: marcelo@it.uc3m.es, dromasca@avaya.com, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 11:07:24 -0000 Hi Trevor,=20 Thanks for the clarification. I fully understand your point that = multiple tasks can share a single schedule/timing. I think concrete examples of the intended schedule structure may be of = help here. (You might also want to refer to my original question and = JS's reponse last week.) Assumption: Controller has sent a Schedule X including descriptions = about a measurement task A and its related reporting task B.=20 For the timing of B, there may be two possibilities:=20 Case 1 (instant reporting): B is required to be performed every time = after A. Their timings are bounded with the same schedule X. Case 2 (independent reporting): B's timing is actually specified by = another Schedule Y. If the above is really what you intended (which I got confirmation from = you by asking questions), I would wish you add proper description in the = main text or use some illustration (not in JSON) in the appendix. And my further question goes to: Upon handling Schedule X (either for the instruction, suppression, = update, etc.), would it be better if we can make it clear to the MA, = whether or not it has to refer to another schedule to fully understand = the timing requirements for the reporting task B?=20 For example, if a suppression instruction is issued some time later for = schedule X, does it also affect reporting task B?=20 Lingli > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of > trevor.burbridge@bt.com > Sent: Tuesday, September 02, 2014 4:10 PM > To: j.schoenwaelder@jacobs-university.de; denglingli@chinamobile.com > Cc: marcelo@it.uc3m.es; dromasca@avaya.com; philip.eardley@bt.com; > lmap@ietf.org > Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 >=20 > If instant reporting is required a measurement task and reporting task = can > be included in the same schedule. The draft states that such as = sequence > of tasks should be executed with minimal gaps. I hoped it was clear = that > everything is a task and that all tasks are treated equally - = therefore you > can mix measurement and other tasks freely within a single schedule. >=20 >=20 > Trevor Burbridge >=20 > >-----Original Message----- > >From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > >Sent: 01 September 2014 21:28 > >To: =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng > >Cc: marcelo@it.uc3m.es; 'Romascanu, Dan (Dan)'; > Burbridge,T,Trevor,TUB8 R; > >Eardley,PL,Philip,TUB8 R; lmap@ietf.org > >Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 > > > >On Fri, Aug 29, 2014 at 06:27:07PM +0800, = =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng wrote: > >> > >> [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] Point taken. So the = schedule for the > >> measurement task, even the one contained a reporting task > >> description (as one of the downstream task) is not intended to set > >> schedule for the reporting task., right? What about a measurement > >> task that requires instant reporting after each round? Does one > >> still need another independent schedule for the reporting task? > > > >I had a more detailed look at the relevant text today and I agree = that > >it is unclear and leads to a number of questions. > > > >/js > > > >-- > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, > Germany > >Fax: +49 421 200 3103 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Sep 2 06:54:14 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 800801A03E6 for ; Tue, 2 Sep 2014 06:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 H4vWUwT2BB0A for ; Tue, 2 Sep 2014 06:54:11 -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 6CD4A1A03E2 for ; Tue, 2 Sep 2014 06:54:11 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DDB1412D7; Tue, 2 Sep 2014 15:54:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id i59qe5xGj4ER; Tue, 2 Sep 2014 15:54:01 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 2 Sep 2014 15:54:08 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDF5020035; Tue, 2 Sep 2014 15:54:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vV0F6z_7oOVf; Tue, 2 Sep 2014 15:54:08 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4FFA20033; Tue, 2 Sep 2014 15:54:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B4A382E572E7; Tue, 2 Sep 2014 15:54:07 +0200 (CEST) Date: Tue, 2 Sep 2014 15:54:07 +0200 From: Juergen Schoenwaelder To: "lmap@ietf.org" Message-ID: <20140902135407.GA77574@elstar.local> Mail-Followup-To: "lmap@ietf.org" , "Romascanu, Dan (Dan)" References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/CY0pQ_WF-JPJoeS4wqEkDV0QlQ4 Cc: "Romascanu, Dan \(Dan\)" Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) 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, 02 Sep 2014 13:54:13 -0000 On Tue, Aug 26, 2014 at 03:44:41PM +0000, Romascanu, Dan (Dan) wrote: > This message opens a Working Group Last Call for the draft-ietf-lmap-information-model-02 Internet-Draft. > > Please read and send comments about this document to the LMAP WG list before Wednesday September 10, 2014. > > If you read the document and believe that it's ready to be submitted to the IESG for consideration as Proposed standards, please state this in a short message to the list. > > The document is available at http://www.ietf.org/id/draft-ietf-lmap-information-model-02.txt. > Hi, Vaibhav and myself went through the exercise to derive a data model from the information model in order to find spots where the information model is unclear or where we find the model may need improvement. The result of ~2 day work is a YANG data model that we have posted as an I-D (together with a configuration XML snippet that validates against the YANG data model): http://tools.ietf.org/html/draft-schoenw-lmap-yang-01 We will post the comments we have collected in a subsequent message. Until we get the notes compiled, enjoy reading the YANG data model. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Sep 2 08:49: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 814171A0AE4 for ; Tue, 2 Sep 2014 08:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.767 X-Spam-Level: X-Spam-Status: No, score=0.767 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, 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 Oc1iMHO4vF5c for ; Tue, 2 Sep 2014 08:49:37 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id DA41F1A04F6 for ; Tue, 2 Sep 2014 08:49:34 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,449,1406606400"; d="scan'208,217";a="503093464" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 02 Sep 2014 11:47:39 -0400 Received: from PRVPEXVS06.corp.twcable.com ([10.136.163.32]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 2 Sep 2014 11:49:00 -0400 From: "Weil, Jason" To: "lmap@ietf.org" Date: Tue, 2 Sep 2014 11:48:59 -0400 Thread-Topic: Draft LMAP Interim Meeting Agenda (Time Correction) Thread-Index: Ac/GxWoRMUShN+MtSHW5kS3fFrCD0Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D02B5E5633B59jasonweiltwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/y-wishIg0cgEiXtNbJl1kacYVmA Subject: [lmap] Draft LMAP Interim Meeting Agenda (Time Correction) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 15:49:38 -0000 --_000_D02B5E5633B59jasonweiltwcablecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It was pointed out by a few of you that I have an incorrect start time for = this meeting. LMAP WG Interim Meeting Date and Time: Monday, September 15, 2014, 1430(2:30pm) -1830 (6:30pm) IST 1. Note Well, Note Takers, Jabber Scribes, Agenda Bashing - Chairs (5 min) 2. WG Status - Chairs (5 min) 3. Use Cases Discussion =96 Respond to AD Comments (tentative) - 15 min 4. LMAP Information Model =96 Address LC Comments =96 TBD =96 30 min 5. Protocol Discussion =96 105 min YANG Model =96 Arne O. - 15min HTTP Style Protocol - ? - 15min REST Style Protocols - ? - 15 min Protocol Discussion - ? - 60 min 6. Discuss IPPM Registry =96 30 min 7. Next steps and open mic - There is still time available, so I have inserted an item to discuss the I= PPM registry as well. Jason ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_D02B5E5633B59jasonweiltwcablecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
It was pointed out by a few of you that I have an incorrect start time= for this meeting. 

LMAP WG Interim Meet=
ing
Date and Time: Monday, September 15, 2014, 1430(2:30pm) -1830 (6:30pm) IST
         =20
         =20

1. Note Well, Note Takers, Jabber Scribes, Agenda =
Bashing - Chairs (5 min)
         =20
2. WG Status - Chairs (5 min)
         =20
3. Use Cases Discussion =96 Respond to AD Comments (tent=
ative) - 15 min
         =20
4. LMAP Information Model =96 Address LC Comments =96 TB=
D =96 30 min
         =20
5. Protocol Discussion =96 105 min 
	YANG Model =96 Arne O. - 15min
	HTTP Style Protocol  - ? - 15min 
	REST Style Protocols -  ? - 15 min
	Protocol Discussion - ?   - 60 min
6. Discuss IPPM Registry =96 30 min
7. Nex=
t steps and open mic -
There is still time available,  so I have inserted an item to dis= cuss the IPPM registry as well. 

Jason


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_D02B5E5633B59jasonweiltwcablecom_-- From nobody Tue Sep 2 11:19:58 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 7FD331A0660 for ; Tue, 2 Sep 2014 11:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.467 X-Spam-Level: * X-Spam-Status: No, score=1.467 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 C4oFUqgX_3Tr for ; Tue, 2 Sep 2014 11:19:55 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id F3A041A02CF for ; Tue, 2 Sep 2014 11:19:54 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,450,1406606400"; d="scan'208,217";a="495577581" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 02 Sep 2014 14:18:25 -0400 Received: from PRVPEXVS06.corp.twcable.com ([10.136.163.32]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 2 Sep 2014 14:19:53 -0400 From: "Weil, Jason" To: "lmap@ietf.org" Date: Tue, 2 Sep 2014 14:19:51 -0400 Thread-Topic: Updated LMAP Interim RSVP List Thread-Index: Ac/G2n11x9NKy+d4RTGJNek9Mhujrg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D02B828733CFBjasonweiltwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/AOPLGPUkSJiAR9WkX78je8A_jiM Subject: [lmap] Updated LMAP Interim RSVP List X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 18:19:56 -0000 --_000_D02B828733CFBjasonweiltwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable LMAP WG, Below is the most recent list for those who responded to the RSVP for the L= MAP Interim meeting on September 15th in Dublin, Ireland. Let me know if I = have missed anyone. I will send this list to the IETF and BBF Secretariats = this evening. As a reminder your LMAP Interim registration will also serve = as a Guest pass to the Broadband Forum meeting that is taking place the wee= k of September 15th at the same location. 1. Jason Weil 2. Stephen Farrell 3. Marcelo Bagnulo Braun 4. Ken Ko 5. Philip Eardley 6. Timothy Carey 7. Juergen Schoenwaelder 8. Valibhav Bajpai 9. Al Morton 10. Arne Oslebo 11. Benoit Claise 12. Barbara Stark 13. Trevor Burbridge Thanks, Jason ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_D02B828733CFBjasonweiltwcablecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
LMAP WG,

 =

Below is the most recent list for those= who responded to the RSVP for the LMAP Interim meeting on September 15th in Dublin, Ireland. Let me know if <= font face=3D"Calibri,sans-serif" style=3D"color: rgb(0, 0, 0); font-family:= Calibri, sans-serif; font-size: 14px;">I have missed anyone. I will send this list to the IETF and BBF Secretariats this evening. As a reminde= r your LMAP Interim registration will also serve as a Guest pass to the Bro= adband Forum meeting that is taking place the week of September 15th at the= same location. 

  1. Jason = Weil
  2. Stephe= n Farrell
  3. Marcel= o Bagnulo Braun
  4. Ken Ko=
  5. Philip= Eardley
  6. Timoth= y Carey
  7. Juerge= n Schoenwaelder
  8. Valibh= av Bajpai
  9. Al Morton
  10. Arne Oslebo
  11. Benoit Claise
  12. Barbara Stark
  13. Trevo= r Burbridge
Thanks,<= /span>
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_D02B828733CFBjasonweiltwcablecom_-- From nobody Wed Sep 3 01:04: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 E6D301A004B for ; Wed, 3 Sep 2014 01:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 Py_oJXFkU5FC for ; Wed, 3 Sep 2014 01:04:27 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF2F1A0073 for ; Wed, 3 Sep 2014 01:04:27 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BC7B91442; Wed, 3 Sep 2014 10:04:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 58F6e6bOnf7p; Wed, 3 Sep 2014 10:04:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Sep 2014 10:04:25 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0415B20033; Wed, 3 Sep 2014 10:04:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sKup2GjWuiDc; Wed, 3 Sep 2014 10:04:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B47FE20035; Wed, 3 Sep 2014 10:04:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 313F82E58257; Wed, 3 Sep 2014 10:04:20 +0200 (CEST) Date: Wed, 3 Sep 2014 10:04:20 +0200 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20140903080419.GB79584@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, denglingli@chinamobile.com, marcelo@it.uc3m.es, dromasca@avaya.com, philip.eardley@bt.com, lmap@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CEDB@AZ-FFEXMB04.global.avaya.com> <003b01cfc33a$704d7e40$50e87ac0$@com> <20140829081714.GB63622@elstar.local> <00f701cfc373$c91cffd0$5b56ff70$@com> <20140901202801.GA74827@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/if9OYDLHMr3q3tLAogRWRTt1K-w Cc: marcelo@it.uc3m.es, dromasca@avaya.com, philip.eardley@bt.com, denglingli@chinamobile.com, lmap@ietf.org Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 08:04:29 -0000 On Tue, Sep 02, 2014 at 09:10:26AM +0100, trevor.burbridge@bt.com wrote: > If instant reporting is required a measurement task and reporting > task can be included in the same schedule. The draft states that > such as sequence of tasks should be executed with minimal gaps. I > hoped it was clear that everything is a task and that all tasks are > treated equally - therefore you can mix measurement and other tasks > freely within a single schedule. What I find somewhat confusing is that we have a sequence of tasks that is executed sequentially and we also have a downstream tasks and it is unclear to me how things interact. One interpretation is that ma-sched-downstream-tasks-obj really is only about information flow, that is any downstream tasks do are invoked by being listed in a task sequence of a schedule. If this interpretation is correct, then I still find the plumping how data flows between tasks somewhat unclear. In the general case, there will be a buffer between a task producing data and a task consuming data. Perhaps we need to model these buffers explicitely and then we can say something like task X feeds into buffer A and task Y consumes data from buffer A. This makes the pluming clearer I think. We could also put constraints on buffers or in future versions have controls on buffers (e.g. old data is discarded if buffers fill up). Right now, we have these magic output selection numbers which I do not find really clear (how do I know which output selection number I have to use for a certain task)? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 3 01:18:39 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 675891A86EA for ; Wed, 3 Sep 2014 01:18:36 -0700 (PDT) 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_91=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 zw9ukWgQpR3V for ; Wed, 3 Sep 2014 01:18:33 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E191A86E6 for ; Wed, 3 Sep 2014 01:16:57 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 3 Sep 2014 09:17:00 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.205]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Wed, 3 Sep 2014 09:16:56 +0100 From: To: Date: Wed, 3 Sep 2014 09:16:55 +0100 Thread-Topic: [lmap] WGLC for draft-ietf-lmap-information-model-02 Thread-Index: Ac/HTa7+CO7JqOfFSTa2gdhtwJ4nJwAACW8A Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CEDB@AZ-FFEXMB04.global.avaya.com> <003b01cfc33a$704d7e40$50e87ac0$@com> <20140829081714.GB63622@elstar.local> <00f701cfc373$c91cffd0$5b56ff70$@com> <20140901202801.GA74827@elstar.local> <20140903080419.GB79584@elstar.local> In-Reply-To: <20140903080419.GB79584@elstar.local> 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/lGY34c5AiNHn5ZEyb9Xg9Jaj84w Cc: marcelo@it.uc3m.es, dromasca@avaya.com, philip.eardley@bt.com, denglingli@chinamobile.com, lmap@ietf.org Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 08:18:36 -0000 As it seems I haven't managed to put to bed the question of how to connect = different tasks together, I'll make it the primary discussion for the Infor= mation Model in Dublin.=20 Also see inline... >-----Original Message----- >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >Sent: 03 September 2014 09:04 >To: Burbridge,T,Trevor,TUB8 R >Cc: denglingli@chinamobile.com; marcelo@it.uc3m.es; dromasca@avaya.com; >Eardley,PL,Philip,TUB8 R; lmap@ietf.org >Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 > >On Tue, Sep 02, 2014 at 09:10:26AM +0100, trevor.burbridge@bt.com wrote: > >> If instant reporting is required a measurement task and reporting task >> can be included in the same schedule. The draft states that such as >> sequence of tasks should be executed with minimal gaps. I hoped it was >> clear that everything is a task and that all tasks are treated equally >> - therefore you can mix measurement and other tasks freely within a >> single schedule. > >What I find somewhat confusing is that we have a sequence of tasks that is >executed sequentially and we also have a downstream tasks and it is unclea= r to >me how things interact. One interpretation is that ma-sched-downstream-tas= ks- >obj really is only about information flow, that is any downstream tasks do= are >invoked by being listed in a task sequence of a schedule. Yes - exactly. >If this interpretation is correct, then I still find the plumping how data= flows >between tasks somewhat unclear. In the general case, there will be a buffe= r >between a task producing data and a task consuming data. Perhaps we need t= o >model these buffers explicitely and then we can say something like task X = feeds >into buffer A and task Y consumes data from buffer A. This makes the plumi= ng >clearer I think.=20 I did consider this idea to have a concept of explicit queues. However I de= cided it was an additional information object that actually wasn't necessar= y. If we start to attach more information to queues such as you describe be= low then they do become useful. I thought this was making things more compl= icated and harder to understand though than just saying "task A output 2 go= es to task B". Instead we'd say "task A output 2 goes to channel X, task B = gets input from channel X". Then we need to discuss if a queue persists dat= a if more than one task is consuming from it etc. >We could also put constraints on buffers or in future versions have >controls on buffers (e.g. old data is discarded if buffers fill up). Right= now, we >have these magic output selection numbers which I do not find really clear= (how >do I know which output selection number I have to use for a certain task)? The input and output data interfaces of any particular task do need to be d= efined by the registry along with the parameters that are used to configure= it. >/js > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From nobody Wed Sep 3 01:35:20 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 2D5521A6F2E for ; Wed, 3 Sep 2014 01:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 bRx6hI4gRm6b for ; Wed, 3 Sep 2014 01:35:17 -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 CAEC41A702A for ; Wed, 3 Sep 2014 01:35:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 94A5712A2; Wed, 3 Sep 2014 10:35:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GkrSOpyv0JRJ; Wed, 3 Sep 2014 10:35:03 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Sep 2014 10:35:15 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE9CF20035; Wed, 3 Sep 2014 10:35:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bpnVEBkAulyY; Wed, 3 Sep 2014 10:35:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DE4A20033; Wed, 3 Sep 2014 10:35:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 365C62E5836D; Wed, 3 Sep 2014 10:35:12 +0200 (CEST) Date: Wed, 3 Sep 2014 10:35:11 +0200 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20140903083511.GA79742@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, lmap@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CEDB@AZ-FFEXMB04.global.avaya.com> <003b01cfc33a$704d7e40$50e87ac0$@com> <20140829081714.GB63622@elstar.local> <00f701cfc373$c91cffd0$5b56ff70$@com> <20140901202801.GA74827@elstar.local> <20140903080419.GB79584@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/sqSd02jAmln0Wj5DBwkRTo3qWTw Cc: lmap@ietf.org Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 08:35:18 -0000 On Wed, Sep 03, 2014 at 09:16:55AM +0100, trevor.burbridge@bt.com wrote: > > I did consider this idea to have a concept of explicit > queues. However I decided it was an additional information object > that actually wasn't necessary. If we start to attach more > information to queues such as you describe below then they do become > useful. I thought this was making things more complicated and harder > to understand though than just saying "task A output 2 goes to task > B". Instead we'd say "task A output 2 goes to channel X, task B gets > input from channel X". Then we need to discuss if a queue persists > data if more than one task is consuming from it etc. > To implement this information model, you have to have queues of some sort and then an implementor has to answer how the queues work, such as whether data can be only consumed once or multiple times if there are multiple readers or what to do if the queues fill up. The likelihood is high that implementers will take different approaches if we do not detail this. For me, modeling queues explicitely makes things more obvious and hence simpler. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 3 02:04:27 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 3CCEE1A86DE for ; Wed, 3 Sep 2014 02:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 QUoFRiLPOEwD for ; Wed, 3 Sep 2014 02:04:21 -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 54A161A011B for ; Wed, 3 Sep 2014 02:04:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 15CB61631; Wed, 3 Sep 2014 11:04:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3zTor5S4fna4; Wed, 3 Sep 2014 11:04:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Sep 2014 11:04:13 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7EAFF20035; Wed, 3 Sep 2014 11:04:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JY7siCvj7oIZ; Wed, 3 Sep 2014 11:04:05 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas01.jacobs.jacobs-university.de [10.70.0.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (not verified)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 5CD3120033; Wed, 3 Sep 2014 11:04:05 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS01.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 11:04:05 +0200 From: "Bajpai, Vaibhav" To: "lmap@ietf.org" Thread-Topic: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) Thread-Index: AQHPxrVkRiK9rsQ1ekWe8+UjI+4sW5vu/RGA Date: Wed, 3 Sep 2014 09:04:04 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> <20140902135407.GA77574@elstar.local> In-Reply-To: <20140902135407.GA77574@elstar.local> 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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/jMT6FkZYPIx26P_zD-ZvxV0Mo-4 Cc: "Bajpai, Vaibhav" , Dan Romascanu , =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 09:04:25 -0000 ** LMAP > On 02 Sep 2014, at 15:54, Juergen Schoenwaelder wrote: > On Tue, Aug 26, 2014 at 03:44:41PM +0000, Romascanu, Dan (Dan) wrote: [...] >> This message opens a Working Group Last Call for the draft-ietf-lmap-inf= ormation-model-02 >> Int= ernet-Draft. >=20 > Hi, >=20 > Vaibhav and myself went through the exercise to derive a data model > from the information model in order to find spots where the > information model is unclear or where we find the model may need > improvement. The result of ~2 day work is a YANG data model that we > have posted as an I-D (together with a configuration XML snippet that > validates against the YANG data model): >=20 > http://tools.ietf.org/html/draft-schoenw-lmap-yang-01 >=20 > We will post the comments we have collected in a subsequent message. > Until we get the notes compiled, enjoy reading the YANG data model. ;-) Please see below our review of the information model: a) structural changes: ~~~~~~~~~~~~~~~~~~~~~~ > 3. LMAP Information Model . . . . . . . . . . . . . . . . . . . 4 > 3.1. Information Structure . . . . . . . . . . . . . . . . . . 4 > 3.2. Pre-Configuration Information . . . . . . . . . . . . . . 8 > 3.3. Configuration Information . . . . . . . . . . . . . . . . 9 > 3.4. Instruction Information . . . . . . . . . . . . . . . . . 11 > 3.5. Logging Information . . . . . . . . . . . . . . . . . . . 13 > 3.6. Capability and Status Information . . . . . . . . . . . . 15 > 3.7. Reporting Information . . . . . . . . . . . . . . . . . . 17 > 3.8. Schedules . . . . . . . . . . . . . . . . . . . . . . . . 18 > 3.9. Channels . . . . . . . . . . . . . . . . . . . . . . . . 21 > 3.10. Task Configurations . . . . . . . . . . . . . . . . . . . 22 > 3.11. Timing Information . . . . . . . . . . . . . . . . . . . 23 > 3.11.1. Periodic Timing . . . . . . . . . . . . . . . . . . 24 > 3.11.2. Calendar Timing . . . . . . . . . . . . . . . . . . 25 > 3.11.3. One-Off Timing . . . . . . . . . . . . . . . . . . . 26 > 3.11.4. Immediate Timing . . . . . . . . . . . . . . . . . . 26 > 3.11.5. Startup Timing . . . . . . . . . . . . . . . . . . . 26 Can we bring the text inside 3.1 one level up directly within 3? This will better show IM division of 6 (core components) + 4 (common objects) (as described below): > For clarity the information model is divided into six sections: > 1. Pre-Configuration Information. > 2. Configuration Information. > 3. Instruction Information. > 4. Logging Information. > 5. Capability and Status Information. > 6. Reporting Information. Perhaps we can also move the 4 common objects (below) into a separate secti= on. This will make it clearer how the IM consists of 6 core components with 4 objects shared amongst multiple components. > The information in these six sections is captured by a number of > common information objects. These objects are also described later > in this document and comprise of: > 1. Schedules. > 2. Channels. > 3. Task Configurations. > 4. Timings. Additionally since everything is defined to be a TASK. It would be nice to have a classfication of envisaged tasks (measurement task, data-aggregation tasks, reporting tasks, et al. for instance) b) comment notations ~~~~~~~~~~~~~~~~~~~~ // Selected Task channel interfaces (selected by integer from array defined= by the task) can be connected to // Channels (referenced by name string(s)) This should be regular text. And in order to help people find the text, it would be useful if the text about object 'foo' or attribute 'bar' would actually refer to 'foo' or 'bar' so that a text search allows to find the relevant text easily. c) channel granularity ~~~~~~~~~~~~~~~~~~~~~~ > object { > string ma-schedule-name; > ma-sched-task-obj ma-schedule-tasks<0..*>; > ma-timing-obj ma-schedule-timing; > } ma-schedule-obj; > object { > string ma-schedule-task-name; > [ma-sched-channels-obj ma-schedule-channels<0..*>;] > [ma-sched-downstream-tasks-obj ma-schedule-downstream-tasks<0..*= >;] > } ma-sched-task-obj; > object { > [int ma-schedule-channel-interface-selection<0..*>;= ] // default: all > [string ma-schedule-channel-names<0..*>]; > } ma-sched-channels-obj; Why do we define a separate channel for each task? Given with the ^ structure, tasks that run measurements will just pipe their measurment resu= lts to a downstream task (a reporting task). As a result, measurement tasks do = not necessarily need to worry about channels. It's eventually the reporting tas= k that pushes data on the reporting channel. Why don't we just pass the chann= el as an option to the reporting / control task and simply remove channel stuf= f from the schedule object? d) task/downstream task relationships ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > object { > string ma-schedule-task-name; > [ma-sched-channels-obj ma-schedule-channels<0..*>;] > [ma-sched-downstream-tasks-obj ma-schedule-downstream-tasks<0..*= >;] > } ma-sched-task-obj; - How do ensure that task and downstram-task relationships are cycle-free? - Example: There is a UDP latency task linked to a downstream immediate reporting task, For how long should the immediate reporting task wait for the upstream UDP latency task to complete? e) terminology ~~~~~~~~~~~~~~ 1) ma-sched-task-obj: This is set of tasks/downstream-tasks that need to be invoked as part of a schedule. Can we come up with a better term for this? -- perhaps: action? 2) downstream-tasks: > include an indication of the cross-traffic. Cross traffic is defined > as the total number of Bytes both upstream and downstream of non- > measurement traffic passing through the interfaces used by a > Measurement Task during the measurement period. The specific A downstream task is the next task in a chain of linked tasks. However, the term "downstream" is generally used to refer to the remote end. In fact it'= s being used in ^ text snippet in that context. Can we come with a replacemen= t term for this? f) schedules: ~~~~~~~~~~~~~ > object { > string ma-schedule-name; > ma-sched-task-obj ma-schedule-tasks<0..*>; > ma-timing-obj ma-schedule-timing; > } ma-schedule-obj; > object { > string ma-schedule-task-name; > [ma-sched-channels-obj ma-schedule-channels<0..*>;] > [ma-sched-downstream-tasks-obj ma-schedule-downstream-tasks<0.= .*>;] > } ma-sched-task-obj; 1) naming inconsistencies: The names within each object sometimes uniquely identify the object (see ma-schedule-obj); however sometimes they provide a reference to another obj= ect by name (see ma-sched-task-obj). Fine with either approach, but be nice to keep it consistent. 2) order of execution of tasks: There can be multiple ma-sched-task-obj with the same timing. How should th= ey be kicked off by the scheduler? -- simultaneously, sequentially or should t= his be implementation dependent? 3) schedule options: How about adding options to the schedule? The idea is that task configurati= on can be rather static and reused while other arguments vary and it would be nice to centralize the place where more frequent changes take place. g) suppressing a reporting task: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ What should happen with the measurement results when a reporting task is either suppressed or not mentioned as a downstream-task in one of the schedules? h) task ~~~~~~~ > object { > string ma-task-name; > uri ma-task-registry-entry; > string ma-role; > name-value-pair ma-task-options<0..*>; > [boolean ma-task-suppress-by-default;] // default: TRUE > [string ma-task-cycle-id;] > } ma-task-obj; 1) roles: Can the ma-role not be identified as one of the task-options? 2) granularity of task-options Arguments are part of task-options. This means, arguments such as name of t= he destination (measurement peer) needs to be indicated at the task-level. If this is a list of destination, this will be replicated for each task per schedule. 3) granularity of cycle ID A cycle ID can be used to tag a measurement campaign involving multiple related tasks for a specific time-period. Would it suffice to just keep thi= s tag at the schedule-level than at the task-level. i) pre-configuration and configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > object { > [uuid ma-agent-id;] > ma-task-obj ma-control-tasks<1..*>; > ma-channel-obj ma-control-channels<1..*>; > ma-schedule-obj ma-control-schedules<1..*>; > [urn ma-device-id;] > credentials ma-credentials; > } ma-config-obj; The preconfiguration dictates that there should atleast be one pseudo task that is used for initial configuration with the controller. This may not be necessary for protocols (NETCONF for instance) which have their own call-ho= me mechanism built in. A pseudo task may not necessarily be required. > object { > uuid ma-agent-id; > [ma-task-obj ma-control-tasks<0..*>;] > ma-channel-obj ma-control-channels<1..*>; > [ma-schedule-obj ma-control-schedules<0..*>]; > [urn ma-device-id;] > credentials ma-credentials; > [string ma-group-id;] > [boolean ma-report-ma-id-flag;] > [int ma-control-channel-failure-threshold;] > } ma-config-obj; 1) cardinality inconsistencies The ^ requirements also leads to cardinality inconsistencies when compared with the configuration object. For instance, the configuration item after t= he initial configuration now allows zero tasks (instead of atleast 1) 2) ma-control-channel-failure-threshold There is no description on this in text. Descriptions around items such as: What happens when the threshold is reached?, Does the threshold limit reset when a success is hit after a sequence of failures? Would it not be nice to report the number of failures crossing this threshold in the report? j) status information ~~~~~~~~~~~~~~~~~~~~~ > object { > uuid ma-agent-id; > urn ma-device-id; > string ma-hardware; > string ma-firmware; > string ma-version; > ma-interface-obj ma-interfaces<0..*>; > datetime ma-last-measurement; > datetime ma-last-report; > datetime ma-last-instruction; > datetime ma-last-configuration; > [ma-condition-obj ma-conditions<0..*>;] > ma-task-capability-obj ma-supported-tasks<0..*>; > } ma-status-obj; 1) ma-hardware and ma-firmware refer to versions. Shall we rename them to ma-hardware-version and ma-firmware-version. 2) ma-version is a string. How do we come up with a lexical ordering of version names? 3) Why do we need both ma-last-instruction and ma-last-configuration? How= is ma-last-instruction different from ma-last-configuration? 4) ma-last-measurement: by last-measurement do we mean, last-measurement-task? Since everything is a task, how does the MA differentiate measurement-task from report-task? 5) Should we also record the datetime of the last failed scheduled task. Should we also keep a record of number of last failures. k) condition codes ~~~~~~~~~~~~~~~~~~ > object { > string ma-condition-code; > string ma-condition-text; > } ma-condition-obj condition codes cannot be learnt at runtime. As such, a list of defined condition codes is needed. Ideally the IM should define these codes to allo= w commonality b/w multiple data models. In the worst case, atleast the IM mus= t mention that these codes are left for the data model documents to define. l) report object ~~~~~~~~~~~~~~~~ > object { > datetime ma-report-date; > [uuid ma-report-agent-id;] > [string ma-report-group-id;] > ma-report-task-obj ma-report-tasks<0..*>; > } ma-report-obj; Is the multiplicity of report-tasks really needed? I understand it's to all= ow reporting of results from multiple tasks in one report object. However, the savings it brings over the wire is minimal (date, agent-id, group-id). It would simplify the data model by having one report object for each task. Results from multiple tasks can be shipped in separate report objects. m) report task headers ~~~~~~~~~~~~~~~~~~~~~~ > object { > ma-task-obj ma-report-task-config; > string ma-report-task-column-labels<0..*>; > ma-result-row-obj ma-report-task-rows<0..*>; > } ma-report-task-obj; 1) We ship the task config, but why don't we also ship the schedule information back in the report? 2) We also ship the task config with each and every report. We should consi= der that task config is slated to change less frequently. n) report result rows: ~~~~~~~~~~~~~~~~~~~~~~ > object { > datetime ma-report-result-start-time; > [datetime ma-report-result-end-time;] > string ma-report-result-conflicting-tasks<0..*>; > [int ma-report-result-cross-traffic;] // Bytes of n= on-measurement traffic > // on measure= ment interface during measurement period > data ma-report-result-values<0..*>; > } ma-result-row-obj; 1) The cross-traffic is reported in absolute number of bytes. It's hard to make any interpretation in the results by observing these absolute numbers (500bytes vs 5Mbytes). Would it not be more useful to report the cross-traf= fic in relation to total traffic seen on the interface? 2) How does the MA identify a conflicting task? Given the configuration can change over time, the task-names referred to in the reports may either not exist or may refer to something entirely different at reporting time. > string ma-report-result-conflicting-tasks<0..*>; > [int ma-report-result-cross-traffic;] // Bytes of n= on-measurement traffic > // on measure= ment interface during measurement period 3) How do we make this environment reporting feature complete? An active te= st may care about the cross-traffic; but a passive test cares more about how m= any number of packets dropped during the test run. o) calendar timing ~~~~~~~~~~~~~~~~~~ > object { > [datetime ma-calendar-start;] // default: immediate > [datetime ma-calendar-end;] // default: indefinite > [int ma-calendar-months<0..*>;] // default: 1-12 > [days ma-calendar-days-of-week<0..*>;] // default: a= ll > [int ma-calendar-days-of-month<0..*>;] // default 1= -31 > [int ma-calendar-hours<0..*>;] // default: 0-23 > [int ma-calendar-minutes<0..*>;] // default: 0-59 > [int ma-calendar-seconds<0..*>;] // default: 0-59 > [int ma-calendar-timezone-offset;] > // default: system timezone offset > } ma-calendar-obj; 1) The default values are very dangerous. A calendar object with a start datetime will essentially make the test run at each clock ticks! 2) Would it not be nice to say: "please run the test on the last day of eac= h month". The current object does not allow such a presentation. We may need negative indexes that enumerate from the end to beginning of the list. p) immediate timing ~~~~~~~~~~~~~~~~~~~ > object { > // empty > } ma-immediate-obj; There is a schedule with immediate timing. Now if the configuration is reloaded, does the scheduler rerun this schedule? Best, Vaibhav ----------------------------------------------------- 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 From nobody Thu Sep 4 02:46: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 EF8731A06C7 for ; Thu, 4 Sep 2014 02:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 wsK2NNdwEhPE for ; Thu, 4 Sep 2014 02:46:43 -0700 (PDT) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:1:8::180:100]) by ietfa.amsl.com (Postfix) with ESMTP id DF1241A0203 for ; Thu, 4 Sep 2014 02:46:42 -0700 (PDT) Received: from [IPv6:2001:700:1:0:cdb:f7ad:600f:930d] (unknown [IPv6:2001:700:1:0:cdb:f7ad:600f:930d]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by epost.uninett.no (Postfix) with ESMTPSA id 257A13360B7 for ; Thu, 4 Sep 2014 11:46:40 +0200 (CEST) Message-ID: <54083500.7090007@uninett.no> Date: Thu, 04 Sep 2014 11:46:40 +0200 From: Arne Oslebo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: lmap@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CEDB@AZ-FFEXMB04.global.avaya.com> <003b01cfc33a$704d7e40$50e87ac0$@com> <20140829081714.GB63622@elstar.local> <00f701cfc373$c91cffd0$5b56ff70$@com> <20140901202801.GA74827@elstar.local> <20140903080419.GB79584@elstar.local> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/F33CkPYaRpViAKldVuIhrQCqVzk Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 09:46:45 -0000 On 03. sep. 2014 10:16, trevor.burbridge@bt.com wrote: >> If this interpretation is correct, then I still find the plumping how data flows >> between tasks somewhat unclear. In the general case, there will be a buffer >> between a task producing data and a task consuming data. Perhaps we need to >> model these buffers explicitely and then we can say something like task X feeds >> into buffer A and task Y consumes data from buffer A. This makes the pluming >> clearer I think. > I did consider this idea to have a concept of explicit queues. However I decided it was an additional information object that actually wasn't necessary. If we start to attach more information to queues such as you describe below then they do become useful. I thought this was making things more complicated and harder to understand though than just saying "task A output 2 goes to task B". Instead we'd say "task A output 2 goes to channel X, task B gets input from channel X". Then we need to discuss if a queue persists data if more than one task is consuming from it etc. The way I understand the information model is that we are actually saying that "Output X from task A in schedule S goes to task B". With this method we have to create a different task for each reporting interval since tasks doesn't have any schedule information in them. I see that in draft-schoenw-lmap-yang-01 the downstream-task is defined as a reference to a task, but in the example xml at the end of the document they are actually referencing a schedule which I think is the correct way to do things. So what we should be able to specify is "Output X from task A in schedule S goes to all tasks in schedule T". Arne From nobody Thu Sep 4 02:57:09 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 E30C41A070F for ; Thu, 4 Sep 2014 02:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 j4-4UdbYvyKL for ; Thu, 4 Sep 2014 02:57:05 -0700 (PDT) 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 6B9D81A06C7 for ; Thu, 4 Sep 2014 02:57:05 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 4 Sep 2014 10:57:09 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.205]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Thu, 4 Sep 2014 10:56:44 +0100 From: To: , Date: Thu, 4 Sep 2014 10:56:43 +0100 Thread-Topic: [lmap] WGLC for draft-ietf-lmap-information-model-02 Thread-Index: Ac/IJSd/jynxwhD7S4qgfwubP+U2NAAARenQ Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CEDB@AZ-FFEXMB04.global.avaya.com> <003b01cfc33a$704d7e40$50e87ac0$@com> <20140829081714.GB63622@elstar.local> <00f701cfc373$c91cffd0$5b56ff70$@com> <20140901202801.GA74827@elstar.local> <20140903080419.GB79584@elstar.local> <54083500.7090007@uninett.no> In-Reply-To: <54083500.7090007@uninett.no> 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/J9Xi9GKl6ewuqu0HwigStH8a9U4 Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 09:57:08 -0000 >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Arne Oslebo >Sent: 04 September 2014 10:47 >To: lmap@ietf.org >Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 > >On 03. sep. 2014 10:16, trevor.burbridge@bt.com wrote: >>> If this interpretation is correct, then I still find the plumping how d= ata flows >>> between tasks somewhat unclear. In the general case, there will be a bu= ffer >>> between a task producing data and a task consuming data. Perhaps we nee= d >to >>> model these buffers explicitely and then we can say something like task= X >feeds >>> into buffer A and task Y consumes data from buffer A. This makes the pl= uming >>> clearer I think. >> I did consider this idea to have a concept of explicit queues. However I= decided >it was an additional information object that actually wasn't necessary. If= we start >to attach more information to queues such as you describe below then they = do >become useful. I thought this was making things more complicated and harde= r to >understand though than just saying "task A output 2 goes to task B". Inste= ad we'd >say "task A output 2 goes to channel X, task B gets input from channel X".= Then >we need to discuss if a queue persists data if more than one task is consu= ming >from it etc. > >The way I understand the information model is that we are actually >saying that "Output X from task A in schedule S goes to task B". With >this method we have to create a different task for each reporting >interval since tasks doesn't have any schedule information in them. Yes - I meant within the scope of that schedule. >I see that in draft-schoenw-lmap-yang-01 the downstream-task is defined >as a reference to a task, but in the example xml at the end of the >document they are actually referencing a schedule which I think is the >correct way to do things. So what we should be able to specify is >"Output X from task A in schedule S goes to all tasks in schedule T". Good point - and yes the downstream task should also be within the scope of= a particular schedule (needs correcting in the Information Model) - so may= be the suggestion of explicit queues does simplify things. >Arne > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Sep 4 04:51: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 DCC3C1A875A for ; Thu, 4 Sep 2014 04:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 9MIE6jsaCiuP for ; Thu, 4 Sep 2014 04:51:15 -0700 (PDT) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:1:8::180:100]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE9E1A874D for ; Thu, 4 Sep 2014 04:51:15 -0700 (PDT) Received: from [IPv6:2001:700:1:0:cdb:f7ad:600f:930d] (unknown [IPv6:2001:700:1:0:cdb:f7ad:600f:930d]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by epost.uninett.no (Postfix) with ESMTPSA id 73562336388 for ; Thu, 4 Sep 2014 13:51:13 +0200 (CEST) Message-ID: <54085231.3060506@uninett.no> Date: Thu, 04 Sep 2014 13:51:13 +0200 From: Arne Oslebo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: lmap@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> <20140902135407.GA77574@elstar.local> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/6aHVqVRWTYnoH-rEz72Q1YHZBws Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 11:51:19 -0000 On 03. sep. 2014 11:04, Bajpai, Vaibhav wrote: > b) comment notations > ~~~~~~~~~~~~~~~~~~~~ > > // Selected Task channel interfaces (selected by integer from array defined by the task) can be connected to > // Channels (referenced by name string(s)) > > This should be regular text. And in order to help people find the > text, it would be useful if the text about object 'foo' or attribute > 'bar' would actually refer to 'foo' or 'bar' so that a text search > allows to find the relevant text easily. I agree. Using integers makes things unnecessarily difficult to read and understand. > c) channel granularity > ~~~~~~~~~~~~~~~~~~~~~~ > > > object { > > string ma-schedule-name; > > ma-sched-task-obj ma-schedule-tasks<0..*>; > > ma-timing-obj ma-schedule-timing; > > } ma-schedule-obj; > > > object { > > string ma-schedule-task-name; > > [ma-sched-channels-obj ma-schedule-channels<0..*>;] > > [ma-sched-downstream-tasks-obj ma-schedule-downstream-tasks<0..*>;] > > } ma-sched-task-obj; > > > object { > > [int ma-schedule-channel-interface-selection<0..*>;] // default: all > > [string ma-schedule-channel-names<0..*>]; > > } ma-sched-channels-obj; > > Why do we define a separate channel for each task? Given with the ^ > structure, tasks that run measurements will just pipe their measurment results > to a downstream task (a reporting task). As a result, measurement tasks do not > necessarily need to worry about channels. It's eventually the reporting task > that pushes data on the reporting channel. Why don't we just pass the channel > as an option to the reporting / control task and simply remove channel stuff > from the schedule object? The list of channels is defined as <0..*>, so if a measurement task do not need a channel then we do not have to specify one. So I prefer it as it is now. > > d) task/downstream task relationships > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > object { > > string ma-schedule-task-name; > > [ma-sched-channels-obj ma-schedule-channels<0..*>;] > > [ma-sched-downstream-tasks-obj ma-schedule-downstream-tasks<0..*>;] > > } ma-sched-task-obj; > > - How do ensure that task and downstram-task relationships are cycle-free? > > - Example: There is a UDP latency task linked to a downstream immediate > reporting task, For how long should the immediate reporting task wait for > the upstream UDP latency task to complete? I am in the very early stages of an implementation and have given this some thought. Assuming that downstream-tasks actually references a schedule and not a task, then I will create a new instance of each task referenced by a schedule. For one off schedules I will terminate the task after it has been executed. For other schedules I will keep the tasks active as long as the MA is running. When a measurement task sends a report to a schedule containing a reporting task I will check the timing of the schedule. If the timing is immediate, I will send the report directly to the channel specified. If not, I will cache the report and send it at the scheduled time. > > e) terminology > ~~~~~~~~~~~~~~ > > 1) ma-sched-task-obj: > > This is set of tasks/downstream-tasks that need to be invoked as part of a > schedule. Can we come up with a better term for this? -- perhaps: action? I like the suggestion of using the term action. [...] > 2) order of execution of tasks: > > There can be multiple ma-sched-task-obj with the same timing. How should they > be kicked off by the scheduler? -- simultaneously, sequentially or should this > be implementation dependent? I think it should be implementation dependent but then we need some text in the information model discussing it. If a device has the resources I would prefer simultaneously, but for a resource limited device I think sequentially is the only option. If we make it implementation dependent we can add an element to ma-status-obj specifying how the timing is done. > > 3) schedule options: > > How about adding options to the schedule? The idea is that task configuration > can be rather static and reused while other arguments vary and it would be > nice to centralize the place where more frequent changes take place. +1 > > g) suppressing a reporting task: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > What should happen with the measurement results when a reporting task is > either suppressed If the actual reporting task is suppressed, then I think the results should be dropped. The only reason I see for suppressing a reporting task is if the caching of results takes too much resources. If a schedule that contains a reporting task is suppressed, then I think we should keep caching the results. But what should happen with the results when there are no more resources left to cache them? Should new results be dropped or should the oldest results be dropped? > or not mentioned as a downstream-task in one of the > schedules? If a reporting task is not mention as a downstream-task it will never receive any measurement results so it shouldn't be a problem. But what should we do when a reporting schedule is deleted and the reporting task in the schedule has measurement results that have not been sent? Should they be dropped? > > h) task > ~~~~~~~ > > > object { > > string ma-task-name; > > uri ma-task-registry-entry; > > string ma-role; > > name-value-pair ma-task-options<0..*>; > > [boolean ma-task-suppress-by-default;] // default: TRUE > > [string ma-task-cycle-id;] > > } ma-task-obj; > > 1) roles: > > Can the ma-role not be identified as one of the task-options? I've wondered the same thing. It should at least be made optional as not all tasks need a role. Arne From nobody Thu Sep 4 05:54:03 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 248BB1A8892 for ; Thu, 4 Sep 2014 05:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.567 X-Spam-Level: X-Spam-Status: No, score=-7.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 oJ4pkdhTALWK for ; Thu, 4 Sep 2014 05:53:59 -0700 (PDT) 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 6C2AC1A8893 for ; Thu, 4 Sep 2014 05:53:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhELAHlgCFSHCzIm/2dsb2JhbABZgkcjI1Nbrz0GBaArAYEGFneEBQEBAxIbXgEMCRVWJgEEGxqIIAGXfYRloBEBF4V8iSCDZ4EdBZE+kxCNQINhgjSBBwEBAQ X-IronPort-AV: E=Sophos; i="5.04,465,1406606400"; d="scan'208,217"; a="81068913" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Sep 2014 08:53:58 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 04 Sep 2014 08:53:58 -0400 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; Thu, 4 Sep 2014 08:53:57 -0400 From: "Romascanu, Dan (Dan)" To: "" Thread-Topic: meeting at IETF-91 Thread-Index: Ac/IP0WFuwpB9/4JRoSaorRF4Or9/w== Date: Thu, 4 Sep 2014 12:53:56 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8868D6@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_9904FB1B0159DA42B0B887B7FA8119CA5C8868D6AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/khLJFeYiDxVVNIqqgn9Fmznip7Y Subject: [lmap] meeting at IETF-91 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 12:54:01 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8868D6AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It's time (already!) to submit a request for a meeting slot at IETF-91. Should we ask for one session of 2.5 hours - as at IETF-90? The current list of conflicts includes: ippm ecrit bmwg dispatch lmap mptcp netconf netmod dime opsarea opsawg rade= xt sacm xrblock rtcweb tictoc irtfopen Are there other conflicts to avoid? Other special requests? Different propo= sals? Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8868D6AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

It’s time (already!) to submit a request for a= meeting slot at IETF-91.

 

Should we ask for one session of 2.5 hours – a= s at IETF-90?

 

The current list of conflicts includes: <= /p>

 

ippm ecrit bmwg dispatch lmap mptcp netconf netmod d= ime opsarea opsawg radext sacm xrblock rtcweb tictoc irtfopen

 

Are there other conflicts to avoid? Other special re= quests? Different proposals?

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8868D6AZFFEXMB04globa_-- From nobody Fri Sep 5 04:58: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 8521E1A06D6 for ; Fri, 5 Sep 2014 04:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 SJnRiXC8wF2j for ; Fri, 5 Sep 2014 04:58:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F301A0432 for ; Fri, 5 Sep 2014 04:58:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BD2A62345; Fri, 5 Sep 2014 13:58:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id b1S-LLr0JXEg; Fri, 5 Sep 2014 13:57:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 5 Sep 2014 13:58:00 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F0AC20036; Fri, 5 Sep 2014 13:58:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Rz0MN4Mx_lcX; Fri, 5 Sep 2014 13:57:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CEB9720035; Fri, 5 Sep 2014 13:57:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3CEB92E5B256; Fri, 5 Sep 2014 13:57:36 +0200 (CEST) Date: Fri, 5 Sep 2014 13:57:36 +0200 From: Juergen Schoenwaelder To: Arne Oslebo Message-ID: <20140905115736.GA87174@elstar.local> Mail-Followup-To: Arne Oslebo , lmap@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> <20140902135407.GA77574@elstar.local> <54085231.3060506@uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54085231.3060506@uninett.no> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/TiR21TBSA6QpCCMrYEFCsqeDWOk Cc: lmap@ietf.org Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 11:58:05 -0000 On Thu, Sep 04, 2014 at 01:51:13PM +0200, Arne Oslebo wrote: > On 03. sep. 2014 11:04, Bajpai, Vaibhav wrote: > > > c) channel granularity > > ~~~~~~~~~~~~~~~~~~~~~~ > > > > > object { > > > string ma-schedule-name; > > > ma-sched-task-obj ma-schedule-tasks<0..*>; > > > ma-timing-obj ma-schedule-timing; > > > } ma-schedule-obj; > > > > > object { > > > string ma-schedule-task-name; > > > [ma-sched-channels-obj ma-schedule-channels<0..*>;] > > > [ma-sched-downstream-tasks-obj ma-schedule-downstream-tasks<0..*>;] > > > } ma-sched-task-obj; > > > > > object { > > > [int ma-schedule-channel-interface-selection<0..*>;] // default: all > > > [string ma-schedule-channel-names<0..*>]; > > > } ma-sched-channels-obj; > > > > Why do we define a separate channel for each task? Given with the ^ > > structure, tasks that run measurements will just pipe their measurment results > > to a downstream task (a reporting task). As a result, measurement tasks do not > > necessarily need to worry about channels. It's eventually the reporting task > > that pushes data on the reporting channel. Why don't we just pass the channel > > as an option to the reporting / control task and simply remove channel stuff > > from the schedule object? > The list of channels is defined as <0..*>, so if a measurement task do > not need a channel then we do not have to specify one. So I prefer it as > it is now. My understanding is that only control and reporting tasks need one of LMAP these channels. I would find it simpler if we would configure the channel where the control / reporting task is configured instead of provisioning a way to configure channels for all tasks. /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 Fri Sep 5 08:06:26 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 3CAE01A0787 for ; Fri, 5 Sep 2014 08:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 K5G7LloIUXZJ for ; Fri, 5 Sep 2014 08:06:17 -0700 (PDT) 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 4FC0D1A0745 for ; Fri, 5 Sep 2014 08:06:16 -0700 (PDT) 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; Fri, 5 Sep 2014 16:06:22 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.45]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 5 Sep 2014 16:05:53 +0100 From: To: Date: Fri, 5 Sep 2014 16:05:51 +0100 Thread-Topic: Workshop following LMAP Interim Meeting Thread-Index: Ac/JFU6dbwA5PcCMRAW2qhZu3NYFmg== 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_A2E337CDB7BC4145B018B9BEE8EB3E0D4135E44653EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/qArzKGKLgD2sJ3i0z_q6avbei1M Subject: [lmap] Workshop following LMAP 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: Fri, 05 Sep 2014 15:06:23 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D4135E44653EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As well as the LMAP interim on Monday afternoon, there are a couple of rela= ted sessions on the Tuesday (all in the same location in Dublin, at the Bro= adband Forum meeting) - LMAP people are invited to these, regardless of whe= ther you're a BBF member. Tuesday morning there's a session to resolve comments on the 'straw ballot'= version of WT-304, see liaison http://www.ietf.org/mail-archive/web/lmap/c= urrent/msg01736.html [Roughly speaking, WT-304 is the Broadband Forum's equ= ivalent of the lmap architecture document, and this is their WG last call.] Tuesday afternoon there's a workshop on "Large-scale measurements - from st= andards to implementation and adoption". Here's the draft agenda:- Topic 1: Implementation and adoption of metrics in BBF devices The IPPM WG at the IETF has defined many IP-related metrics and is currentl= y defining additional metrics, measurement protocol extensions and a proces= s for registering metrics. How should this work be implemented in a BBF dev= ice? 1. Introduction - The overall Registry concept and an overview of the IPPM RFCs and = documents 2. Walk through "the life of a metric" (perhaps packet delay variation): - Definition, e.g. in an RFC. - Additional info required for registry (roles, parameters, etc.) th= at's not in RFC. - The registration process, including review and approval within IET= F. - How Measurement Tasks are derived from a registry entry. - How Measurement Results are specified. - If time allows, it would also be useful to discuss a sub-IP metric= . 3. BBF's role in metrics - Should the BBF define a list of metrics that BBF devices must /sho= uld /typically implement? (WT-304 Section 7 lists some performance metrics = but not associated requirements) - What metrics will the BBF define itself, at IP and other layers, i= f any? How will metrics defined by non-IETF organizations (and especially t= hose at non-IP layers) be registered? 4. BBF's role in related issues - Should the BBF define specific statistics derived from measurement= results? - Should the BBF define Characterization Plans (how many probes test= ing on what schedule)? Topic 2: Implementation and adoption of the information model in BBF device= s The LMAP WG at the IETF is defining an (abstract) information model for bro= adband measurements. How should this work be implemented in BBF devices? 1. Introduction - the overall information and data model concept and an ove= rview of the TR-181 based work 2. Implementation of the Information Model by BBF 1. Control protocol and data model based on TR-181 2. Report protocol and data model based on TR-232 (IPDR) 3. BBF extensions to information model 1. Rules for avoiding cross-traffic? 2. Rules of retrying tests? 4. Early planning for an interop /plugfest --- Note: Non- Broadband Forum members can come to all 3 sessions for free - providin= g you register as soon as possible http://www.ietf.org/mail-archive/web/lm= ap/current/msg01750.html There will be remote listen-in for the lmap meeting - not sure about the Tu= esday sessions (please let me know if you'd like it, and I'll try) On Tuesday, the exact timings are to be confirmed. Different BBF WGs meet in parallel - the agenda is decided late. Best wishes, phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason Sent: 02 September 2014 16:49 To: lmap@ietf.org Subject: [lmap] Draft LMAP Interim Meeting Agenda (Time Correction) It was pointed out by a few of you that I have an incorrect start time for = this meeting. LMAP WG Interim Meeting Date and Time: Monday, September 15, 2014, 1430(2:30pm) -1830 (6:30pm) IST 1. Note Well, Note Takers, Jabber Scribes, Agenda Bashing - Chairs (5 min) 2. WG Status - Chairs (5 min) 3. Use Cases Discussion - Respond to AD Comments (tentative) - 15 min 4. LMAP Information Model - Address LC Comments - TBD - 30 min 5. Protocol Discussion - 105 min YANG Model - Arne O. - 15min HTTP Style Protocol - ? - 15min REST Style Protocols - ? - 15 min Protocol Discussion - ? - 60 min 6. Discuss IPPM Registry - 30 min 7. Next steps and open mic - There is still time available, so I have inserted an item to discuss the I= PPM registry as well. Jason ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D4135E44653EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As well as the LMAP in= terim on Monday afternoon, there are a couple of related sessions on the Tu= esday (all in the same location in Dublin, at the Broadband Forum meeting) = – LMAP people are invited to these, regardless of whether you’r= e a BBF member.

 

Tuesday morning there’s a session to resolve com= ments on the ‘straw ballot’ version of WT-304, see liaison htt= p://www.ietf.org/mail-archive/web/lmap/current/msg01736.html [Roughly s= peaking, WT-304 is the Broadband Forum’s equivalent of the lmap archi= tecture document, and this is their WG last call.]

 

Tuesday afternoon th= ere’s a workshop on "Large-scale measurements – from stand= ards to implementation and adoption". Here’s the draft agenda:-<= o:p>

 

Topic 1: Implementation and adoption of metrics in BBF devices<= /o:p>

The IPPM WG at the IETF has defined ma= ny IP-related metrics and is currently defining additional metrics, measure= ment protocol extensions and a process for registering metrics. How should = this work be implemented in a BBF device?

1. Introduction

–      &n= bsp; The overall Registry concept and an ove= rview of the IPPM RFCs and documents

<= ![if !supportLists]>2. Walk through “the li= fe of a metric” (perhaps packet delay variation):

–        Definition, e.g. in an RFC.

–        Additional info required for registry (roles, paramet= ers, etc.) that’s not in RFC.

–        The registration process, including review and approval within IETF.

–<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp;  How Measurement Tasks are derive= d from a registry entry.

– = ;       How Me= asurement Results are specified.

– BBF’s role in metrics

–        Should the BBF define a list of metrics that BBF devices must /should /t= ypically implement? (WT-304 Section 7 lists some performance metrics but no= t associated requirements)

–&n= bsp;       Wha= t metrics will the BBF define itself, at IP and other layers, if any? How w= ill metrics defined by non-IETF organizations (and especially those at non-= IP layers) be registered?

4. BBF’s role in related issues

–     &nb= sp;  Should the BBF define specific sta= tistics derived from measurement results?

        Should the BBF define Characterization Plans (how many probes te= sting on what schedule)?

 <= /o:p>

Topic 2: Impl= ementation and adoption of the information model in BBF devices<= /b>

The LMAP WG at the IETF is defining an (abst= ract) information model for broadband measurements. How should this work be= implemented in BBF devices?

1. Introduction – the overall in= formation and data model concept and an overview of the TR-181 based work <= o:p>

2. Implementation of the Information Model by BBF

1.= Contr= ol protocol and data model based on TR-181

2. Report protocol and d= ata model based on TR-232 (IPDR)

3. BBF extensions to information m= odel

1. Rules for avoiding cross-traffic?

2. Rules of re= trying tests?

4. Early planning for an interop /plugfest

 

---

Note:

Non- = Broadband Forum members can come to all 3 sessions for free – providi= ng you register as soon as possible  = http://www.ietf.org/mail-archive/web/lmap/cu= rrent/msg01750.html

There will be remote listen-in for the lmap meeting - not sure about th= e Tuesday sessions (please let me know if you’d like it, and I’= ll try)

On Tuesday, the exact timings a= re to be confirmed.

Different BBF WGs= meet in parallel – the agenda is decided late.

 

Best wishes,

phil

 = ;

 

<= p class=3DMsoNormal>From: lmap [mailto:lmap-bounces= @ietf.org] On Behalf Of Weil, Jason
Sent: 02 September 201= 4 16:49
To: lmap@ietf.org
Subject: [lmap] Draft LMAP In= terim Meeting Agenda (Time Correction)

 

It wa= s pointed out by a few of you that I have an incorrect start time for this = meeting. 

 

LMAP WG Interim Meeting
Date and Time: Monday, September 15, 2014, 1430(2:30pm) -=
1830 (6:30pm) IST
          
     &=
nbsp;    
1. Note Well, Note Takers, Jabber Scr=
ibes, Agenda Bashing - Chairs (5 min)<=
/pre>
     &nb=
sp;    
2. WG Status - Chairs (5 min)
  &nbs=
p;       
3. Use Cases Discussion –=
 Respond to AD Comments (tentative) - 15 min<=
/span>
    &n=
bsp;     
4. LMAP Information Model – Address L=
C Comments – TBD – 30 min<=
/pre>
     &nb=
sp;    
5. Protocol Discussion – 105 min 
            &n=
bsp;     YANG Model – Arn=
e O. - 15min
=
            &nb=
sp;     HTTP Style Protocol  - =
? - 15min 
&n=
bsp;            =
;     REST Style Protocols -  ?=
 - 15 min
&nb=
sp;            =
     Protocol Discussion - ? &n=
bsp; - 60 min

= 6. Discuss IPPM Registry – 30 min

7. Next steps =
and open mic -
=

There is still time available,  so I have in= serted an item to discuss the IPPM registry as well. 

 

Jason

= 
 

 

This E-mail and an= y of its attachments may contain Time Warner Cable proprietary information,= which is privileged, confidential, or subject to copyright belonging to Ti= me Warner Cable. This E-mail is intended solely for the use of the individu= al or entity to which it is addressed. If you are not the intended recipien= t of this E-mail, you are hereby notified that any dissemination, distribut= ion, copying, or action taken in relation to the contents of and attachment= s to this E-mail is strictly prohibited and may be unlawful. If you have re= ceived this E-mail in error, please notify the sender immediately and perma= nently delete the original and any copy of this E-mail and any printout.

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D4135E44653EMV67UKRDdoma_-- From nobody Fri Sep 5 10:04: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 9675F1A0386 for ; Fri, 5 Sep 2014 10:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hs6vp4qZVW3z for ; Fri, 5 Sep 2014 10:04:17 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C751A037B for ; Fri, 5 Sep 2014 10:04:16 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 5 Sep 2014 18:04:20 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.45]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Fri, 5 Sep 2014 18:04:14 +0100 From: To: , Date: Fri, 5 Sep 2014 18:04:12 +0100 Thread-Topic: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) Thread-Index: Ac/BRKYtnn+Vlv70S1io/c4SvgSgDQH0Gvsg Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/pTV1RaZe73_lzy0ws74ZPQsvFPY Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 17:04:23 -0000 Here are some fairly minor comments /suggestions The nits checker has quite a few complaints, especially there are many line= s that are too long - reaching an impressive 52 characters in excess! http:= //www.ietf.org/tools/idnits?url=3Dhttp://www.ietf.org/archive/id/draft-ietf= -lmap-information-model-02.txt =20 There are quite a few places where the items in an object seem to be incons= istently named. For example << object { ma-task-obj ma-instruction-tasks<0..*>; ma-channel-obj ma-report-channels<0..*>; ma-schedule-obj ma-instruction-schedules<0..*>; ma-suppression-obj ma-suppression; } ma-instruction-obj; >> This makes me wonder, why not << ma-instruction-report-channels<0..*>;>> an= d << ma-instruction-suppression;>> Here it may be deliberate (they're objects, so effectively points off to an= other section where they're defined), but there are other examples where th= is doesn't seem the case. Also, maybe in the comments you could add some po= inters to other sections, where it isn't obvious. Later, you have things like ma-report-XX and ma-report-task-XX. I wonder if= it would be better to write ma-reporttask-XX or ma-report_task-obj, to mak= e clear they're not linked? Page 20 you have <> which I don't think is defi= ned S3.10,=20 << string ma-role;>> Think this is optional, ie needs [...]. and ma-task-role would be better na= me? S3.4 << [string ma-suppression-task-names<0..*>;] // default: all tasks if // ma-suppression-task-names is empty [string ma-suppression-schedule-names<0..*>;] // default: all schedules if // ma-suppression-schedule-names is empty >> You mean: default is obey the boolean ma-task-suppress-by-default (see S3.= 10) S3.10, in the discussion of ma-task-options, it would be good to mention In= put Parameters (I presume this is what this is referring to). The framework S5.2.2 (Instruction) also mentions the interface to use (for = the Measurement Task) and the 'measurement point designation' (*) of the MA= and other MA/MP(s) if applicable. Are either of these things included, or = are they further ma-task-options? (*)'measurement point designation' is an abstract definition, on the lines = of 'MA at the home gateway' and can be useful for helping the privacy of re= ports - see draft-ietf-ippm-reference-path. S3.7 Reporting information The framework S5.4 about the report mentions two things which may be in the= report & I didn't spot in the information model: the subscriber's service = parameters & the MA(s)/MP(s) 'measurement point designation'. Framework also says that optionally a report isn't sent if there are no mea= surement results - should the info model cover this? (ie is this something = the controller decides or the MA?) Thanks phil ------------ From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: 26 August 2014 16:45 To: lmap@ietf.org Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected da= te) This message opens a Working Group Last Call for the draft-ietf-lmap-inform= ation-model-02 Internet-Draft. Please read and send comments about this document to the LMAP WG list befor= e Wednesday September 10, 2014.=20 If you read the document and believe that it's ready to be submitted to the= IESG for consideration as Proposed standards, please state this in a short= message to the list.=20 The document is available at http://www.ietf.org/id/draft-ietf-lmap-informa= tion-model-02.txt.=20 Thanks and Regards, Jason and Dan From nobody Mon Sep 8 11:27: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 712E01A027C for ; Mon, 8 Sep 2014 11:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 M8-t2GqKs6IY for ; Mon, 8 Sep 2014 11:27:35 -0700 (PDT) Received: from p01c11o147.mxlogic.net (p01c11o147.mxlogic.net [208.65.144.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A544B1A0282 for ; Mon, 8 Sep 2014 11:27:35 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p01c11o147.mxlogic.net(mxl_mta-8.1.0-0) with ESMTP id 715fd045.2b63727fe940.12712.00-599.35070.p01c11o147.mxlogic.net (envelope-from ); Mon, 08 Sep 2014 12:27:35 -0600 (MDT) X-MXL-Hash: 540df517242f3a5e-690de8595fcbb2ce79d089887466d2d3d79039d8 Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p01c11o147.mxlogic.net(mxl_mta-8.1.0-0) over TLS secured channel with ESMTP id 215fd045.0.12667.00-308.34929.p01c11o147.mxlogic.net (envelope-from ); Mon, 08 Sep 2014 12:27:32 -0600 (MDT) X-MXL-Hash: 540df514621f44dc-c0a4091e96852d637ebbf133a8c30e29c6c8a694 Received: from ex-mb3.corp.adtran.com ([fe80::60aa:f95:ad49:a0f1]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0195.001; Mon, 8 Sep 2014 13:27:29 -0500 From: KEN KO To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Thread-Topic: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) Thread-Index: Ac/BRKYtnn+Vlv70S1io/c4SvgSgDQCiBiJA Date: Mon, 8 Sep 2014 18:27:28 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.196] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB7792BC2D5exmb3corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=bN4CIZOZ c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=Ei4VsVqArvYA:10 a=heL] X-AnalysisOut: [zwM1u-ZMA:10 a=qZHQZMT3apYA:10 a=aQomRHkrLCgA:10 a=BLceEmw] X-AnalysisOut: [cHowA:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=48vgC7mUAAAA:8 a=B0K5SNElpFGnD6aujg8A:9 a=CjuIK1q_8ug] X-AnalysisOut: [A:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a] X-AnalysisOut: [=i_pQuZ6qfsyP4MqwK70A:9 a=p-2qDFVSpMwadVnh:21 a=gKO2Hq4RSV] X-AnalysisOut: [kA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:1] X-AnalysisOut: [0] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014090808); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/-ai4XnMSPgguzCyqMxn04_QZqwU Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 18:27:39 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB7792BC2D5exmb3corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My comments: Technical: p.11, in MA Configuration object: I think "ma-schedule-obj ma-control-sc= hedules<0..*>" should be mandatory. This is a repeat comment from -01. pp.19-20, directing output from Tasks. If the specified destination Task is= listed in multiple Schedules, can we unambiguously define which Scheduled = Task is the destination? We might need to specify both the Task and the Sch= edule in ma-sched-downstream-tasks-obj. p.20, the Example refers to a ma-sched-send-to-tasks-obj. This object is no= t documented anywhere in the draft. I think you mean ma-sched-downstream-ta= sks-obj. Even then, the example syntax shown is unclear (there are a lot of= dashes) and I can't tell from it what the intended destination is for Outp= ut 2. Editorial: P.12, "If both individual tasks and individual schedules are listed then /t= he union of these options is considered - i.e. the listed shcedules/only th= e listed schedules plus the listed tasks where present in other schedules w= ill be suppressed regardless of the suppress-by-default flag/." Formatting throughout draft - insert line breaks to prevent IETF tool from = generating microscopic pages! Best regards, Ken From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, August 26, 2014 11:45 AM To: lmap@ietf.org Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected da= te) This message opens a Working Group Last Call for the draft-ietf-lmap-inform= ation-model-02 Internet-Draft. Please read and send comments about this document to the LMAP WG list befor= e Wednesday September 10, 2014. If you read the document and believe that it's ready to be submitted to the= IESG for consideration as Proposed standards, please state this in a short= message to the list. The document is available at http://www.ietf.org/id/draft-ietf-lmap-informa= tion-model-02.txt. Thanks and Regards, Jason and Dan --_000_D14B7E40AEBFD54EA3AD964902DD7CB7792BC2D5exmb3corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My comments:

 

Technical:<= /span>

 

p.11, in MA Configurat= ion object: I think “ma-schedule-obj    ma-control-sch= edules<0..*>” should be mandatory. This is a repeat comment fro= m -01.

 

pp.19-20, directing ou= tput from Tasks. If the specified destination Task is listed in multiple Sc= hedules, can we unambiguously define which Scheduled Task is the destinatio= n? We might need to specify both the Task and the Schedule in ma-sched-downstream-tasks-obj.<= /p>

 

p.20, the Example refe= rs to a ma-sched-send-to-tasks-obj. This object is not documented anywhere = in the draft. I think you mean ma-sched-downstream-tasks-obj. Even then, th= e example syntax shown is unclear (there are a lot of dashes) and I can’t tell from it what the intended dest= ination is for Output 2.

 

Editorial:<= /span>

 

P.12, “If both i= ndividual tasks and individual schedules are listed then /the union of thes= e options is considered - i.e. the listed shcedules/only the listed schedul= es plus the listed tasks where present in other schedules will be suppressed regardless of the suppress-by-default f= lag/.”

 

Formatting throughout = draft – insert line breaks to prevent IETF tool from generating micro= scopic pages!

 

Best regards,

Ken<= /p>

 

From: lmap [mailto:lm= ap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, August 26, 2014 11:45 AM
To: lmap@ietf.org
Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corre= cted date)

 

This message opens a Work= ing Group Last Call for the draft-ietf-lmap-information-model-02= Internet-Draft.

 

Please read and send comm= ents about this document to the LMAP WG list before Wednesday September 10,= 2014.

 

If you read the document = and believe that it’s ready to be submitted to the IESG for considera= tion as Proposed standards, please state this in a short message to the lis= t.

 

The document is available= at http://www.ietf.org/id/draft-ietf-lmap-information-model-02.txt. <= /o:p>

 

Thanks and Regards,<= /o:p>

 

Jason and Dan<= /p>

 

 

--_000_D14B7E40AEBFD54EA3AD964902DD7CB7792BC2D5exmb3corpadtran_-- From nobody Tue Sep 9 09:32: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 3DD281A7013 for ; Tue, 9 Sep 2014 09:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.551 X-Spam-Level: X-Spam-Status: No, score=-8.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652] 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 S3WDem9JP_Ew for ; Tue, 9 Sep 2014 09:32:28 -0700 (PDT) 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 B64C21A04F6 for ; Tue, 9 Sep 2014 09:32:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4MANgqD1TGmAcV/2dsb2JhbABZgkcjIyAzVwSxDwaDHpQMgUUBGAEJh0wBgQ0WeIQDAQEBAQMSCxBCGgIBCA0EBAEBCxYBBgcyFAkIAQEEEwgBGYggAQycVaA3AReFfIh6CQUYNwEGgjIPRCSBHQWKeoQyghWEMIhhhguEUIh0g2FsAYEGQYEHAQEB X-IronPort-AV: E=Sophos; i="5.04,492,1406606400"; d="scan'208,217"; a="84063914" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Sep 2014 12:32:18 -0400 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 Sep 2014 12:32:18 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Tue, 9 Sep 2014 18:32:17 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) Thread-Index: Ac/BRKYtnn+Vlv70S1io/c4SvgSgDQLAAGoA Date: Tue, 9 Sep 2014 16:32:16 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C895ACF@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C895ACFAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/wbmCzXu8zIffoWskPgKzqh4WW3c Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 16:32:32 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C895ACFAZFFEXMB04globa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please find below my comments. Technical T1: In section 3.1, when talking about Instruction Information, the followi= ng is said: =D8 It also inlcudes Task Suppression =D8 information that is used to over-ride normal Task execution =D8 during emergency situations. =D8 While Task Suppression is certainly used in emergency situations, the frame= work does not limit its usage to emergency cases, I believe that this claim= should not be made here either T2: Also in 3.1, under 1. Measurements Tasks I find the concept of Data Cap= ture Tasks. This is again something the framework does not talk about, and = neither could I find usage later in the IM. Unless there is some good justi= fication or details that I am missing, I suggest to take this out T3. Also in 3.1 - the concept of Downstream Tasks is introduced but never d= efined. Neither is it covered by the framework. T4: In Section 3.3 I found: =D8 While pre-configuration is persistent upon device reset or power =D8 cycle due to its very nature, the persistency of the addtional =D8 configuration information may be control protocol dependent. Some =D8 protocols may assume that reset devices will revert back to their =D8 pre-configuration state, while other protocols may assume that all =D8 configuration and instruction information is held in persistent =D8 storage. =D8 Is this something that really depends on the protocol? Can somebody give an= example of a protocol that assumes that reset devices will revert to their= pre-configuration state? I tend to believe that this is a device rather th= an a protocol characteristic, but I may be wrong T5. In section 3.4 I see 'The datetime format ... MUST conform to RFC 3339 = [RFC 3339] and ISO8601.' Are these the same thing, or does ISO8601 contain = more requirements. As this is a MUST clause, we need clarity here and a Nor= mative reference to ISO8601. Or drop it if the two are the same. T6. In Section 3.5 and 3.6. Are the interfaces of an MA the same as the int= erfaces of the device that hosts the MA? If they are the same some text sho= uld clarify this. If they are different or may be different, the examples i= n 3 'Status updates from the MA' should specify whether the interfaces of t= he MA or of the device are referred. T7. I could not find some of the pieces of information described in section= 5.2 of the framework I-D related to Logging in the IM objects in Section 3= .5 of this I-D - e.g. the last time the MA ran a Measurement Task o the last time the MA sent a Measurement Report o the last time the MA received an Instruction Message T8. What is ma-task-role? Requester/responder? If so or if something else s= ome clarification would be welcome. T9. The security considerations section should include some warning against= using the (mis)configuration of the MAs as a mean to overload the network = or launch DoS attacks. T10. I believe that we should say some place in the document that the consi= derations of the Privacy Considerations section in the framework document a= pply to the IM model wherever applicable Editorial E1. The Introduction talks about 'basically three protocols' but the text t= hat follows indicates that there are actually three types of protocols, but= there can be more instances. E2. First purpose in Introduction - implementations are not standardized, s= o s/data model implementations/data models/. Also s/Report protocol/Report = protocols/ E3. In section 3.1 s/inlcudes/includes/ E4. In section 3.2 s/The detail of the Channel/The details of the Channel/ E5. In Section 3.3 s/addtional/additional/. Also please fix the first sente= nce in the second paragraph. Also s/vaue/value/ E6. In section 3.4 s/exceution/execution/ E7. In section 3.5 - What means 'achieved simply and flexibly'? sounds like= 'marketing' E8. In section 3.7 - s/inlcudes/includes/ E9. The first sentence in 3.9 looks like a circular definition with 'channe= l' being defined by being a 'channel' of some sorts. Maybe s/bi-directional= communication channel/bi-directional communication path/ E10. Also in 3.9 - what a 'local short name' means? 'short' requires some c= ontext, or just drop it E11. In 3.10 - s/bye used/be used/. Also do not capitalize NOT! E12. Why is the appendix numbered as section 6? Either do not call this sec= tion 'Appendix' or append it at the end of the document. Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, August 26, 2014 6:45 PM To: lmap@ietf.org Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected da= te) This message opens a Working Group Last Call for the draft-ietf-lmap-inform= ation-model-02 Internet-Draft. Please read and send comments about this document to the LMAP WG list befor= e Wednesday September 10, 2014. If you read the document and believe that it's ready to be submitted to the= IESG for consideration as Proposed standards, please state this in a short= message to the list. The document is available at http://www.ietf.org/id/draft-ietf-lmap-informa= tion-model-02.txt. Thanks and Regards, Jason and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C895ACFAZFFEXMB04globa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please find below my c= omments.

 

Technical

 

T1: In section 3.1, wh= en talking about Instruction Information, the following is said:

 

=D8  It also inlcudes Task Sup= pression

=D8      &= nbsp;  information that is used to over-ride normal Task executio= n

=D8      &= nbsp;  during emergency situations.

=D8   <= /p>

 

While Task Suppression= is certainly used in emergency situations, the framework does not limit it= s usage to emergency cases, I believe that this claim should not be made he= re either

 

T2: Also in 3.1, under= 1. Measurements Tasks I find the concept of Data Capture Tasks. This is ag= ain something the framework does not talk about, and neither could I find u= sage later in the IM. Unless there is some good justification or details that I am missing, I suggest to take th= is out

 

T3. Also in 3.1 –= ; the concept of Downstream Tasks is introduced but never defined. Neither = is it covered by the framework.

 

T4: In Section 3.3 I f= ound:

 

=D8  While pr=
e-configuration is persistent upon device reset or power
=D8   &n=
bsp; cycle due to its very nature, the persistency of the addtional
=D8   &n=
bsp; configuration information may be control protocol dependent. =
; Some
=D8   &n=
bsp; protocols may assume that reset devices will revert back to their=

=D8   &n=
bsp; pre-configuration state, while other protocols may assume that al=
l
=D8   &n=
bsp; configuration and instruction information is held in persistent
=D8   &n=
bsp; storage.
=D8  &nb=
sp;

 

Is this something that= really depends on the protocol? Can somebody give an example of a protocol= that assumes that reset devices will revert to their pre-configuration sta= te? I tend to believe that this is a device rather than a protocol characteristic, but I may be wrong

 

T5. In section 3.4 I s= ee ‘The datetime format … MUST conform to RFC 3339 [RFC 3339] a= nd ISO8601.’ Are these the same thing, or does ISO8601 contain more r= equirements. As this is a MUST clause, we need clarity here and a Normative reference to ISO8601.  Or drop it if the two are= the same.

 

T6. In Section 3.5 and= 3.6. Are the interfaces of an MA the same as the interfaces of the device = that hosts the MA? If they are the same some text should clarify this. If t= hey are different or may be different, the examples in 3 ‘Status updates from the MA’ should specify = whether the interfaces of the MA or of the device are referred.

 

T7. I could not find some of the pieces of information described in = section 5.2 of the framework I-D related to Logging in the IM objects in Se= ction 3.5 of this I-D – e.g.

 

           &n= bsp;    the last time the MA ran a Measurement Task

 

   o  the last= time the MA sent a Measurement Report

 

   o  the last= time the MA received an Instruction Message

 

 

 

T8. What is ma-task-ro= le? Requester/responder? If so or if something else some clarification woul= d be welcome.

 

T9. The security consi= derations section should include some warning against using the (mis)config= uration of the MAs as a mean to overload the network or launch DoS attacks.=

 

T10. I believe that we= should say some place in the document that the considerations of the Priva= cy Considerations section in the framework document apply to the IM model w= herever applicable

 

 

Editorial

 

E1. The Introduction t= alks about ‘basically three protocols’ but the text that follow= s indicates that there are actually three types of protocols, but there can= be more instances.

 

E2. First purpose in I= ntroduction – implementations are not standardized, so s/data model i= mplementations/data models/. Also s/Report protocol/Report protocols/<= /o:p>

 

E3. In section 3.1 s/i= nlcudes/includes/

 

E4. In section 3.2 s/T= he detail of the Channel/The details of the Channel/

 

E5. In Section 3.3 s/a= ddtional/additional/. Also please fix the first sentence in the second para= graph. Also s/vaue/value/

 

E6. In section 3.4 s/e= xceution/execution/

 

E7. In section 3.5 - W= hat means ‘achieved simply and flexibly’? sounds like ‘ma= rketing’

 

E8. In section 3.7 - s= /inlcudes/includes/

 

E9. The first sentence= in 3.9 looks like a circular definition with ‘channel’ being d= efined by being a ‘channel’ of some sorts. Maybe s/bi-direction= al communication channel/bi-directional communication path/

 

E10. Also in 3.9 ̵= 1; what a ‘local short name’ means? ‘short’ require= s some context, or just drop it

 

E11. In 3.10 – s= /bye used/be used/. Also do not capitalize NOT!

 

E12. Why is the append= ix numbered as section 6? Either do not call this section ‘Appendix&#= 8217; or append it at the end of the document.

 

 

Regards,

 

Dan<= /p>

 

 

 

 

 

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, August 26, 2014 6:45 PM
To: lmap@ietf.org
Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corre= cted date)

 

This message opens a Working Group Last Call for the= draft-ietf-lmap-information-model-02 Internet-Draft.

 

Please read and send comments about this document to= the LMAP WG list before Wednesday September 10, 2014.

 

If you read the document and believe that it’s= ready to be submitted to the IESG for consideration as Proposed standards,= please state this in a short message to the list.

 

The document is available at http://www.ietf.org/id/draft-ietf-lmap-information-model-02.txt. <= /o:p>

 

Thanks and Regards,

 

Jason and Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C895ACFAZFFEXMB04globa_-- From nobody Tue Sep 9 09:58:13 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 0C3871A7014 for ; Tue, 9 Sep 2014 09:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] 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 ISsbfcMFh5TU for ; Tue, 9 Sep 2014 09:58:05 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47FC1A7008 for ; Tue, 9 Sep 2014 09:58:04 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id B830EA03EC6CD; Tue, 9 Sep 2014 16:58:00 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s89Gw0cd023195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 12:58:03 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 9 Sep 2014 12:58:00 -0400 From: "Carey, Timothy (Timothy)" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Thread-Topic: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) Thread-Index: AQHPzEusRR6AxaorbEW4cTGAHS2Twpv5A/Wg Date: Tue, 9 Sep 2014 16:57:59 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7734F8A2F6@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C87CF15@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C895ACF@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C895ACF@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.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F7734F8A2F6US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/-GRVt3TAIaDsfYr585i8TXQikaM Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 16:58:10 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7734F8A2F6US70UWXCHMBA05z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dan, RFC 3339 and ISO8601 are not the same. Honestly we should just pick one because its confusing to mandate both. I j= ust assumed it meant RFC 3339 because this is a RFC draft...:) The loss of configuration is not a protocol thing it is a device thing. Cer= tain constrained devices might not have the persistent storage necessary fo= r configuration so if the device resets; the controller will have to reload= configuration. Doesn't happen much today as I am aware things like modems = and RGs but who knows with other devices. BR, Tim From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Tuesday, September 09, 2014 11:32 AM To: lmap@ietf.org Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (correcte= d date) Please find below my comments. Technical T1: In section 3.1, when talking about Instruction Information, the followi= ng is said: =D8 It also inlcudes Task Suppression =D8 information that is used to over-ride normal Task execution =D8 during emergency situations. =D8 While Task Suppression is certainly used in emergency situations, the frame= work does not limit its usage to emergency cases, I believe that this claim= should not be made here either T2: Also in 3.1, under 1. Measurements Tasks I find the concept of Data Cap= ture Tasks. This is again something the framework does not talk about, and = neither could I find usage later in the IM. Unless there is some good justi= fication or details that I am missing, I suggest to take this out T3. Also in 3.1 - the concept of Downstream Tasks is introduced but never d= efined. Neither is it covered by the framework. T4: In Section 3.3 I found: =D8 While pre-configuration is persistent upon device reset or power =D8 cycle due to its very nature, the persistency of the addtional =D8 configuration information may be control protocol dependent. Some =D8 protocols may assume that reset devices will revert back to their =D8 pre-configuration state, while other protocols may assume that all =D8 configuration and instruction information is held in persistent =D8 storage. =D8 Is this something that really depends on the protocol? Can somebody give an= example of a protocol that assumes that reset devices will revert to their= pre-configuration state? I tend to believe that this is a device rather th= an a protocol characteristic, but I may be wrong T5. In section 3.4 I see 'The datetime format ... MUST conform to RFC 3339 = [RFC 3339] and ISO8601.' Are these the same thing, or does ISO8601 contain = more requirements. As this is a MUST clause, we need clarity here and a Nor= mative reference to ISO8601. Or drop it if the two are the same. T6. In Section 3.5 and 3.6. Are the interfaces of an MA the same as the int= erfaces of the device that hosts the MA? If they are the same some text sho= uld clarify this. If they are different or may be different, the examples i= n 3 'Status updates from the MA' should specify whether the interfaces of t= he MA or of the device are referred. T7. I could not find some of the pieces of information described in section= 5.2 of the framework I-D related to Logging in the IM objects in Section 3= .5 of this I-D - e.g. the last time the MA ran a Measurement Task o the last time the MA sent a Measurement Report o the last time the MA received an Instruction Message T8. What is ma-task-role? Requester/responder? If so or if something else s= ome clarification would be welcome. T9. The security considerations section should include some warning against= using the (mis)configuration of the MAs as a mean to overload the network = or launch DoS attacks. T10. I believe that we should say some place in the document that the consi= derations of the Privacy Considerations section in the framework document a= pply to the IM model wherever applicable Editorial E1. The Introduction talks about 'basically three protocols' but the text t= hat follows indicates that there are actually three types of protocols, but= there can be more instances. E2. First purpose in Introduction - implementations are not standardized, s= o s/data model implementations/data models/. Also s/Report protocol/Report = protocols/ E3. In section 3.1 s/inlcudes/includes/ E4. In section 3.2 s/The detail of the Channel/The details of the Channel/ E5. In Section 3.3 s/addtional/additional/. Also please fix the first sente= nce in the second paragraph. Also s/vaue/value/ E6. In section 3.4 s/exceution/execution/ E7. In section 3.5 - What means 'achieved simply and flexibly'? sounds like= 'marketing' E8. In section 3.7 - s/inlcudes/includes/ E9. The first sentence in 3.9 looks like a circular definition with 'channe= l' being defined by being a 'channel' of some sorts. Maybe s/bi-directional= communication channel/bi-directional communication path/ E10. Also in 3.9 - what a 'local short name' means? 'short' requires some c= ontext, or just drop it E11. In 3.10 - s/bye used/be used/. Also do not capitalize NOT! E12. Why is the appendix numbered as section 6? Either do not call this sec= tion 'Appendix' or append it at the end of the document. Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, August 26, 2014 6:45 PM To: lmap@ietf.org Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected da= te) This message opens a Working Group Last Call for the draft-ietf-lmap-inform= ation-model-02 Internet-Draft. Please read and send comments about this document to the LMAP WG list befor= e Wednesday September 10, 2014. If you read the document and believe that it's ready to be submitted to the= IESG for consideration as Proposed standards, please state this in a short= message to the list. The document is available at http://www.ietf.org/id/draft-ietf-lmap-informa= tion-model-02.txt. Thanks and Regards, Jason and Dan --_000_9966516C6EB5FC4381E05BF80AA55F7734F8A2F6US70UWXCHMBA05z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dan,

 

RFC 3339 and ISO8601 are not the same= .

Honestly we should just pick one beca= use its confusing to mandate both. I just assumed it meant RFC 3339 because= this is a RFC draft…J

 

The loss of configuration is not a pr= otocol thing it is a device thing. Certain constrained devices might not ha= ve the persistent storage necessary for configuration so if the device resets; the controller will have to reload configuration. Do= esn’t happen much today as I am aware things like modems and RGs but = who knows with other devices.

 

BR,

Tim

 

 

 

From: Romascan= u, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Tuesday, September 09, 2014 11:32 AM
To: lmap@ietf.org
Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (c= orrected date)

 

Please find below my c= omments.

 

Technical

 

T1: In section 3.1, wh= en talking about Instruction Information, the following is said:

 

=D8  It also inlcudes Task Suppression

=D8         informat= ion that is used to over-ride normal Task execution

=D8         during e= mergency situations.

=D8   

 

While Task Suppression= is certainly used in emergency situations, the framework does not limit it= s usage to emergency cases, I believe that this claim should not be made he= re either

 

T2: Also in 3.1, under= 1. Measurements Tasks I find the concept of Data Capture Tasks. This is ag= ain something the framework does not talk about, and neither could I find u= sage later in the IM. Unless there is some good justification or details that I am missing, I suggest to take th= is out

 

T3. Also in 3.1 –= ; the concept of Downstream Tasks is introduced but never defined. Neither = is it covered by the framework.

 

T4: In Section 3.3 I f= ound:

 

=
=D8&=
nbsp; While pre-configuration is persistent =
upon device reset or power
=
=D8&=
nbsp;    cycle due to its ver=
y nature, the persistency of the addtional
=
=D8&=
nbsp;    configuration inform=
ation may be control protocol dependent.  Some
=
=D8&=
nbsp;    protocols may assume=
 that reset devices will revert back to their
=
=D8&=
nbsp;    pre-configuration st=
ate, while other protocols may assume that all
=
=D8&=
nbsp;    configuration and in=
struction information is held in persistent
=
=D8&=
nbsp;    storage.<=
/pre>

=
=D8&=
nbsp;  


 


Is this something that=
 really depends on the protocol? Can somebody give an example of a protocol=
 that assumes that reset devices will revert to their pre-configuration sta=
te? I tend to believe that this is a
 device rather than a protocol characteristic, but I may be wrong


 


T5. In section 3.4 I s=
ee ‘The datetime format … MUST conform to RFC 3339 [RFC 3339] a=
nd ISO8601.’ Are these the same thing, or does ISO8601 contain more r=
equirements. As this is a MUST clause, we need clarity
 here and a Normative reference to ISO8601.  Or drop it if the two are=
 the same. 



 


T6. In Section 3.5 and=
 3.6. Are the interfaces of an MA the same as the interfaces of the device =
that hosts the MA? If they are the same some text should clarify this. If t=
hey are different or may be different,
 the examples in 3 ‘Status updates from the MA’ should specify =
whether the interfaces of the MA or of the device are referred.



 


T7. I could not find some of the pieces of information described in =
section 5.2 of the framework I-D related to Logging in the IM objects in Se=
ction 3.5 of this I-D – e.g.



 


           &n=
bsp;   
the last time the MA ran a Measurement Task


 


   o  the last=
 time the MA sent a Measurement Report


 


   o  the last=
 time the MA received an Instruction Message


 


 


 


T8. What is ma-task-ro=
le? Requester/responder? If so or if something else some clarification woul=
d be welcome.


 


T9. The security consi=
derations section should include some warning against using the (mis)config=
uration of the MAs as a mean to overload the network or launch DoS attacks.=



 


T10. I believe that we=
 should say some place in the document that the considerations of the Priva=
cy Considerations section in the framework document apply to the IM model w=
herever applicable


 


 


Editorial


 


E1. The Introduction t=
alks about ‘basically three protocols’ but the text that follow=
s indicates that there are actually three types of protocols, but there can=
 be more instances.


 


E2. First purpose in I=
ntroduction – implementations are not standardized, so s/data model i=
mplementations/data models/. Also s/Report protocol/Report protocols/<=
/o:p>


 


E3. In section 3.1 s/i=
nlcudes/includes/


 


E4. In section 3.2 s/T=
he detail of the Channel/The details of the Channel/


 


E5. In Section 3.3 s/a=
ddtional/additional/. Also please fix the first sentence in the second para=
graph. Also s/vaue/value/


 


E6. In section 3.4 s/e=
xceution/execution/


 


E7. In section 3.5 - W=
hat means ‘achieved simply and flexibly’? sounds like ‘ma=
rketing’


 


E8. In section 3.7 - s=
/inlcudes/includes/


 


E9. The first sentence=
 in 3.9 looks like a circular definition with ‘channel’ being d=
efined by being a ‘channel’ of some sorts. Maybe s/bi-direction=
al communication channel/bi-directional communication path/


 


E10. Also in 3.9 ̵=
1; what a ‘local short name’ means? ‘short’ require=
s some context, or just drop it


 


E11. In 3.10 – s=
/bye used/be used/. Also do not capitalize NOT!


 


E12. Why is the append=
ix numbered as section 6? Either do not call this section ‘Appendix&#=
8217; or append it at the end of the document.



 


 


Regards,


 


Dan<=
/p>

 


 


 


 


 


 








From: lmap [mailto:lmap-bounces@ietf.org]
On Behalf Of Romascanu, Dan (Dan)

Sent: Tuesday, August 26, 2014 6:45 PM

To: lmap@ietf.org

Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corre=
cted date)






 


This message opens a Working Group Last Call for the=
 
draft-ietf-lmap-information-model-02 Internet-Draft.


 


Please read and send comments about this document to=
 the LMAP WG list before Wednesday September 10, 2014.



 


If you read the document and believe that it’s=
 ready to be submitted to the IESG for consideration as Proposed standards,=
 please state this in a short message to the list.



 


The document is available at 
http://www.ietf.org/id/draft-ietf-lmap-information-model-02.txt. <=
/o:p>


 


Thanks and Regards,


 


Jason and Dan


 


 
--_000_9966516C6EB5FC4381E05BF80AA55F7734F8A2F6US70UWXCHMBA05z_-- From nobody Wed Sep 10 06:34:19 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 2EAA01A00E7 for ; Wed, 10 Sep 2014 06:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.551 X-Spam-Level: X-Spam-Status: No, score=-8.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652] 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 1oLG1q0zaydB for ; Wed, 10 Sep 2014 06:34:16 -0700 (PDT) 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 7F72A1A7022 for ; Wed, 10 Sep 2014 06:34:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgLABRTEFTGmAcV/2dsb2JhbABZgkcjI1NXBLEjmRKHTAGBDxZ4hAMBAQEBAxIbXAIBCA0EBAEBCx0HMhQJCAEBBBMIARmIIAEMnh+fcwEXhXyGIgGCXQEBHjcBgy+BHQWRQYZsjDCEOYkLg2FsAYEOOYEHAQEB X-IronPort-AV: E=Sophos; i="5.04,499,1406606400"; d="scan'208,217"; a="84189904" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Sep 2014 09:33:45 -0400 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; 10 Sep 2014 09:33:39 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Wed, 10 Sep 2014 15:33:37 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [lmap] LMAP Framework - ready for submission to the IESG? Thread-Index: Ac/B44MV/q3ebtFuToqdna6pxGH8yQLGBFow Date: Wed, 10 Sep 2014 13:33:36 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C89741F@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C87DBF2@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C87DBF2@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C89741FAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ynhuhVtw-gckQSFC_cJx0mrfeME Subject: Re: [lmap] LMAP Framework - ready for submission to the IESG? 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, 10 Sep 2014 13:34:18 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C89741FAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, No concern or other comments were expressed. The chairs will prepare the write-up and submit the document to the IESG. Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, August 27, 2014 1:42 PM To: lmap@ietf.org Subject: [lmap] LMAP Framework - ready for submission to the IESG? Hi, A revised I-D for the LMAP framework was submitted and is available at http= ://www.ietf.org/id/draft-ietf-lmap-framework-08.txt. We already ran two WGLCs for this I-D, and we deferred the decision about t= he need of a third one after IETF-90, in order to allow for an examination = of the list of changes. Phil described the changes in http://www.ietf.org/m= ail-archive/web/lmap/current/msg01742.html. Jason and me believe that a ful= l WGLC is not needed, but we would like to allow for one more week for folk= s who have sent comments to check and confirm that they were addressed, and= for everybody else to have another look and share any concerns left. So, please, have another read of this document and let us know if you belie= ve that there are good reasons NOT to forward this document to the IESG for= considerations and Informational RFC. Please send these before Wednesday, = September 3, 2014, COB. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C89741FAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, =

 

No concern or other co= mments were expressed.

 

The chairs will prepar= e the write-up and submit the document to the IESG.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, August 27, 2014 1:42 PM
To: lmap@ietf.org
Subject: [lmap] LMAP Framework - ready for submission to the IESG?

 

Hi,

 

A revised I-D for the LMAP framework was submitted a= nd is available at http://= www.ietf.org/id/draft-ietf-lmap-framework-08.txt.

 

We already ran two WGLCs for this I-D, and we deferr= ed the decision about the need of a third one after IETF-90, in order to al= low for an examination of the list of changes. Phil described the changes i= n http://www.ietf.org/mail-archive/web/lmap/current/msg01742.html. Jason= and me believe that a full WGLC is not needed, but we would like to allow = for one more week for folks who have sent comments to check and confirm that they were addressed, and for every= body else to have another look and share any concerns left.

 

So, please, have another read of this document and l= et us know if you believe that there are good reasons NOT to forward this d= ocument to the IESG for considerations and Informational RFC. Please send t= hese before Wednesday, September 3, 2014, COB.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C89741FAZFFEXMB04globa_-- From nobody Wed Sep 10 12:26: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 DBF351A86EB for ; Wed, 10 Sep 2014 12:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 Cve5zn9s4VUj for ; Wed, 10 Sep 2014 12:26:40 -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 9A1AC1A014E for ; Wed, 10 Sep 2014 12:26:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DB9251CC3 for ; Wed, 10 Sep 2014 21:26:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ti_KIQqTKAj6 for ; Wed, 10 Sep 2014 21:26:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 10 Sep 2014 21:26:37 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48BA920036 for ; Wed, 10 Sep 2014 21:26:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IhKRpW9me5q6 for ; Wed, 10 Sep 2014 21:26:36 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas04.jacobs.jacobs-university.de [10.70.0.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (not verified)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 6F29F20035 for ; Wed, 10 Sep 2014 21:26:36 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS04.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 21:26:36 +0200 From: "Bajpai, Vaibhav" To: "" Thread-Topic: draft-bagnulo-lmap-http-03 Thread-Index: AQHPzS0i64oi1jTGkk+zkIv5ojfXsw== Date: Wed, 10 Sep 2014 19:26:35 +0000 Message-ID: References: <20140910191747.21478.13439.idtracker@ietfa.amsl.com> In-Reply-To: <20140910191747.21478.13439.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [95.91.203.254] Content-Type: text/plain; charset="us-ascii" Content-ID: <684C8E77D82ADA438A3AB6D75036C17A@jacobs.jacobs-university.de> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/7wyksEfXXRFnQX7sXEKFCqBBK8k Cc: "Bajpai, Vaibhav" Subject: [lmap] draft-bagnulo-lmap-http-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: Wed, 10 Sep 2014 19:26:42 -0000 LMAP, We have uploaded a new version of the LMAP HTTP protocol draft. http://tools.ietf.org/html/draft-bagnulo-lmap-http-03 This version updates the JSON data model to align it with=20 the current information model objects [1] [1] http://tools.ietf.org/html/draft-ietf-lmap-information-model-02 Comments and feedback are welcome. > A new version of I-D, draft-bagnulo-lmap-http-03.txt > has been successfully submitted by Vaibhav Bajpai and posted to the > IETF repository. >=20 > Name: draft-bagnulo-lmap-http > Revision: 03 > Title: Large MeAsurement Platform Protocol > Document date: 2014-09-10 > Group: Individual Submission > Pages: 26 > URL: http://www.ietf.org/internet-drafts/draft-bagnulo-lmap-ht= tp-03.txt > Status: https://datatracker.ietf.org/doc/draft-bagnulo-lmap-http/ > Htmlized: http://tools.ietf.org/html/draft-bagnulo-lmap-http-03 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-bagnulo-lmap-htt= p-03 >=20 > Abstract: > This documents specifies the LMAP protocol based on HTTP for the > Control and Report in Large Scale Measurement Platforms. Best, Vaibhav ----------------------------------------------------- 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= From nobody Fri Sep 12 07:57:59 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 A3A7A1A006A for ; Fri, 12 Sep 2014 07:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 oFKchpr9DaYV for ; Fri, 12 Sep 2014 07:57:51 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5E31A6F32 for ; Fri, 12 Sep 2014 07:57:50 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 12 Sep 2014 15:57:59 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.45]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 12 Sep 2014 15:57:48 +0100 From: To: Date: Fri, 12 Sep 2014 15:53:28 +0100 Thread-Topic: [lmap] AD review of draft-ietf-lmap-use-cases-03 Thread-Index: Ac+nS90VGZDTeKZHRaWkZRSU+j/CmwgCXTPQAdD/nbU= Message-ID: References: <53C8247C.2000509@cisco.com> <53D11873.4080603@cisco.com>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D4135D6F9C2EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_cHw2c0YEaFNTSa3PMWgwhfgaUk Subject: [lmap] FW: AD review of draft-ietf-lmap-use-cases-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: Fri, 12 Sep 2014 14:57:57 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D4135D6F9C2EMV67UKRDdoma_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable cfi - in case there needs to be any discussion during Monday's interim, her= e are the proposed resolutions to Benoit's comments. best wishes, phil ________________________________ From: philip.eardley@bt.com [philip.eardley@bt.com] Sent: 03 September 2014 14:20 To: bclaise@cisco.com; draft-ietf-lmap-use-cases@tools.ietf.org Subject: RE: [lmap] AD review of draft-ietf-lmap-use-cases-03 Benoit, Thank-you very much for your review. Sorry for the slow response - crossed = wires amongst the authors I=92ve proposed resolutions to all your comments below =96 except for one t= hat I don=92t understand <<- Section 3.1 Operators want to understand the quality of experience (QoE) of their broadband customers. There is a QoE reference in RFC 5481 >> [phil] This was clarified:- The QoE reference is actually https://tools.ietf.org/html/rfc6390#section-2= .4 [to try and close the issues more rapidly, am emailing the use cases author= s rather than lmap list.] Thanks! phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Benoit Claise Sent: 24 July 2014 15:30 To: lmap@ietf.org Subject: [lmap] AD review of draft-ietf-lmap-use-cases-03 Dear all, Here is my AD review - OLD 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 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. NEW: 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 Mea= surement 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. Yes =96 agree. - Section 2.1 An ISP, or indeed another network operator, needs to understand the performance of their networks, the performance of the suppliers (downstream and upstream networks), the performance of services, and the impact that such performance has on the experience of their customers. "indeed another network operator"? NEW: A network operator needs to understand the performance of their networks, the performance of the suppliers (downstream and upstream networks), the performance of services, and the impact that such performance has on the experience of their customers. - Section 2.1 Identifying, isolating and fixing problems in the network, services or with CPE and end user equipment. I can't parse the sentence NEW Identifying, isolating and fixing problems, which may be in the netwo= rk, with the service provider, or in the end user equipment. - Section 2.1 This sentence speaks about "services" o Identifying, isolating and fixing problems in the network, services or with CPE and end user equipment. Section 3.2 speaks about new services. So, this paragraph also includes "services": o Understanding the impact and operation of new devices and technology. As a new product is deployed, or a new technology introduced into the network, it is essential that its operation and impact on other services is measured. This also helps to quantify the advantage that the new technology is bringing and support the business case for larger roll-out. NEW: o Understanding the impact and operation of new devices, technology, or services. As a new product is deployed, or a new techn= ology introduced into the network, it is essential that its operation and impact on other services is measured. This also helps to quantify the advantage that the new technology is bringing and support the business case for larger roll-out. I think =91services=92 here & in S3.2 is mainly being used in the sense of = =91network services=92, which is confusing. NEW o Understanding the impact and operation of new devices and technology. As a new product is deployed, or a new technology introduced into the network, it is essential that its operation and its impact is measured. This also helps to quantify the advantage that the new technology is bringing and support the business case for larger roll-out. and in S3.2, first sentence OLD Another type of measurement is to test new capabilities and services before they are rolled out. NEW Another type of measurement is to test new capabilities before they are rolled out. - I'm confused by: 2 Use = Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Internet Service Provider (ISP) Use Case . . . . . . . . . . 3 2.2 Regulators . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Implementation options . . . . . . . . . . . . . . . . . . . 5 What is the link between the "Implementation options" subsection and use ca= ses? Should "implementation options" have its own section? I agree. Think it fits best as a section near the end. NEW 5 Im= plementation options . . . . . . . . . . . . . . . . . . . 12 6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - Another approach involves implementing the measurement capability as a webpage or an "app" that end users are encouraged to download onto their mobile phone or computing device. Measurements are triggered by the end user, for example the user interface may have a button to "test my broadband now". Compared with the previous approach, the system is much more loosely controlled, as the panel of end users and the schedule of tests are determined by the end users themselves rather than the measurement system. It would be easier to get large- scale, however it is harder to get comparable benchmarks as the measurements are affected by the home network and also the population is self-selecting and so potentially biased towards those who think they have a problem. This could be alleviated by stimulating widespread downloading of the app and careful post-processing of the results to reduce biases. This end-user triggered measurement provides a huge advantage: it reflects = the end-user QoE, as opposed to the broadband device QoE (*). In combinati= on with LMAP measurements in the broadband device, the end-user triggered m= easurement might prove that the home network is the source of performance d= egradations. You might want to add those points either in section "Implementation option= s" or around the section 3.1 3rd paragraph. This point is partly covered in last paragraph of section 3.5 (*) except if the end-user triggered measurement is executed directly on th= e broadband device ... For example, downloading a page, or initiating a tes= t from the web server on the broadband device, as you mentioned: There are several other possibilities. For example, as a variant on the first approach, the measurement capability could be implemented as software embedded in the home gateway, which would make it more viable to have the capability on every user line. As a variant on the second approach, the end user could initiate measurements in response to a request from the measurement system. NEW Another approach involves implementing the measurement capability as a webpage or an "app" that end users are encouraged to download onto their mobile phone or computing device. Measurements are triggered by the end user, for example the user interface may have a button to "test my broadband now". One advantage of this approach is that the perf= ormance is measured to the end user, rather than to the home gateway, and s= o includes the home network. Another difference is that the system is much more loosely controlled, as the panel of end users and the schedule of tests are determined by the end users themselves rather than the measurement system. It would be easier to get large- scale, however it is harder to get comparable benchmarks as the measurements are affected by the home network and also the population is self-selecting and so potentially biased towards those who think they have a problem. This could be alleviated by stimulating widespread downloading of the app and careful post-processing of the results to reduce biases. - In connection with the previous point, I was confused while reading the = document. I don't see"end-user triggered measurement" in section 2.X next to the ISP = and operators use case. fine, but it's still discussed throughout the draft= . For example Measurements are triggered by the end user, for example the user interface may have a button to "test my broadband now". OR As a variant on the second approach, the end user could initiate measurements in response to a request from the measurement system. OR The operator really wants to understand the end-to-end service experience. However, the home network (Ethernet, WiFi, powerline) is highly variable and outside its control. To date, operators (and regulators) have instead measured performance from the home gateway. However, mobile operators clearly must include the wireless link in the measurement. OR The operator would like the end-to-end view of the service, rather than (say) just the access portion So, I've been wondering whether this end-user triggered measurement was in = scope or not. I only found my answer in the conclusion section There are other use cases that are not the focus of the initial LMAP charter (although it is expected that the mechanisms developed would be readily applied), for example end users would like to use measurements to help identify problems in their home network and to monitor the performance of their broadband provider. You should make it very clear, upfront, that the end-user triggered measure= ment is not in scope. Something like section 5.6.1 End-user-controlled measurement system in the = framework document Suggest changing S1 Introduction OLD This document describes two use cases for the Large-scale Measurement of Broadband Performance (LMAP), in particular use cases for ISPs and regulators. Although there are many other use cases for large-scale measurements systems, the two described here are the consensus starting point for defining the system. NEW This document describes two use cases for the Large-scale Measurement of Broadband Performance (LMAP). Firstly, to enable network operators to= understand the performance of the network and the quality experienced by c= ustomers. Secondly, to enable regulators to provide information on the perf= ormance of the ISPs in their jurisdiction. There are other use cases that a= re not the focus of the initial LMAP work, for example end users would like= to use measurements to help identify problems in their home network and to= monitor the performance of their broadband provider; it is expected that t= he same mechanisms are applicable. - Section 3.1 Operators want to understand the quality of experience (QoE) of their broadband customers. There is a QoE reference in RFC 5481 I don=92t understand this comment, sorry. I couldn=92t find =93QoE=94 in RF= C5481 - Section 3.5 One example was described in [IETF85-Plenary]. The operator was running a measurement panel for reasons discussed in sub use case #1. Should we all review [IETF85-Plenary] to understand what sub use case # 1 i= s? ;-) This meant sub use case #1 in draft-lmap-use-cases. However, I think the cu= rrent text can be improved. OLD One example was described in [IETF85-Plenary]. The operator was running a measurement panel for reasons discussed in sub use case #1. It was noticed that the performance of some lines had unexpectedly degraded. This led to a detailed (off-line) investigation which discovered that a particular home gateway upgrade had caused a (mistaken!) drop in line rate. Another example is that occasionally some internal network management event (like re-routing) can be customer-affecting (of course this is unusual). This affects a whole group of customers, for instance those on the same DSLAM. Understanding this will help an operator fix the fault more rapidly and/or allow the affected customers to be informed what's happening and/or request them to re-set their home hub (required to cure some conditions). More accurate information enables the operator to reassure customers and take more rapid and effective action to cure the problem. There may also be problems unique to a single user line (e.g. copper access) that need to be identified. NEW An operator can obtain useful information without measuring the performance= on every broadband line. By measuring a subset, the operator identify prob= lems that affect a group of customers. For example, the issue could be at a= shared point in the network topology (such as an exchange) or common to a = vendor or equipment type ([IETF85-Plenary] describes a case where a particu= lar home gateway upgrade had caused a (mistaken!) drop in line rate). A mor= e extensive deployment of the measurement capability to every broadband lin= e would enable an operator to identify issues unique to a single customer. = Overall, large-scale measurements can help an operator help an operator fix= the fault more rapidly and/or allow the affected customers to be informed = what's happening. More accurate information enables the operator to reassur= e customers and take more rapid and effective action to cure the problem. - Section 4.1 The published information needs to be: o Accurate - the measurement results must be correct and not influenced by errors or side effects. The results should be reproducible and consistent over time. o Comparable - common metrics should be used across different ISPs and service offerings so that measurement results can be compared. o Meaningful - the metrics used for measurements need to reflect what end users value about their broadband Internet access service o Reliable - the number and distribution of measurement agents, and the statistical processing of the raw measurement raw data, needs to be appropriate Not sure if this was discussed, but one goal behind the regulator use case = is to strongly suggest the ISPs to use the same metrics in their SLC (Servi= ce Level Contracts). If you ever tried to compare SLC between ISPs, well, go luck. This would be a nice additional 4.x section Rather than a new section, I suggest an additional sentence in the 2nd para= of S4.1: NEW End users need effective transparency to be able to make informed choices throughout the different stages of their relationship with ISPs, when selecting Internet access service offers, and when considering switching service offer within an ISP or to an alternative ISP. Quality information about service offers could include speed, delay, and jitter. Regulators can publish such information to facilitate end users' choice of service provider and offer. It may also encourage ISPs to use the same metrics in their servi= ce level contracts, which would further help end users to choose an ISP. Fi= nally, transparency may help content, application, service and device providers develop their Internet offerings. - Pervasive Monitoring, RFC 7528. This RFC should at least be referenced, f= or example around this sentence: The other approach is passive measurements on the customer's ordinary traffic; the advantage is that it measures what the customer actually does, but it creates extra variability (different traffic mixes give different results) and especially it raises privacy concerns. Do you mean RFC6973? (Privacy Considerations for Internet Protocols) NEW The other approach is passive measurements on the customer's ordinary traffic; the advantage is that it measures what the customer actually does, but it creates extra variability (different traffic mixes give different results) and especially it raises privacy concerns. [RFC6973] discusses privacy considerations for = Internet protocols in general, whilst [framework] discusses them specifical= ly for large-scale measurement systems. And add to references: [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013. Regards, Benoit -- Nits spotted: S2.2 Programs /programmes (twice) S2.2, end of penultimate paragraph is missing a full stop. S3.5 Large scale measurements can help provide a more nuance view that =3D=3D> Large-scale measurements can help provide a more nuanced view that S4.3 take away for LMAP purposes are that policy-makers are looking for =3D=3D> take-away for LMAP purposes is that policy-makers are looking for --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D4135D6F9C2EMV67UKRDdoma_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
cfi - in case there needs to be any discussion during Monday's interim= , here are the proposed resolutions to Benoit's comments.
best wishes,
phil
=  
From: philip.eard= ley@bt.com [philip.eardley@bt.com]
Sent: 03 September 2014 14:20
To: bclaise@cisco.com; draft-ietf-lmap-use-cases@tools.ietf.org
Subject: RE: [lmap] AD review of draft-ietf-lmap-use-cases-03

Benoit,

Thank-you very much for your review. Sorry for the slow response= - crossed wires amongst the authors

 

I=92ve proposed resolutions to all your comments below =96 excep= t for one that I don=92t understand

<<- Section 3.1 

   Operators want to understand the quality of experien=
ce (QoE) of their
   broadband customers.

There is a QoE reference in RFC 5481

>> 

 

[phil] This was clarified:-

The QoE reference is actually https://tools.ietf.org/html/rfc6390#section-2.4<= br>

 

[to try and close the issues more rapidly, am emailing the use c= ases authors rather than lmap list.]

 

Thanks!

phil

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: 24 July 2014 15:30
To: lmap@ietf.org
Subject: [lmap] AD review of draft-ietf-lmap-use-cases-03

 

Dear all,

Here is my AD review

 

- OLD

Abstract
 
   Measuring broadband performance on a large scale is impor=
tant for
   network diagnostics by providers and users, as well as fo=
r public
   policy.  Understanding the various scenarios and use=
rs of measuring
   broadband performance is essential to development of the =
framework,
   information model and protocol. This document details two=
 use cases
   that can assist to developing that framework.  The d=
etails of the
   measurement metrics themselves are beyond the scope of th=
is document.

NEW:

Abstract
 
   Measuring broadband performance on a large scale is impor=
tant for
   network diagnostics by providers and users, as well as fo=
r public
   policy.  Understanding the various scenarios and use=
rs 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 d=
etails of the
   measurement metrics themselves are beyond the scope of th=
is document.

 

Yes =96 agree.

 

-  Section 2.1

   An ISP, or indeed another network operator, needs to unde=
rstand the
   performance of their networks, the performance of the sup=
pliers
   (downstream and upstream networks), the performance of se=
rvices, and
   the impact that such performance has on the experience of=
 their
   customers.

"indeed another network operator"?<= br>
NEW:

   A network operator needs to understand the
   performance of their networks, the performance of the sup=
pliers
   (downstream and upstream networks), the performance of se=
rvices, and
   the impact that such performance has on the experience of=
 their
   customers.

 

 


- Section 2.1

      Identifying, isolating and fixing probl=
ems in the network,
      services or with CPE and end user equip=
ment. 
 
I can't parse the sentence
 
NEW
      Identifying, isolating and fixing problems, which may be in the network,
      with the ser=
vice provider, or in the end user equipment. 
 


-  Section 2.1

This sentence speaks about "services"

      o Identifying, isolating and fixing pro=
blems in the network,
      services or with CPE and end user equip=
ment. 
 
Section 3.2 speaks about new services.
So, this paragraph also includes "services":
 
      o Understanding the impact and operatio=
n of new devices and
      technology. As a new product is deploye=
d, or a new technology
      introduced into the network, it is esse=
ntial that its operation
      and impact on other services is measure=
d. This also helps to
      quantify the advantage that the new tec=
hnology is bringing and
      support the business case for larger ro=
ll-out.
 

NEW:

      o Understanding the impact and operatio=
n of new devices, 
      technology, or services. As=
 a new product is deployed, or a new technology
      introduced into the network, it is esse=
ntial that its operation
      and impact on other services is measure=
d. This also helps to
      quantify the advantage that the new tec=
hnology is bringing and
      support the business case for larger ro=
ll-out.

 

I think =91services=92 here & in S3.2 is mainly being used i= n the sense of =91network services=92, which is confusing.

NEW

      o Understanding the impact and operatio=
n of new devices and
      technology. As a new product is deploye=
d, or a new technology
      introduced into the network, it is esse=
ntial that its operation
      and its impa=
ct is measured. This also helps to
      quantify the advantage that the new tec=
hnology is bringing and
      support the business case for larger ro=
ll-out.

 

and in S3.2, first sentence

OLD

Another type of measurement is to test new capabilities= and services

   before they are rolled out.

 

NEW

Another type of measurement is to test new capabilities

   before they = are rolled out.


- I'm confused by:

 2  Use Cases . . . . . . . . . . . . . =
. . . . . . . . . . . . . .  3
     2.1 Internet Servi=
ce Provider (ISP) Use Case . . . . . . . . . .  3
     2.2 Regulators . .=
 . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3 Implementation=
 options . . . . . . . . . . . . . . . . . . .  5

What is the link between the "Implementation op= tions" subsection and use cases?
Should "implementation options" have its own section?

I agree. Think it fits best as a section near the end.

NEW

 &n= bsp; 5  Implementation options . . . . . . . . . = . . . . . . . . . .  12

   6  Conclusions . . . . . . . . . . . . = . . . . . . . . . . . . . . 12



- 

   Another approach involves implementing the measureme=
nt capability as
   a webpage or an "app" that end users are encour=
aged to download onto
   their mobile phone or computing device. Measurements are =
triggered by
   the end user, for example the user interface may have a b=
utton to
   "test my broadband now". Compared with the prev=
ious approach, the
   system is much more loosely controlled, as the panel of e=
nd users and
   the schedule of tests are determined by the end users the=
mselves
   rather than the measurement system. It would be easier to=
 get large-
   scale, however it is harder to get comparable benchmarks =
as the
   measurements are affected by the home network and also th=
e population
   is self-selecting and so potentially biased towards those=
 who think
   they have a problem. This could be alleviated by stimulat=
ing
   widespread downloading of the app and careful post-proces=
sing of the
   results to reduce biases.

This end-user triggere= d measurement provides a huge advantage: it reflects the end-user QoE, as o= pposed to the broadband device QoE (*).  In combination with LMAP meas= urements in the broadband device, the end-user triggered measurement might prove that the home network is the source of p= erformance degradations.
You might want to add those points either in section "Implementation o= ptions" or around the section 3.1  3rd paragraph.
This point is partly covered in last paragraph of section 3.5

(*) except if the end-user triggered measurement is executed directly on th= e broadband device ... For example, downloading a page, or initiating a tes= t from the web server on the broadband device, as you mentioned:

   There are several other possibilities. For example, as a =
variant on
   the first approach, the measurement capability could be i=
mplemented
   as software embedded in the home gateway, which would mak=
e it more
   viable to have the capability on every user line. As a va=
riant on the
   second approach, the end user could initiate measurements=
 in response
   to a request from the measurement system.

 

NEW

   Another approach involves implementing the measurement ca=
pability as
   a webpage or an "app" that end users are encour=
aged to download onto
   their mobile phone or computing device. Measurements are =
triggered by
   the end user, for example the user interface may have a b=
utton to
   "test my broadband now". One advantage of this approach is that the performance is measured to =
the end user, rather than to the home gateway, and so includes the home net=
work. Another difference is that the
   system is much more loosely controlled, as the panel of e=
nd users and
   the schedule of tests are determined by the end users the=
mselves
   rather than the measurement system. It would be easier to=
 get large-
   scale, however it is harder to get comparable benchmarks =
as the
   measurements are affected by the home network and also th=
e population
   is self-selecting and so potentially biased towards those=
 who think
   they have a problem. This could be alleviated by stimulat=
ing
   widespread downloading of the app and careful post-proces=
sing of the
   results to reduce biases.

 



- In connection with the previous point,  I was confused while reading= the document.
I don't see"end-user triggered measurement" in section 2.X next t= o the ISP and operators use case. fine, but it's still discussed throughout= the draft. For example

   Measurements are triggered by
   the end user, for example the user interface may have a b=
utton to
   "test my broadband now".
 
   OR
   As a variant on the
   second approach, the end user could initiate measurements=
 in response
   to a request from the measurement system.
 
   OR
 
   The operator really wants to understand the end-to-end se=
rvice
   experience. However, the home network (Ethernet, WiFi, po=
werline) is
   highly variable and outside its control. To date, operato=
rs (and
   regulators) have instead measured performance from the ho=
me gateway.
   However, mobile operators clearly must include the wirele=
ss link in
   the measurement. 
 
   OR
 
   The operator would like the
   end-to-end view of the service, rather than (say) just th=
e access
   portion
 

So, I've been wondering whether this end-user trigge= red measurement was in scope or not.
I only found my answer in the conclusion section

   There are
   other use cases that are not the focus of the initial LMA=
P charter
   (although it is expected that the mechanisms developed wo=
uld be
   readily applied), for example end users would like to use=

   measurements to help identify problems in their home netw=
ork and to
   monitor the performance of their broadband provider.

You should make it ver=
y clear, upfront, that the end-user triggered measurement is not in scope.<=
br>
Something like section 5.6.1 End-user-controlled measurement system in the =
framework document






Suggest changing S1 Introduction


OLD


   This document describes two use cases for =
the Large-scale Measurement


   of Broadband Performance (LMAP), in partic=
ular use cases for ISPs and


   regulators.  Although there are many =
other use cases for large-scale


   measurements systems, the two described he=
re are the consensus


   starting point for defining the system.


NEW


   This document describes two use cases for =
the Large-scale Measurement


   of Broadband Performance (LMAP). Firstly, to enable network operators to under=
stand the performance of the network and the quality experienced by custome=
rs. Secondly, to enable regulators to provide information on the performanc=
e of the ISPs in their jurisdiction. There are other use cases that are not=
 the focus of the initial LMAP work, for example end users would like to us=
e measurements to help identify problems in their home network and to monit=
or the performance of their broadband provider; it is expected that the sam=
e mechanisms are applicable. 


 




- Section 3.1 


   Operators want to understand the quality of experien=
ce (QoE) of their


   broadband customers. 


There is a QoE reference in RFC 5481


 


I don=92t understand this comment, sorry. I couldn=92t find =93Q=
oE=94 in RFC5481






- Section 3.5


   One example was described in [IETF85-Plenary]. The operat=
or was


   running a measurement panel for reasons discussed in sub =
use case #1.


Should we all review [IETF85-Plenary] to understand =
what sub use case # 1 is? ;-)






This meant sub use case #1 in draft-lmap-use-cases. However, I t=
hink the current text can be improved.


 


OLD


   One example was described in [IETF85-Plenary].
 The operator was


   running a measurement panel for reasons di=
scussed in sub use case #1.


   It was noticed that the performance of som=
e lines had unexpectedly


   degraded. This led to a detailed (off-line=
) investigation which


   discovered that a particular home gateway =
upgrade had caused a


   (mistaken!) drop in line rate.


 


   Another example is that occasionally some =
internal network management


   event (like re-routing) can be customer-af=
fecting (of course this is


   unusual). This affects a whole group of cu=
stomers, for instance those


   on the same DSLAM. Understanding this will=
 help an operator fix the


   fault more rapidly and/or allow the affect=
ed customers to be informed


   what's happening and/or request them to re=
-set their home hub


   (required to cure some conditions). More a=
ccurate information enables


   the operator to reassure customers and tak=
e more rapid and effective


   action to cure the problem.


 


   There may also be problems unique to a sin=
gle user line (e.g. copper


   access) that need to be identified.=



 


NEW


 


An operator can obtain usef=
ul information without measuring the performance on every broadband line. B=
y measuring a subset, the operator identify
 problems that affect a group of customers. For example, the issue could be=
 at a shared point in the network topology (such as an exchange) or common =
to a vendor or equipment type ([IETF85-Plenary] describes a case where a
particular home gateway upgrade had caused a (mistaken!) dr=
op in line rate). A more=
 extensive deployment of the measurement
 capability to every broadband line would enable an operator to identify is=
sues unique to a single customer. Overall, large-scale measurements can hel=
p an operator
help an operator fix the fault more rapidly and/or allow th=
e affected customers to be informed what's happening. More accurate informa=
tion enables the operator to reassure
 customers and take more rapid and effective action to cure the problem.


 


 




- Section 4.1


   The published information needs to be:


 


      o  Accurate - the measurement resu=
lts must be correct and not


      influenced by errors or side effects. T=
he results should be


      reproducible and consistent over time.<=
/pre>

 


      o  Comparable - common metrics sho=
uld be used across different


      ISPs and service offerings so that meas=
urement results can be


      compared.


 


      o  Meaningful - the metrics used f=
or measurements need to reflect


      what end users value about their broadb=
and Internet access service


 


      o  Reliable - the number and distr=
ibution of measurement agents,


      and the statistical processing of the r=
aw measurement raw data,


      needs to be appropriate




Not sure if this was discussed, but one goal behind the regulator use case =
is to strongly suggest the ISPs to use the same metrics in their SLC (Servi=
ce Level Contracts).

If you ever tried to compare SLC between ISPs, well, go luck.

This would be a nice additional 4.x section






Rather than a new section, I suggest an additional sentence in t=
he 2nd para of S4.1:


NEW


   End users need effective transparency to b=
e able to make informed


   choices throughout the different stages of=
 their relationship with


   ISPs, when selecting Internet access servi=
ce offers, and when


   considering switching service offer within=
 an ISP or to an


   alternative ISP. Quality information about=
 service offers could


   include speed, delay, and jitter. Regulato=
rs can publish such


   information to facilitate end users' choic=
e of service provider and


   offer.
It may also encourage ISPs to use the same metrics in their=
 service level contracts, which would further help end users to choose an I=
SP. Finally, transparency may
help content, application, service and device=



   providers develop their Internet offerings=
.


 






- Pervasive Monitoring, RFC 7528. This RFC should at least be referenced, f=
or example around this sentence:


   The other approach is passive measurements


   on the customer's ordinary traffic; the advantage is that=
 it measures


   what the customer actually does, but it creates extra var=
iability


   (different traffic mixes give different results) and espe=
cially it


   raises privacy concerns.


 


Do you m=
ean RFC6973? (Privacy Co=
nsiderations for Internet Protocols)


NEW


   The other approach is passive measurements


   on the customer's ordinary traffic; the advantage is that=
 it measures


   what the customer actually does, but it creates extra var=
iability


   (different traffic mixes give different results) and espe=
cially it


   raises privacy concerns. [RFC6=
973] discusses privacy considerations for Internet protocols in general, wh=
ilst [framework] discusses them specifically for large-scale measurement sy=
stems. 


 


And add to references:


 


   [RFC6973]  Coope=
r, A., Tschofenig, H., Aboba, B., Peterson, J.,


          &n=
bsp;   Morris, J., Hansen, M., and R. Smith, "Privacy=



          &n=
bsp;   Considerations for Internet Protocols",
RFC 6973, July


          &n=
bsp;   2013.


 


 


 


Regards, Benoit

 

--

Nits spotted:

S2.2

Programs /programmes (twice)

 

S2.2, end of penultimate paragraph is missing a full stop.

 

S3.5 Large scale measurements= can help provide a more nuance view that

=E8  Large-scale measurements can help pr= ovide a more nuanced view that

 

S4.3 take away for LMAP purpo= ses are that policy-makers are looking for

=E8  take-away for LMAP purposes is that policy-makers are l= ooking for

--_000_A2E337CDB7BC4145B018B9BEE8EB3E0D4135D6F9C2EMV67UKRDdoma_-- From nobody Fri Sep 12 09:42: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 0DACD1A0672 for ; Fri, 12 Sep 2014 09:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 cHditDJFERte for ; Fri, 12 Sep 2014 09:42:14 -0700 (PDT) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:1:8::180:100]) by ietfa.amsl.com (Postfix) with ESMTP id 7561E1A6FC8 for ; Fri, 12 Sep 2014 09:42:14 -0700 (PDT) Received: from [IPv6:2001:700:1:0:7053:648a:af01:a7fd] (unknown [IPv6:2001:700:1:0:7053:648a:af01:a7fd]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by epost.uninett.no (Postfix) with ESMTPSA id F28F43364BA for ; Fri, 12 Sep 2014 18:42:12 +0200 (CEST) Message-ID: <54132264.7060308@uninett.no> Date: Fri, 12 Sep 2014 18:42:12 +0200 From: Arne Oslebo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: lmap@ietf.org References: <20140912162650.13528.15706.idtracker@ietfa.amsl.com> In-Reply-To: <20140912162650.13528.15706.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/rl4M_tLsilneJrVvpg-QEu_m49Y Subject: [lmap] draft-oslebo-lmap-control-yang-00.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: Fri, 12 Sep 2014 16:42:17 -0000 Hello, I've put together a quick draft describing the LMAP YANG model that I've been working on. This solution is based on MAs polling the controller for information so the YANG model defines the information stored on a controller. Arne On 12. sep. 2014 18:26, internet-drafts@ietf.org wrote: > A new version of I-D, draft-oslebo-lmap-control-yang-00.txt > has been successfully submitted by Arne Oslebo and posted to the > IETF repository. > > Name: draft-oslebo-lmap-control-yang > Revision: 00 > Title: A YANG based Data Model for the LMAP Control Protocol > Document date: 2014-09-12 > Group: Individual Submission > Pages: 25 > URL: http://www.ietf.org/internet-drafts/draft-oslebo-lmap-control-yang-00.txt > Status: https://datatracker.ietf.org/doc/draft-oslebo-lmap-control-yang/ > Htmlized: http://tools.ietf.org/html/draft-oslebo-lmap-control-yang-00 > > > Abstract: > This document defines a YANG data model for the LMAP control > protocol. The model is based on measurement agents polling > information from a controller. > > > > > 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. > > The IETF Secretariat > From nobody Sun Sep 14 04:51: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 D51A41A0316 for ; Sun, 14 Sep 2014 04:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.551 X-Spam-Level: X-Spam-Status: No, score=-8.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652] 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 8qAElM_aNdiS for ; Sun, 14 Sep 2014 04:51:46 -0700 (PDT) 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 F025A1A0317 for ; Sun, 14 Sep 2014 04:51:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMLAJmAFVSHCzIm/2dsb2JhbABggkcjI1NbshoBAQEBAQEGnmwBgQQWeIQFAQEDEhteAQwJFVYmAQQbGogcAZMOhGWfWxiFfIkgg2aBHQWRTZMrjU+DXoI0gQIBAQE X-IronPort-AV: E=Sophos; i="5.04,521,1406606400"; d="scan'208,217"; a="72152305" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Sep 2014 07:51:43 -0400 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; 14 Sep 2014 07:51:42 -0400 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, 14 Sep 2014 13:51:41 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: remote participation, presentations for the interim Thread-Index: Ac/QEj5vZKm+Ut9VQCK6CBkt4Kj0sg== Date: Sun, 14 Sep 2014 11:51:40 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C89A80C@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_9904FB1B0159DA42B0B887B7FA8119CA5C89A80CAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/0_1WoexGlI3HVMqKA6QWeraT34U Subject: [lmap] remote participation, presentations for the interim X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 11:51:48 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C89A80CAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As you probably know we will have remote participation in the interim meeti= ng tomorrow via Webex. If you are preparing any presentation for the meetin= g, please send it to the chairs so that it can be uploaded and made availab= le for the remote participants. Thanks and regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C89A80CAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As you probably know we will have remote participati= on in the interim meeting tomorrow via Webex. If you are preparing any pres= entation for the meeting, please send it to the chairs so that it can be up= loaded and made available for the remote participants.

 

Thanks and regards,

 

Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C89A80CAZFFEXMB04globa_-- From nobody Sun Sep 14 09:29:44 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 3EFA91A008F for ; Sun, 14 Sep 2014 09:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.471 X-Spam-Level: X-Spam-Status: No, score=-12.471 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, 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 5t2N7g-pM0Sd for ; Sun, 14 Sep 2014 09:29:30 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF10B1A00A8 for ; Sun, 14 Sep 2014 09:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=84595; q=dns/txt; s=iport; t=1410712169; x=1411921769; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=0Ia4zXFb20iA4ItywDw1msRHqADLGR0vszh6+K2+GnY=; b=WjUDEvJMOTSmIKC2SZTNKdzgSdxle+QGv3RMOR1gSz5pbCeH32YtqVSm GqWlyayE2KtifPqDrW8jZoqIuX9BLDAfbpZQzFdsRj4KYIMxpoS/uEgBQ uhZ+sKWzHQPSkF5un3rFXA1IiXiF5z6j+gYs4+Ka8UcDwgGpwhc0e/1aS s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsFAPTBFVStJssW/2dsb2JhbABWBAaCR4EZiS66NoYxAQuHTAGBG3iEAwEBAQMBAQEBFwFTBAIEEQsRBAEBChYBAQYHCQMCAQIBFR8IAQgHDAQCAgEBiDIIDbgFAReOcRk5EAGESwWGHzGIZ4ZNhwSBX4VojXiDYDsEKwGCSQEBAQ X-IronPort-AV: E=Sophos;i="5.04,521,1406592000"; d="scan'208,217";a="173017215" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 14 Sep 2014 16:29:24 +0000 Received: from [10.61.210.211] ([10.61.210.211]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8EGTNWT023598; Sun, 14 Sep 2014 16:29:23 GMT Message-ID: <5415C263.9080107@cisco.com> Date: Sun, 14 Sep 2014 18:29:23 +0200 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: philip.eardley@bt.com, lmap@ietf.org References: <53C8247C.2000509@cisco.com> <53D11873.4080603@cisco.com>, In-Reply-To: Content-Type: multipart/alternative; boundary="------------060904000807090007020009" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/t7yMhde--zlyHIRHzJmEeDXfBk8 Subject: Re: [lmap] FW: AD review of draft-ietf-lmap-use-cases-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: Sun, 14 Sep 2014 16:29:42 -0000 This is a multi-part message in MIME format. --------------060904000807090007020009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Phil, I'm happy with the way you addressed my feedback. Just one point needs correction: the last one. Pervasive Monitoring, RFC 7528. This RFC should at least be referenced, for example around this sentence: The other approach is passive measurements on the customer's ordinary traffic; the advantage is that it measures what the customer actually does, but it creates extra variability (different traffic mixes give different results) and especially it raises privacy concerns. It's actually my fault. Wrong reference! it should be RFC 7258 Regards, Benoit > cfi - in case there needs to be any discussion during Monday's > interim, here are the proposed resolutions to Benoit's comments. > best wishes, > phil > ------------------------------------------------------------------------ > *From:* philip.eardley@bt.com [philip.eardley@bt.com] > *Sent:* 03 September 2014 14:20 > *To:* bclaise@cisco.com; draft-ietf-lmap-use-cases@tools.ietf.org > *Subject:* RE: [lmap] AD review of draft-ietf-lmap-use-cases-03 > > Benoit, > > Thank-you very much for your review. Sorry for the slow response - > crossed wires amongst the authors > > I've proposed resolutions to all your comments below -- except for one > that I don't understand > > <<- Section 3.1 > > Operators want to understand the quality of experience (QoE) of their > broadband customers. > > There is a QoE reference in RFC 5481 > > >> > > [phil] This was clarified:- > > The QoE reference is > actuallyhttps://tools.ietf.org/html/rfc6390#section-2.4 > > [to try and close the issues more rapidly, am emailing the use cases > authors rather than lmap list.] > > Thanks! > > phil > > *From:*lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of *Benoit Claise > *Sent:* 24 July 2014 15:30 > *To:* lmap@ietf.org > *Subject:* [lmap] AD review of draft-ietf-lmap-use-cases-03 > > Dear all, > > Here is my AD review > > - OLD > > 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 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. > > NEW: > > 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. > > Yes -- agree. > > - Section 2.1 > > An ISP, or indeed another network operator, needs to understand the > performance of their networks, the performance of the suppliers > (downstream and upstream networks), the performance of services, and > the impact that such performance has on the experience of their > customers. > > "indeed _another _network operator"? > > NEW: > > A network operator needsto understand the > performance of their networks, the performance of the suppliers > (downstream and upstream networks), the performance of services, and > the impact that such performance has on the experience of their > customers. > > > - Section 2.1 > > Identifying, isolating and fixing problems in the network, > services or with CPE and end user equipment. > > I can't parse the sentence > > NEW > Identifying, isolating and fixingproblems, which may be in the network, > with the service provider, or in theend user equipment. > > > > - Section 2.1 > > This sentence speaks about "services" > > o Identifying, isolating and fixing problems in the network, > services or with CPE and end user equipment. > > Section 3.2 speaks about new services. > So, this paragraph also includes "services": > > o Understanding the impact and operation of new devices and > technology. As a new product is deployed, or a new technology > introduced into the network, it is essential that its operation > and impact on other services is measured. This also helps to > quantify the advantage that the new technology is bringing and > support the business case for larger roll-out. > > > NEW: > > o Understanding the impact and operation of new devices, > technology,_or services._ As a new product is deployed, or a new technology > introduced into the network, it is essential that its operation > and impact on other services is measured. This also helps to > quantify the advantage that the new technology is bringing and > support the business case for larger roll-out. > > I think 'services' here & in S3.2 is mainly being used in the sense of > 'network services', which is confusing. > > NEW > > o Understanding the impact and operation of new devices and > technology. As a new product is deployed, or a new technology > introduced into the network, it is essential that its operation > andits impact ismeasured. This also helps to > quantify the advantage that the new technology is bringing and > support the business case for larger roll-out. > > and in S3.2, first sentence > > OLD > > Another type of measurement is to test new capabilities and services > > before they are rolled out. > > NEW > > Another type of measurement is to test new capabilities > > before they are rolled out. > > > - I'm confused by: > > 2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . .3 > 2.1 Internet Service Provider (ISP) Use Case . . . . . . . . . .3 > 2.2 Regulators . . . . . . . . . . . . . . . . . . . . . . . . .4 > 2.3 Implementation options . . . . . . . . . . . . . . . . . . .5 > > What is the link between the "Implementation options" subsection and > use cases? > Should "implementation options" have its own section? > > I agree. Think it fits best as a section near the end. > > NEW > > 5 > Implementation options . . . . . . . . . . . . . . . . . . . 12 > > > 6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . > 12 > > > > - > > Another approach involves implementing the measurement capability as > a webpage or an "app" that end users are encouraged to download onto > their mobile phone or computing device. Measurements are triggered by > the end user, for example the user interface may have a button to > "test my broadband now". Compared with the previous approach, the > system is much more loosely controlled, as the panel of end users and > the schedule of tests are determined by the end users themselves > rather than the measurement system. It would be easier to get large- > scale, however it is harder to get comparable benchmarks as the > measurements are affected by the home network and also the population > is self-selecting and so potentially biased towards those who think > they have a problem. This could be alleviated by stimulating > widespread downloading of the app and careful post-processing of the > results to reduce biases. > > This end-user triggered measurement provides a huge advantage: it > reflects the end-user QoE, as opposed to the broadband device QoE > (*). In combination with LMAP measurements in the broadband device, > the end-user triggered measurement might prove that the home network > is the source of performance degradations. > You might want to add those points either in section "Implementation > options" or around the section 3.1 3rd paragraph. > This point is partly covered in last paragraph of section 3.5 > > (*) except if the end-user triggered measurement is executed directly > on the broadband device ... For example, downloading a page, or > initiating a test from the web server on the broadband device, as you > mentioned: > > There are several other possibilities. For example, as a variant on > the first approach, the measurement capability could be implemented > as software embedded in the home gateway, which would make it more > viable to have the capability on every user line. As a variant on the > second approach, the end user could initiate measurements in response > to a request from the measurement system. > > NEW > > Another approach involves implementing the measurement capability as > a webpage or an "app" that end users are encouraged to download onto > their mobile phone or computing device. Measurements are triggered by > the end user, for example the user interface may have a button to > "test my broadband now".One advantage of this approach is that the performance is measured to the end user, rather than to the home gateway, and so includes the home network. Another difference is thatthe > system is much more loosely controlled, as the panel of end users and > the schedule of tests are determined by the end users themselves > rather than the measurement system. It would be easier to get large- > scale, however it is harder to get comparable benchmarks as the > measurements are affected by the home network and also the population > is self-selecting and so potentially biased towards those who think > they have a problem. This could be alleviated by stimulating > widespread downloading of the app and careful post-processing of the > results to reduce biases. > > > > - In connection with the previous point, I was confused while reading > the document. > I don't see"end-user triggered measurement" in section 2.X next to the > ISP and operators use case. fine, but it's still discussed throughout > the draft. For example > > Measurements are triggered by > the end user, for example the user interface may have a button to > "test my broadband now". > > OR > As a variant on the > second approach, the end user could initiate measurements in response > to a request from the measurement system. > > OR > > The operator really wants to understand the end-to-end service > experience. However, the home network (Ethernet, WiFi, powerline) is > highly variable and outside its control. To date, operators (and > regulators) have instead measured performance from the home gateway. > However, mobile operators clearly must include the wireless link in > the measurement. > > OR > > The operator would like the > end-to-end view of the service, rather than (say) just the access > portion > > > So, I've been wondering whether this end-user triggered measurement > was in scope or not. > I only found my answer in the conclusion section > > There are > other use cases that are not the focus of the initial LMAP charter > (although it is expected that the mechanisms developed would be > readily applied), for example end users would like to use > measurements to help identify problems in their home network and to > monitor the performance of their broadband provider. > > You should make it very clear, upfront, that the end-user triggered > measurement is not in scope. > Something like section 5.6.1 End-user-controlled measurement system in > the framework document > > Suggest changing S1 Introduction > > OLD > > This document describes two use cases for the Large-scale Measurement > > of Broadband Performance (LMAP), in particular use cases for ISPs and > > regulators. Although there are many other use cases for large-scale > > measurements systems, the two described here are the consensus > > starting point for defining the system. > > NEW > > This document describes two use cases for the Large-scale Measurement > > of Broadband Performance (LMAP). Firstly, to enable network operators to understand the performance of the network and the quality experienced by customers. Secondly, to enable regulators to provide information on the performance of the ISPs in their jurisdiction. There are other use cases that are not the focus of the initial LMAP work, for example end users would like to use measurements to help identify problems in their home network and to monitor the performance of their broadband provider; it is expected that the same mechanisms are applicable. > > > - Section 3.1 > > Operators want to understand the quality of experience (QoE) of their > broadband customers. > > There is a QoE reference in RFC 5481 > > I don't understand this comment, sorry. I couldn't find "QoE" in RFC5481 > > > > - Section 3.5 > > One example was described in [IETF85-Plenary]. The operator was > running a measurement panel for reasons discussed in sub use case #1. > > Should we all review [IETF85-Plenary] to understand what sub use case > # 1 is? ;-) > > This meant sub use case #1 in draft-lmap-use-cases. However, I think > the current text can be improved. > > OLD > > One example was described in [IETF85-Plenary > ]. > The operator was > > running a measurement panel for reasons discussed in sub use case #1. > > It was noticed that the performance of some lines had unexpectedly > > degraded. This led to a detailed (off-line) investigation which > > discovered that a particular home gateway upgrade had caused a > > (mistaken!) drop in line rate. > > Another example is that occasionally some internal network management > > event (like re-routing) can be customer-affecting (of course this is > > unusual). This affects a whole group of customers, for instance those > > on the same DSLAM. Understanding this will help an operator fix the > > fault more rapidly and/or allow the affected customers to be informed > > what's happening and/or request them to re-set their home hub > > (required to cure some conditions). More accurate information enables > > the operator to reassure customers and take more rapid and effective > > action to cure the problem. > > There may also be problems unique to a single user line (e.g. copper > > access) that need to be identified. > > NEW > > An operator can obtain useful information without measuring the > performance on every broadband line. By measuring a subset, the > operator identify problems that affect a group of customers. For > example, the issue could be at a shared point in the network topology > (such as an exchange) or common to a vendor or equipment type > ([IETF85-Plenary] describes a case where a particular home gateway > upgrade had caused a (mistaken!) drop in line rate). A more extensive > deployment of the measurement capability to every broadband line would > enable an operator to identify issues unique to a single customer. > Overall, large-scale measurements can help an operator help an > operator fix the fault more rapidly and/or allow the affected > customers to be informed what's happening. More accurate information > enables the operator to reassure customers and take more rapid and > effective action to cure the problem. > > > - Section 4.1 > > The published information needs to be: > > o Accurate - the measurement results must be correct and not > influenced by errors or side effects. The results should be > reproducible and consistent over time. > > o Comparable - common metrics should be used across different > ISPs and service offerings so that measurement results can be > compared. > > o Meaningful - the metrics used for measurements need to reflect > what end users value about their broadband Internet access service > > o Reliable - the number and distribution of measurement agents, > and the statistical processing of the raw measurement raw data, > needs to be appropriate > > > Not sure if this was discussed, but one goal behind the regulator use > case is to strongly suggest the ISPs to use the same metrics in their > SLC (Service Level Contracts). > If you ever tried to compare SLC between ISPs, well, go luck. > This would be a nice additional 4.x section > > Rather than a new section, I suggest an additional sentence in the > 2^nd para of S4.1: > > NEW > > End users need effective transparency to be able to make informed > > choices throughout the different stages of their relationship with > > ISPs, when selecting Internet access service offers, and when > > considering switching service offer within an ISP or to an > > alternative ISP. Quality information about service offers could > > include speed, delay, and jitter. Regulators can publish such > > information to facilitate end users' choice of service provider and > > offer. It may also encourage ISPs to use the same metrics in their > service level contracts, which would further help end users to choose > an ISP. Finally, transparency may help content, application, service > and device > > providers develop their Internet offerings. > > > > - Pervasive Monitoring, RFC 7528. This RFC should at least be > referenced, for example around this sentence: > > The other approach is passive measurements > on the customer's ordinary traffic; the advantage is that it measures > what the customer actually does, but it creates extra variability > (different traffic mixes give different results) and especially it > raises privacy concerns. > > > Do you mean RFC6973? (Privacy Considerations for Internet Protocols) > > NEW > > The other approach is passive measurements > on the customer's ordinary traffic; the advantage is that it measures > what the customer actually does, but it creates extra variability > (different traffic mixes give different results) and especially it > raises privacy concerns.[RFC6973] discusses privacy considerations for Internet protocols in general, whilst [framework] discusses them specifically for large-scale measurement systems. > > And add to references: > > [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., > > Morris, J., Hansen, M., and R. Smith, "Privacy > > Considerations for Internet Protocols", RFC 6973 > , July > > 2013. > > Regards, Benoit > > -- > > Nits spotted: > > S2.2 > > Programs /programmes (twice) > > S2.2, end of penultimate paragraph is missing a full stop. > > S3.5 Large scale measurements can help provide a more nuance view that > > Large-scale measurements can help provide a more nuanced view that > > S4.3 take away for LMAP purposes are that policy-makers are looking for > > take-away for LMAP purposes is that policy-makers are looking for > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --------------060904000807090007020009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Phil,

I'm happy with the way you addressed my feedback.
Just one point needs correction: the last one.
Pervasive Monitoring, RFC 7528. This RFC should at least be referenced, for example around this sentence: 
   The other approach is passive measurements
   on the customer's ordinary traffic; the advantage is that it measures
   what the customer actually does, but it creates extra variability
   (different traffic mixes give different results) and especially it
   raises privacy concerns.
It's actually my fault. Wrong reference! it should be RFC 7258

Regards, Benoit
cfi - in case there needs to be any discussion during Monday's interim, here are the proposed resolutions to Benoit's comments.
best wishes,
phil
 
From: philip.eardley@bt.com [philip.eardley@bt.com]
Sent: 03 September 2014 14:20
To: bclaise@cisco.com; draft-ietf-lmap-use-cases@tools.ietf.org
Subject: RE: [lmap] AD review of draft-ietf-lmap-use-cases-03

Benoit,

Thank-you very much for your review. Sorry for the slow response - crossed wires amongst the authors

 

I’ve proposed resolutions to all your comments below – except for one that I don’t understand

<<- Section 3.1 

   Operators want to understand the quality of experience (QoE) of their
   broadband customers.

There is a QoE reference in RFC 5481

>> 

 

[phil] This was clarified:-

The QoE reference is actually https://tools.ietf.org/html/rfc6390#section-2.4

 

[to try and close the issues more rapidly, am emailing the use cases authors rather than lmap list.]

 

Thanks!

phil

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: 24 July 2014 15:30
To: lmap@ietf.org
Subject: [lmap] AD review of draft-ietf-lmap-use-cases-03

 

Dear all,

Here is my AD review

 

- OLD

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 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.

NEW:

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.

 

Yes – agree.

 

-  Section 2.1

   An ISP, or indeed another network operator, needs to understand the
   performance of their networks, the performance of the suppliers
   (downstream and upstream networks), the performance of services, and
   the impact that such performance has on the experience of their
   customers.

"indeed another network operator"?

NEW:

   A network operator needs to understand the
   performance of their networks, the performance of the suppliers
   (downstream and upstream networks), the performance of services, and
   the impact that such performance has on the experience of their
   customers.

 

 


- Section 2.1

      Identifying, isolating and fixing problems in the network,
      services or with CPE and end user equipment. 
 
I can't parse the sentence
 
NEW
      Identifying, isolating and fixing problems, which may be in the network,
      with the service provider, or in the end user equipment. 
 


-  Section 2.1

This sentence speaks about "services"

      o Identifying, isolating and fixing problems in the network,
      services or with CPE and end user equipment. 
 
Section 3.2 speaks about new services.
So, this paragraph also includes "services":
 
      o Understanding the impact and operation of new devices and
      technology. As a new product is deployed, or a new technology
      introduced into the network, it is essential that its operation
      and impact on other services is measured. This also helps to
      quantify the advantage that the new technology is bringing and
      support the business case for larger roll-out.
 

NEW:

      o Understanding the impact and operation of new devices, 
      technology, or services. As a new product is deployed, or a new technology
      introduced into the network, it is essential that its operation
      and impact on other services is measured. This also helps to
      quantify the advantage that the new technology is bringing and
      support the business case for larger roll-out.

 

I think ‘services’ here & in S3.2 is mainly being used in the sense of ‘network services’, which is confusing.

NEW

      o Understanding the impact and operation of new devices and
      technology. As a new product is deployed, or a new technology
      introduced into the network, it is essential that its operation
      and its impact is measured. This also helps to
      quantify the advantage that the new technology is bringing and
      support the business case for larger roll-out.

 

and in S3.2, first sentence

OLD

Another type of measurement is to test new capabilities and services

   before they are rolled out.

 

NEW

Another type of measurement is to test new capabilities

   before they are rolled out.


- I'm confused by:

 2  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1 Internet Service Provider (ISP) Use Case . . . . . . . . . .  3
     2.2 Regulators . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3 Implementation options . . . . . . . . . . . . . . . . . . .  5

What is the link between the "Implementation options" subsection and use cases?
Should "implementation options" have its own section?

I agree. Think it fits best as a section near the end.

NEW

   5  Implementation options . . . . . . . . . . . . . . . . . . .  12

   6  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 12



- 

   Another approach involves implementing the measurement capability as
   a webpage or an "app" that end users are encouraged to download onto
   their mobile phone or computing device. Measurements are triggered by
   the end user, for example the user interface may have a button to
   "test my broadband now". Compared with the previous approach, the
   system is much more loosely controlled, as the panel of end users and
   the schedule of tests are determined by the end users themselves
   rather than the measurement system. It would be easier to get large-
   scale, however it is harder to get comparable benchmarks as the
   measurements are affected by the home network and also the population
   is self-selecting and so potentially biased towards those who think
   they have a problem. This could be alleviated by stimulating
   widespread downloading of the app and careful post-processing of the
   results to reduce biases.

This end-user triggered measurement provides a huge advantage: it reflects the end-user QoE, as opposed to the broadband device QoE (*).  In combination with LMAP measurements in the broadband device, the end-user triggered measurement might prove that the home network is the source of performance degradations.
You might want to add those points either in section "Implementation options" or around the section 3.1  3rd paragraph.
This point is partly covered in last paragraph of section 3.5

(*) except if the end-user triggered measurement is executed directly on the broadband device ... For example, downloading a page, or initiating a test from the web server on the broadband device, as you mentioned:

   There are several other possibilities. For example, as a variant on
   the first approach, the measurement capability could be implemented
   as software embedded in the home gateway, which would make it more
   viable to have the capability on every user line. As a variant on the
   second approach, the end user could initiate measurements in response
   to a request from the measurement system.

 

NEW

   Another approach involves implementing the measurement capability as
   a webpage or an "app" that end users are encouraged to download onto
   their mobile phone or computing device. Measurements are triggered by
   the end user, for example the user interface may have a button to
   "test my broadband now". One advantage of this approach is that the performance is measured to the end user, rather than to the home gateway, and so includes the home network. Another difference is that the
   system is much more loosely controlled, as the panel of end users and
   the schedule of tests are determined by the end users themselves
   rather than the measurement system. It would be easier to get large-
   scale, however it is harder to get comparable benchmarks as the
   measurements are affected by the home network and also the population
   is self-selecting and so potentially biased towards those who think
   they have a problem. This could be alleviated by stimulating
   widespread downloading of the app and careful post-processing of the
   results to reduce biases.

 



- In connection with the previous point,  I was confused while reading the document.
I don't see"end-user triggered measurement" in section 2.X next to the ISP and operators use case. fine, but it's still discussed throughout the draft. For example

   Measurements are triggered by
   the end user, for example the user interface may have a button to
   "test my broadband now".
 
   OR
   As a variant on the
   second approach, the end user could initiate measurements in response
   to a request from the measurement system.
 
   OR
 
   The operator really wants to understand the end-to-end service
   experience. However, the home network (Ethernet, WiFi, powerline) is
   highly variable and outside its control. To date, operators (and
   regulators) have instead measured performance from the home gateway.
   However, mobile operators clearly must include the wireless link in
   the measurement. 
 
   OR
 
   The operator would like the
   end-to-end view of the service, rather than (say) just the access
   portion
 

So, I've been wondering whether this end-user triggered measurement was in scope or not.
I only found my answer in the conclusion section

   There are
   other use cases that are not the focus of the initial LMAP charter
   (although it is expected that the mechanisms developed would be
   readily applied), for example end users would like to use
   measurements to help identify problems in their home network and to
   monitor the performance of their broadband provider.

You should make it very clear, upfront, that the end-user triggered measurement is not in scope.
Something like section 5.6.1 End-user-controlled measurement system in the framework document

Suggest changing S1 Introduction

OLD

   This document describes two use cases for the Large-scale Measurement

   of Broadband Performance (LMAP), in particular use cases for ISPs and

   regulators.  Although there are many other use cases for large-scale

   measurements systems, the two described here are the consensus

   starting point for defining the system.

NEW

   This document describes two use cases for the Large-scale Measurement

   of Broadband Performance (LMAP). Firstly, to enable network operators to understand the performance of the network and the quality experienced by customers. Secondly, to enable regulators to provide information on the performance of the ISPs in their jurisdiction. There are other use cases that are not the focus of the initial LMAP work, for example end users would like to use measurements to help identify problems in their home network and to monitor the performance of their broadband provider; it is expected that the same mechanisms are applicable.

 


- Section 3.1 

   Operators want to understand the quality of experience (QoE) of their
   broadband customers.

There is a QoE reference in RFC 5481

 

I don’t understand this comment, sorry. I couldn’t find “QoE” in RFC5481



- Section 3.5

   One example was described in [IETF85-Plenary]. The operator was
   running a measurement panel for reasons discussed in sub use case #1.

Should we all review [IETF85-Plenary] to understand what sub use case # 1 is? ;-)

This meant sub use case #1 in draft-lmap-use-cases. However, I think the current text can be improved.

 

OLD

   One example was described in [IETF85-Plenary]. The operator was

   running a measurement panel for reasons discussed in sub use case #1.

   It was noticed that the performance of some lines had unexpectedly

   degraded. This led to a detailed (off-line) investigation which

   discovered that a particular home gateway upgrade had caused a

   (mistaken!) drop in line rate.

 

   Another example is that occasionally some internal network management

   event (like re-routing) can be customer-affecting (of course this is

   unusual). This affects a whole group of customers, for instance those

   on the same DSLAM. Understanding this will help an operator fix the

   fault more rapidly and/or allow the affected customers to be informed

   what's happening and/or request them to re-set their home hub

   (required to cure some conditions). More accurate information enables

   the operator to reassure customers and take more rapid and effective

   action to cure the problem.

 

   There may also be problems unique to a single user line (e.g. copper

   access) that need to be identified.

 

NEW

 

An operator can obtain useful information without measuring the performance on every broadband line. By measuring a subset, the operator identify problems that affect a group of customers. For example, the issue could be at a shared point in the network topology (such as an exchange) or common to a vendor or equipment type ([IETF85-Plenary] describes a case where a particular home gateway upgrade had caused a (mistaken!) drop in line rate). A more extensive deployment of the measurement capability to every broadband line would enable an operator to identify issues unique to a single customer. Overall, large-scale measurements can help an operator help an operator fix the fault more rapidly and/or allow the affected customers to be informed what's happening. More accurate information enables the operator to reassure customers and take more rapid and effective action to cure the problem.

 

 


- Section 4.1

   The published information needs to be:
 
      o  Accurate - the measurement results must be correct and not
      influenced by errors or side effects. The results should be
      reproducible and consistent over time.
 
      o  Comparable - common metrics should be used across different
      ISPs and service offerings so that measurement results can be
      compared.
 
      o  Meaningful - the metrics used for measurements need to reflect
      what end users value about their broadband Internet access service
 
      o  Reliable - the number and distribution of measurement agents,
      and the statistical processing of the raw measurement raw data,
      needs to be appropriate


Not sure if this was discussed, but one goal behind the regulator use case is to strongly suggest the ISPs to use the same metrics in their SLC (Service Level Contracts).
If you ever tried to compare SLC between ISPs, well, go luck.
This would be a nice additional 4.x section

Rather than a new section, I suggest an additional sentence in the 2nd para of S4.1:

NEW

   End users need effective transparency to be able to make informed

   choices throughout the different stages of their relationship with

   ISPs, when selecting Internet access service offers, and when

   considering switching service offer within an ISP or to an

   alternative ISP. Quality information about service offers could

   include speed, delay, and jitter. Regulators can publish such

   information to facilitate end users' choice of service provider and

   offer. It may also encourage ISPs to use the same metrics in their service level contracts, which would further help end users to choose an ISP. Finally, transparency may help content, application, service and device

   providers develop their Internet offerings.

 



- Pervasive Monitoring, RFC 7528. This RFC should at least be referenced, for example around this sentence:

   The other approach is passive measurements
   on the customer's ordinary traffic; the advantage is that it measures
   what the customer actually does, but it creates extra variability
   (different traffic mixes give different results) and especially it
   raises privacy concerns.

 

Do you mean RFC6973? (Privacy Considerations for Internet Protocols)

NEW

   The other approach is passive measurements
   on the customer's ordinary traffic; the advantage is that it measures
   what the customer actually does, but it creates extra variability
   (different traffic mixes give different results) and especially it
   raises privacy concerns. [RFC6973] discusses privacy considerations for Internet protocols in general, whilst [framework] discusses them specifically for large-scale measurement systems.

 

And add to references:

 

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,

              Morris, J., Hansen, M., and R. Smith, "Privacy

              Considerations for Internet Protocols", RFC 6973, July

              2013.

 

 

 

Regards, Benoit

 

--

Nits spotted:

S2.2

Programs /programmes (twice)

 

S2.2, end of penultimate paragraph is missing a full stop.

 

S3.5 Large scale measurements can help provide a more nuance view that

è  Large-scale measurements can help provide a more nuanced view that

 

S4.3 take away for LMAP purposes are that policy-makers are looking for

è  take-away for LMAP purposes is that policy-makers are looking for



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

--------------060904000807090007020009-- From nobody Sun Sep 14 15:38: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 B98B51A03D0 for ; Sun, 14 Sep 2014 15:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.253 X-Spam-Level: X-Spam-Status: No, score=-14.253 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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=-1.652, 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 WZRTLrDp4oKS for ; Sun, 14 Sep 2014 15:38:47 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B421A03CB for ; Sun, 14 Sep 2014 15:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=86959; q=dns/txt; s=iport; t=1410734326; x=1411943926; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=zNqY/6PFb2cISoxDE8+lGEu7CuJkveA4uhvWYfKNMSc=; b=ELD5Q+ZmuPj1lw/jxVzM1MelNRQrColaOE6hYy66tShR/eMPSNLM/vav HP7kfT8MRWOiD5dmsIxwmXO+EO2sn+DOY2aHmUllJiOjaujZ1gy//gQng lHVxtj8DwLPxETWfzf09B6+H3aNzqXUv+2+KqPD1U8TAtjRPAbwDXTT1/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIFAGAYFlStJssW/2dsb2JhbABZB4NgWIhWwQOHTgGBHniEBAEBAwEaAQxNBAYLGwIPFgEBDQkDAgECATcOBgoDCAEBiDIIDbh8AReOfwUBT4RLAQSGH4kYhk2CPYF2glGBOCeFaIR/iHmDYDuBNQEfA4EhAQEB X-IronPort-AV: E=Sophos;i="5.04,523,1406592000"; d="scan'208,217";a="178083380" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 14 Sep 2014 22:38:42 +0000 Received: from [10.61.95.148] (ams3-vpn-dhcp8085.cisco.com [10.61.95.148]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8EMcWvL031919 for ; Sun, 14 Sep 2014 22:38:32 GMT Message-ID: <541618E8.3060200@cisco.com> Date: Mon, 15 Sep 2014 00:38:32 +0200 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" References: <5416090C.5070402@cisco.com> In-Reply-To: <5416090C.5070402@cisco.com> Content-Type: multipart/alternative; boundary="------------050003000807060502020505" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/DP-bb37lB_9dpJAiSsv6TeJNo7o Subject: [lmap] Feedback on draft-ietf-lmap-information-model X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 22:38:54 -0000 This is a multi-part message in MIME format. --------------050003000807060502020505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Since we will be spending time on draft-ietf-lmap-information-model tomorrow, here is some more feedback. I haven't had the time to review it all, so here is part 1. If some points were already discussed, don't hesitate to let me know. > Network Working Group T. Burbridge > Internet-Draft P. Eardley > Intended status: Standards Track BT > Expires: February 21, 2015 M. Bagnulo > Universidad Carlos III de Madrid > J. Schoenwaelder > Jacobs University Bremen > August 20, 2014 > > > Information Model for Large-Scale Measurement Platforms (LMAP) > draft-ietf-lmap-information-model-02 What does LMAP stand for? In the use cases draft, it says "Large-scale Measurement of Broadband Performance (LMAP)" Both the framework and the information model say: Large-Scale Measurement Platforms (LMAP) > > Abstract > > This Information Model applies to the Measurement Agent within a > Large-Scale Measurement Platform. As such it outlines the > information that is (pre-)configured on the MA or exists in > communications with a Controller or Collector within an LMAP > framework. The purpose of such an Information Model is to provide a > protocol and device independent view of the MA that can be > implemented via one or more Control and Report protocols. > > Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on February 21, 2015. > > > > > > > Burbridge, et al. Expires February 21, 2015 [Page 1] > > Internet-Draft LMAP Information Model August 2014 > > > Copyright Notice > > Copyright (c) 2014 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. LMAP Information Model . . . . . . . . . . . . . . . . . . . 4 > 3.1. Information Structure . . . . . . . . . . . . . . . . . . 4 > 3.2. Pre-Configuration Information . . . . . . . . . . . . . . 8 > 3.3. Configuration Information . . . . . . . . . . . . . . . . 9 > 3.4. Instruction Information . . . . . . . . . . . . . . . . . 11 > 3.5. Logging Information . . . . . . . . . . . . . . . . . . . 13 > 3.6. Capability and Status Information . . . . . . . . . . . . 15 > 3.7. Reporting Information . . . . . . . . . . . . . . . . . . 17 > 3.8. Schedules . . . . . . . . . . . . . . . . . . . . . . . . 18 > 3.9. Channels . . . . . . . . . . . . . . . . . . . . . . . . 21 > 3.10. Task Configurations . . . . . . . . . . . . . . . . . . . 22 > 3.11. Timing Information . . . . . . . . . . . . . . . . . . . 23 > 3.11.1. Periodic Timing . . . . . . . . . . . . . . . . . . 24 > 3.11.2. Calendar Timing . . . . . . . . . . . . . . . . . . 25 > 3.11.3. One-Off Timing . . . . . . . . . . . . . . . . . . . 26 > 3.11.4. Immediate Timing . . . . . . . . . . . . . . . . . . 26 > 3.11.5. Startup Timing . . . . . . . . . . . . . . . . . . . 26 > 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 > 6. Appendix: JSON Example . . . . . . . . . . . . . . . . . . . 27 > 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 > 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 > 8.1. Normative References . . . . . . . . . . . . . . . . . . 35 > 8.2. Informative References . . . . . . . . . . . . . . . . . 35 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 > > > > > > > > Burbridge, et al. Expires February 21, 2015 [Page 2] > > Internet-Draft LMAP Information Model August 2014 > > > 1. Introduction > > A large-scale measurement platform is a collection of components that > work in a coordinated fashion to perform measurements from a large > number of vantage points. The main components of a large-scale > measurement platform are the Measurement Agents (hereafter MAs), the > Controller(s) and the Collector(s). > > The MAs are the elements actually performing the measurements. The > MAs are controlled by exactly one Controller at a time and the > Collectors gather the results generated by the MAs. In a nutshell, > the normal operation of a large-scale measurement platform starts > with the Controller instructing a set of one or more MAs to perform a > set of one or more Measurement Tasks at a certain point in time. The > MAs execute the instructions from a Controller, and once they have > done so, they report the results of the measurements to one or more > Collectors. The overall framework for a Large Measurement platform > as used in this document is described in detail in > [I-D.ietf-lmap-framework]. > > A large-scale measurement platform involves basically three > protocols, namely, a Control protocol between a Controller and the Control Protocol > MAs, a Report protocol between the MAs and the Collector(s) and > several measurement protocols between the MAs and Measurement Peers > (MPs), used to actually perform the measurements. In addition some > information is required to be configured on the MA prior to any > communication with the initial Controller. "initial" confused me. It's only later (section 3.3) that I understood that the Controller could be changed. Candidate for removal, improvement, or forward reference? > > This document defines the information model for both the Control and > the Report protocol along with pre-configuration information that is > required add "on the MA" > before communicating with the Controller, broadly named as > the LMAP Information Model. The measurement protocols are out of the > scope of this document. > > As defined in [RFC3444], the LMAP IM defines the concepts involved in IM = Information Model this is the first occurrence. > a large-scale measurement platform at a high level of abstraction, > independent of any specific implementation or actual protocol used to > exchange the information. It is expected that the proposed > information model can be used with different protocols in different > measurement platform architectures and across different types of MA > devices (e.g., home gateway, smartphone, PC, router). > > The definition of an Information Model serves a number of purposes: > > 1. To guide the standardisation of one or more Control and Report > protocol and data model implementations > > > > > > Burbridge, et al. Expires February 21, 2015 [Page 3] > > Internet-Draft LMAP Information Model August 2014 > > > 2. To enable high-level inter-operability between different Control > and Report protocols by facilitating translation between their > respective data models such that a Controller could instruct sub- > populations of MAs using different protocols > > 3. To form agreement of what information needs to be held by an MA > and passed over the Control and Report interfaces and support the > functionality described in the LMAP framework > > 4. Enable existing protocols and data models to be assessed for > their suitability as part of a large-scale measurement system > > 2. Notation > > This document use an object-oriented programming-like notation to > define the parameters (names/values) of the objects of the > information model. An optional field is enclosed by [ ], and an > array is indicated by two numbers in angle brackets, , where m > indicates the minimal number of values, and n is the maximum. The > symbol * for n means no upper bound. > > 3. LMAP Information Model > > 3.1. Information Structure > > The information described herein relates to the information stored, > received or transmitted by a Measurement Agent as described within > the LMAP framework [I-D.ietf-lmap-framework]. Should the framework be normative? I believe so, specifically when I see all those Capitalized terms that are only defined in the framework. This leads to another point. You miss a terminology section because some terms are specific to this document. Example: Task Suppression. > As such, some subsets > of this information model are applicable to the measurement > Controller, Collector add a "," Otherwise we can believe that the Collector could pre-configure the MA. > and systems that pre-configure the Measurement > Agent. The information described in these models will be transmitted > by protocols using interfaces between the Measurement Agent and such > systems according to a Data Model. > > For clarity the information model is divided into six sections: > > 1. Pre-Configuration Information. Information pre-configured on the > Measurement Agent prior to any communication with other > components of the LMAP architecture (i.e., the Controller, > Collector and Measurement Peers), specifically detailing how to > communicate with a Controller and whether the device is enabled > to participate as an MA. > > 2. Configuration Information. Update of the pre-configuration > information during the registration of the MA or subsequent > communication with the Controller, along with the configuration > of further parameters about the MA (rather than the Tasks it > > > > > Burbridge, et al. Expires February 21, 2015 [Page 4] > > Internet-Draft LMAP Information Model August 2014 > > > should perform) that were not mandatory for the initial > communication between the MA and a Controller. > > 3. Instruction Information. Information that is received by the MA > from the Controller pertaining to the Tasks that should be > executed. This includes the task execution Schedules (other than > the Controller communication Schedule supplied as > (pre)configuration information) and related information such as > the Task Configuration, communication Channels to Collectors and > schedule Timing information. It also inlcudes Task Suppression > information that is used to over-ride normal Task execution > during emergency situations. > > 4. Logging Information. Information transmitted from the MA to the > Controller detailing the results of any configuration operations > along with error and status information from the operation of the > MA. > > 5. Capability and Status Information. Information on the general > status and capabilities of the MA. For example, the set of > measurements that are supported on the device. > > 6. Reporting Information. Information transmitted from the MA to > one or more Collectors including measurement results and the > context in which they were conducted. > > In addition the MA may hold further information not described herein, > and which may be optionally transferred to or from other systems > including the Controller and Collector. One example of information > in this category is subscriber or line information that may be > extracted by a task and reported by the MA in the reporting > communication to a Collector. > > It should also be noted that the MA may be in communication with The "MA" or the "MA device"? I'm asking because the rest of the sentence speaks about "configuring", and we said that MA can only be configured by one and only one Controller. > other management systems which may be responsible for configuring and > retrieving information from the MA device. Such systems, where > available, can perform an important role in transferring the pre- > configuration information to the MA or enabling/disabling the > measurement functionality of the MA. "such systemS" ... "enabling/disabling the measurement functionality of the MA." This is not possible. See my previous point. > > The Information Model is divided into sub-sections for a number of > reasons. Firstly the grouping of information facilitates reader > understanding. Secondly, the particular groupings chosen are > expected to map to different protocols or different transmissions > within those protocols. > > The granularity of data transmitted in each operation of the Control > and Report Protocols is not dictated by the Information Model. For > > > > Burbridge, et al. Expires February 21, 2015 [Page 5] > > Internet-Draft LMAP Information Model August 2014 > > > example, the Instruction object may be delivered in a single > operation. Alternatively, Schedules and Task Configurations may be > separated or even each Schdule/Task Configuration may be delivered > individually. Similarly the Information Model does not dictate > whether data is read, write, or read/write. For example, some > Control Protocols may have the ability to read back Configuration and > Instruction information which have been previosuly set on the MA. > Lastly, while some protocols may simply overwrite information (for > example refreshing the entire Instruction Information), other > protocols may have the ability to update or delete selected items of > information. > > The information in these six sections is captured by a number of > common information objects. These objects are also described later > in this document and comprise of: > > 1. Schedules. A set of Schedules tell the MA to do something. > Without a Schedule no Task (from a measurement to reporting or > communicating with the Controller) is ever executed. Schedules > are used within the Instruction to specify what tasks should be > performed, when, and how to direct their results. A Schedule is > also used within the pre-Configuration and Configuration > information in order to execute the Task or Tasks required to > communicate with the Controller. > > 2. Channels. A set of Channel objects are used to communicate with > a number of endpoints (i.e. the Controller and Collectors). OLD: (i.e. the Controller and Collectors). NEW: (the Controller, Collectors, and MAs). These are the only 3 possibilities, right? Logging always goes to the Collector, right? > Each > Channel object contains the information required for the > communication with a single endpoint such as the target location > and security details. Channels are referenced from within > Schedules in order to say how Tasks should communicate. > > 3. Task Configurations. A set of Task Configurations is used to > configure the Tasks that are run by the MA. This includes the > registry entry for the Task and any configuration parameters. > Task Configurations are referenced from a Schedule in order to > specify what Tasks the MA should execute. > > 4. Timings. A set of Timing objects that can be referenced from the > Schedules. Each Schedule always references exactly one Timing > object. A Timing object specfies either a singleton or series of > time events. They are used to indicate when Tasks should be > executed. > > The following diagram illustrates the structure in which these common > information objects are referenced. The references are achieved by > each object (Channel, Task Configuration, Timing) being given a short > > > > > Burbridge, et al. Expires February 21, 2015 [Page 6] > > Internet-Draft LMAP Information Model August 2014 > > > text name that is used by other objects. The objects shown in > parenthesis are part of the internal object structure of a Schedule. > > Schedule > |----------> Timing > |----------> (Scheduled Tasks) > |----------> Task Configuration > |----------> (Task Channels and > downstream Tasks) > |----------> Channels > |----------> Downstream Tasks Please number the figures. Why is only "configuration" mentioned in the figure? I understood that everything is now a task: controller communication reporting measurement data aggregation ... This was confusing to me. > > It should be clear that the top-level bahaviour of an MA is simply to > execute Schedules. Every action referenced by a Schedule is defined > as a Task. As such, these actions are configured through Task > Configurations and executed according to the Timing referenced by the > Schedule in which they appear. Tasks can implement a variety of > different types of actions. While in terms of the Information Model, > all Tasks have the same structure, it can help conceptually to think > of different Task categories: > > 1. Measurement Tasks > > A. Measurement Tasks measure some aspect of network performance > or traffic > > B. Data Capture Tasks capture and analyse passive information Why capture? We can analyse without capture. > stored on the MA device such as counters and device/network > status information Why not traffic? From 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 > > 2. Data Transfer Tasks > > A. Reporting Tasks report the results or Measurement Tasks to > Collectors "Reporting Tasks report Measurement Tasks to Collectors" Really? So the Controller configures the Reporting Tasks on the MA, and the MA reports them to the Collector? Maybe you meant? A. Reporting Tasks report the results _of _Measurement Tasks to Collectors > > B. Control Task(s) implement the Control Protocol and > communicate with the Controller. Depending on the Control > Protocol this may be a number of specialist tasks such as: What is "this"? > Configuration Task; Instruction Task; Suppression Task; > Capabilities Task; Logging Task etc. > > 3. Data Analysis Tasks can exist to analyse data from other > Measurement Tasks locally on the MA > > 4. Data Management Tasks may exist to clean-up, filter or compress > data on the MA such as Measurement Task results > > > > > > > Burbridge, et al. Expires February 21, 2015 [Page 7] > > Internet-Draft LMAP Information Model August 2014 > > > 3.2. Pre-Configuration Information > > This information is the minimal information that needs to be pre- > configured to the MA in order for it to successfully communicate with > a Controller during the registration process. In section 3.1, we learned: 1. Pre-Configuration Information. Information pre-configured on the Measurement Agent prior to any communication with other components of the LMAP architecture (i.e., the Controller, Collector and Measurement Peers), specifically detailing how to communicate with a Controller and whether the device is enabled to participate as an MA. So the pre-configuration information is only for the Controller communication (I guess so) or also for the collector and measurement peers? > The pre-configuration > information is a subset of the Configuration Information along with > some parameters that are not under the control of the LMAP framework > (such as the the device identifier and device security credentials). I can't parse "not under the control of the LMAP framework" > > This pre-configuration information needs to include a URL of the > initial Controller where configuration information can be retrieved OLD: retrieved NEW: communicated NEW (alternative): pulled or pushed Justification: the next paragraphs make the distinction. > along with the security information required for the communication > including the certificate of the Controller (or the certificate of > the Certification Authority which was used to issue the certificate > for the Controller). All this is expressed as a Channel. While > multiple Channels may be provided in the pre-configuration > information they must all be associated with a single Controller > (e.g. over different interfaces or network protocols). > > Where the MA pulls information from the Controller, the Pre- > Configuration Information also needs to contain the timing of the > communication with the Controller as well as the nature of the > communication itself (such as the protocol and data to be > transfered). The timing is given as a Schedule that executes the > Task(s) responsible for communication with the Controller. It is > this Task (or Tasks) that implement the Control protocol between the > MA and the Controller. The Task(s) may take additional parameters in > which case a Task Configuration can also be included. > > Even where information is pushed to the MA from the Controller > (rather than pulled by the MA), a Schedule still needs to be > supplied. In this case the Schedule will simply execute a Controller > listener task when the MA is started. A Channel is still required > for the MA to establish secure communication with the Controller. > > It can be seen that these Channels, Schedules and Task Configurations > for the initial MA-Controller communication are no different in terms > of the Information Model to any other Channel, Schedule or Task > Configuration that might execute a Measurement Task or report the > measurement results (as described later). > > The MA may be pre-configured with an MA ID, or may use a Device ID in > the initial Controller contact before it is assigned an MA ID. Again, I'm confused by this initial Controller. > The > Device ID may be a MAC address or some other device identifier > expressed as a URN. If the MA ID is not provided at this stage then > it must be provided by the Controller during Configuration. > > Detail of the information model elements: > > > > Burbridge, et al. Expires February 21, 2015 [Page 8] > > Internet-Draft LMAP Information Model August 2014 > > > // MA pre-configuration minimal information to communicate initially > with Controller > > object { > [uuid ma-agent-id;] > ma-task-obj ma-control-tasks<1..*>; > ma-channel-obj ma-control-channels<1..*>; > ma-schedule-obj ma-control-schedules<1..*>; > [urn ma-device-id;] > credentials ma-credentials; > } ma-config-obj; > > The detail of the Channel and Schedule objects are described later > since they are common to several parts of the information model. > > 3.3. Configuration Information > > During registration or at any later point at which the MA contacts > the Controller (or vice-versa), the choice of Controller, "The choice of Controller", do you want to say "an alternate Controller", because at this point the MA is already in contact with the Controller. > details for > the timing of communication with the Controller or parameters for the > communication Task(s) can be changed (as captured by the Channels, > Schedules and Task Configurations objects). For example the pre- > configured Controller (specified as a Channel or Channels) may be > replaced with a specific Controller that is more appropriate to the > MA device type, location or characteristics of the network (e.g. > access technology type or broadband product). The initial > communication Schedule may be replaced with one more relevant to > routine communications between the MA and the Controller. > > While some Control protocols and uses may only use a single Schedule, > other protocols and uses may uses several Schedules (and related data > transfer Tasks) to update the Configuration Information, transfer the > Instruction Information, transfer Capability and Status Information > and send other information to the Controller such as log or error > notifications. Multiple Channels may be used to communicate with the > same Controller over multiple interfaces (e.g. to send logging > information over a different network). > > In addition the MA will be given further items of information that > relate specifically to the MA rather than the measurements it is to > conduct or how to report results. The assignment of an ID to the MA > is mandatory. If the MA Agent ID was not optionally provided during > the pre-configuration then one must be provided by the Controller > during Configuration. Optionally a Group ID may also be given which > identifies a group of interest to which that MA belongs. For example > the group could represent an ISP, broadband product, technology, > market classification, geographic region, or a combination of > multiple such characteristics. Where the Measurement Group ID is set > an additional flag (the Report MA ID flag) is required to control > > > > Burbridge, et al. Expires February 21, 2015 [Page 9] > > Internet-Draft LMAP Information Model August 2014 > > > whether the Measurement Agent ID is also to be reported. The > reporting of a Group ID without the MA ID allows the MA to remain > anonymous, which may be particularly useful to prevent tracking of > mobile MA devices. > > Optionally an MA can also be configured to stop executing any > Instruction Schedule if the Controller is unreachable. This can be > used as a fail-safe to stop Measurement and other Tasks being > conducted when there is doubt that the Instruction Information is > still valid. This is simply represented as a time window in > milliseconds since the last communication with the Controller after > which Instruction Schedules are to be suspended. The appropriate > vaue of the time window will depend on the specified communication value > Schedule with the Controller and the duration for which the system is > willing to tolerate continued operation with potentially stale > Instruction Information. > > While pre-configuration is persistent upon device reset or power > cycle due to its very nature, the persistency of the addtional > configuration information may be control protocol dependent. Why "Control Protocol" dependent? Why isn't the persistence IM (or DM) specific? > Some > protocols may assume that reset devices will revert back to their > pre-configuration state, while other protocols may assume that all > configuration and instruction information is held in persistent > storage. > > It should be noted that control shedules and tasks cannot be > suppressed as evidenced by the lack of suppression information in the > Configuration. The control schedule must only reference tasks listed > as control tasks. Any suppress-by-default flag against control tasks > will be ignored. > > Detail of the additional and updated information model elements: > > // MA Configuration > > object { > uuid ma-agent-id; > [ma-task-obj ma-control-tasks<0..*>;] > ma-channel-obj ma-control-channels<1..*>; > [ma-schedule-obj ma-control-schedules<0..*>]; > [urn ma-device-id;] > credentials ma-credentials; > [string ma-group-id;] > [boolean ma-report-ma-id-flag;] > [int ma-control-channel-failure-threshold;] > } ma-config-obj; > > That's where I arrived. And now, time for a Guinness or two. I'm in Dublin after all :-) Regards, Benoit --------------050003000807060502020505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Since we will be spending time on draft-ietf-lmap-information-model tomorrow, here is some more feedback. I haven't had the time to review it all, so here is part 1.
If some points were already discussed, don't hesitate to let me know.

Network Working Group                                       T. Burbridge
Internet-Draft                                                P. Eardley
Intended status: Standards Track                                      BT
Expires: February 21, 2015                                    M. Bagnulo
                                        Universidad Carlos III de Madrid
                                                        J. Schoenwaelder
                                                Jacobs University Bremen
                                                         August 20, 2014


     Information Model for Large-Scale Measurement Platforms (LMAP)
                  draft-ietf-lmap-information-model-02
What does LMAP stand for?
In the use cases draft, it says "Large-scale Measurement of Broadband Performance (LMAP)"
Both the framework and the information model say: Large-Scale Measurement Platforms (LMAP)


Abstract

   This Information Model applies to the Measurement Agent within a
   Large-Scale Measurement Platform.  As such it outlines the
   information that is (pre-)configured on the MA or exists in
   communications with a Controller or Collector within an LMAP
   framework.  The purpose of such an Information Model is to provide a
   protocol and device independent view of the MA that can be
   implemented via one or more Control and Report protocols.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 21, 2015.






Burbridge, et al.       Expires February 21, 2015               [Page 1]

Internet-Draft           LMAP Information Model              August 2014


Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Notation  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  LMAP Information Model  . . . . . . . . . . . . . . . . . . .   4
     3.1.  Information Structure . . . . . . . . . . . . . . . . . .   4
     3.2.  Pre-Configuration Information . . . . . . . . . . . . . .   8
     3.3.  Configuration Information . . . . . . . . . . . . . . . .   9
     3.4.  Instruction Information . . . . . . . . . . . . . . . . .  11
     3.5.  Logging Information . . . . . . . . . . . . . . . . . . .  13
     3.6.  Capability and Status Information . . . . . . . . . . . .  15
     3.7.  Reporting Information . . . . . . . . . . . . . . . . . .  17
     3.8.  Schedules . . . . . . . . . . . . . . . . . . . . . . . .  18
     3.9.  Channels  . . . . . . . . . . . . . . . . . . . . . . . .  21
     3.10. Task Configurations . . . . . . . . . . . . . . . . . . .  22
     3.11. Timing Information  . . . . . . . . . . . . . . . . . . .  23
       3.11.1.  Periodic Timing  . . . . . . . . . . . . . . . . . .  24
       3.11.2.  Calendar Timing  . . . . . . . . . . . . . . . . . .  25
       3.11.3.  One-Off Timing . . . . . . . . . . . . . . . . . . .  26
       3.11.4.  Immediate Timing . . . . . . . . . . . . . . . . . .  26
       3.11.5.  Startup Timing . . . . . . . . . . . . . . . . . . .  26
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
   6.  Appendix: JSON Example  . . . . . . . . . . . . . . . . . . .  27
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  35
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  35
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  35
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35







Burbridge, et al.       Expires February 21, 2015               [Page 2]

Internet-Draft           LMAP Information Model              August 2014


1.  Introduction

   A large-scale measurement platform is a collection of components that
   work in a coordinated fashion to perform measurements from a large
   number of vantage points.  The main components of a large-scale
   measurement platform are the Measurement Agents (hereafter MAs), the
   Controller(s) and the Collector(s).

   The MAs are the elements actually performing the measurements.  The
   MAs are controlled by exactly one Controller at a time and the
   Collectors gather the results generated by the MAs.  In a nutshell,
   the normal operation of a large-scale measurement platform starts
   with the Controller instructing a set of one or more MAs to perform a
   set of one or more Measurement Tasks at a certain point in time.  The
   MAs execute the instructions from a Controller, and once they have
   done so, they report the results of the measurements to one or more
   Collectors.  The overall framework for a Large Measurement platform
   as used in this document is described in detail in
   [I-D.ietf-lmap-framework].

   A large-scale measurement platform involves basically three
   protocols, namely, a Control protocol between a Controller and the
Control Protocol
   MAs, a Report protocol between the MAs and the Collector(s) and
   several measurement protocols between the MAs and Measurement Peers
   (MPs), used to actually perform the measurements.  In addition some
   information is required to be configured on the MA prior to any
   communication with the initial Controller.
"initial" confused me.
It's only later (section 3.3) that I understood that the Controller could be changed.
Candidate for removal, improvement, or forward reference?

   This document defines the information model for both the Control and
   the Report protocol along with pre-configuration information that is
   required
add "on the MA"
before communicating with the Controller, broadly named as
   the LMAP Information Model.  The measurement protocols are out of the
   scope of this document.

   As defined in [RFC3444], the LMAP IM defines the concepts involved in
IM = Information Model
this is the first occurrence.

   a large-scale measurement platform at a high level of abstraction,
   independent of any specific implementation or actual protocol used to
   exchange the information.  It is expected that the proposed
   information model can be used with different protocols in different
   measurement platform architectures and across different types of MA
   devices (e.g., home gateway, smartphone, PC, router).

   The definition of an Information Model serves a number of purposes:

   1.  To guide the standardisation of one or more Control and Report
       protocol and data model implementations





Burbridge, et al.       Expires February 21, 2015               [Page 3]

Internet-Draft           LMAP Information Model              August 2014


   2.  To enable high-level inter-operability between different Control
       and Report protocols by facilitating translation between their
       respective data models such that a Controller could instruct sub-
       populations of MAs using different protocols

   3.  To form agreement of what information needs to be held by an MA
       and passed over the Control and Report interfaces and support the
       functionality described in the LMAP framework

   4.  Enable existing protocols and data models to be assessed for
       their suitability as part of a large-scale measurement system

2.  Notation

   This document use an object-oriented programming-like notation to
   define the parameters (names/values) of the objects of the
   information model.  An optional field is enclosed by [ ], and an
   array is indicated by two numbers in angle brackets, <m..n>, where m
   indicates the minimal number of values, and n is the maximum.  The
   symbol * for n means no upper bound.

3.  LMAP Information Model

3.1.  Information Structure

   The information described herein relates to the information stored,
   received or transmitted by a Measurement Agent as described within
   the LMAP framework [I-D.ietf-lmap-framework]. 
Should the framework be normative? I believe so, specifically when I see all those Capitalized terms that are only defined in the framework.
This leads to another point. You miss a terminology section because some terms are specific to this document. Example: Task Suppression.
As such, some subsets
   of this information model are applicable to the measurement
   Controller, Collector
add a ","
Otherwise we can believe that the Collector could pre-configure the MA.
and systems that pre-configure the Measurement
   Agent.  The information described in these models will be transmitted
   by protocols using interfaces between the Measurement Agent and such
   systems according to a Data Model.

   For clarity the information model is divided into six sections:

   1.  Pre-Configuration Information.  Information pre-configured on the
       Measurement Agent prior to any communication with other
       components of the LMAP architecture (i.e., the Controller,
       Collector and Measurement Peers), specifically detailing how to
       communicate with a Controller and whether the device is enabled
       to participate as an MA.

   2.  Configuration Information.  Update of the pre-configuration
       information during the registration of the MA or subsequent
       communication with the Controller, along with the configuration
       of further parameters about the MA (rather than the Tasks it




Burbridge, et al.       Expires February 21, 2015               [Page 4]

Internet-Draft           LMAP Information Model              August 2014


       should perform) that were not mandatory for the initial
       communication between the MA and a Controller.

   3.  Instruction Information.  Information that is received by the MA
       from the Controller pertaining to the Tasks that should be
       executed.  This includes the task execution Schedules (other than
       the Controller communication Schedule supplied as
       (pre)configuration information) and related information such as
       the Task Configuration, communication Channels to Collectors and
       schedule Timing information.  It also inlcudes Task Suppression
       information that is used to over-ride normal Task execution
       during emergency situations.

   4.  Logging Information.  Information transmitted from the MA to the
       Controller detailing the results of any configuration operations
       along with error and status information from the operation of the
       MA.

   5.  Capability and Status Information.  Information on the general
       status and capabilities of the MA.  For example, the set of
       measurements that are supported on the device.

   6.  Reporting Information.  Information transmitted from the MA to
       one or more Collectors including measurement results and the
       context in which they were conducted.

   In addition the MA may hold further information not described herein,
   and which may be optionally transferred to or from other systems
   including the Controller and Collector.  One example of information
   in this category is subscriber or line information that may be
   extracted by a task and reported by the MA in the reporting
   communication to a Collector.

   It should also be noted that the MA may be in communication with
The "MA" or the "MA device"?
I'm asking because the rest of the sentence speaks about "configuring", and we said that MA can only be configured by one and only one Controller.
   other management systems which may be responsible for configuring and
   retrieving information from the MA device.  Such systems, where
   available, can perform an important role in transferring the pre-
   configuration information to the MA or enabling/disabling the
   measurement functionality of the MA.
"such systemS" ... "enabling/disabling the measurement functionality of the MA."
This is not possible. See my previous point.

   The Information Model is divided into sub-sections for a number of
   reasons.  Firstly the grouping of information facilitates reader
   understanding.  Secondly, the particular groupings chosen are
   expected to map to different protocols or different transmissions
   within those protocols.

   The granularity of data transmitted in each operation of the Control
   and Report Protocols is not dictated by the Information Model.  For



Burbridge, et al.       Expires February 21, 2015               [Page 5]

Internet-Draft           LMAP Information Model              August 2014


   example, the Instruction object may be delivered in a single
   operation.  Alternatively, Schedules and Task Configurations may be
   separated or even each Schdule/Task Configuration may be delivered
   individually.  Similarly the Information Model does not dictate
   whether data is read, write, or read/write.  For example, some
   Control Protocols may have the ability to read back Configuration and
   Instruction information which have been previosuly set on the MA.
   Lastly, while some protocols may simply overwrite information (for
   example refreshing the entire Instruction Information), other
   protocols may have the ability to update or delete selected items of
   information.

   The information in these six sections is captured by a number of
   common information objects.  These objects are also described later
   in this document and comprise of:

   1.  Schedules.  A set of Schedules tell the MA to do something.
       Without a Schedule no Task (from a measurement to reporting or
       communicating with the Controller) is ever executed.  Schedules
       are used within the Instruction to specify what tasks should be
       performed, when, and how to direct their results.  A Schedule is
       also used within the pre-Configuration and Configuration
       information in order to execute the Task or Tasks required to
       communicate with the Controller.

   2.  Channels.  A set of Channel objects are used to communicate with
       a number of endpoints (i.e. the Controller and Collectors). 
OLD: (i.e. the Controller and Collectors). 
NEW: (the Controller, Collectors, and MAs). 

These are the only 3 possibilities, right?
Logging always goes to the Collector, right?

Each
       Channel object contains the information required for the
       communication with a single endpoint such as the target location
       and security details.  Channels are referenced from within
       Schedules in order to say how Tasks should communicate.

   3.  Task Configurations.  A set of Task Configurations is used to
       configure the Tasks that are run by the MA.  This includes the
       registry entry for the Task and any configuration parameters.
       Task Configurations are referenced from a Schedule in order to
       specify what Tasks the MA should execute.

   4.  Timings.  A set of Timing objects that can be referenced from the
       Schedules.  Each Schedule always references exactly one Timing
       object.  A Timing object specfies either a singleton or series of
       time events.  They are used to indicate when Tasks should be
       executed.

   The following diagram illustrates the structure in which these common
   information objects are referenced.  The references are achieved by
   each object (Channel, Task Configuration, Timing) being given a short




Burbridge, et al.       Expires February 21, 2015               [Page 6]

Internet-Draft           LMAP Information Model              August 2014


   text name that is used by other objects.  The objects shown in
   parenthesis are part of the internal object structure of a Schedule.

          Schedule
              |----------> Timing
              |----------> (Scheduled Tasks)
                                   |----------> Task Configuration
                                   |----------> (Task Channels and downstream Tasks)
                                                      |----------> Channels
                                                      |----------> Downstream Tasks
Please number the figures.

Why is only "configuration" mentioned in the figure?
I understood that everything is now a task:
    controller communication
    reporting
    measurement
    data aggregation
    ...
This was confusing to me.



   It should be clear that the top-level bahaviour of an MA is simply to
   execute Schedules.  Every action referenced by a Schedule is defined
   as a Task.  As such, these actions are configured through Task
   Configurations and executed according to the Timing referenced by the
   Schedule in which they appear.  Tasks can implement a variety of
   different types of actions.  While in terms of the Information Model,
   all Tasks have the same structure, it can help conceptually to think
   of different Task categories:

   1.  Measurement Tasks

       A.  Measurement Tasks measure some aspect of network performance
           or traffic

       B.  Data Capture Tasks capture and analyse passive information
Why capture? We can analyse without capture.
           stored on the MA device such as counters and device/network
           status information

Why not traffic?
From 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


   2.  Data Transfer Tasks

       A.  Reporting Tasks report the results or Measurement Tasks to
           Collectors
"Reporting Tasks report Measurement Tasks to Collectors"
Really? So the Controller configures the Reporting Tasks on the MA, and the MA reports them to the Collector?

Maybe you meant?
       A.  Reporting Tasks report the results of Measurement Tasks to
           Collectors

       B.  Control Task(s) implement the Control Protocol and
           communicate with the Controller.  Depending on the Control
           Protocol this may be a number of specialist tasks such as:
What is "this"?
           Configuration Task; Instruction Task; Suppression Task;
           Capabilities Task; Logging Task etc.

   3.  Data Analysis Tasks can exist to analyse data from other
       Measurement Tasks locally on the MA

   4.  Data Management Tasks may exist to clean-up, filter or compress
       data on the MA such as Measurement Task results






Burbridge, et al.       Expires February 21, 2015               [Page 7]

Internet-Draft           LMAP Information Model              August 2014


3.2.  Pre-Configuration Information

   This information is the minimal information that needs to be pre-
   configured to the MA in order for it to successfully communicate with
   a Controller during the registration process. 
In section 3.1, we learned:
   1.  Pre-Configuration Information.  Information pre-configured on the
       Measurement Agent prior to any communication with other
       components of the LMAP architecture (i.e., the Controller,
       Collector and Measurement Peers), specifically detailing how to
       communicate with a Controller and whether the device is enabled
       to participate as an MA.
So the pre-configuration information is only for the Controller communication (I guess so) or also for the collector and measurement peers?
The pre-configuration
   information is a subset of the Configuration Information along with
   some parameters that are not under the control of the LMAP framework
   (such as the the device identifier and device security credentials).
I can't parse "not under the control of the LMAP framework"

   This pre-configuration information needs to include a URL of the
   initial Controller where configuration information can be retrieved
OLD: retrieved
NEW: communicated
NEW (alternative): pulled or pushed

Justification: the next paragraphs make the distinction.
   along with the security information required for the communication
   including the certificate of the Controller (or the certificate of
   the Certification Authority which was used to issue the certificate
   for the Controller).  All this is expressed as a Channel.  While
   multiple Channels may be provided in the pre-configuration
   information they must all be associated with a single Controller
   (e.g. over different interfaces or network protocols).

   Where the MA pulls information from the Controller, the Pre-
   Configuration Information also needs to contain the timing of the
   communication with the Controller as well as the nature of the
   communication itself (such as the protocol and data to be
   transfered).  The timing is given as a Schedule that executes the
   Task(s) responsible for communication with the Controller.  It is
   this Task (or Tasks) that implement the Control protocol between the
   MA and the Controller.  The Task(s) may take additional parameters in
   which case a Task Configuration can also be included.

   Even where information is pushed to the MA from the Controller
   (rather than pulled by the MA), a Schedule still needs to be
   supplied.  In this case the Schedule will simply execute a Controller
   listener task when the MA is started.  A Channel is still required
   for the MA to establish secure communication with the Controller.

   It can be seen that these Channels, Schedules and Task Configurations
   for the initial MA-Controller communication are no different in terms
   of the Information Model to any other Channel, Schedule or Task
   Configuration that might execute a Measurement Task or report the
   measurement results (as described later).

   The MA may be pre-configured with an MA ID, or may use a Device ID in
   the initial Controller contact before it is assigned an MA ID. 
Again, I'm confused by this initial Controller.  

The
   Device ID may be a MAC address or some other device identifier
   expressed as a URN.  If the MA ID is not provided at this stage then
   it must be provided by the Controller during Configuration.

   Detail of the information model elements:



Burbridge, et al.       Expires February 21, 2015               [Page 8]

Internet-Draft           LMAP Information Model              August 2014


// MA pre-configuration minimal information to communicate initially with Controller

object {
    [uuid                ma-agent-id;]
     ma-task-obj         ma-control-tasks<1..*>;
     ma-channel-obj      ma-control-channels<1..*>;
     ma-schedule-obj     ma-control-schedules<1..*>;
    [urn                 ma-device-id;]
     credentials         ma-credentials;
} ma-config-obj;

   The detail of the Channel and Schedule objects are described later
   since they are common to several parts of the information model.

3.3.  Configuration Information

   During registration or at any later point at which the MA contacts
   the Controller (or vice-versa), the choice of Controller,
"The choice of Controller", do you want to say "an alternate Controller", because at this point the MA is already in contact with the Controller.
details for
   the timing of communication with the Controller or parameters for the
   communication Task(s) can be changed (as captured by the Channels,
   Schedules and Task Configurations objects).  For example the pre-
   configured Controller (specified as a Channel or Channels) may be
   replaced with a specific Controller that is more appropriate to the
   MA device type, location or characteristics of the network (e.g.
   access technology type or broadband product).  The initial
   communication Schedule may be replaced with one more relevant to
   routine communications between the MA and the Controller.

   While some Control protocols and uses may only use a single Schedule,
   other protocols and uses may uses several Schedules (and related data
   transfer Tasks) to update the Configuration Information, transfer the
   Instruction Information, transfer Capability and Status Information
   and send other information to the Controller such as log or error
   notifications.  Multiple Channels may be used to communicate with the
   same Controller over multiple interfaces (e.g. to send logging
   information over a different network).

   In addition the MA will be given further items of information that
   relate specifically to the MA rather than the measurements it is to
   conduct or how to report results.  The assignment of an ID to the MA
   is mandatory.  If the MA Agent ID was not optionally provided during
   the pre-configuration then one must be provided by the Controller
   during Configuration.  Optionally a Group ID may also be given which
   identifies a group of interest to which that MA belongs.  For example
   the group could represent an ISP, broadband product, technology,
   market classification, geographic region, or a combination of
   multiple such characteristics.  Where the Measurement Group ID is set
   an additional flag (the Report MA ID flag) is required to control



Burbridge, et al.       Expires February 21, 2015               [Page 9]

Internet-Draft           LMAP Information Model              August 2014


   whether the Measurement Agent ID is also to be reported.  The
   reporting of a Group ID without the MA ID allows the MA to remain
   anonymous, which may be particularly useful to prevent tracking of
   mobile MA devices.

   Optionally an MA can also be configured to stop executing any
   Instruction Schedule if the Controller is unreachable.  This can be
   used as a fail-safe to stop Measurement and other Tasks being
   conducted when there is doubt that the Instruction Information is
   still valid.  This is simply represented as a time window in
   milliseconds since the last communication with the Controller after
   which Instruction Schedules are to be suspended.  The appropriate
   vaue of the time window will depend on the specified communication
value
   Schedule with the Controller and the duration for which the system is
   willing to tolerate continued operation with potentially stale
   Instruction Information.

   While pre-configuration is persistent upon device reset or power
   cycle due to its very nature, the persistency of the addtional
   configuration information may be control protocol dependent. 
Why "Control Protocol" dependent?
Why isn't the persistence IM (or DM) specific?
Some
   protocols may assume that reset devices will revert back to their
   pre-configuration state, while other protocols may assume that all
   configuration and instruction information is held in persistent
   storage.

   It should be noted that control shedules and tasks cannot be
   suppressed as evidenced by the lack of suppression information in the
   Configuration.  The control schedule must only reference tasks listed
   as control tasks.  Any suppress-by-default flag against control tasks
   will be ignored.

   Detail of the additional and updated information model elements:

   // MA Configuration

   object {
       uuid                ma-agent-id;
      [ma-task-obj         ma-control-tasks<0..*>;]
       ma-channel-obj      ma-control-channels<1..*>;
      [ma-schedule-obj    ma-control-schedules<0..*>];
      [urn                 ma-device-id;]
       credentials         ma-credentials;
      [string              ma-group-id;]
      [boolean             ma-report-ma-id-flag;]
      [int                 ma-control-channel-failure-threshold;]
   } ma-config-obj;


That's where I arrived.

And now, time for a Guinness or two. I'm in Dublin after all :-)

Regards, Benoit

--------------050003000807060502020505-- From nobody Mon Sep 15 04:15: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 905A01A0B08 for ; Mon, 15 Sep 2014 04:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.406 X-Spam-Level: X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 oeLxJwABbO0U for ; Mon, 15 Sep 2014 04:15:16 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 78A111A0ADC for ; Mon, 15 Sep 2014 04:15:10 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,527,1406606400"; d="scan'208,217";a="516534390" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 15 Sep 2014 07:12:43 -0400 Received: from PRVPEXVS06.corp.twcable.com ([10.136.163.32]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 15 Sep 2014 07:15:09 -0400 From: "Weil, Jason" To: "lmap@ietf.org" Date: Mon, 15 Sep 2014 07:15:14 -0400 Thread-Topic: Meeting invitation: LMAP WG Interim Thread-Index: Ac/Q1k+KuuVy9AVmQC6zD2Zyy6/adg== Message-ID: References: <728028476.43839.1407876931696.JavaMail.nobody@jsj2tc501.webex.com> In-Reply-To: <728028476.43839.1407876931696.JavaMail.nobody@jsj2tc501.webex.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D03C413435411jasonweiltwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/CNJwn5F67N3L_ksDpZ-rvtgKEWI Subject: [lmap] FW: Meeting invitation: LMAP WG Interim X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 11:15:18 -0000 --_000_D03C413435411jasonweiltwcablecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, Here is a reminder for the Webex session for today=92s LMAP Interim meeting= that will begin at 14:30 IST, 0930 EST: Hello , Cindy Morgan invites you to attend this online meeting. Topic: LMAP WG Interim Date: Monday, September 15, 2014 Time: 2:30 pm, GMT Summer Time (London, GMT+01:00) Meeting Number: 969 298 120 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?MTID=3Dm60f196749b2a7a= 0ba06a5392b678cc05 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?MTID=3Dmbe7b44c48e8d9a1191da0c7= 2a0b004f8 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): 1-877-668-4490 Call-in toll number (US/Canada): 1-408-792-6300 Access code:969 298 120 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.= php?serviceType=3DMC&ED=3D280436217&tollFree=3D1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 Add this meeting to your calendar program: https://workgreen.webex.com/workgreen/j.php?MTID=3Dm47ec996341f4fa1bdf4c065= 83d229985 The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://workgreen.webex.com/workgreen/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14087926300x969298120# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ________________________________ 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_D03C413435411jasonweiltwcablecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
All,

Here is a reminder for the Webex session for today=92s LMAP Interim me= eting that will begin at 14:30 IST, 0930 EST:

Hello ,

Cindy Morgan invites you to attend this online meeting.

Topic: LMAP WG Interim
Date: Monday, September 15, 2014
Time: 2:30 pm, GMT Summer Time (London, GMT+01:00)
Meeting Number: 969 298 120
Meeting Password: 1234


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://workgreen.webex.com/workgreen/j.php?MTID=3Dm60f196749b2a7a0ba06a539= 2b678cc05
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".

To view in other time zones or languages, please click the link:
https://workgreen.webex.com/workgre= en/j.php?MTID=3Dmbe7b44c48e8d9a1191da0c72a0b004f8

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code.
Call-in toll-free number (US/Canada): 1-877-668-4490
Call-in toll number (US/Canada): 1-408-792-6300

Access code:969 298 120
Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&= ;ED=3D280436217&tollFree=3D1
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://workgreen.webex.com/workgreen/mc
2. On the left navigation bar, click "Support".

You can contact me at:
cmorgan@amsl.com
1-510-492-4085

Add this meeting to your calendar program:
https://workgreen.webex.com/workgre= en/j.php?MTID=3Dm47ec996341f4fa1bdf4c06583d229985

The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https= ://workgreen.webex.com/workgreen/systemdiagnosis.php.

Sign up for a free trial of WebEx
http://= www.webex.com/go/mcemfreetrial

http://www.webex.com=

CCP:+14087926300x969298120#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation.

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_D03C413435411jasonweiltwcablecom_-- From nobody Mon Sep 15 06:41:26 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 8DB741A034E for ; Mon, 15 Sep 2014 06:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, 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 3jLbRCOqr7u6 for ; Mon, 15 Sep 2014 06:41:14 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642821A034D for ; Mon, 15 Sep 2014 06:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=88193; q=dns/txt; s=iport; t=1410788473; x=1411998073; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=3UqBAmNXjkhlJXeFHgqfqtcjrnGrCGiFPr+zGV4FYdU=; b=B14mALnK7wy8uGXjQd7ds4zhzYvcj7wWjeXhLdcsHrKU1z/iFIEUhnxs qLnhR1X0xDzdADBIoRfI/Ng1sFMyZMzT15JLeiVdqfinynGnDMD93lOk0 haS10yxr7fbXnC5txZgKOXmKGrluO/8OOgjTkAkjW3wdmclrovjAiEWy3 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloGAP/rFlStJssW/2dsb2JhbABZB4NgWIhWwhSHTgGBKHiEBAEBAwEaAQxNBBELEAIPFgEBDQkDAgECATcOBgoDCAEBiDIIDbpGAReOfwUBT4RLAQSGH4kYhk2CPYF2glGBOCeFaIR/iHmDYDuBNQEfA4EhAQEB X-IronPort-AV: E=Sophos;i="5.04,528,1406592000"; d="scan'208,217";a="178862835" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 15 Sep 2014 13:41:09 +0000 Received: from [10.61.213.184] ([10.61.213.184]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8FDf98W025480 for ; Mon, 15 Sep 2014 13:41:09 GMT Message-ID: <5416EC74.2040606@cisco.com> Date: Mon, 15 Sep 2014 15:41:08 +0200 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" References: <5416090C.5070402@cisco.com> <541618E8.3060200@cisco.com> In-Reply-To: <541618E8.3060200@cisco.com> Content-Type: multipart/alternative; boundary="------------090505070004030302050100" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/jjazvorim2QauvkAsO64-e8IZZc Subject: Re: [lmap] Feedback on draft-ietf-lmap-information-model X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 13:41:24 -0000 This is a multi-part message in MIME format. --------------090505070004030302050100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, A generic point about the information model: I find it difficult to see how the objects are related since they are spread all over the document. See how all classes were grouped in a single place in the EMAN framework: http://tools.ietf.org/html/rfc7326#section-7 Regards, Benoit > Dear all, > > Since we will be spending time on draft-ietf-lmap-information-model > tomorrow, here is some more feedback. I haven't had the time to review > it all, so here is part 1. > If some points were already discussed, don't hesitate to let me know. > >> Network Working Group T. Burbridge >> Internet-Draft P. Eardley >> Intended status: Standards Track BT >> Expires: February 21, 2015 M. Bagnulo >> Universidad Carlos III de Madrid >> J. Schoenwaelder >> Jacobs University Bremen >> August 20, 2014 >> >> >> Information Model for Large-Scale Measurement Platforms (LMAP) >> draft-ietf-lmap-information-model-02 > What does LMAP stand for? > In the use cases draft, it says "Large-scale Measurement of Broadband > Performance (LMAP)" > Both the framework and the information model say: Large-Scale > Measurement Platforms (LMAP) > >> >> Abstract >> >> This Information Model applies to the Measurement Agent within a >> Large-Scale Measurement Platform. As such it outlines the >> information that is (pre-)configured on the MA or exists in >> communications with a Controller or Collector within an LMAP >> framework. The purpose of such an Information Model is to provide a >> protocol and device independent view of the MA that can be >> implemented via one or more Control and Report protocols. >> >> Requirements Language >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in RFC 2119 [RFC2119]. >> >> Status of This Memo >> >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF). Note that other groups may also distribute >> working documents as Internet-Drafts. The list of current Internet- >> Drafts is at http://datatracker.ietf.org/drafts/current/. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> This Internet-Draft will expire on February 21, 2015. >> >> >> >> >> >> >> Burbridge, et al. Expires February 21, 2015 [Page 1] >> >> Internet-Draft LMAP Information Model August 2014 >> >> >> Copyright Notice >> >> Copyright (c) 2014 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions with respect >> to this document. Code Components extracted from this document must >> include Simplified BSD License text as described in Section 4.e of >> the Trust Legal Provisions and are provided without warranty as >> described in the Simplified BSD License. >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 >> 3. LMAP Information Model . . . . . . . . . . . . . . . . . . . 4 >> 3.1. Information Structure . . . . . . . . . . . . . . . . . . 4 >> 3.2. Pre-Configuration Information . . . . . . . . . . . . . . 8 >> 3.3. Configuration Information . . . . . . . . . . . . . . . . 9 >> 3.4. Instruction Information . . . . . . . . . . . . . . . . . 11 >> 3.5. Logging Information . . . . . . . . . . . . . . . . . . . 13 >> 3.6. Capability and Status Information . . . . . . . . . . . . 15 >> 3.7. Reporting Information . . . . . . . . . . . . . . . . . . 17 >> 3.8. Schedules . . . . . . . . . . . . . . . . . . . . . . . . 18 >> 3.9. Channels . . . . . . . . . . . . . . . . . . . . . . . . 21 >> 3.10. Task Configurations . . . . . . . . . . . . . . . . . . . 22 >> 3.11. Timing Information . . . . . . . . . . . . . . . . . . . 23 >> 3.11.1. Periodic Timing . . . . . . . . . . . . . . . . . . 24 >> 3.11.2. Calendar Timing . . . . . . . . . . . . . . . . . . 25 >> 3.11.3. One-Off Timing . . . . . . . . . . . . . . . . . . . 26 >> 3.11.4. Immediate Timing . . . . . . . . . . . . . . . . . . 26 >> 3.11.5. Startup Timing . . . . . . . . . . . . . . . . . . . 26 >> 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 >> 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 >> 6. Appendix: JSON Example . . . . . . . . . . . . . . . . . . . 27 >> 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 >> 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 >> 8.1. Normative References . . . . . . . . . . . . . . . . . . 35 >> 8.2. Informative References . . . . . . . . . . . . . . . . . 35 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 >> >> >> >> >> >> >> >> Burbridge, et al. Expires February 21, 2015 [Page 2] >> >> Internet-Draft LMAP Information Model August 2014 >> >> >> 1. Introduction >> >> A large-scale measurement platform is a collection of components that >> work in a coordinated fashion to perform measurements from a large >> number of vantage points. The main components of a large-scale >> measurement platform are the Measurement Agents (hereafter MAs), the >> Controller(s) and the Collector(s). >> >> The MAs are the elements actually performing the measurements. The >> MAs are controlled by exactly one Controller at a time and the >> Collectors gather the results generated by the MAs. In a nutshell, >> the normal operation of a large-scale measurement platform starts >> with the Controller instructing a set of one or more MAs to perform a >> set of one or more Measurement Tasks at a certain point in time. The >> MAs execute the instructions from a Controller, and once they have >> done so, they report the results of the measurements to one or more >> Collectors. The overall framework for a Large Measurement platform >> as used in this document is described in detail in >> [I-D.ietf-lmap-framework]. >> >> A large-scale measurement platform involves basically three >> protocols, namely, a Control protocol between a Controller and the > Control Protocol >> MAs, a Report protocol between the MAs and the Collector(s) and >> several measurement protocols between the MAs and Measurement Peers >> (MPs), used to actually perform the measurements. In addition some >> information is required to be configured on the MA prior to any >> communication with the initial Controller. > "initial" confused me. > It's only later (section 3.3) that I understood that the Controller > could be changed. > Candidate for removal, improvement, or forward reference? >> >> This document defines the information model for both the Control and >> the Report protocol along with pre-configuration information that is >> required > add "on the MA" >> before communicating with the Controller, broadly named as >> the LMAP Information Model. The measurement protocols are out of the >> scope of this document. >> >> As defined in [RFC3444], the LMAP IM defines the concepts involved in > IM = Information Model > this is the first occurrence. > >> a large-scale measurement platform at a high level of abstraction, >> independent of any specific implementation or actual protocol used to >> exchange the information. It is expected that the proposed >> information model can be used with different protocols in different >> measurement platform architectures and across different types of MA >> devices (e.g., home gateway, smartphone, PC, router). >> >> The definition of an Information Model serves a number of purposes: >> >> 1. To guide the standardisation of one or more Control and Report >> protocol and data model implementations >> >> >> >> >> >> Burbridge, et al. Expires February 21, 2015 [Page 3] >> >> Internet-Draft LMAP Information Model August 2014 >> >> >> 2. To enable high-level inter-operability between different Control >> and Report protocols by facilitating translation between their >> respective data models such that a Controller could instruct sub- >> populations of MAs using different protocols >> >> 3. To form agreement of what information needs to be held by an MA >> and passed over the Control and Report interfaces and support the >> functionality described in the LMAP framework >> >> 4. Enable existing protocols and data models to be assessed for >> their suitability as part of a large-scale measurement system >> >> 2. Notation >> >> This document use an object-oriented programming-like notation to >> define the parameters (names/values) of the objects of the >> information model. An optional field is enclosed by [ ], and an >> array is indicated by two numbers in angle brackets, , where m >> indicates the minimal number of values, and n is the maximum. The >> symbol * for n means no upper bound. >> >> 3. LMAP Information Model >> >> 3.1. Information Structure >> >> The information described herein relates to the information stored, >> received or transmitted by a Measurement Agent as described within >> the LMAP framework [I-D.ietf-lmap-framework]. > Should the framework be normative? I believe so, specifically when I > see all those Capitalized terms that are only defined in the framework. > This leads to another point. You miss a terminology section because > some terms are specific to this document. Example: Task Suppression. >> As such, some subsets >> of this information model are applicable to the measurement >> Controller, Collector > add a "," > Otherwise we can believe that the Collector could pre-configure the MA. >> and systems that pre-configure the Measurement >> Agent. The information described in these models will be transmitted >> by protocols using interfaces between the Measurement Agent and such >> systems according to a Data Model. >> >> For clarity the information model is divided into six sections: >> >> 1. Pre-Configuration Information. Information pre-configured on the >> Measurement Agent prior to any communication with other >> components of the LMAP architecture (i.e., the Controller, >> Collector and Measurement Peers), specifically detailing how to >> communicate with a Controller and whether the device is enabled >> to participate as an MA. >> >> 2. Configuration Information. Update of the pre-configuration >> information during the registration of the MA or subsequent >> communication with the Controller, along with the configuration >> of further parameters about the MA (rather than the Tasks it >> >> >> >> >> Burbridge, et al. Expires February 21, 2015 [Page 4] >> >> Internet-Draft LMAP Information Model August 2014 >> >> >> should perform) that were not mandatory for the initial >> communication between the MA and a Controller. >> >> 3. Instruction Information. Information that is received by the MA >> from the Controller pertaining to the Tasks that should be >> executed. This includes the task execution Schedules (other than >> the Controller communication Schedule supplied as >> (pre)configuration information) and related information such as >> the Task Configuration, communication Channels to Collectors and >> schedule Timing information. It also inlcudes Task Suppression >> information that is used to over-ride normal Task execution >> during emergency situations. >> >> 4. Logging Information. Information transmitted from the MA to the >> Controller detailing the results of any configuration operations >> along with error and status information from the operation of the >> MA. >> >> 5. Capability and Status Information. Information on the general >> status and capabilities of the MA. For example, the set of >> measurements that are supported on the device. >> >> 6. Reporting Information. Information transmitted from the MA to >> one or more Collectors including measurement results and the >> context in which they were conducted. >> >> In addition the MA may hold further information not described herein, >> and which may be optionally transferred to or from other systems >> including the Controller and Collector. One example of information >> in this category is subscriber or line information that may be >> extracted by a task and reported by the MA in the reporting >> communication to a Collector. >> >> It should also be noted that the MA may be in communication with > The "MA" or the "MA device"? > I'm asking because the rest of the sentence speaks about > "configuring", and we said that MA can only be configured by one and > only one Controller. >> other management systems which may be responsible for configuring and >> retrieving information from the MA device. Such systems, where >> available, can perform an important role in transferring the pre- >> configuration information to the MA or enabling/disabling the >> measurement functionality of the MA. > "such systemS" ... "enabling/disabling the measurement functionality > of the MA." > This is not possible. See my previous point. >> >> The Information Model is divided into sub-sections for a number of >> reasons. Firstly the grouping of information facilitates reader >> understanding. Secondly, the particular groupings chosen are >> expected to map to different protocols or different transmissions >> within those protocols. >> >> The granularity of data transmitted in each operation of the Control >> and Report Protocols is not dictated by the Information Model. For >> >> >> >> Burbridge, et al. Expires February 21, 2015 [Page 5] >> >> Internet-Draft LMAP Information Model August 2014 >> >> >> example, the Instruction object may be delivered in a single >> operation. Alternatively, Schedules and Task Configurations may be >> separated or even each Schdule/Task Configuration may be delivered >> individually. Similarly the Information Model does not dictate >> whether data is read, write, or read/write. For example, some >> Control Protocols may have the ability to read back Configuration and >> Instruction information which have been previosuly set on the MA. >> Lastly, while some protocols may simply overwrite information (for >> example refreshing the entire Instruction Information), other >> protocols may have the ability to update or delete selected items of >> information. >> >> The information in these six sections is captured by a number of >> common information objects. These objects are also described later >> in this document and comprise of: >> >> 1. Schedules. A set of Schedules tell the MA to do something. >> Without a Schedule no Task (from a measurement to reporting or >> communicating with the Controller) is ever executed. Schedules >> are used within the Instruction to specify what tasks should be >> performed, when, and how to direct their results. A Schedule is >> also used within the pre-Configuration and Configuration >> information in order to execute the Task or Tasks required to >> communicate with the Controller. >> >> 2. Channels. A set of Channel objects are used to communicate with >> a number of endpoints (i.e. the Controller and Collectors). > OLD: (i.e. the Controller and Collectors). > NEW: (the Controller, Collectors, and MAs). > > These are the only 3 possibilities, right? > Logging always goes to the Collector, right? > >> Each >> Channel object contains the information required for the >> communication with a single endpoint such as the target location >> and security details. Channels are referenced from within >> Schedules in order to say how Tasks should communicate. >> >> 3. Task Configurations. A set of Task Configurations is used to >> configure the Tasks that are run by the MA. This includes the >> registry entry for the Task and any configuration parameters. >> Task Configurations are referenced from a Schedule in order to >> specify what Tasks the MA should execute. >> >> 4. Timings. A set of Timing objects that can be referenced from the >> Schedules. Each Schedule always references exactly one Timing >> object. A Timing object specfies either a singleton or series of >> time events. They are used to indicate when Tasks should be >> executed. >> >> The following diagram illustrates the structure in which these common >> information objects are referenced. The references are achieved by >> each object (Channel, Task Configuration, Timing) being given a short >> >> >> >> >> Burbridge, et al. Expires February 21, 2015 [Page 6] >> >> Internet-Draft LMAP Information Model August 2014 >> >> >> text name that is used by other objects. The objects shown in >> parenthesis are part of the internal object structure of a Schedule. >> >> Schedule >> |----------> Timing >> |----------> (Scheduled Tasks) >> |----------> Task Configuration >> |----------> (Task Channels and >> downstream Tasks) >> |----------> Channels >> |----------> Downstream Tasks > Please number the figures. > > Why is only "configuration" mentioned in the figure? > I understood that everything is now a task: > controller communication > reporting > measurement > data aggregation > ... > This was confusing to me. > > >> >> It should be clear that the top-level bahaviour of an MA is simply to >> execute Schedules. Every action referenced by a Schedule is defined >> as a Task. As such, these actions are configured through Task >> Configurations and executed according to the Timing referenced by the >> Schedule in which they appear. Tasks can implement a variety of >> different types of actions. While in terms of the Information Model, >> all Tasks have the same structure, it can help conceptually to think >> of different Task categories: >> >> 1. Measurement Tasks >> >> A. Measurement Tasks measure some aspect of network performance >> or traffic >> >> B. Data Capture Tasks capture and analyse passive information > Why capture? We can analyse without capture. >> stored on the MA device such as counters and device/network >> status information > > Why not traffic? > From 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 > > >> >> 2. Data Transfer Tasks >> >> A. Reporting Tasks report the results or Measurement Tasks to >> Collectors > "Reporting Tasks report Measurement Tasks to Collectors" > Really? So the Controller configures the Reporting Tasks on the MA, > and the MA reports them to the Collector? > > Maybe you meant? > A. Reporting Tasks report the results _of _Measurement Tasks to > Collectors >> >> B. Control Task(s) implement the Control Protocol and >> communicate with the Controller. Depending on the Control >> Protocol this may be a number of specialist tasks such as: > What is "this"? >> Configuration Task; Instruction Task; Suppression Task; >> Capabilities Task; Logging Task etc. >> >> 3. Data Analysis Tasks can exist to analyse data from other >> Measurement Tasks locally on the MA >> >> 4. Data Management Tasks may exist to clean-up, filter or compress >> data on the MA such as Measurement Task results >> >> >> >> >> >> >> Burbridge, et al. Expires February 21, 2015 [Page 7] >> >> Internet-Draft LMAP Information Model August 2014 >> >> >> 3.2. Pre-Configuration Information >> >> This information is the minimal information that needs to be pre- >> configured to the MA in order for it to successfully communicate with >> a Controller during the registration process. > In section 3.1, we learned: > 1. Pre-Configuration Information. Information pre-configured on the > Measurement Agent prior to any communication with other > components of the LMAP architecture (i.e., the Controller, > Collector and Measurement Peers), specifically detailing how to > communicate with a Controller and whether the device is enabled > to participate as an MA. > So the pre-configuration information is only for the Controller > communication (I guess so) or also for the collector and measurement > peers? >> The pre-configuration >> information is a subset of the Configuration Information along with >> some parameters that are not under the control of the LMAP framework >> (such as the the device identifier and device security credentials). > I can't parse "not under the control of the LMAP framework" >> >> This pre-configuration information needs to include a URL of the >> initial Controller where configuration information can be retrieved > OLD: retrieved > NEW: communicated > NEW (alternative): pulled or pushed > > Justification: the next paragraphs make the distinction. >> along with the security information required for the communication >> including the certificate of the Controller (or the certificate of >> the Certification Authority which was used to issue the certificate >> for the Controller). All this is expressed as a Channel. While >> multiple Channels may be provided in the pre-configuration >> information they must all be associated with a single Controller >> (e.g. over different interfaces or network protocols). >> >> Where the MA pulls information from the Controller, the Pre- >> Configuration Information also needs to contain the timing of the >> communication with the Controller as well as the nature of the >> communication itself (such as the protocol and data to be >> transfered). The timing is given as a Schedule that executes the >> Task(s) responsible for communication with the Controller. It is >> this Task (or Tasks) that implement the Control protocol between the >> MA and the Controller. The Task(s) may take additional parameters in >> which case a Task Configuration can also be included. >> >> Even where information is pushed to the MA from the Controller >> (rather than pulled by the MA), a Schedule still needs to be >> supplied. In this case the Schedule will simply execute a Controller >> listener task when the MA is started. A Channel is still required >> for the MA to establish secure communication with the Controller. >> >> It can be seen that these Channels, Schedules and Task Configurations >> for the initial MA-Controller communication are no different in terms >> of the Information Model to any other Channel, Schedule or Task >> Configuration that might execute a Measurement Task or report the >> measurement results (as described later). >> >> The MA may be pre-configured with an MA ID, or may use a Device ID in >> the initial Controller contact before it is assigned an MA ID. > Again, I'm confused by this initial Controller. > >> The >> Device ID may be a MAC address or some other device identifier >> expressed as a URN. If the MA ID is not provided at this stage then >> it must be provided by the Controller during Configuration. >> >> Detail of the information model elements: >> >> >> >> Burbridge, et al. Expires February 21, 2015 [Page 8] >> >> Internet-Draft LMAP Information Model August 2014 >> >> >> // MA pre-configuration minimal information to communicate initially >> with Controller >> >> object { >> [uuid ma-agent-id;] >> ma-task-obj ma-control-tasks<1..*>; >> ma-channel-obj ma-control-channels<1..*>; >> ma-schedule-obj ma-control-schedules<1..*>; >> [urn ma-device-id;] >> credentials ma-credentials; >> } ma-config-obj; >> >> The detail of the Channel and Schedule objects are described later >> since they are common to several parts of the information model. >> >> 3.3. Configuration Information >> >> During registration or at any later point at which the MA contacts >> the Controller (or vice-versa), the choice of Controller, > "The choice of Controller", do you want to say "an alternate > Controller", because at this point the MA is already in contact with > the Controller. >> details for >> the timing of communication with the Controller or parameters for the >> communication Task(s) can be changed (as captured by the Channels, >> Schedules and Task Configurations objects). For example the pre- >> configured Controller (specified as a Channel or Channels) may be >> replaced with a specific Controller that is more appropriate to the >> MA device type, location or characteristics of the network (e.g. >> access technology type or broadband product). The initial >> communication Schedule may be replaced with one more relevant to >> routine communications between the MA and the Controller. >> >> While some Control protocols and uses may only use a single Schedule, >> other protocols and uses may uses several Schedules (and related data >> transfer Tasks) to update the Configuration Information, transfer the >> Instruction Information, transfer Capability and Status Information >> and send other information to the Controller such as log or error >> notifications. Multiple Channels may be used to communicate with the >> same Controller over multiple interfaces (e.g. to send logging >> information over a different network). >> >> In addition the MA will be given further items of information that >> relate specifically to the MA rather than the measurements it is to >> conduct or how to report results. The assignment of an ID to the MA >> is mandatory. If the MA Agent ID was not optionally provided during >> the pre-configuration then one must be provided by the Controller >> during Configuration. Optionally a Group ID may also be given which >> identifies a group of interest to which that MA belongs. For example >> the group could represent an ISP, broadband product, technology, >> market classification, geographic region, or a combination of >> multiple such characteristics. Where the Measurement Group ID is set >> an additional flag (the Report MA ID flag) is required to control >> >> >> >> Burbridge, et al. Expires February 21, 2015 [Page 9] >> >> Internet-Draft LMAP Information Model August 2014 >> >> >> whether the Measurement Agent ID is also to be reported. The >> reporting of a Group ID without the MA ID allows the MA to remain >> anonymous, which may be particularly useful to prevent tracking of >> mobile MA devices. >> >> Optionally an MA can also be configured to stop executing any >> Instruction Schedule if the Controller is unreachable. This can be >> used as a fail-safe to stop Measurement and other Tasks being >> conducted when there is doubt that the Instruction Information is >> still valid. This is simply represented as a time window in >> milliseconds since the last communication with the Controller after >> which Instruction Schedules are to be suspended. The appropriate >> vaue of the time window will depend on the specified communication > value >> Schedule with the Controller and the duration for which the system is >> willing to tolerate continued operation with potentially stale >> Instruction Information. >> >> While pre-configuration is persistent upon device reset or power >> cycle due to its very nature, the persistency of the addtional >> configuration information may be control protocol dependent. > Why "Control Protocol" dependent? > Why isn't the persistence IM (or DM) specific? >> Some >> protocols may assume that reset devices will revert back to their >> pre-configuration state, while other protocols may assume that all >> configuration and instruction information is held in persistent >> storage. >> >> It should be noted that control shedules and tasks cannot be >> suppressed as evidenced by the lack of suppression information in the >> Configuration. The control schedule must only reference tasks listed >> as control tasks. Any suppress-by-default flag against control tasks >> will be ignored. >> >> Detail of the additional and updated information model elements: >> >> // MA Configuration >> >> object { >> uuid ma-agent-id; >> [ma-task-obj ma-control-tasks<0..*>;] >> ma-channel-obj ma-control-channels<1..*>; >> [ma-schedule-obj ma-control-schedules<0..*>]; >> [urn ma-device-id;] >> credentials ma-credentials; >> [string ma-group-id;] >> [boolean ma-report-ma-id-flag;] >> [int ma-control-channel-failure-threshold;] >> } ma-config-obj; >> >> > That's where I arrived. > > And now, time for a Guinness or two. I'm in Dublin after all :-) > > Regards, Benoit > --------------090505070004030302050100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

A generic point about the information model: I find it difficult to see how the objects are related since they are spread all over the document.
See how all classes were grouped in a single place in the EMAN framework: http://tools.ietf.org/html/rfc7326#section-7

Regards, Benoit
Dear all,

Since we will be spending time on draft-ietf-lmap-information-model tomorrow, here is some more feedback. I haven't had the time to review it all, so here is part 1.
If some points were already discussed, don't hesitate to let me know.

Network Working Group                                       T. Burbridge
Internet-Draft                                                P. Eardley
Intended status: Standards Track                                      BT
Expires: February 21, 2015                                    M. Bagnulo
                                        Universidad Carlos III de Madrid
                                                        J. Schoenwaelder
                                                Jacobs University Bremen
                                                         August 20, 2014


     Information Model for Large-Scale Measurement Platforms (LMAP)
                  draft-ietf-lmap-information-model-02
What does LMAP stand for?
In the use cases draft, it says "Large-scale Measurement of Broadband Performance (LMAP)"
Both the framework and the information model say: Large-Scale Measurement Platforms (LMAP)


Abstract

   This Information Model applies to the Measurement Agent within a
   Large-Scale Measurement Platform.  As such it outlines the
   information that is (pre-)configured on the MA or exists in
   communications with a Controller or Collector within an LMAP
   framework.  The purpose of such an Information Model is to provide a
   protocol and device independent view of the MA that can be
   implemented via one or more Control and Report protocols.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 21, 2015.






Burbridge, et al.       Expires February 21, 2015               [Page 1]

Internet-Draft           LMAP Information Model              August 2014


Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Notation  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  LMAP Information Model  . . . . . . . . . . . . . . . . . . .   4
     3.1.  Information Structure . . . . . . . . . . . . . . . . . .   4
     3.2.  Pre-Configuration Information . . . . . . . . . . . . . .   8
     3.3.  Configuration Information . . . . . . . . . . . . . . . .   9
     3.4.  Instruction Information . . . . . . . . . . . . . . . . .  11
     3.5.  Logging Information . . . . . . . . . . . . . . . . . . .  13
     3.6.  Capability and Status Information . . . . . . . . . . . .  15
     3.7.  Reporting Information . . . . . . . . . . . . . . . . . .  17
     3.8.  Schedules . . . . . . . . . . . . . . . . . . . . . . . .  18
     3.9.  Channels  . . . . . . . . . . . . . . . . . . . . . . . .  21
     3.10. Task Configurations . . . . . . . . . . . . . . . . . . .  22
     3.11. Timing Information  . . . . . . . . . . . . . . . . . . .  23
       3.11.1.  Periodic Timing  . . . . . . . . . . . . . . . . . .  24
       3.11.2.  Calendar Timing  . . . . . . . . . . . . . . . . . .  25
       3.11.3.  One-Off Timing . . . . . . . . . . . . . . . . . . .  26
       3.11.4.  Immediate Timing . . . . . . . . . . . . . . . . . .  26
       3.11.5.  Startup Timing . . . . . . . . . . . . . . . . . . .  26
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
   6.  Appendix: JSON Example  . . . . . . . . . . . . . . . . . . .  27
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  35
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  35
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  35
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35







Burbridge, et al.       Expires February 21, 2015               [Page 2]

Internet-Draft           LMAP Information Model              August 2014


1.  Introduction

   A large-scale measurement platform is a collection of components that
   work in a coordinated fashion to perform measurements from a large
   number of vantage points.  The main components of a large-scale
   measurement platform are the Measurement Agents (hereafter MAs), the
   Controller(s) and the Collector(s).

   The MAs are the elements actually performing the measurements.  The
   MAs are controlled by exactly one Controller at a time and the
   Collectors gather the results generated by the MAs.  In a nutshell,
   the normal operation of a large-scale measurement platform starts
   with the Controller instructing a set of one or more MAs to perform a
   set of one or more Measurement Tasks at a certain point in time.  The
   MAs execute the instructions from a Controller, and once they have
   done so, they report the results of the measurements to one or more
   Collectors.  The overall framework for a Large Measurement platform
   as used in this document is described in detail in
   [I-D.ietf-lmap-framework].

   A large-scale measurement platform involves basically three
   protocols, namely, a Control protocol between a Controller and the
Control Protocol
   MAs, a Report protocol between the MAs and the Collector(s) and
   several measurement protocols between the MAs and Measurement Peers
   (MPs), used to actually perform the measurements.  In addition some
   information is required to be configured on the MA prior to any
   communication with the initial Controller.
"initial" confused me.
It's only later (section 3.3) that I understood that the Controller could be changed.
Candidate for removal, improvement, or forward reference?

   This document defines the information model for both the Control and
   the Report protocol along with pre-configuration information that is
   required
add "on the MA"
before communicating with the Controller, broadly named as
   the LMAP Information Model.  The measurement protocols are out of the
   scope of this document.

   As defined in [RFC3444], the LMAP IM defines the concepts involved in
IM = Information Model
this is the first occurrence.

   a large-scale measurement platform at a high level of abstraction,
   independent of any specific implementation or actual protocol used to
   exchange the information.  It is expected that the proposed
   information model can be used with different protocols in different
   measurement platform architectures and across different types of MA
   devices (e.g., home gateway, smartphone, PC, router).

   The definition of an Information Model serves a number of purposes:

   1.  To guide the standardisation of one or more Control and Report
       protocol and data model implementations





Burbridge, et al.       Expires February 21, 2015               [Page 3]

Internet-Draft           LMAP Information Model              August 2014


   2.  To enable high-level inter-operability between different Control
       and Report protocols by facilitating translation between their
       respective data models such that a Controller could instruct sub-
       populations of MAs using different protocols

   3.  To form agreement of what information needs to be held by an MA
       and passed over the Control and Report interfaces and support the
       functionality described in the LMAP framework

   4.  Enable existing protocols and data models to be assessed for
       their suitability as part of a large-scale measurement system

2.  Notation

   This document use an object-oriented programming-like notation to
   define the parameters (names/values) of the objects of the
   information model.  An optional field is enclosed by [ ], and an
   array is indicated by two numbers in angle brackets, <m..n>, where m
   indicates the minimal number of values, and n is the maximum.  The
   symbol * for n means no upper bound.

3.  LMAP Information Model

3.1.  Information Structure

   The information described herein relates to the information stored,
   received or transmitted by a Measurement Agent as described within
   the LMAP framework [I-D.ietf-lmap-framework]. 
Should the framework be normative? I believe so, specifically when I see all those Capitalized terms that are only defined in the framework.
This leads to another point. You miss a terminology section because some terms are specific to this document. Example: Task Suppression.
As such, some subsets
   of this information model are applicable to the measurement
   Controller, Collector
add a ","
Otherwise we can believe that the Collector could pre-configure the MA.
and systems that pre-configure the Measurement
   Agent.  The information described in these models will be transmitted
   by protocols using interfaces between the Measurement Agent and such
   systems according to a Data Model.

   For clarity the information model is divided into six sections:

   1.  Pre-Configuration Information.  Information pre-configured on the
       Measurement Agent prior to any communication with other
       components of the LMAP architecture (i.e., the Controller,
       Collector and Measurement Peers), specifically detailing how to
       communicate with a Controller and whether the device is enabled
       to participate as an MA.

   2.  Configuration Information.  Update of the pre-configuration
       information during the registration of the MA or subsequent
       communication with the Controller, along with the configuration
       of further parameters about the MA (rather than the Tasks it




Burbridge, et al.       Expires February 21, 2015               [Page 4]

Internet-Draft           LMAP Information Model              August 2014


       should perform) that were not mandatory for the initial
       communication between the MA and a Controller.

   3.  Instruction Information.  Information that is received by the MA
       from the Controller pertaining to the Tasks that should be
       executed.  This includes the task execution Schedules (other than
       the Controller communication Schedule supplied as
       (pre)configuration information) and related information such as
       the Task Configuration, communication Channels to Collectors and
       schedule Timing information.  It also inlcudes Task Suppression
       information that is used to over-ride normal Task execution
       during emergency situations.

   4.  Logging Information.  Information transmitted from the MA to the
       Controller detailing the results of any configuration operations
       along with error and status information from the operation of the
       MA.

   5.  Capability and Status Information.  Information on the general
       status and capabilities of the MA.  For example, the set of
       measurements that are supported on the device.

   6.  Reporting Information.  Information transmitted from the MA to
       one or more Collectors including measurement results and the
       context in which they were conducted.

   In addition the MA may hold further information not described herein,
   and which may be optionally transferred to or from other systems
   including the Controller and Collector.  One example of information
   in this category is subscriber or line information that may be
   extracted by a task and reported by the MA in the reporting
   communication to a Collector.

   It should also be noted that the MA may be in communication with
The "MA" or the "MA device"?
I'm asking because the rest of the sentence speaks about "configuring", and we said that MA can only be configured by one and only one Controller.
   other management systems which may be responsible for configuring and
   retrieving information from the MA device.  Such systems, where
   available, can perform an important role in transferring the pre-
   configuration information to the MA or enabling/disabling the
   measurement functionality of the MA.
"such systemS" ... "enabling/disabling the measurement functionality of the MA."
This is not possible. See my previous point.

   The Information Model is divided into sub-sections for a number of
   reasons.  Firstly the grouping of information facilitates reader
   understanding.  Secondly, the particular groupings chosen are
   expected to map to different protocols or different transmissions
   within those protocols.

   The granularity of data transmitted in each operation of the Control
   and Report Protocols is not dictated by the Information Model.  For



Burbridge, et al.       Expires February 21, 2015               [Page 5]

Internet-Draft           LMAP Information Model              August 2014


   example, the Instruction object may be delivered in a single
   operation.  Alternatively, Schedules and Task Configurations may be
   separated or even each Schdule/Task Configuration may be delivered
   individually.  Similarly the Information Model does not dictate
   whether data is read, write, or read/write.  For example, some
   Control Protocols may have the ability to read back Configuration and
   Instruction information which have been previosuly set on the MA.
   Lastly, while some protocols may simply overwrite information (for
   example refreshing the entire Instruction Information), other
   protocols may have the ability to update or delete selected items of
   information.

   The information in these six sections is captured by a number of
   common information objects.  These objects are also described later
   in this document and comprise of:

   1.  Schedules.  A set of Schedules tell the MA to do something.
       Without a Schedule no Task (from a measurement to reporting or
       communicating with the Controller) is ever executed.  Schedules
       are used within the Instruction to specify what tasks should be
       performed, when, and how to direct their results.  A Schedule is
       also used within the pre-Configuration and Configuration
       information in order to execute the Task or Tasks required to
       communicate with the Controller.

   2.  Channels.  A set of Channel objects are used to communicate with
       a number of endpoints (i.e. the Controller and Collectors). 
OLD: (i.e. the Controller and Collectors). 
NEW: (the Controller, Collectors, and MAs). 

These are the only 3 possibilities, right?
Logging always goes to the Collector, right?

Each
       Channel object contains the information required for the
       communication with a single endpoint such as the target location
       and security details.  Channels are referenced from within
       Schedules in order to say how Tasks should communicate.

   3.  Task Configurations.  A set of Task Configurations is used to
       configure the Tasks that are run by the MA.  This includes the
       registry entry for the Task and any configuration parameters.
       Task Configurations are referenced from a Schedule in order to
       specify what Tasks the MA should execute.

   4.  Timings.  A set of Timing objects that can be referenced from the
       Schedules.  Each Schedule always references exactly one Timing
       object.  A Timing object specfies either a singleton or series of
       time events.  They are used to indicate when Tasks should be
       executed.

   The following diagram illustrates the structure in which these common
   information objects are referenced.  The references are achieved by
   each object (Channel, Task Configuration, Timing) being given a short




Burbridge, et al.       Expires February 21, 2015               [Page 6]

Internet-Draft           LMAP Information Model              August 2014


   text name that is used by other objects.  The objects shown in
   parenthesis are part of the internal object structure of a Schedule.

          Schedule
              |----------> Timing
              |----------> (Scheduled Tasks)
                                   |----------> Task Configuration
                                   |----------> (Task Channels and downstream Tasks)
                                                      |----------> Channels
                                                      |----------> Downstream Tasks
Please number the figures.

Why is only "configuration" mentioned in the figure?
I understood that everything is now a task:
    controller communication
    reporting
    measurement
    data aggregation
    ...
This was confusing to me.



   It should be clear that the top-level bahaviour of an MA is simply to
   execute Schedules.  Every action referenced by a Schedule is defined
   as a Task.  As such, these actions are configured through Task
   Configurations and executed according to the Timing referenced by the
   Schedule in which they appear.  Tasks can implement a variety of
   different types of actions.  While in terms of the Information Model,
   all Tasks have the same structure, it can help conceptually to think
   of different Task categories:

   1.  Measurement Tasks

       A.  Measurement Tasks measure some aspect of network performance
           or traffic

       B.  Data Capture Tasks capture and analyse passive information
Why capture? We can analyse without capture.
           stored on the MA device such as counters and device/network
           status information

Why not traffic?
From 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


   2.  Data Transfer Tasks

       A.  Reporting Tasks report the results or Measurement Tasks to
           Collectors
"Reporting Tasks report Measurement Tasks to Collectors"
Really? So the Controller configures the Reporting Tasks on the MA, and the MA reports them to the Collector?

Maybe you meant?
       A.  Reporting Tasks report the results of Measurement Tasks to
           Collectors

       B.  Control Task(s) implement the Control Protocol and
           communicate with the Controller.  Depending on the Control
           Protocol this may be a number of specialist tasks such as:
What is "this"?
           Configuration Task; Instruction Task; Suppression Task;
           Capabilities Task; Logging Task etc.

   3.  Data Analysis Tasks can exist to analyse data from other
       Measurement Tasks locally on the MA

   4.  Data Management Tasks may exist to clean-up, filter or compress
       data on the MA such as Measurement Task results






Burbridge, et al.       Expires February 21, 2015               [Page 7]

Internet-Draft           LMAP Information Model              August 2014


3.2.  Pre-Configuration Information

   This information is the minimal information that needs to be pre-
   configured to the MA in order for it to successfully communicate with
   a Controller during the registration process. 
In section 3.1, we learned:
   1.  Pre-Configuration Information.  Information pre-configured on the
       Measurement Agent prior to any communication with other
       components of the LMAP architecture (i.e., the Controller,
       Collector and Measurement Peers), specifically detailing how to
       communicate with a Controller and whether the device is enabled
       to participate as an MA.
So the pre-configuration information is only for the Controller communication (I guess so) or also for the collector and measurement peers?
The pre-configuration
   information is a subset of the Configuration Information along with
   some parameters that are not under the control of the LMAP framework
   (such as the the device identifier and device security credentials).
I can't parse "not under the control of the LMAP framework"

   This pre-configuration information needs to include a URL of the
   initial Controller where configuration information can be retrieved
OLD: retrieved
NEW: communicated
NEW (alternative): pulled or pushed

Justification: the next paragraphs make the distinction.
   along with the security information required for the communication
   including the certificate of the Controller (or the certificate of
   the Certification Authority which was used to issue the certificate
   for the Controller).  All this is expressed as a Channel.  While
   multiple Channels may be provided in the pre-configuration
   information they must all be associated with a single Controller
   (e.g. over different interfaces or network protocols).

   Where the MA pulls information from the Controller, the Pre-
   Configuration Information also needs to contain the timing of the
   communication with the Controller as well as the nature of the
   communication itself (such as the protocol and data to be
   transfered).  The timing is given as a Schedule that executes the
   Task(s) responsible for communication with the Controller.  It is
   this Task (or Tasks) that implement the Control protocol between the
   MA and the Controller.  The Task(s) may take additional parameters in
   which case a Task Configuration can also be included.

   Even where information is pushed to the MA from the Controller
   (rather than pulled by the MA), a Schedule still needs to be
   supplied.  In this case the Schedule will simply execute a Controller
   listener task when the MA is started.  A Channel is still required
   for the MA to establish secure communication with the Controller.

   It can be seen that these Channels, Schedules and Task Configurations
   for the initial MA-Controller communication are no different in terms
   of the Information Model to any other Channel, Schedule or Task
   Configuration that might execute a Measurement Task or report the
   measurement results (as described later).

   The MA may be pre-configured with an MA ID, or may use a Device ID in
   the initial Controller contact before it is assigned an MA ID. 
Again, I'm confused by this initial Controller.  

The
   Device ID may be a MAC address or some other device identifier
   expressed as a URN.  If the MA ID is not provided at this stage then
   it must be provided by the Controller during Configuration.

   Detail of the information model elements:



Burbridge, et al.       Expires February 21, 2015               [Page 8]

Internet-Draft           LMAP Information Model              August 2014


// MA pre-configuration minimal information to communicate initially with Controller

object {
    [uuid                ma-agent-id;]
     ma-task-obj         ma-control-tasks<1..*>;
     ma-channel-obj      ma-control-channels<1..*>;
     ma-schedule-obj     ma-control-schedules<1..*>;
    [urn                 ma-device-id;]
     credentials         ma-credentials;
} ma-config-obj;

   The detail of the Channel and Schedule objects are described later
   since they are common to several parts of the information model.

3.3.  Configuration Information

   During registration or at any later point at which the MA contacts
   the Controller (or vice-versa), the choice of Controller,
"The choice of Controller", do you want to say "an alternate Controller", because at this point the MA is already in contact with the Controller.
details for
   the timing of communication with the Controller or parameters for the
   communication Task(s) can be changed (as captured by the Channels,
   Schedules and Task Configurations objects).  For example the pre-
   configured Controller (specified as a Channel or Channels) may be
   replaced with a specific Controller that is more appropriate to the
   MA device type, location or characteristics of the network (e.g.
   access technology type or broadband product).  The initial
   communication Schedule may be replaced with one more relevant to
   routine communications between the MA and the Controller.

   While some Control protocols and uses may only use a single Schedule,
   other protocols and uses may uses several Schedules (and related data
   transfer Tasks) to update the Configuration Information, transfer the
   Instruction Information, transfer Capability and Status Information
   and send other information to the Controller such as log or error
   notifications.  Multiple Channels may be used to communicate with the
   same Controller over multiple interfaces (e.g. to send logging
   information over a different network).

   In addition the MA will be given further items of information that
   relate specifically to the MA rather than the measurements it is to
   conduct or how to report results.  The assignment of an ID to the MA
   is mandatory.  If the MA Agent ID was not optionally provided during
   the pre-configuration then one must be provided by the Controller
   during Configuration.  Optionally a Group ID may also be given which
   identifies a group of interest to which that MA belongs.  For example
   the group could represent an ISP, broadband product, technology,
   market classification, geographic region, or a combination of
   multiple such characteristics.  Where the Measurement Group ID is set
   an additional flag (the Report MA ID flag) is required to control



Burbridge, et al.       Expires February 21, 2015               [Page 9]

Internet-Draft           LMAP Information Model              August 2014


   whether the Measurement Agent ID is also to be reported.  The
   reporting of a Group ID without the MA ID allows the MA to remain
   anonymous, which may be particularly useful to prevent tracking of
   mobile MA devices.

   Optionally an MA can also be configured to stop executing any
   Instruction Schedule if the Controller is unreachable.  This can be
   used as a fail-safe to stop Measurement and other Tasks being
   conducted when there is doubt that the Instruction Information is
   still valid.  This is simply represented as a time window in
   milliseconds since the last communication with the Controller after
   which Instruction Schedules are to be suspended.  The appropriate
   vaue of the time window will depend on the specified communication
value
   Schedule with the Controller and the duration for which the system is
   willing to tolerate continued operation with potentially stale
   Instruction Information.

   While pre-configuration is persistent upon device reset or power
   cycle due to its very nature, the persistency of the addtional
   configuration information may be control protocol dependent. 
Why "Control Protocol" dependent?
Why isn't the persistence IM (or DM) specific?
Some
   protocols may assume that reset devices will revert back to their
   pre-configuration state, while other protocols may assume that all
   configuration and instruction information is held in persistent
   storage.

   It should be noted that control shedules and tasks cannot be
   suppressed as evidenced by the lack of suppression information in the
   Configuration.  The control schedule must only reference tasks listed
   as control tasks.  Any suppress-by-default flag against control tasks
   will be ignored.

   Detail of the additional and updated information model elements:

   // MA Configuration

   object {
       uuid                ma-agent-id;
      [ma-task-obj         ma-control-tasks<0..*>;]
       ma-channel-obj      ma-control-channels<1..*>;
      [ma-schedule-obj    ma-control-schedules<0..*>];
      [urn                 ma-device-id;]
       credentials         ma-credentials;
      [string              ma-group-id;]
      [boolean             ma-report-ma-id-flag;]
      [int                 ma-control-channel-failure-threshold;]
   } ma-config-obj;


That's where I arrived.

And now, time for a Guinness or two. I'm in Dublin after all :-)

Regards, Benoit


--------------090505070004030302050100-- From nobody Mon Sep 15 06:42:19 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 A27A01A034D for ; Mon, 15 Sep 2014 06:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.123 X-Spam-Level: X-Spam-Status: No, score=-8.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652] 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 5Pep0nK0Nk6a for ; Mon, 15 Sep 2014 06:42:16 -0700 (PDT) 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 BCC691A034E for ; Mon, 15 Sep 2014 06:42:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0zAIPrFlTGmAcV/2dsb2JhbABggWwCAgFWIyNTW7NBAQeebAEfcxZ4hAUBAQMSBxAEXgECCgkVViYBBBsaiBwBlW+EZZEZjmQYhXyGIgGCfYNmgR0FkU2TK41Pg16CNIECAQEB X-IronPort-AV: E=Sophos; i="5.04,528,1406606400"; d="scan'208,217"; a="72231764" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Sep 2014 09:42:13 -0400 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; 15 Sep 2014 09:42:12 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Mon, 15 Sep 2014 09:42:11 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: are you not sharing slides on Webex? Thread-Index: Ac/Q6tmLSXC2tiCuSc2aq7O24HSIFg== Importance: high X-Priority: 1 Date: Mon, 15 Sep 2014 13:42:11 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C89C212@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_9904FB1B0159DA42B0B887B7FA8119CA5C89C212AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/1ueHammjSwsHPNuAu66OLNt5tnI Subject: [lmap] are you not sharing slides on Webex? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 13:42:17 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C89C212AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_9904FB1B0159DA42B0B887B7FA8119CA5C89C212AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C89C212AZFFEXMB04globa_-- From nobody Mon Sep 15 06:44:19 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 46F9A1A034B for ; Mon, 15 Sep 2014 06:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.551 X-Spam-Level: X-Spam-Status: No, score=-8.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652] 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 9OzxII76leje for ; Mon, 15 Sep 2014 06:44:08 -0700 (PDT) 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 B73161A0BEC for ; Mon, 15 Sep 2014 06:44:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsLADjsFlTGmAcV/2dsb2JhbABggkcjI1NXBLNCB55sAYESFniEAwEBAQEDEhcEXgECBgQJBAQBAQtWHQkBBBMIGogcAZVwhGWffQEXhXyGIgGCfYNmgR0FkU2TK41Pg15sgUiBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,528,1406606400"; d="scan'208,217"; a="82475561" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Sep 2014 09:44:06 -0400 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; 15 Sep 2014 09:44:06 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Mon, 15 Sep 2014 15:44:05 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: are you not sharing slides on Webex? Thread-Index: Ac/Q6tmLSXC2tiCuSc2aq7O24HSIFgAAC2wg Importance: high X-Priority: 1 Date: Mon, 15 Sep 2014 13:44:05 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C89C227@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_9904FB1B0159DA42B0B887B7FA8119CA5C89C227AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/nl2pqTEcY7RYmnNct-8VBMMLXOY Subject: Re: [lmap] are you not sharing slides on Webex? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 13:44:12 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C89C227AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is anybody following Webex chat? Or listening to Webex? I cannot do jabber.= Slides are not shared. Dan From: Romascanu, Dan (Dan) Sent: Monday, September 15, 2014 4:42 PM To: lmap@ietf.org Subject: are you not sharing slides on Webex? Importance: High --_000_9904FB1B0159DA42B0B887B7FA8119CA5C89C227AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is anybody following W= ebex chat? Or listening to Webex? I cannot do jabber. Slides are not shared= .

 

Dan<= /p>

 

From: Romascan= u, Dan (Dan)
Sent: Monday, September 15, 2014 4:42 PM
To: lmap@ietf.org
Subject: are you not sharing slides on Webex?
Importance: High

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C89C227AZFFEXMB04globa_-- From nobody Mon Sep 15 15:39: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 E21111A882A for ; Mon, 15 Sep 2014 15:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, 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 9ISHOrIopcaD for ; Mon, 15 Sep 2014 15:39:46 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060A51A8839 for ; Mon, 15 Sep 2014 15:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20024; q=dns/txt; s=iport; t=1410820785; x=1412030385; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=V+uFPDmNpqPfCwcMK/sAft/iKoIF5q65octk1IZ8szY=; b=IGOZK0PbNRsY7wFPcr/OeGb/SjXz3T6PaFm3XXU4R7AcTRglsDTXPEM+ G9kH5Zwj0fPw326G0CsmzYI+aO5UQHrctb/W5yaB052R3zq0YOsIuCx3V kEzLfzdPqmFOjjSGQyEt/cdFs47xwhU/zwEQS5xJPlHJDpP7jctHWHu0Y M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EANxpF1RIo8UY/2dsb2JhbABZB4NgV8puh1YBgTF4hAQBAQMBOEAGCywWDwkDAgECAUUGCgMIAQGIMgi7MQEXjn8FAU+ESwEEjzeGTYcEh0eEf4h5g2A7LwGBBQEfAwGBIAEBAQ X-IronPort-AV: E=Sophos;i="5.04,531,1406592000"; d="scan'208";a="44750527" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 15 Sep 2014 22:39:43 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8FMdfQZ004186 for ; Mon, 15 Sep 2014 22:39:42 GMT Message-ID: <54174F8F.9030308@cisco.com> Date: Mon, 15 Sep 2014 22:43:59 +0200 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" References: <5416090C.5070402@cisco.com> In-Reply-To: <5416090C.5070402@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_CUWwZ8S6D8fbcBd-BU5tc4j_Cs Subject: [lmap] Feedback on draft-ietf-lmap-information-model : 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: Mon, 15 Sep 2014 22:39:49 -0000 Dear all, Here is part 2. Again, if some points were already discussed, don't hesitate to let me know. See in-line. Regards, Benoit .3.3. Configuration Information > During registration or at any later point at which the MA contacts > the Controller (or vice-versa), the choice of Controller, details for > the timing of communication with the Controller or parameters for the > communication Task(s) can be changed (as captured by the Channels, > Schedules and Task Configurations objects). For example the pre- > configured Controller (specified as a Channel or Channels) may be > replaced with a specific Controller that is more appropriate to the > MA device type, location or characteristics of the network (e.g. > access technology type or broadband product). The initial > communication Schedule may be replaced with one more relevant to > routine communications between the MA and the Controller. > > While some Control protocols and uses may only use a single Schedule, > other protocols and uses may uses several Schedules (and related data > transfer Tasks) to update the Configuration Information, transfer the > Instruction Information, transfer Capability and Status Information > and send other information to the Controller such as log or error > notifications. Multiple Channels may be used to communicate with the > same Controller over multiple interfaces (e.g. to send logging > information over a different network). > > In addition the MA will be given further items of information that > relate specifically to the MA rather than the measurements it is to > conduct or how to report results. The assignment of an ID to the MA > is mandatory. If the MA Agent ID was not optionally provided during > the pre-configuration then one must be provided by the Controller > during Configuration. Optionally a Group ID may also be given which > identifies a group of interest to which that MA belongs. For example > the group could represent an ISP, broadband product, technology, > market classification, geographic region, or a combination of > multiple such characteristics. Where the Measurement Group ID is set > an additional flag (the Report MA ID flag) is required to control > > > > Burbridge, et al. Expires February 21, 2015 [Page 9] > > Internet-Draft LMAP Information Model August 2014 > > > whether the Measurement Agent ID is also to be reported. The > reporting of a Group ID without the MA ID allows the MA to remain > anonymous, which may be particularly useful to prevent tracking of > mobile MA devices. > > Optionally an MA can also be configured to stop executing any > Instruction Schedule if the Controller is unreachable. This can be > used as a fail-safe to stop Measurement and other Tasks being > conducted when there is doubt that the Instruction Information is > still valid. That makes sense, but have you considered the following case: when the Reporter is not available? Should the MA store all the reports? Will it have enough memory/space? What if it can't store it (memory/space). If I take IPFIX as a specific LMAP platform, it's key to push the flow records (read Measurement Reports) as soon as possible. Maybe this case is discussed in the framework draft? Note that this would be another easy suppression mechanism: stopping the Reporting Channel > This is simply represented as a time window in > milliseconds since the last communication with the Controller after > which Instruction Schedules are to be suspended. The appropriate > vaue of the time window will depend on the specified communication > Schedule with the Controller and the duration for which the system is > willing to tolerate continued operation with potentially stale > Instruction Information. > > While pre-configuration is persistent upon device reset or power > cycle due to its very nature, the persistency of the addtional > configuration information may be control protocol dependent. Some > protocols may assume that reset devices will revert back to their > pre-configuration state, while other protocols may assume that all > configuration and instruction information is held in persistent > storage. > > It should be noted that control shedules and tasks cannot be > suppressed as evidenced by the lack of suppression information in the > Configuration. The control schedule must only reference tasks listed > as control tasks. Any suppress-by-default flag against control tasks > will be ignored. > > Detail of the additional and updated information model elements: "additional and updated"? > > // MA Configuration > > object { > uuid ma-agent-id; > [ma-task-obj ma-control-tasks<0..*>;] > ma-channel-obj ma-control-channels<1..*>; > [ma-schedule-obj ma-control-schedules<0..*>]; > [urn ma-device-id;] > credentials ma-credentials; > [string ma-group-id;] > [boolean ma-report-ma-id-flag;] > [int ma-control-channel-failure-threshold;] > } ma-config-obj; > > > > > > Burbridge, et al. Expires February 21, 2015 [Page 10] > > Internet-Draft LMAP Information Model August 2014 > > > 3.4. Instruction Information > > The Instruction information model has four sub-elements: > > 1. Instruction Task Configurations > > 2. Report Channels > > 3. Instruction Schedules > > 4. Suppression > > The Instruction supports the exceution of all Tasks on the MA except execution > those that deal with communication with the Controller (specified in > (pre)configuration information). The Tasks are configured in > Instruction Task Configurations and inlcuded by reference in included. > Instruction Schdules that specify when to execute them. The results Schedules From now, I will stop mentioned spelling mistakes. I advice you to run the draft through a spell checker. > are communicated to other Tasks or over Report Channels. Suppression > is used to temporarily stop the excution of new Tasks as specified by > the Instruction Schedules (and optionaly to stop ongoing Tasks). > > A Task Configuration is used to configure the optional parameters of > a Task. Why "optional"? How are the non-optional parameters configured then? Is there a difference between Task Configuration and Instruction Task Configurations? > It also serves to instruct the MA about the Task including > the ability to resolve the Task to an executable and specifying the > schema for the Task parameters. > > A Report Channel defines how to communicate with a single remote > system specified by a URL. A Report Channel is used to send results > to single Collector but is no different in terms of the Information > Model to the Control Channel used to transfer information between the > MA and the Controller. Several Report Channels can be defined to > enable results to be split or duplicated across different > destinations. The two sentences above are contradictory: to single Collector duplicated across different destinations. > A single Channel can also be used by multiple > Schedules to transfer data at different cycles to the same Collector. > E.g. a single Collector may receive data at three different cycle > rates, one Schedule reporting hourly, another reporting daily and a > third specifying that results should be sent immediately for on- > demand measurement tasks. Alternatively multiple Report Channels can > be used to send Measurement Task results to different Collectors. > The details of the Channel element is described later as it is common > to several objects. > > Instruction Schedules specify which Tasks to execute according to a > given Timing (that can execute a single or repeated series of Tasks). > The Schedule also specifies how to deal with Task inputs and outputs > - e.g. sending selected outputs to other Tasks or specifying the > Report Channels that should be used to report results to Collectors. > > > > > Burbridge, et al. Expires February 21, 2015 [Page 11] > > Internet-Draft LMAP Information Model August 2014 > > > Measurement Suppression information is used to over-ride the > Instruction Schedule and temporarily stop measurements or other Tasks > from running on the MA for a defined or indefinite period. While > conceptually measurements can be stopped by simply removing them from > the Measurement Schedule, splitting out separate information on > Measurement Suppression allows this information to be updated on the > MA on a different timing cycle or protocol implementation to the > Measurement Schedule. It is also considered that it will be easier > for a human operator to implement a temporary explicit suppression > rather than having to move to a reduced Schedule and then roll-back > at a later time. > > The explicit Suppression instruction message is able to simply > enable/disable all Instruction Tasks (that are enabled for default > suppression) as well as having fine control on which Tasks are > suppressed. Suppression of both specified Task Configurations and > Measurement Schedules is supported. Support for disabling specific > Task Configurations allows malfunctioning or mis-configured Tasks or > Task Configurations that have an impact on a particular part of the > network infrastructure (e.g., a particular Measurement Peer) to be > targetted. Support for disabling specific Schedules allows for > particularly heavy cycles or sets of less essential Measurement Tasks > to be suppressed quickly and effectively. Note that Suppression has > no effect on either Controller Tasks or Controller Schedules. > > When no tasks or schedules are explicitly listed, all Instruction Tasks or Schedules. That's a generic comment on the draft. Be consistent with capitalization > tasks will be suppressed (or not) as indicated by the suppress-by- > default flag in the Task Configuration. If tasks or schedules are > listed explicitly then only these listed tasks or schedules will be > suppressed regardless of the suppress-by-default flag. If both > individual tasks and individual schedules are listed then the union > of these options is considered - i.e. the listed shcedules plus the > listed tasks where present in other schedules. > > Suppression stops new Tasks from executing. In addtion, the > Suppression information also supports an additional Boolean that is > used to select whether on-going tasks are also to be terminated. > > Unsuppression is achieved through either overwriting the Measurement > Suppression information (e.g. changing 'enabled' to False) or through > the use of an End time such that the Measurement Suppression will no > longer be in effect beyond this time. The datetime format used for > all elements in the information model (e.g. the suppression start and > end dates) MUST conform to RFC 3339 [RFC3339] and ISO8601. > > The goal when defining these four different elements is to allow each > part of the information model to change without affecting the other > three elements. For example it is envisaged that the Report Channels > > > > Burbridge, et al. Expires February 21, 2015 [Page 12] > > Internet-Draft LMAP Information Model August 2014 > > > and the set of Task Configurations will be relatively static. The > Instruction Schedule, on the other hand, is likely to be more > dynamic, as the measurement panel and test frequency are changed for > various business goals. Another example is that measurements can be > suppressed with a Suppression command without removing the existing > Instruction Schedules that would continue to apply after the > Suppression expires or is removed. In terms of the Controller-MA > communication this can reduce the data overhead. It also encourages > the re-use of the same standard Task Configurations and Reporting > Channels to help ensure consistency and reduce errors. > > Definition of the information model elements: > > // Instruction to the MA to configure Tasks, Channels, Schedules and > Suppression > > object { > ma-task-obj ma-instruction-tasks<0..*>; > ma-channel-obj ma-report-channels<0..*>; > ma-schedule-obj ma-instruction-schedules<0..*>; > ma-suppression-obj ma-suppression; > } ma-instruction-obj; > > // Suppression object to temporarily override new task execution in > Instructions and optionally stop currently running tasks > > object { > boolean ma-suppression-enabled; > [boolean ma-suppression-stop-ongoing-tasks;] // > default: false > [datetime ma-suppression-start;] // default: immediate > [datetime ma-suppression-end;] // default: indefinite > [string ma-suppression-task-names<0..*>;] > // default: all tasks if > // ma-suppression-task-names is empty > [string ma-suppression-schedule-names<0..*>;] > // default: all schedules if > // ma-suppression-schedule-names is empty > } ma-suppression-obj; > > 3.5. Logging Information From what I can read in the framework, the logging information is always sent to the Controller. Is that always what we want? Maybe the operational category 2 and 3 logging information (and potentially the configuration information in category 1) should be sent to a syslog server. From my quick IM read, this is a limitation. Is this what you want? > > The MA may report on the success or failure of Configuration or > Instruction communications from the Controller. In addition further > operational logs may be produced during the operation of the MA and > updates to capabilities may also be reported. Reporting this > information is achieved simply and flexibly in exactly the same > manner as any other Task. We make no distinction between a > Measurement Task conducting an active or passive network measurement > and one which solely retrieves static or dynamic information from the > MA such as capabilities or logging information. One or more logging > > > > Burbridge, et al. Expires February 21, 2015 [Page 13] > > Internet-Draft LMAP Information Model August 2014 > > > tasks can be programmed or configured to capture subsets of the > Logging Information. These logging tasks are then executed by > Schedules which also specify that the resultant data is to be > transferred over the Controller Channels. > > The type of Logging Information will fall into three different > categories: > > 1. Success/failure/warning messages in response to information > updates from the Controller. Failure messages could be produced > due to some inability to receive or parse the Controller > communication, or if the MA is not able to act as instructed. > For example: > > * "Measurement Schedules updated OK" > > * "Unable to parse JSON" > > * "Missing mandatory element: Measurement Timing" > > * "'Start' does not conform to schema - expected datetime" > > * "Date specified is in the past" > > * "'Hour' must be in the range 1..24" > > * "Schedule A refers to non-existent Measurement Task > Configuration" > > * "Measurement Task Configuration X registry entry Y not found" > > * "Updated Measurement Task Configurations do not include M used > by Measurement Schedule N" > > 2. Operational updates from the MA. For example: > > * "Out of memory: cannot record result" > > * "Collector 'collector.example.com' not responding" > > * "Unexpected restart" > > * "Suppression timeout" > > * "Failed to execute Measurement Task Configuration H" > > 3. Status updates from the MA. For example: > > > > > Burbridge, et al. Expires February 21, 2015 [Page 14] > > Internet-Draft LMAP Information Model August 2014 > > > * "Interface added: eth3 " > > * "Supported measurements updated" > > * "New IP address on eth0: xxx.xxx.xxx.xxx" > > This Information Model document does not detail the precise format of > logging information since it is to a large extent protocol and MA > specific. However, some common information can be identified. > > MA Logging information model elements: > > // Logging object > > object { > uuid ma-log-agent-id; > datetime ma-log-event-time; > code ma-log-code; > string ma-log-description; > } ma-log-obj; > > 3.6. Capability and Status Information > > The MA will hold Capability Information that can be retrieved by a > Controller. Capabilities include the interface details available to > Measurement Tasks and Channels as well as the set of Measurement > Tasks/Roles that are actually installed or available on the MA. > Status information includes the times that operations were last > performed such as contacting the Controller or producing Reports. > > MA Status information model elements: > > > > > > > > > > > > > > > > > > > > > Burbridge, et al. Expires February 21, 2015 [Page 15] > > Internet-Draft LMAP Information Model August 2014 > > > // Main MA Status information object > > object { > uuid ma-agent-id; > urn ma-device-id; > string ma-hardware; > string ma-firmware; > string ma-version; > ma-interface-obj ma-interfaces<0..*>; > > datetime ma-last-measurement; > datetime ma-last-report; > datetime ma-last-instruction; > datetime ma-last-configuration; > > [ma-condition-obj ma-conditions<0..*>;] > > ma-task-capability-obj ma-supported-tasks<0..*>; > } ma-status-obj; > > // Additional status conditions > > object { > string ma-condition-code; > string ma-condition-text; > } ma-condition-obj > > > // Interface information > > object { > string ma-interface-name; > string ma-interface-type; > [int ma-interface-speed;] // bps > [string ma-link-layer-address;] > [ip-address ma-interface-ip-addresses<0..*>]; > [ip-address ma-interface-gateways<0..*>;] > [ip-address ma-interface-dns-servers<0..*>;] > } ma-interface-obj; > > // Supported tasks/roles > > object { > string ma-task-name; > uri ma-task-registry; > string ma-task-role; > } ma-task-capability-obj; > > > > > Burbridge, et al. Expires February 21, 2015 [Page 16] > > Internet-Draft LMAP Information Model August 2014 > > This is where I arrived. I'll stop here and review the next draft version. Regards, Benoit From nobody Wed Sep 17 04:41:26 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 821E51A00FA for ; Wed, 17 Sep 2014 04:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ONQAP4VxalkU for ; Wed, 17 Sep 2014 04:41:18 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C200F1A00F5 for ; Wed, 17 Sep 2014 04:41:17 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id le20so1157181vcb.18 for ; Wed, 17 Sep 2014 04:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F7YxgYd02ZKmdRJdbt4faLn/RKVJjWK++rj4Z66EDiQ=; b=nmVrViJSD20N894YGKFDG1rWazFURBvycLVQyql9vpT/paNYrGfztM5YV9TdVqLo5Z ipOmdYlEXfu9X25c9zsUnnljM656o410FHjiUKzgL4MQbRIoUPqPEhCB4FuAAK36SHUA 25xtxO4BSd29mX3tBiWnjndC6X0f556dyfRnjW0MDCT1jWVebKgeeqTmP0VIXm/6jaBJ OEWAKkd8R1pnE6y4GSO/rclHbQiHIVS7LjJNkx4Ljr4rWlHNDZ7+MAYDDLEg1jYEWUki AbikOHhhaPY6kvNl8VGCKS+Tn2lPWl0HVCIbdYEKF5N7H/p/cF6p7LfAPL3riwoEQMTE FiyA== MIME-Version: 1.0 X-Received: by 10.220.190.134 with SMTP id di6mr493331vcb.43.1410954076761; Wed, 17 Sep 2014 04:41:16 -0700 (PDT) Received: by 10.220.43.208 with HTTP; Wed, 17 Sep 2014 04:41:16 -0700 (PDT) In-Reply-To: <541618E8.3060200@cisco.com> References: <5416090C.5070402@cisco.com> <541618E8.3060200@cisco.com> Date: Wed, 17 Sep 2014 12:41:16 +0100 Message-ID: From: Greg Mirsky To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11c1c11c8a62c30503415824 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/LQD6B3vjCmgXhaUxNqVirkT5ZtI Cc: "lmap@ietf.org" Subject: Re: [lmap] Feedback on draft-ietf-lmap-information-model 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, 17 Sep 2014 11:41:24 -0000 --001a11c1c11c8a62c30503415824 Content-Type: text/plain; charset=UTF-8 Hi Benoit, on just one question: Logging always goes to the Collector, right? According to LMAP framework document Logging goes over Control, not Report Channel: Control Channel: A Channel between a Controller and a MA over which Instruction Messages and Capabilities, Failure and Logging Information are sent. Regards, Greg On Sun, Sep 14, 2014 at 11:38 PM, Benoit Claise wrote: > Dear all, > > Since we will be spending time on draft-ietf-lmap-information-model > tomorrow, here is some more feedback. I haven't had the time to review it > all, so here is part 1. > If some points were already discussed, don't hesitate to let me know. > > Network Working Group T. Burbridge > Internet-Draft P. Eardley > Intended status: Standards Track BT > Expires: February 21, 2015 M. Bagnulo > Universidad Carlos III de Madrid > J. Schoenwaelder > Jacobs University Bremen > August 20, 2014 > > > Information Model for Large-Scale Measurement Platforms (LMAP) > draft-ietf-lmap-information-model-02 > > What does LMAP stand for? > In the use cases draft, it says "Large-scale Measurement of Broadband > Performance (LMAP)" > Both the framework and the information model say: Large-Scale Measurement > Platforms (LMAP) > > > Abstract > > This Information Model applies to the Measurement Agent within a > Large-Scale Measurement Platform. As such it outlines the > information that is (pre-)configured on the MA or exists in > communications with a Controller or Collector within an LMAP > framework. The purpose of such an Information Model is to provide a > protocol and device independent view of the MA that can be > implemented via one or more Control and Report protocols. > > Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on February 21, 2015. > > > > > > > Burbridge, et al. Expires February 21, 2015 [Page 1] > > Internet-Draft LMAP Information Model August 2014 > > > Copyright Notice > > Copyright (c) 2014 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. LMAP Information Model . . . . . . . . . . . . . . . . . . . 4 > 3.1. Information Structure . . . . . . . . . . . . . . . . . . 4 > 3.2. Pre-Configuration Information . . . . . . . . . . . . . . 8 > 3.3. Configuration Information . . . . . . . . . . . . . . . . 9 > 3.4. Instruction Information . . . . . . . . . . . . . . . . . 11 > 3.5. Logging Information . . . . . . . . . . . . . . . . . . . 13 > 3.6. Capability and Status Information . . . . . . . . . . . . 15 > 3.7. Reporting Information . . . . . . . . . . . . . . . . . . 17 > 3.8. Schedules . . . . . . . . . . . . . . . . . . . . . . . . 18 > 3.9. Channels . . . . . . . . . . . . . . . . . . . . . . . . 21 > 3.10. Task Configurations . . . . . . . . . . . . . . . . . . . 22 > 3.11. Timing Information . . . . . . . . . . . . . . . . . . . 23 > 3.11.1. Periodic Timing . . . . . . . . . . . . . . . . . . 24 > 3.11.2. Calendar Timing . . . . . . . . . . . . . . . . . . 25 > 3.11.3. One-Off Timing . . . . . . . . . . . . . . . . . . . 26 > 3.11.4. Immediate Timing . . . . . . . . . . . . . . . . . . 26 > 3.11.5. Startup Timing . . . . . . . . . . . . . . . . . . . 26 > 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 > 6. Appendix: JSON Example . . . . . . . . . . . . . . . . . . . 27 > 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 > 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 > 8.1. Normative References . . . . . . . . . . . . . . . . . . 35 > 8.2. Informative References . . . . . . . . . . . . . . . . . 35 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 > > > > > > > > Burbridge, et al. Expires February 21, 2015 [Page 2] > > Internet-Draft LMAP Information Model August 2014 > > > 1. Introduction > > A large-scale measurement platform is a collection of components that > work in a coordinated fashion to perform measurements from a large > number of vantage points. The main components of a large-scale > measurement platform are the Measurement Agents (hereafter MAs), the > Controller(s) and the Collector(s). > > The MAs are the elements actually performing the measurements. The > MAs are controlled by exactly one Controller at a time and the > Collectors gather the results generated by the MAs. In a nutshell, > the normal operation of a large-scale measurement platform starts > with the Controller instructing a set of one or more MAs to perform a > set of one or more Measurement Tasks at a certain point in time. The > MAs execute the instructions from a Controller, and once they have > done so, they report the results of the measurements to one or more > Collectors. The overall framework for a Large Measurement platform > as used in this document is described in detail in > [I-D.ietf-lmap-framework]. > > A large-scale measurement platform involves basically three > protocols, namely, a Control protocol between a Controller and the > > Control Protocol > > MAs, a Report protocol between the MAs and the Collector(s) and > several measurement protocols between the MAs and Measurement Peers > (MPs), used to actually perform the measurements. In addition some > information is required to be configured on the MA prior to any > communication with the initial Controller. > > "initial" confused me. > It's only later (section 3.3) that I understood that the Controller could > be changed. > Candidate for removal, improvement, or forward reference? > > > This document defines the information model for both the Control and > the Report protocol along with pre-configuration information that is > required > > add "on the MA" > > before communicating with the Controller, broadly named as > the LMAP Information Model. The measurement protocols are out of the > scope of this document. > > As defined in [RFC3444], the LMAP IM defines the concepts involved in > > IM = Information Model > this is the first occurrence. > > a large-scale measurement platform at a high level of abstraction, > independent of any specific implementation or actual protocol used to > exchange the information. It is expected that the proposed > information model can be used with different protocols in different > measurement platform architectures and across different types of MA > devices (e.g., home gateway, smartphone, PC, router). > > The definition of an Information Model serves a number of purposes: > > 1. To guide the standardisation of one or more Control and Report > protocol and data model implementations > > > > > > Burbridge, et al. Expires February 21, 2015 [Page 3] > > Internet-Draft LMAP Information Model August 2014 > > > 2. To enable high-level inter-operability between different Control > and Report protocols by facilitating translation between their > respective data models such that a Controller could instruct sub- > populations of MAs using different protocols > > 3. To form agreement of what information needs to be held by an MA > and passed over the Control and Report interfaces and support the > functionality described in the LMAP framework > > 4. Enable existing protocols and data models to be assessed for > their suitability as part of a large-scale measurement system > > 2. Notation > > This document use an object-oriented programming-like notation to > define the parameters (names/values) of the objects of the > information model. An optional field is enclosed by [ ], and an > array is indicated by two numbers in angle brackets, , where m > indicates the minimal number of values, and n is the maximum. The > symbol * for n means no upper bound. > > 3. LMAP Information Model > > 3.1. Information Structure > > The information described herein relates to the information stored, > received or transmitted by a Measurement Agent as described within > the LMAP framework [I-D.ietf-lmap-framework]. > > Should the framework be normative? I believe so, specifically when I see > all those Capitalized terms that are only defined in the framework. > This leads to another point. You miss a terminology section because some > terms are specific to this document. Example: Task Suppression. > > As such, some subsets > of this information model are applicable to the measurement > Controller, Collector > > add a "," > Otherwise we can believe that the Collector could pre-configure the MA. > > and systems that pre-configure the Measurement > Agent. The information described in these models will be transmitted > by protocols using interfaces between the Measurement Agent and such > systems according to a Data Model. > > For clarity the information model is divided into six sections: > > 1. Pre-Configuration Information. Information pre-configured on the > Measurement Agent prior to any communication with other > components of the LMAP architecture (i.e., the Controller, > Collector and Measurement Peers), specifically detailing how to > communicate with a Controller and whether the device is enabled > to participate as an MA. > > 2. Configuration Information. Update of the pre-configuration > information during the registration of the MA or subsequent > communication with the Controller, along with the configuration > of further parameters about the MA (rather than the Tasks it > > > > > Burbridge, et al. Expires February 21, 2015 [Page 4] > > Internet-Draft LMAP Information Model August 2014 > > > should perform) that were not mandatory for the initial > communication between the MA and a Controller. > > 3. Instruction Information. Information that is received by the MA > from the Controller pertaining to the Tasks that should be > executed. This includes the task execution Schedules (other than > the Controller communication Schedule supplied as > (pre)configuration information) and related information such as > the Task Configuration, communication Channels to Collectors and > schedule Timing information. It also inlcudes Task Suppression > information that is used to over-ride normal Task execution > during emergency situations. > > 4. Logging Information. Information transmitted from the MA to the > Controller detailing the results of any configuration operations > along with error and status information from the operation of the > MA. > > 5. Capability and Status Information. Information on the general > status and capabilities of the MA. For example, the set of > measurements that are supported on the device. > > 6. Reporting Information. Information transmitted from the MA to > one or more Collectors including measurement results and the > context in which they were conducted. > > In addition the MA may hold further information not described herein, > and which may be optionally transferred to or from other systems > including the Controller and Collector. One example of information > in this category is subscriber or line information that may be > extracted by a task and reported by the MA in the reporting > communication to a Collector. > > It should also be noted that the MA may be in communication with > > The "MA" or the "MA device"? > I'm asking because the rest of the sentence speaks about "configuring", > and we said that MA can only be configured by one and only one Controller. > > other management systems which may be responsible for configuring and > retrieving information from the MA device. Such systems, where > available, can perform an important role in transferring the pre- > configuration information to the MA or enabling/disabling the > measurement functionality of the MA. > > "such systemS" ... "enabling/disabling the measurement functionality of > the MA." > This is not possible. See my previous point. > > > The Information Model is divided into sub-sections for a number of > reasons. Firstly the grouping of information facilitates reader > understanding. Secondly, the particular groupings chosen are > expected to map to different protocols or different transmissions > within those protocols. > > The granularity of data transmitted in each operation of the Control > and Report Protocols is not dictated by the Information Model. For > > > > Burbridge, et al. Expires February 21, 2015 [Page 5] > > Internet-Draft LMAP Information Model August 2014 > > > example, the Instruction object may be delivered in a single > operation. Alternatively, Schedules and Task Configurations may be > separated or even each Schdule/Task Configuration may be delivered > individually. Similarly the Information Model does not dictate > whether data is read, write, or read/write. For example, some > Control Protocols may have the ability to read back Configuration and > Instruction information which have been previosuly set on the MA. > Lastly, while some protocols may simply overwrite information (for > example refreshing the entire Instruction Information), other > protocols may have the ability to update or delete selected items of > information. > > The information in these six sections is captured by a number of > common information objects. These objects are also described later > in this document and comprise of: > > 1. Schedules. A set of Schedules tell the MA to do something. > Without a Schedule no Task (from a measurement to reporting or > communicating with the Controller) is ever executed. Schedules > are used within the Instruction to specify what tasks should be > performed, when, and how to direct their results. A Schedule is > also used within the pre-Configuration and Configuration > information in order to execute the Task or Tasks required to > communicate with the Controller. > > 2. Channels. A set of Channel objects are used to communicate with > a number of endpoints (i.e. the Controller and Collectors). > > OLD: (i.e. the Controller and Collectors). > NEW: (the Controller, Collectors, and MAs). > > These are the only 3 possibilities, right? > Logging always goes to the Collector, right? > > Each > Channel object contains the information required for the > communication with a single endpoint such as the target location > and security details. Channels are referenced from within > Schedules in order to say how Tasks should communicate. > > 3. Task Configurations. A set of Task Configurations is used to > configure the Tasks that are run by the MA. This includes the > registry entry for the Task and any configuration parameters. > Task Configurations are referenced from a Schedule in order to > specify what Tasks the MA should execute. > > 4. Timings. A set of Timing objects that can be referenced from the > Schedules. Each Schedule always references exactly one Timing > object. A Timing object specfies either a singleton or series of > time events. They are used to indicate when Tasks should be > executed. > > The following diagram illustrates the structure in which these common > information objects are referenced. The references are achieved by > each object (Channel, Task Configuration, Timing) being given a short > > > > > Burbridge, et al. Expires February 21, 2015 [Page 6] > > Internet-Draft LMAP Information Model August 2014 > > > text name that is used by other objects. The objects shown in > parenthesis are part of the internal object structure of a Schedule. > > Schedule > |----------> Timing > |----------> (Scheduled Tasks) > |----------> Task Configuration > |----------> (Task Channels and > downstream Tasks) > |----------> > Channels > |----------> > Downstream Tasks > > Please number the figures. > > Why is only "configuration" mentioned in the figure? > I understood that everything is now a task: > controller communication > reporting > measurement > data aggregation > ... > This was confusing to me. > > > > It should be clear that the top-level bahaviour of an MA is simply to > execute Schedules. Every action referenced by a Schedule is defined > as a Task. As such, these actions are configured through Task > Configurations and executed according to the Timing referenced by the > Schedule in which they appear. Tasks can implement a variety of > different types of actions. While in terms of the Information Model, > all Tasks have the same structure, it can help conceptually to think > of different Task categories: > > 1. Measurement Tasks > > A. Measurement Tasks measure some aspect of network performance > or traffic > > B. Data Capture Tasks capture and analyse passive information > > Why capture? We can analyse without capture. > > stored on the MA device such as counters and device/network > status information > > > Why not traffic? > From 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 > > > > 2. Data Transfer Tasks > > A. Reporting Tasks report the results or Measurement Tasks to > Collectors > > "Reporting Tasks report Measurement Tasks to Collectors" > Really? So the Controller configures the Reporting Tasks on the MA, and > the MA reports them to the Collector? > > Maybe you meant? > A. Reporting Tasks report the results *of *Measurement Tasks to > Collectors > > > B. Control Task(s) implement the Control Protocol and > communicate with the Controller. Depending on the Control > Protocol this may be a number of specialist tasks such as: > > What is "this"? > > Configuration Task; Instruction Task; Suppression Task; > Capabilities Task; Logging Task etc. > > 3. Data Analysis Tasks can exist to analyse data from other > Measurement Tasks locally on the MA > > 4. Data Management Tasks may exist to clean-up, filter or compress > data on the MA such as Measurement Task results > > > > > > > Burbridge, et al. Expires February 21, 2015 [Page 7] > > Internet-Draft LMAP Information Model August 2014 > > > 3.2. Pre-Configuration Information > > This information is the minimal information that needs to be pre- > configured to the MA in order for it to successfully communicate with > a Controller during the registration process. > > In section 3.1, we learned: > > 1. Pre-Configuration Information. Information pre-configured on the > Measurement Agent prior to any communication with other > components of the LMAP architecture (i.e., the Controller, > Collector and Measurement Peers), specifically detailing how to > communicate with a Controller and whether the device is enabled > to participate as an MA. > > So the pre-configuration information is only for the Controller > communication (I guess so) or also for the collector and measurement peers? > > The pre-configuration > information is a subset of the Configuration Information along with > some parameters that are not under the control of the LMAP framework > (such as the the device identifier and device security credentials). > > I can't parse "not under the control of the LMAP framework" > > > This pre-configuration information needs to include a URL of the > initial Controller where configuration information can be retrieved > > OLD: retrieved > NEW: communicated > NEW (alternative): pulled or pushed > > Justification: the next paragraphs make the distinction. > > along with the security information required for the communication > including the certificate of the Controller (or the certificate of > the Certification Authority which was used to issue the certificate > for the Controller). All this is expressed as a Channel. While > multiple Channels may be provided in the pre-configuration > information they must all be associated with a single Controller > (e.g. over different interfaces or network protocols). > > Where the MA pulls information from the Controller, the Pre- > Configuration Information also needs to contain the timing of the > communication with the Controller as well as the nature of the > communication itself (such as the protocol and data to be > transfered). The timing is given as a Schedule that executes the > Task(s) responsible for communication with the Controller. It is > this Task (or Tasks) that implement the Control protocol between the > MA and the Controller. The Task(s) may take additional parameters in > which case a Task Configuration can also be included. > > Even where information is pushed to the MA from the Controller > (rather than pulled by the MA), a Schedule still needs to be > supplied. In this case the Schedule will simply execute a Controller > listener task when the MA is started. A Channel is still required > for the MA to establish secure communication with the Controller. > > It can be seen that these Channels, Schedules and Task Configurations > for the initial MA-Controller communication are no different in terms > of the Information Model to any other Channel, Schedule or Task > Configuration that might execute a Measurement Task or report the > measurement results (as described later). > > The MA may be pre-configured with an MA ID, or may use a Device ID in > the initial Controller contact before it is assigned an MA ID. > > Again, I'm confused by this initial Controller. > > The > Device ID may be a MAC address or some other device identifier > expressed as a URN. If the MA ID is not provided at this stage then > it must be provided by the Controller during Configuration. > > Detail of the information model elements: > > > > Burbridge, et al. Expires February 21, 2015 [Page 8] > > Internet-Draft LMAP Information Model August 2014 > > > // MA pre-configuration minimal information to communicate initially with > Controller > > object { > [uuid ma-agent-id;] > ma-task-obj ma-control-tasks<1..*>; > ma-channel-obj ma-control-channels<1..*>; > ma-schedule-obj ma-control-schedules<1..*>; > [urn ma-device-id;] > credentials ma-credentials; > } ma-config-obj; > > The detail of the Channel and Schedule objects are described later > since they are common to several parts of the information model. > > 3.3. Configuration Information > > During registration or at any later point at which the MA contacts > the Controller (or vice-versa), the choice of Controller, > > "The choice of Controller", do you want to say "an alternate Controller", > because at this point the MA is already in contact with the Controller. > > details for > the timing of communication with the Controller or parameters for the > communication Task(s) can be changed (as captured by the Channels, > Schedules and Task Configurations objects). For example the pre- > configured Controller (specified as a Channel or Channels) may be > replaced with a specific Controller that is more appropriate to the > MA device type, location or characteristics of the network (e.g. > access technology type or broadband product). The initial > communication Schedule may be replaced with one more relevant to > routine communications between the MA and the Controller. > > While some Control protocols and uses may only use a single Schedule, > other protocols and uses may uses several Schedules (and related data > transfer Tasks) to update the Configuration Information, transfer the > Instruction Information, transfer Capability and Status Information > and send other information to the Controller such as log or error > notifications. Multiple Channels may be used to communicate with the > same Controller over multiple interfaces (e.g. to send logging > information over a different network). > > In addition the MA will be given further items of information that > relate specifically to the MA rather than the measurements it is to > conduct or how to report results. The assignment of an ID to the MA > is mandatory. If the MA Agent ID was not optionally provided during > the pre-configuration then one must be provided by the Controller > during Configuration. Optionally a Group ID may also be given which > identifies a group of interest to which that MA belongs. For example > the group could represent an ISP, broadband product, technology, > market classification, geographic region, or a combination of > multiple such characteristics. Where the Measurement Group ID is set > an additional flag (the Report MA ID flag) is required to control > > > > Burbridge, et al. Expires February 21, 2015 [Page 9] > > Internet-Draft LMAP Information Model August 2014 > > > whether the Measurement Agent ID is also to be reported. The > reporting of a Group ID without the MA ID allows the MA to remain > anonymous, which may be particularly useful to prevent tracking of > mobile MA devices. > > Optionally an MA can also be configured to stop executing any > Instruction Schedule if the Controller is unreachable. This can be > used as a fail-safe to stop Measurement and other Tasks being > conducted when there is doubt that the Instruction Information is > still valid. This is simply represented as a time window in > milliseconds since the last communication with the Controller after > which Instruction Schedules are to be suspended. The appropriate > vaue of the time window will depend on the specified communication > > value > > Schedule with the Controller and the duration for which the system is > willing to tolerate continued operation with potentially stale > Instruction Information. > > While pre-configuration is persistent upon device reset or power > cycle due to its very nature, the persistency of the addtional > configuration information may be control protocol dependent. > > Why "Control Protocol" dependent? > Why isn't the persistence IM (or DM) specific? > > Some > protocols may assume that reset devices will revert back to their > pre-configuration state, while other protocols may assume that all > configuration and instruction information is held in persistent > storage. > > It should be noted that control shedules and tasks cannot be > suppressed as evidenced by the lack of suppression information in the > Configuration. The control schedule must only reference tasks listed > as control tasks. Any suppress-by-default flag against control tasks > will be ignored. > > Detail of the additional and updated information model elements: > > // MA Configuration > > object { > uuid ma-agent-id; > [ma-task-obj ma-control-tasks<0..*>;] > ma-channel-obj ma-control-channels<1..*>; > [ma-schedule-obj ma-control-schedules<0..*>]; > [urn ma-device-id;] > credentials ma-credentials; > [string ma-group-id;] > [boolean ma-report-ma-id-flag;] > [int ma-control-channel-failure-threshold;] > } ma-config-obj; > > > That's where I arrived. > > And now, time for a Guinness or two. I'm in Dublin after all :-) > > Regards, Benoit > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > --001a11c1c11c8a62c30503415824 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Benoit,
on just one question:
Logging always goes to the Collector, right?
According to LMAP framework document Logging goes over Control, not Repo= rt Channel:
   Control Channel: A Channel between a Controller and =
a MA over which
   Instruction Messages and Capabilities, Failure and Logging
   Information are sent.

Regards,
Greg
<=
/pre>

On= Sun, Sep 14, 2014 at 11:38 PM, Benoit Claise <bclaise@cisco.com> wrote:
=20 =20 =20
Dear all,

Since we will be spending time on draft-ietf-lmap-information-model tomorrow, here is some more feedback. I haven't had the time to review it all, so here is par= t 1.
If some points were already discussed, don't hesitate to let me know.

Network Working Group=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 T. Burbridge
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 P. Eardley
Intended status: Standards Track=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 BT
Expires: February 21, 2015=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 M. Bagnulo
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Universidad Carlos III de Madrid
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 J. Schoenwaelder
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Jacobs Univ= ersity Bremen
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 August 20, 2014


=C2=A0=C2=A0=C2=A0=C2=A0 Information Model for Large-Scale Measuremen= t Platforms (LMAP)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-ietf-lmap-information-model-02
What does LMAP stand for?
In the use cases draft, it says "Large-scale Measurement of Broadband Performance (LMAP)"
Both the framework and the information model say: Large-Scale Measurement Platforms (LMAP)


Abstract

=C2=A0=C2=A0 This Information Model applies to the Measurement Agent = within a
=C2=A0=C2=A0 Large-Scale Measurement Platform.=C2=A0 As such it outli= nes the
=C2=A0=C2=A0 information that is (pre-)configured on the MA or exists= in
=C2=A0=C2=A0 communications with a Controller or Collector within an = LMAP
=C2=A0=C2=A0 framework.=C2=A0 The purpose of such an Information Mode= l is to provide a
=C2=A0=C2=A0 protocol and device independent view of the MA that can = be
=C2=A0=C2=A0 implemented via one or more Control and Report protocols= .

Requirements Language

=C2=A0=C2=A0 The key words "MUST", "MUST NOT", &q= uot;REQUIRED", "SHALL", "SHALL NOT",
=C2=A0=C2=A0 "SHOULD", "SHOULD NOT", "RECOMM= ENDED", "MAY", and "OPTIONAL" in this
=C2=A0=C2=A0 document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

=C2=A0=C2=A0 This Internet-Draft is submitted in full conformance wit= h the
=C2=A0=C2=A0 provisions of BCP 78 and BCP 79.

=C2=A0=C2=A0 Internet-Drafts are working documents of the Internet Engineering
=C2=A0=C2=A0 Task Force (IETF).=C2=A0 Note that other groups may also= distribute
=C2=A0=C2=A0 working documents as Internet-Drafts.=C2=A0 The list of = current Internet-
=C2=A0=C2=A0 Drafts is at http://datatracker.ietf.org/drafts/current/<= /a>.

=C2=A0=C2=A0 Internet-Drafts are draft documents valid for a maximum = of six months
=C2=A0=C2=A0 and may be updated, replaced, or obsoleted by other docu= ments at any
=C2=A0=C2=A0 time.=C2=A0 It is inappropriate to use Internet-Drafts a= s reference
=C2=A0=C2=A0 material or to cite them other than as "work in pro= gress."

=C2=A0=C2=A0 This Internet-Draft will expire on February 21, 2015.






Burbridge, et al.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expires Februar= y 21, 2015=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 [Page 1]
=0C
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 LMAP Information Model=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 August 2014


Copyright Notice

=C2=A0=C2=A0 Copyright (c) 2014 IETF Trust and the persons identified= as the
=C2=A0=C2=A0 document authors.=C2=A0 All rights reserved.

=C2=A0=C2=A0 This document is subject to BCP 78 and the IETF Trust= 9;s Legal
=C2=A0=C2=A0 Provisions Relating to IETF Documents
=C2=A0=C2=A0 (http://trustee.ietf.org/license-info) in effect on the date= of
=C2=A0=C2=A0 publication of this document.=C2=A0 Please review these = documents
=C2=A0=C2=A0 carefully, as they describe your rights and restrictions= with respect
=C2=A0=C2=A0 to this document.=C2=A0 Code Components extracted from t= his document must
=C2=A0=C2=A0 include Simplified BSD License text as described in Sect= ion 4.e of
=C2=A0=C2=A0 the Trust Legal Provisions and are provided without warr= anty as
=C2=A0=C2=A0 described in the Simplified BSD License.

Table of Contents

=C2=A0=C2=A0 1.=C2=A0 Introduction=C2=A0 . . . . . . . . . . . . . . = . . . . . . . . . .=C2=A0=C2=A0 3
=C2=A0=C2=A0 2.=C2=A0 Notation=C2=A0 . . . . . . . . . . . . . . . . = . . . . . . . . . .=C2=A0=C2=A0 4
=C2=A0=C2=A0 3.=C2=A0 LMAP Information Model=C2=A0 . . . . . . . . . = . . . . . . . . . .=C2=A0=C2=A0 4
=C2=A0=C2=A0=C2=A0=C2=A0 3.1.=C2=A0 Information Structure . . . . . .= . . . . . . . . . . . .=C2=A0=C2=A0 4
=C2=A0=C2=A0=C2=A0=C2=A0 3.2.=C2=A0 Pre-Configuration Information . .= . . . . . . . . . . . .=C2=A0=C2=A0 8
=C2=A0=C2=A0=C2=A0=C2=A0 3.3.=C2=A0 Configuration Information . . . .= . . . . . . . . . . . .=C2=A0=C2=A0 9
=C2=A0=C2=A0=C2=A0=C2=A0 3.4.=C2=A0 Instruction Information . . . . .= . . . . . . . . . . . .=C2=A0 11
=C2=A0=C2=A0=C2=A0=C2=A0 3.5.=C2=A0 Logging Information . . . . . . .= . . . . . . . . . . . .=C2=A0 13
=C2=A0=C2=A0=C2=A0=C2=A0 3.6.=C2=A0 Capability and Status Information= . . . . . . . . . . . .=C2=A0 15
=C2=A0=C2=A0=C2=A0=C2=A0 3.7.=C2=A0 Reporting Information . . . . . .= . . . . . . . . . . . .=C2=A0 17
=C2=A0=C2=A0=C2=A0=C2=A0 3.8.=C2=A0 Schedules . . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 18
=C2=A0=C2=A0=C2=A0=C2=A0 3.9.=C2=A0 Channels=C2=A0 . . . . . . . . . = . . . . . . . . . . . . . . .=C2=A0 21
=C2=A0=C2=A0=C2=A0=C2=A0 3.10. Task Configurations . . . . . . . . . = . . . . . . . . . .=C2=A0 22
=C2=A0=C2=A0=C2=A0=C2=A0 3.11. Timing Information=C2=A0 . . . . . . .= . . . . . . . . . . . .=C2=A0 23
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3.11.1.=C2=A0 Periodic Timing=C2= =A0 . . . . . . . . . . . . . . . . . .=C2=A0 24
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3.11.2.=C2=A0 Calendar Timing=C2= =A0 . . . . . . . . . . . . . . . . . .=C2=A0 25
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3.11.3.=C2=A0 One-Off Timing . .= . . . . . . . . . . . . . . . . .=C2=A0 26
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3.11.4.=C2=A0 Immediate Timing .= . . . . . . . . . . . . . . . . .=C2=A0 26
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3.11.5.=C2=A0 Startup Timing . .= . . . . . . . . . . . . . . . . .=C2=A0 26
=C2=A0=C2=A0 4.=C2=A0 IANA Considerations . . . . . . . . . . . . . .= . . . . . . .=C2=A0 26
=C2=A0=C2=A0 5.=C2=A0 Security Considerations . . . . . . . . . . . .= . . . . . . .=C2=A0 26
=C2=A0=C2=A0 6.=C2=A0 Appendix: JSON Example=C2=A0 . . . . . . . . . = . . . . . . . . . .=C2=A0 27
=C2=A0=C2=A0 7.=C2=A0 Acknowledgements=C2=A0 . . . . . . . . . . . . = . . . . . . . . . .=C2=A0 35
=C2=A0=C2=A0 8.=C2=A0 References=C2=A0 . . . . . . . . . . . . . . . = . . . . . . . . . .=C2=A0 35
=C2=A0=C2=A0=C2=A0=C2=A0 8.1.=C2=A0 Normative References=C2=A0 . . . = . . . . . . . . . . . . . . .=C2=A0 35
=C2=A0=C2=A0=C2=A0=C2=A0 8.2.=C2=A0 Informative References=C2=A0 . . = . . . . . . . . . . . . . . .=C2=A0 35
=C2=A0=C2=A0 Authors' Addresses=C2=A0 . . . . . . . . . . . . . .= . . . . . . . . .=C2=A0 35







Burbridge, et al.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expires Februar= y 21, 2015=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 [Page 2]
=0C
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 LMAP Information Model=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 August 2014


1.=C2=A0 Introduction

=C2=A0=C2=A0 A large-scale measurement platform is a collection of components that
=C2=A0=C2=A0 work in a coordinated fashion to perform measurements fr= om a large
=C2=A0=C2=A0 number of vantage points.=C2=A0 The main components of a= large-scale
=C2=A0=C2=A0 measurement platform are the Measurement Agents (hereaft= er MAs), the
=C2=A0=C2=A0 Controller(s) and the Collector(s).

=C2=A0=C2=A0 The MAs are the elements actually performing the measure= ments.=C2=A0 The
=C2=A0=C2=A0 MAs are controlled by exactly one Controller at a time a= nd the
=C2=A0=C2=A0 Collectors gather the results generated by the MAs.=C2= =A0 In a nutshell,
=C2=A0=C2=A0 the normal operation of a large-scale measurement platfo= rm starts
=C2=A0=C2=A0 with the Controller instructing a set of one or more MAs= to perform a
=C2=A0=C2=A0 set of one or more Measurement Tasks at a certain point = in time.=C2=A0 The
=C2=A0=C2=A0 MAs execute the instructions from a Controller, and once= they have
=C2=A0=C2=A0 done so, they report the results of the measurements to = one or more
=C2=A0=C2=A0 Collectors.=C2=A0 The overall framework for a Large Meas= urement platform
=C2=A0=C2=A0 as used in this document is described in detail in
=C2=A0=C2=A0 [I-D.ietf-lmap-framework].

=C2=A0=C2=A0 A large-scale measurement platform involves basically th= ree
=C2=A0=C2=A0 protocols, namely, a Control protocol between a Controll= er and the
Control Protocol
=C2=A0=C2=A0 MAs, a Report protocol between the MAs and the Collector(s) and
=C2=A0=C2=A0 several measurement protocols between the MAs and Measur= ement Peers
=C2=A0=C2=A0 (MPs), used to actually perform the measurements.=C2=A0 = In addition some
=C2=A0=C2=A0 information is required to be configured on the MA prior= to any
=C2=A0=C2=A0 communication with the initial Controller.
"initial" confused me.
It's only later (section 3.3) that I understood that the Controller could be changed.
Candidate for removal, improvement, or forward reference?

=C2=A0=C2=A0 This document defines the information model for both the Control and
=C2=A0=C2=A0 the Report protocol along with pre-configuration informa= tion that is
=C2=A0=C2=A0 required
add "on the MA"
before communicating with the Controller, broadly named as
=C2=A0=C2=A0 the LMAP Information Model.=C2=A0 The measurement protoc= ols are out of the
=C2=A0=C2=A0 scope of this document.

=C2=A0=C2=A0 As defined in [RFC3444], the LMAP IM defines the concept= s involved in
IM =3D Information Model
this is the first occurrence.

=C2=A0=C2=A0 a large-scale measurement platform at a high level of abstraction,
=C2=A0=C2=A0 independent of any specific implementation or actual pro= tocol used to
=C2=A0=C2=A0 exchange the information.=C2=A0 It is expected that the = proposed
=C2=A0=C2=A0 information model can be used with different protocols i= n different
=C2=A0=C2=A0 measurement platform architectures and across different = types of MA
=C2=A0=C2=A0 devices (e.g., home gateway, smartphone, PC, router).

=C2=A0=C2=A0 The definition of an Information Model serves a number o= f purposes:

=C2=A0=C2=A0 1.=C2=A0 To guide the standardisation of one or more Con= trol and Report
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 protocol and data model implemen= tations





Burbridge, et al.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expires Februar= y 21, 2015=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 [Page 3]
=0C
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 LMAP Information Model=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 August 2014


=C2=A0=C2=A0 2.=C2=A0 To enable high-level inter-operability between = different Control
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and Report protocols by facilita= ting translation between their
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 respective data models such that= a Controller could instruct sub-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 populations of MAs using differe= nt protocols

=C2=A0=C2=A0 3.=C2=A0 To form agreement of what information needs to = be held by an MA
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and passed over the Control and = Report interfaces and support the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 functionality described in the L= MAP framework

=C2=A0=C2=A0 4.=C2=A0 Enable existing protocols and data models to be= assessed for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 their suitability as part of a l= arge-scale measurement system

2.=C2=A0 Notation

=C2=A0=C2=A0 This document use an object-oriented programming-like no= tation to
=C2=A0=C2=A0 define the parameters (names/values) of the objects of t= he
=C2=A0=C2=A0 information model.=C2=A0 An optional field is enclosed b= y [ ], and an
=C2=A0=C2=A0 array is indicated by two numbers in angle brackets, <m..n>, where m
=C2=A0=C2=A0 indicates the minimal number of values, and n is the max= imum.=C2=A0 The
=C2=A0=C2=A0 symbol * for n means no upper bound.

3.=C2=A0 LMAP Information Model

3.1.=C2=A0 Information Structure

=C2=A0=C2=A0 The information described herein relates to the informat= ion stored,
=C2=A0=C2=A0 received or transmitted by a Measurement Agent as descri= bed within
=C2=A0=C2=A0 the LMAP framework [I-D.ietf-lmap-framework].=C2=A0 Should the framework be normative? I believe so, specifically when I see all those Capitalized terms that are only defined in the framework.
This leads to another point. You miss a terminology section because some terms are specific to this document. Example: Task Suppression.
As such, some subsets
=C2=A0=C2=A0 of this information model are applicable to the measurem= ent
=C2=A0=C2=A0 Controller, Collector
add a ","
Otherwise we can believe that the Collector could pre-configure the MA.
and systems that pre-configure the Measurement
=C2=A0=C2=A0 Agent.=C2=A0 The information described in these models w= ill be transmitted
=C2=A0=C2=A0 by protocols using interfaces between the Measurement Ag= ent and such
=C2=A0=C2=A0 systems according to a Data Model.

=C2=A0=C2=A0 For clarity the information model is divided into six se= ctions:

=C2=A0=C2=A0 1.=C2=A0 Pre-Configuration Information.=C2=A0 Informatio= n pre-configured on the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Measurement Agent prior to any c= ommunication with other
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 components of the LMAP architect= ure (i.e., the Controller,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Collector and Measurement Peers)= , specifically detailing how to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communicate with a Controller an= d whether the device is enabled
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to participate as an MA.

=C2=A0=C2=A0 2.=C2=A0 Configuration Information.=C2=A0 Update of the = pre-configuration
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 information during the registrat= ion of the MA or subsequent
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communication with the Controlle= r, along with the configuration
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of further parameters about the = MA (rather than the Tasks it




Burbridge, et al.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expires Februar= y 21, 2015=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 [Page 4]
=0C
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 LMAP Information Model=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 August 2014


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 should perform) that were not ma= ndatory for the initial
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communication between the MA and= a Controller.

=C2=A0=C2=A0 3.=C2=A0 Instruction Information.=C2=A0 Information that= is received by the MA
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 from the Controller pertaining t= o the Tasks that should be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 executed.=C2=A0 This includes th= e task execution Schedules (other than
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the Controller communication Sch= edule supplied as
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (pre)configuration information) = and related information such as
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the Task Configuration, communic= ation Channels to Collectors and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 schedule Timing information.=C2= =A0 It also inlcudes Task Suppression
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 information that is used to over= -ride normal Task execution
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 during emergency situations.

=C2=A0=C2=A0 4.=C2=A0 Logging Information.=C2=A0 Information transmit= ted from the MA to the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Controller detailing the results= of any configuration operations
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 along with error and status info= rmation from the operation of the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MA.

=C2=A0=C2=A0 5.=C2=A0 Capability and Status Information.=C2=A0 Inform= ation on the general
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 status and capabilities of the M= A.=C2=A0 For example, the set of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 measurements that are supported = on the device.

=C2=A0=C2=A0 6.=C2=A0 Reporting Information.=C2=A0 Information transm= itted from the MA to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 one or more Collectors including= measurement results and the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 context in which they were condu= cted.

=C2=A0=C2=A0 In addition the MA may hold further information not desc= ribed herein,
=C2=A0=C2=A0 and which may be optionally transferred to or from other systems
=C2=A0=C2=A0 including the Controller and Collector.=C2=A0 One exampl= e of information
=C2=A0=C2=A0 in this category is subscriber or line information that = may be
=C2=A0=C2=A0 extracted by a task and reported by the MA in the report= ing
=C2=A0=C2=A0 communication to a Collector.

=C2=A0=C2=A0 It should also be noted that the MA may be in communicat= ion with
The "MA" or the "MA device"?
I'm asking because the rest of the sentence speaks about "configuring", and we said that MA can only be configured by = one and only one Controller.
=C2=A0=C2=A0 other management systems which may be responsible for configuring and
=C2=A0=C2=A0 retrieving information from the MA device.=C2=A0 Such sy= stems, where
=C2=A0=C2=A0 available, can perform an important role in transferring= the pre-
=C2=A0=C2=A0 configuration information to the MA or enabling/disablin= g the
=C2=A0=C2=A0 measurement functionality of the MA.
"such systemS" ... "enabling/disabling the measurement functionality of the MA."
This is not possible. See my previous point.

=C2=A0=C2=A0 The Information Model is divided into sub-sections for a= number of
=C2=A0=C2=A0 reasons.=C2=A0 Firstly the grouping of information facil= itates reader
=C2=A0=C2=A0 understanding.=C2=A0 Secondly, the particular groupings = chosen are
=C2=A0=C2=A0 expected to map to different protocols or different transmissions
=C2=A0=C2=A0 within those protocols.

=C2=A0=C2=A0 The granularity of data transmitted in each operation of= the Control
=C2=A0=C2=A0 and Report Protocols is not dictated by the Information = Model.=C2=A0 For



Burbridge, et al.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expires Februar= y 21, 2015=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 [Page 5]
=0C
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 LMAP Information Model=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 August 2014


=C2=A0=C2=A0 example, the Instruction object may be delivered in a si= ngle
=C2=A0=C2=A0 operation.=C2=A0 Alternatively, Schedules and Task Confi= gurations may be
=C2=A0=C2=A0 separated or even each Schdule/Task Configuration may be delivered
=C2=A0=C2=A0 individually.=C2=A0 Similarly the Information Model does= not dictate
=C2=A0=C2=A0 whether data is read, write, or read/write.=C2=A0 For ex= ample, some
=C2=A0=C2=A0 Control Protocols may have the ability to read back Configuration and
=C2=A0=C2=A0 Instruction information which have been previosuly set o= n the MA.
=C2=A0=C2=A0 Lastly, while some protocols may simply overwrite inform= ation (for
=C2=A0=C2=A0 example refreshing the entire Instruction Information), = other
=C2=A0=C2=A0 protocols may have the ability to update or delete selec= ted items of
=C2=A0=C2=A0 information.

=C2=A0=C2=A0 The information in these six sections is captured by a n= umber of
=C2=A0=C2=A0 common information objects.=C2=A0 These objects are also= described later
=C2=A0=C2=A0 in this document and comprise of:

=C2=A0=C2=A0 1.=C2=A0 Schedules.=C2=A0 A set of Schedules tell the MA= to do something.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Without a Schedule no Task (from= a measurement to reporting or
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communicating with the Controlle= r) is ever executed.=C2=A0 Schedules
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 are used within the Instruction = to specify what tasks should be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 performed, when, and how to dire= ct their results.=C2=A0 A Schedule is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 also used within the pre-Configu= ration and Configuration
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 information in order to execute = the Task or Tasks required to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communicate with the Controller.

=C2=A0=C2=A0 2.=C2=A0 Channels.=C2=A0 A set of Channel objects are us= ed to communicate with
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a number of endpoints (i.e. the = Controller and Collectors).=C2=A0
OLD: (i.e. the Controller and Collectors).=C2=A0
NEW: (the Controller, Collectors, and MAs).=C2=A0

These are the only 3 possibilities, right?
Logging always goes to the Collector, right?

Each
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Channel object contains the info= rmation required for the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communication with a single endp= oint such as the target location
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and security details.=C2=A0 Chan= nels are referenced from within
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Schedules in order to say how Ta= sks should communicate.

=C2=A0=C2=A0 3.=C2=A0 Task Configurations.=C2=A0 A set of Task Config= urations is used to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 configure the Tasks that are run= by the MA.=C2=A0 This includes the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 registry entry for the Task and = any configuration parameters.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Task Configurations are referenc= ed from a Schedule in order to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 specify what Tasks the MA should= execute.

=C2=A0=C2=A0 4.=C2=A0 Timings.=C2=A0 A set of Timing objects that can= be referenced from the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Schedules.=C2=A0 Each Schedule a= lways references exactly one Timing
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 object.=C2=A0 A Timing object sp= ecfies either a singleton or series of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 time events.=C2=A0 They are used= to indicate when Tasks should be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 executed.

=C2=A0=C2=A0 The following diagram illustrates the structure in which= these common
=C2=A0=C2=A0 information objects are referenced.=C2=A0 The references= are achieved by
=C2=A0=C2=A0 each object (Channel, Task Configuration, Timing) being = given a short




Burbridge, et al.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expires Februar= y 21, 2015=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 [Page 6]
=0C
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 LMAP Information Model=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 August 2014


=C2=A0=C2=A0 text name that is used by other objects.=C2=A0 The objec= ts shown in
=C2=A0=C2=A0 parenthesis are part of the internal object structure of= a Schedule.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Schedule
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |----------> Timing
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |----------> (Scheduled Tasks)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |---------->= ; Task Configuration
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |---------->= ; (Task Channels and downstream Tasks)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |----------> Channels
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |----------> Downstream Tasks
Please number the figures.

Why is only "configuration" mentioned in the figure?
I understood that everything is now a task:
=C2=A0=C2=A0=C2=A0 controller communication
=C2=A0=C2=A0=C2=A0 reporting
=C2=A0=C2=A0=C2=A0 measurement
=C2=A0=C2=A0=C2=A0 data aggregation
=C2=A0=C2=A0=C2=A0 ...
This was confusing to me.



=C2=A0=C2=A0 It should be clear that the top-level bahaviour of an MA= is simply to
=C2=A0=C2=A0 execute Schedules.=C2=A0 Every action referenced by a Sc= hedule is defined
=C2=A0=C2=A0 as a Task.=C2=A0 As such, these actions are configured t= hrough Task
=C2=A0=C2=A0 Configurations and executed according to the Timing refe= renced by the
=C2=A0=C2=A0 Schedule in which they appear.=C2=A0 Tasks can implement= a variety of
=C2=A0=C2=A0 different types of actions.=C2=A0 While in terms of the = Information Model,
=C2=A0=C2=A0 all Tasks have the same structure, it can help conceptua= lly to think
=C2=A0=C2=A0 of different Task categories:

=C2=A0=C2=A0 1.=C2=A0 Measurement Tasks

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A.=C2=A0 Measurement Tasks measu= re some aspect of network performance
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or traff= ic

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 B.=C2=A0 Data Capture Tasks capt= ure and analyse passive information
Why capture? We can analyse without capture.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 stored on the MA device such as counters and device/network
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 status i= nformation

Why not traffic?
From 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


=C2=A0=C2=A0 2.=C2=A0 Data Transfer Tasks

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A.=C2=A0 Reporting Tasks report = the results or Measurement Tasks to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Collecto= rs
"Reporting Tasks report Measurement Tasks to Collectors"
Really? So the Controller configures the Reporting Tasks on the MA, and the MA reports them to the Collector?

Maybe you meant?
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A.=C2=A0 Reporting Tasks report th= e results of Measurement Tasks to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Collectors

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 B.=C2=A0 Control Task(s) impleme= nt the Control Protocol and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communic= ate with the Controller.=C2=A0 Depending on the Control
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Protocol= this may be a number of specialist tasks such as:
What is "this"?
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Configuration Task; Instruction Task; Suppression Task;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Capabili= ties Task; Logging Task etc.

=C2=A0=C2=A0 3.=C2=A0 Data Analysis Tasks can exist to analyse data f= rom other
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Measurement Tasks locally on the= MA

=C2=A0=C2=A0 4.=C2=A0 Data Management Tasks may exist to clean-up, fi= lter or compress
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 data on the MA such as Measureme= nt Task results






Burbridge, et al.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expires Februar= y 21, 2015=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 [Page 7]
=0C
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 LMAP Information Model=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 August 2014


3.2.=C2=A0 Pre-Configuration Information

=C2=A0=C2=A0 This information is the minimal information that needs t= o be pre-
=C2=A0=C2=A0 configured to the MA in order for it to successfully communicate with
=C2=A0=C2=A0 a Controller during the registration process.=C2=A0 In section 3.1, we learned:
   1.  Pre-Configuration Information.  Information pre-configured =
on the
       Measurement Agent prior to any communication with other
       components of the LMAP architecture (i.e., the Controller,
       Collector and Measurement Peers), specifically detailing how to
       communicate with a Controller and whether the device is enabled
       to participate as an MA.
So the pre-configuration information is only for the Controller communication (I guess so) or also for the collector and measurement peers?
The pre-configuration
=C2=A0=C2=A0 information is a subset of the Configuration Information= along with
=C2=A0=C2=A0 some parameters that are not under the control of the LM= AP framework
=C2=A0=C2=A0 (such as the the device identifier and device security credentials).
I can't parse "not under the control of the LMAP framework&quo= t;

=C2=A0=C2=A0 This pre-configuration information needs to include a UR= L of the
=C2=A0=C2=A0 initial Controller where configuration information can b= e retrieved
OLD: retrieved
NEW: communicated
NEW (alternative): pulled or pushed

Justification: the next paragraphs make the distinction.
=C2=A0=C2=A0 along with the security information required for the communication
=C2=A0=C2=A0 including the certificate of the Controller (or the cert= ificate of
=C2=A0=C2=A0 the Certification Authority which was used to issue the certificate
=C2=A0=C2=A0 for the Controller).=C2=A0 All this is expressed as a Ch= annel.=C2=A0 While
=C2=A0=C2=A0 multiple Channels may be provided in the pre-configurati= on
=C2=A0=C2=A0 information they must all be associated with a single Controller
=C2=A0=C2=A0 (e.g. over different interfaces or network protocols).

=C2=A0=C2=A0 Where the MA pulls information from the Controller, the = Pre-
=C2=A0=C2=A0 Configuration Information also needs to contain the timi= ng of the
=C2=A0=C2=A0 communication with the Controller as well as the nature = of the
=C2=A0=C2=A0 communication itself (such as the protocol and data to b= e
=C2=A0=C2=A0 transfered).=C2=A0 The timing is given as a Schedule tha= t executes the
=C2=A0=C2=A0 Task(s) responsible for communication with the Controlle= r.=C2=A0 It is
=C2=A0=C2=A0 this Task (or Tasks) that implement the Control protocol between the
=C2=A0=C2=A0 MA and the Controller.=C2=A0 The Task(s) may take additi= onal parameters in
=C2=A0=C2=A0 which case a Task Configuration can also be included.

=C2=A0=C2=A0 Even where information is pushed to the MA from the Cont= roller
=C2=A0=C2=A0 (rather than pulled by the MA), a Schedule still needs t= o be
=C2=A0=C2=A0 supplied.=C2=A0 In this case the Schedule will simply ex= ecute a Controller
=C2=A0=C2=A0 listener task when the MA is started.=C2=A0 A Channel is= still required
=C2=A0=C2=A0 for the MA to establish secure communication with the Controller.

=C2=A0=C2=A0 It can be seen that these Channels, Schedules and Task Configurations
=C2=A0=C2=A0 for the initial MA-Controller communication are no diffe= rent in terms
=C2=A0=C2=A0 of the Information Model to any other Channel, Schedule = or Task
=C2=A0=C2=A0 Configuration that might execute a Measurement Task or r= eport the
=C2=A0=C2=A0 measurement results (as described later).

=C2=A0=C2=A0 The MA may be pre-configured with an MA ID, or may use a= Device ID in
=C2=A0=C2=A0 the initial Controller contact before it is assigned an = MA ID.=C2=A0
Again, I'm confused by this initial Controller.=C2=A0=C2=A0

The
=C2=A0=C2=A0 Device ID may be a MAC address or some other device iden= tifier
=C2=A0=C2=A0 expressed as a URN.=C2=A0 If the MA ID is not provided a= t this stage then
=C2=A0=C2=A0 it must be provided by the Controller during Configurati= on.

=C2=A0=C2=A0 Detail of the information model elements:



Burbridge, et al.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expires Februar= y 21, 2015=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 [Page 8]
=0C
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 LMAP Information Model=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 August 2014


// MA pre-configuration minimal information to communicate initially with Controller

object {
=C2=A0=C2=A0=C2=A0 [uuid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ma-agent-id;]
=C2=A0=C2=A0=C2=A0=C2=A0 ma-task-obj=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ma-control-tasks<1..*>;
=C2=A0=C2=A0=C2=A0=C2=A0 ma-channel-obj=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= ma-control-channels<1..*>;
=C2=A0=C2=A0=C2=A0=C2=A0 ma-schedule-obj=C2=A0=C2=A0=C2=A0=C2=A0 ma-c= ontrol-schedules<1..*>;
=C2=A0=C2=A0=C2=A0 [urn=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ma-device-id;]
=C2=A0=C2=A0=C2=A0=C2=A0 credentials=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ma-credentials;
} ma-config-obj;

=C2=A0=C2=A0 The detail of the Channel and Schedule objects are descr= ibed later
=C2=A0=C2=A0 since they are common to several parts of the informatio= n model.

3.3.=C2=A0 Configuration Information

=C2=A0=C2=A0 During registration or at any later point at which the M= A contacts
=C2=A0=C2=A0 the Controller (or vice-versa), the choice of Controller= ,
"The choice of Controller", do you want to say "an alter= nate Controller", because at this point the MA is already in contact wi= th the Controller.
details for
=C2=A0=C2=A0 the timing of communication with the Controller or param= eters for the
=C2=A0=C2=A0 communication Task(s) can be changed (as captured by the Channels,
=C2=A0=C2=A0 Schedules and Task Configurations objects).=C2=A0 For ex= ample the pre-
=C2=A0=C2=A0 configured Controller (specified as a Channel or Channel= s) may be
=C2=A0=C2=A0 replaced with a specific Controller that is more appropr= iate to the
=C2=A0=C2=A0 MA device type, location or characteristics of the netwo= rk (e.g.
=C2=A0=C2=A0 access technology type or broadband product).=C2=A0 The = initial
=C2=A0=C2=A0 communication Schedule may be replaced with one more rel= evant to
=C2=A0=C2=A0 routine communications between the MA and the Controller= .

=C2=A0=C2=A0 While some Control protocols and uses may only use a sin= gle Schedule,
=C2=A0=C2=A0 other protocols and uses may uses several Schedules (and related data
=C2=A0=C2=A0 transfer Tasks) to update the Configuration Information, transfer the
=C2=A0=C2=A0 Instruction Information, transfer Capability and Status Information
=C2=A0=C2=A0 and send other information to the Controller such as log= or error
=C2=A0=C2=A0 notifications.=C2=A0 Multiple Channels may be used to co= mmunicate with the
=C2=A0=C2=A0 same Controller over multiple interfaces (e.g. to send l= ogging
=C2=A0=C2=A0 information over a different network).

=C2=A0=C2=A0 In addition the MA will be given further items of inform= ation that
=C2=A0=C2=A0 relate specifically to the MA rather than the measuremen= ts it is to
=C2=A0=C2=A0 conduct or how to report results.=C2=A0 The assignment o= f an ID to the MA
=C2=A0=C2=A0 is mandatory.=C2=A0 If the MA Agent ID was not optionall= y provided during
=C2=A0=C2=A0 the pre-configuration then one must be provided by the Controller
=C2=A0=C2=A0 during Configuration.=C2=A0 Optionally a Group ID may al= so be given which
=C2=A0=C2=A0 identifies a group of interest to which that MA belongs.= =C2=A0 For example
=C2=A0=C2=A0 the group could represent an ISP, broadband product, technology,
=C2=A0=C2=A0 market classification, geographic region, or a combinati= on of
=C2=A0=C2=A0 multiple such characteristics.=C2=A0 Where the Measureme= nt Group ID is set
=C2=A0=C2=A0 an additional flag (the Report MA ID flag) is required t= o control



Burbridge, et al.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expires Februar= y 21, 2015=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 [Page 9]
=0C
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 LMAP Information Model=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 August 2014


=C2=A0=C2=A0 whether the Measurement Agent ID is also to be reported.= =C2=A0 The
=C2=A0=C2=A0 reporting of a Group ID without the MA ID allows the MA = to remain
=C2=A0=C2=A0 anonymous, which may be particularly useful to prevent t= racking of
=C2=A0=C2=A0 mobile MA devices.

=C2=A0=C2=A0 Optionally an MA can also be configured to stop executin= g any
=C2=A0=C2=A0 Instruction Schedule if the Controller is unreachable.= =C2=A0 This can be
=C2=A0=C2=A0 used as a fail-safe to stop Measurement and other Tasks = being
=C2=A0=C2=A0 conducted when there is doubt that the Instruction Infor= mation is
=C2=A0=C2=A0 still valid.=C2=A0 This is simply represented as a time = window in
=C2=A0=C2=A0 milliseconds since the last communication with the Contr= oller after
=C2=A0=C2=A0 which Instruction Schedules are to be suspended.=C2=A0 T= he appropriate
=C2=A0=C2=A0 vaue of the time window will depend on the specified communication
value
=C2=A0=C2=A0 Schedule with the Controller and the duration for which the system is
=C2=A0=C2=A0 willing to tolerate continued operation with potentially= stale
=C2=A0=C2=A0 Instruction Information.

=C2=A0=C2=A0 While pre-configuration is persistent upon device reset = or power
=C2=A0=C2=A0 cycle due to its very nature, the persistency of the add= tional
=C2=A0=C2=A0 configuration information may be control protocol depend= ent.=C2=A0
Why "Control Protocol" dependent?
Why isn't the persistence IM (or DM) specific?
Some
=C2=A0=C2=A0 protocols may assume that reset devices will revert back= to their
=C2=A0=C2=A0 pre-configuration state, while other protocols may assum= e that all
=C2=A0=C2=A0 configuration and instruction information is held in per= sistent
=C2=A0=C2=A0 storage.

=C2=A0=C2=A0 It should be noted that control shedules and tasks canno= t be
=C2=A0=C2=A0 suppressed as evidenced by the lack of suppression infor= mation in the
=C2=A0=C2=A0 Configuration.=C2=A0 The control schedule must only refe= rence tasks listed
=C2=A0=C2=A0 as control tasks.=C2=A0 Any suppress-by-default flag aga= inst control tasks
=C2=A0=C2=A0 will be ignored.

=C2=A0=C2=A0 Detail of the additional and updated information model elements:

=C2=A0=C2=A0 // MA Configuration

=C2=A0=C2=A0 object {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uuid=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ma-agent-id= ;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [ma-task-obj=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ma-control-tasks<0..*>;]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ma-channel-obj=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 ma-control-channels<1..*>;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [ma-schedule-obj=C2=A0=C2=A0=C2=A0 ma-= control-schedules<0..*>];
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [urn=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ma-device-i= d;]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 credentials=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 ma-credentials;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [string=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ma-group-id;]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [boolean=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ma-report-ma-id-flag;]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [int=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ma-control-= channel-failure-threshold;]
=C2=A0=C2=A0 } ma-config-obj;


That's where I arrived.

And now, time for a Guinness or two. I'm in Dublin after all :-)
Regards, Benoit


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


--001a11c1c11c8a62c30503415824-- From nobody Thu Sep 18 02:41:19 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 DD5E11A8718 for ; Thu, 18 Sep 2014 02:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Efqdjd4_fjrl for ; Thu, 18 Sep 2014 02:41:08 -0700 (PDT) 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 EAB8C1A7006 for ; Thu, 18 Sep 2014 02:41:06 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 18 Sep 2014 10:41:17 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.45]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Thu, 18 Sep 2014 10:40:59 +0100 From: To: , Date: Thu, 18 Sep 2014 10:40:58 +0100 Thread-Topic: [lmap] Feedback on draft-ietf-lmap-information-model Thread-Index: Ac/SbFdzgB2zgRIwS8uJvWX8FYF2XwAt9fTQ Message-ID: References: <5416090C.5070402@cisco.com> <541618E8.3060200@cisco.com> 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_A2E337CDB7BC4145B018B9BEE8EB3E0D4135F72CA7EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/FNy1IipqDoC1xARrzJlvz7JZqPw Cc: lmap@ietf.org Subject: Re: [lmap] Feedback on draft-ietf-lmap-information-model X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 09:41:17 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D4135F72CA7EMV67UKRDdoma_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgdGhpbmsgdGhlIHRleHQgQmVub2l0IHdhcyBjb21tZW50aW5nIG9uIGlzOg0KPDwg ICAyLiAgQ2hhbm5lbHMuICBBIHNldCBvZiBDaGFubmVsIG9iamVjdHMgYXJlIHVzZWQgdG8gY29t bXVuaWNhdGUgd2l0aA0KICAgICAgIGEgbnVtYmVyIG9mIGVuZHBvaW50cyAoaS5lLiB0aGUgQ29u dHJvbGxlciBhbmQgQ29sbGVjdG9ycykuDQo+Pg0KQmVub2l0IGlzIHJpZ2h0IHRoYXQgdGhpcyBj b3VsZCBiZSB3cml0dGVuIGJldHRlci4gUGVyaGFwcyBzaW1wbHkgcXVvdGUgdGhlIGRlZmluaXRp b24gZnJvbSB0aGUgZnJhbWV3b3JrOg0KQ2hhbm5lbDogQSBiaS1kaXJlY3Rpb25hbCBsb2dpY2Fs IGNvbm5lY3Rpb24gdGhhdCBpcyBkZWZpbmVkIGJ5IGENCiAgIHNwZWNpZmljIENvbnRyb2xsZXIg YW5kIE1BLCBvciBDb2xsZWN0b3IgYW5kIE1BLCBwbHVzIGFzc29jaWF0ZWQNCiAgIHNlY3VyaXR5 Lg0KDQpHcmVnIOKAkyB5ZXMuIFJlcG9ydHMgKG9mIG1lYXN1cmVtZW50cykgZ28gdG8gdGhlIGNv bGxlY3Rvci4gTG9nZ2luZyBpbmZvcm1hdGlvbiDigJMgaW5mbyBhYm91dCB0aGUgb3BlcmF0aW9u IG9mIHRoZSBNQSB0aGF0IG1heSBiZSB1c2VmdWwgZm9yIGRlYnVnZ2luZyDigJMgZ29lcyB0byB0 aGUgQ29udHJvbGxlci4NCg0KQmVzdCB3aXNoZXMNCnBoaWwNCg0KRnJvbTogbG1hcCBbbWFpbHRv OmxtYXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWcgTWlyc2t5DQpTZW50OiAx NyBTZXB0ZW1iZXIgMjAxNCAxMjo0MQ0KVG86IEJlbm9pdCBDbGFpc2UNCkNjOiBsbWFwQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW2xtYXBdIEZlZWRiYWNrIG9uIGRyYWZ0LWlldGYtbG1hcC1pbmZv cm1hdGlvbi1tb2RlbA0KDQpIaSBCZW5vaXQsDQpvbiBqdXN0IG9uZSBxdWVzdGlvbjoNCkxvZ2dp bmcgYWx3YXlzIGdvZXMgdG8gdGhlIENvbGxlY3RvciwgcmlnaHQ/DQpBY2NvcmRpbmcgdG8gTE1B UCBmcmFtZXdvcmsgZG9jdW1lbnQgTG9nZ2luZyBnb2VzIG92ZXIgQ29udHJvbCwgbm90IFJlcG9y dCBDaGFubmVsOg0KDQogICBDb250cm9sIENoYW5uZWw6IEEgQ2hhbm5lbCBiZXR3ZWVuIGEgQ29u dHJvbGxlciBhbmQgYSBNQSBvdmVyIHdoaWNoDQoNCiAgIEluc3RydWN0aW9uIE1lc3NhZ2VzIGFu ZCBDYXBhYmlsaXRpZXMsIEZhaWx1cmUgYW5kIExvZ2dpbmcNCg0KICAgSW5mb3JtYXRpb24gYXJl IHNlbnQuDQoNClJlZ2FyZHMsDQoNCkdyZWcNCg0KDQpPbiBTdW4sIFNlcCAxNCwgMjAxNCBhdCAx MTozOCBQTSwgQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFpc2VA Y2lzY28uY29tPj4gd3JvdGU6DQpEZWFyIGFsbCwNCg0KU2luY2Ugd2Ugd2lsbCBiZSBzcGVuZGlu ZyB0aW1lIG9uIGRyYWZ0LWlldGYtbG1hcC1pbmZvcm1hdGlvbi1tb2RlbCB0b21vcnJvdywgaGVy ZSBpcyBzb21lIG1vcmUgZmVlZGJhY2suIEkgaGF2ZW4ndCBoYWQgdGhlIHRpbWUgdG8gcmV2aWV3 IGl0IGFsbCwgc28gaGVyZSBpcyBwYXJ0IDEuDQpJZiBzb21lIHBvaW50cyB3ZXJlIGFscmVhZHkg ZGlzY3Vzc2VkLCBkb24ndCBoZXNpdGF0ZSB0byBsZXQgbWUga25vdy4NCk5ldHdvcmsgV29ya2lu ZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFQuIEJ1cmJyaWRn ZQ0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBQLiBFYXJkbGV5DQpJbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQlQNCkV4cGlyZXM6IEZlYnJ1YXJ5IDIx LCAyMDE1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gQmFnbnVsbw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFVuaXZlcnNpZGFkIENhcmxvcyBJ SUkgZGUgTWFkcmlkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEouIFNjaG9lbndhZWxkZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXVndXN0IDIw LCAyMDE0DQoNCg0KICAgICBJbmZvcm1hdGlvbiBNb2RlbCBmb3IgTGFyZ2UtU2NhbGUgTWVhc3Vy ZW1lbnQgUGxhdGZvcm1zIChMTUFQKQ0KICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1sbWFw LWluZm9ybWF0aW9uLW1vZGVsLTAyDQpXaGF0IGRvZXMgTE1BUCBzdGFuZCBmb3I/DQpJbiB0aGUg dXNlIGNhc2VzIGRyYWZ0LCBpdCBzYXlzICJMYXJnZS1zY2FsZSBNZWFzdXJlbWVudCBvZiBCcm9h ZGJhbmQgUGVyZm9ybWFuY2UgKExNQVApIg0KQm90aCB0aGUgZnJhbWV3b3JrIGFuZCB0aGUgaW5m b3JtYXRpb24gbW9kZWwgc2F5OiBMYXJnZS1TY2FsZSBNZWFzdXJlbWVudCBQbGF0Zm9ybXMgKExN QVApDQoNCg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIEluZm9ybWF0aW9uIE1vZGVsIGFwcGxpZXMg dG8gdGhlIE1lYXN1cmVtZW50IEFnZW50IHdpdGhpbiBhDQogICBMYXJnZS1TY2FsZSBNZWFzdXJl bWVudCBQbGF0Zm9ybS4gIEFzIHN1Y2ggaXQgb3V0bGluZXMgdGhlDQogICBpbmZvcm1hdGlvbiB0 aGF0IGlzIChwcmUtKWNvbmZpZ3VyZWQgb24gdGhlIE1BIG9yIGV4aXN0cyBpbg0KICAgY29tbXVu aWNhdGlvbnMgd2l0aCBhIENvbnRyb2xsZXIgb3IgQ29sbGVjdG9yIHdpdGhpbiBhbiBMTUFQDQog ICBmcmFtZXdvcmsuICBUaGUgcHVycG9zZSBvZiBzdWNoIGFuIEluZm9ybWF0aW9uIE1vZGVsIGlz IHRvIHByb3ZpZGUgYQ0KICAgcHJvdG9jb2wgYW5kIGRldmljZSBpbmRlcGVuZGVudCB2aWV3IG9m IHRoZSBNQSB0aGF0IGNhbiBiZQ0KICAgaW1wbGVtZW50ZWQgdmlhIG9uZSBvciBtb3JlIENvbnRy b2wgYW5kIFJlcG9ydCBwcm90b2NvbHMuDQoNClJlcXVpcmVtZW50cyBMYW5ndWFnZQ0KDQogICBU aGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNI QUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZ IiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJl dGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbUkZDMjExOV0uDQoNClN0YXR1cyBvZiBUaGlz IE1lbW8NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25m b3JtYW5jZSB3aXRoIHRoZQ0KICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0K ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQg RW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3Vw cyBtYXkgYWxzbyBkaXN0cmlidXRlDQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1E cmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQ0KICAgRHJhZnRzIGlzIGF0IGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uDQoNCiAgIEludGVybmV0 LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1v bnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90 aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVz ZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRo ZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoaXMgSW50ZXJuZXQt RHJhZnQgd2lsbCBleHBpcmUgb24gRmVicnVhcnkgMjEsIDIwMTUuDQoNCg0KDQoNCg0KDQpCdXJi cmlkZ2UsIGV0IGFsLiAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIxLCAyMDE1ICAgICAgICAgICAg ICAgW1BhZ2UgMV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIExNQVAgSW5mb3JtYXRpb24g TW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDE0DQoNCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQog ICBDb3B5cmlnaHQgKGMpIDIwMTQgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmll ZCBhcyB0aGUNCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQog ICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdz IExlZ2FsDQogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzDQogICAoaHR0 cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUg b2YNCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNl IGRvY3VtZW50cw0KICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFu ZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0DQogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBD b21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdA0KICAgaW5jbHVkZSBT aW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9m DQogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQg d2FycmFudHkgYXMNCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4N Cg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzDQogICAyLiAgTm90YXRpb24g IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQN CiAgIDMuICBMTUFQIEluZm9ybWF0aW9uIE1vZGVsICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgNA0KICAgICAzLjEuICBJbmZvcm1hdGlvbiBTdHJ1Y3R1cmUgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0DQogICAgIDMuMi4gIFByZS1Db25maWd1 cmF0aW9uIEluZm9ybWF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgNCiAgICAg My4zLiAgQ29uZmlndXJhdGlvbiBJbmZvcm1hdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgOQ0KICAgICAzLjQuICBJbnN0cnVjdGlvbiBJbmZvcm1hdGlvbiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExDQogICAgIDMuNS4gIExvZ2dpbmcgSW5mb3JtYXRp b24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTMNCiAgICAgMy42LiAg Q2FwYWJpbGl0eSBhbmQgU3RhdHVzIEluZm9ybWF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxNQ0KICAgICAzLjcuICBSZXBvcnRpbmcgSW5mb3JtYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDE3DQogICAgIDMuOC4gIFNjaGVkdWxlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTgNCiAgICAgMy45LiAgQ2hhbm5l bHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMQ0K ICAgICAzLjEwLiBUYXNrIENvbmZpZ3VyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDIyDQogICAgIDMuMTEuIFRpbWluZyBJbmZvcm1hdGlvbiAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjMNCiAgICAgICAzLjExLjEuICBQZXJpb2Rp YyBUaW1pbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNA0KICAgICAg IDMuMTEuMi4gIENhbGVuZGFyIFRpbWluZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDI1DQogICAgICAgMy4xMS4zLiAgT25lLU9mZiBUaW1pbmcgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjYNCiAgICAgICAzLjExLjQuICBJbW1lZGlhdGUgVGlt aW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNg0KICAgICAgIDMuMTEu NS4gIFN0YXJ0dXAgVGltaW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDI2DQogICA0LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMjYNCiAgIDUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNg0KICAgNi4gIEFwcGVuZGl4OiBK U09OIEV4YW1wbGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI3DQog ICA3LiAgQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMzUNCiAgIDguICBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzNQ0KICAgICA4LjEuICBOb3JtYXRpdmUgUmVm ZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM1DQogICAgIDgu Mi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMzUNCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzNQ0KDQoNCg0KDQoNCg0KDQpCdXJicmlkZ2UsIGV0IGFs LiAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIxLCAyMDE1ICAgICAgICAgICAgICAgW1BhZ2UgMl0N Cg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIExNQVAgSW5mb3JtYXRpb24gTW9kZWwgICAgICAg ICAgICAgIEF1Z3VzdCAyMDE0DQoNCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBBIGxhcmdlLXNj YWxlIG1lYXN1cmVtZW50IHBsYXRmb3JtIGlzIGEgY29sbGVjdGlvbiBvZiBjb21wb25lbnRzIHRo YXQNCiAgIHdvcmsgaW4gYSBjb29yZGluYXRlZCBmYXNoaW9uIHRvIHBlcmZvcm0gbWVhc3VyZW1l bnRzIGZyb20gYSBsYXJnZQ0KICAgbnVtYmVyIG9mIHZhbnRhZ2UgcG9pbnRzLiAgVGhlIG1haW4g Y29tcG9uZW50cyBvZiBhIGxhcmdlLXNjYWxlDQogICBtZWFzdXJlbWVudCBwbGF0Zm9ybSBhcmUg dGhlIE1lYXN1cmVtZW50IEFnZW50cyAoaGVyZWFmdGVyIE1BcyksIHRoZQ0KICAgQ29udHJvbGxl cihzKSBhbmQgdGhlIENvbGxlY3RvcihzKS4NCg0KICAgVGhlIE1BcyBhcmUgdGhlIGVsZW1lbnRz IGFjdHVhbGx5IHBlcmZvcm1pbmcgdGhlIG1lYXN1cmVtZW50cy4gIFRoZQ0KICAgTUFzIGFyZSBj b250cm9sbGVkIGJ5IGV4YWN0bHkgb25lIENvbnRyb2xsZXIgYXQgYSB0aW1lIGFuZCB0aGUNCiAg IENvbGxlY3RvcnMgZ2F0aGVyIHRoZSByZXN1bHRzIGdlbmVyYXRlZCBieSB0aGUgTUFzLiAgSW4g YSBudXRzaGVsbCwNCiAgIHRoZSBub3JtYWwgb3BlcmF0aW9uIG9mIGEgbGFyZ2Utc2NhbGUgbWVh c3VyZW1lbnQgcGxhdGZvcm0gc3RhcnRzDQogICB3aXRoIHRoZSBDb250cm9sbGVyIGluc3RydWN0 aW5nIGEgc2V0IG9mIG9uZSBvciBtb3JlIE1BcyB0byBwZXJmb3JtIGENCiAgIHNldCBvZiBvbmUg b3IgbW9yZSBNZWFzdXJlbWVudCBUYXNrcyBhdCBhIGNlcnRhaW4gcG9pbnQgaW4gdGltZS4gIFRo ZQ0KICAgTUFzIGV4ZWN1dGUgdGhlIGluc3RydWN0aW9ucyBmcm9tIGEgQ29udHJvbGxlciwgYW5k IG9uY2UgdGhleSBoYXZlDQogICBkb25lIHNvLCB0aGV5IHJlcG9ydCB0aGUgcmVzdWx0cyBvZiB0 aGUgbWVhc3VyZW1lbnRzIHRvIG9uZSBvciBtb3JlDQogICBDb2xsZWN0b3JzLiAgVGhlIG92ZXJh bGwgZnJhbWV3b3JrIGZvciBhIExhcmdlIE1lYXN1cmVtZW50IHBsYXRmb3JtDQogICBhcyB1c2Vk IGluIHRoaXMgZG9jdW1lbnQgaXMgZGVzY3JpYmVkIGluIGRldGFpbCBpbg0KICAgW0ktRC5pZXRm LWxtYXAtZnJhbWV3b3JrXS4NCg0KICAgQSBsYXJnZS1zY2FsZSBtZWFzdXJlbWVudCBwbGF0Zm9y bSBpbnZvbHZlcyBiYXNpY2FsbHkgdGhyZWUNCiAgIHByb3RvY29scywgbmFtZWx5LCBhIENvbnRy b2wgcHJvdG9jb2wgYmV0d2VlbiBhIENvbnRyb2xsZXIgYW5kIHRoZQ0KQ29udHJvbCBQcm90b2Nv bA0KDQogICBNQXMsIGEgUmVwb3J0IHByb3RvY29sIGJldHdlZW4gdGhlIE1BcyBhbmQgdGhlIENv bGxlY3RvcihzKSBhbmQNCiAgIHNldmVyYWwgbWVhc3VyZW1lbnQgcHJvdG9jb2xzIGJldHdlZW4g dGhlIE1BcyBhbmQgTWVhc3VyZW1lbnQgUGVlcnMNCiAgIChNUHMpLCB1c2VkIHRvIGFjdHVhbGx5 IHBlcmZvcm0gdGhlIG1lYXN1cmVtZW50cy4gIEluIGFkZGl0aW9uIHNvbWUNCiAgIGluZm9ybWF0 aW9uIGlzIHJlcXVpcmVkIHRvIGJlIGNvbmZpZ3VyZWQgb24gdGhlIE1BIHByaW9yIHRvIGFueQ0K ICAgY29tbXVuaWNhdGlvbiB3aXRoIHRoZSBpbml0aWFsIENvbnRyb2xsZXIuDQoiaW5pdGlhbCIg Y29uZnVzZWQgbWUuDQpJdCdzIG9ubHkgbGF0ZXIgKHNlY3Rpb24gMy4zKSB0aGF0IEkgdW5kZXJz dG9vZCB0aGF0IHRoZSBDb250cm9sbGVyIGNvdWxkIGJlIGNoYW5nZWQuDQpDYW5kaWRhdGUgZm9y IHJlbW92YWwsIGltcHJvdmVtZW50LCBvciBmb3J3YXJkIHJlZmVyZW5jZT8NCg0KDQogICBUaGlz IGRvY3VtZW50IGRlZmluZXMgdGhlIGluZm9ybWF0aW9uIG1vZGVsIGZvciBib3RoIHRoZSBDb250 cm9sIGFuZA0KICAgdGhlIFJlcG9ydCBwcm90b2NvbCBhbG9uZyB3aXRoIHByZS1jb25maWd1cmF0 aW9uIGluZm9ybWF0aW9uIHRoYXQgaXMNCiAgIHJlcXVpcmVkDQphZGQgIm9uIHRoZSBNQSINCg0K YmVmb3JlIGNvbW11bmljYXRpbmcgd2l0aCB0aGUgQ29udHJvbGxlciwgYnJvYWRseSBuYW1lZCBh cw0KICAgdGhlIExNQVAgSW5mb3JtYXRpb24gTW9kZWwuICBUaGUgbWVhc3VyZW1lbnQgcHJvdG9j b2xzIGFyZSBvdXQgb2YgdGhlDQogICBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQogICBBcyBk ZWZpbmVkIGluIFtSRkMzNDQ0XSwgdGhlIExNQVAgSU0gZGVmaW5lcyB0aGUgY29uY2VwdHMgaW52 b2x2ZWQgaW4NCklNID0gSW5mb3JtYXRpb24gTW9kZWwNCnRoaXMgaXMgdGhlIGZpcnN0IG9jY3Vy cmVuY2UuDQoNCg0KICAgYSBsYXJnZS1zY2FsZSBtZWFzdXJlbWVudCBwbGF0Zm9ybSBhdCBhIGhp Z2ggbGV2ZWwgb2YgYWJzdHJhY3Rpb24sDQogICBpbmRlcGVuZGVudCBvZiBhbnkgc3BlY2lmaWMg aW1wbGVtZW50YXRpb24gb3IgYWN0dWFsIHByb3RvY29sIHVzZWQgdG8NCiAgIGV4Y2hhbmdlIHRo ZSBpbmZvcm1hdGlvbi4gIEl0IGlzIGV4cGVjdGVkIHRoYXQgdGhlIHByb3Bvc2VkDQogICBpbmZv cm1hdGlvbiBtb2RlbCBjYW4gYmUgdXNlZCB3aXRoIGRpZmZlcmVudCBwcm90b2NvbHMgaW4gZGlm ZmVyZW50DQogICBtZWFzdXJlbWVudCBwbGF0Zm9ybSBhcmNoaXRlY3R1cmVzIGFuZCBhY3Jvc3Mg ZGlmZmVyZW50IHR5cGVzIG9mIE1BDQogICBkZXZpY2VzIChlLmcuLCBob21lIGdhdGV3YXksIHNt YXJ0cGhvbmUsIFBDLCByb3V0ZXIpLg0KDQogICBUaGUgZGVmaW5pdGlvbiBvZiBhbiBJbmZvcm1h dGlvbiBNb2RlbCBzZXJ2ZXMgYSBudW1iZXIgb2YgcHVycG9zZXM6DQoNCiAgIDEuICBUbyBndWlk ZSB0aGUgc3RhbmRhcmRpc2F0aW9uIG9mIG9uZSBvciBtb3JlIENvbnRyb2wgYW5kIFJlcG9ydA0K ICAgICAgIHByb3RvY29sIGFuZCBkYXRhIG1vZGVsIGltcGxlbWVudGF0aW9ucw0KDQoNCg0KDQoN CkJ1cmJyaWRnZSwgZXQgYWwuICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjEsIDIwMTUgICAgICAg ICAgICAgICBbUGFnZSAzXQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgTE1BUCBJbmZvcm1h dGlvbiBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMTQNCg0KDQogICAyLiAgVG8gZW5hYmxl IGhpZ2gtbGV2ZWwgaW50ZXItb3BlcmFiaWxpdHkgYmV0d2VlbiBkaWZmZXJlbnQgQ29udHJvbA0K ICAgICAgIGFuZCBSZXBvcnQgcHJvdG9jb2xzIGJ5IGZhY2lsaXRhdGluZyB0cmFuc2xhdGlvbiBi ZXR3ZWVuIHRoZWlyDQogICAgICAgcmVzcGVjdGl2ZSBkYXRhIG1vZGVscyBzdWNoIHRoYXQgYSBD b250cm9sbGVyIGNvdWxkIGluc3RydWN0IHN1Yi0NCiAgICAgICBwb3B1bGF0aW9ucyBvZiBNQXMg dXNpbmcgZGlmZmVyZW50IHByb3RvY29scw0KDQogICAzLiAgVG8gZm9ybSBhZ3JlZW1lbnQgb2Yg d2hhdCBpbmZvcm1hdGlvbiBuZWVkcyB0byBiZSBoZWxkIGJ5IGFuIE1BDQogICAgICAgYW5kIHBh c3NlZCBvdmVyIHRoZSBDb250cm9sIGFuZCBSZXBvcnQgaW50ZXJmYWNlcyBhbmQgc3VwcG9ydCB0 aGUNCiAgICAgICBmdW5jdGlvbmFsaXR5IGRlc2NyaWJlZCBpbiB0aGUgTE1BUCBmcmFtZXdvcmsN Cg0KICAgNC4gIEVuYWJsZSBleGlzdGluZyBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIHRvIGJl IGFzc2Vzc2VkIGZvcg0KICAgICAgIHRoZWlyIHN1aXRhYmlsaXR5IGFzIHBhcnQgb2YgYSBsYXJn ZS1zY2FsZSBtZWFzdXJlbWVudCBzeXN0ZW0NCg0KMi4gIE5vdGF0aW9uDQoNCiAgIFRoaXMgZG9j dW1lbnQgdXNlIGFuIG9iamVjdC1vcmllbnRlZCBwcm9ncmFtbWluZy1saWtlIG5vdGF0aW9uIHRv DQogICBkZWZpbmUgdGhlIHBhcmFtZXRlcnMgKG5hbWVzL3ZhbHVlcykgb2YgdGhlIG9iamVjdHMg b2YgdGhlDQogICBpbmZvcm1hdGlvbiBtb2RlbC4gIEFuIG9wdGlvbmFsIGZpZWxkIGlzIGVuY2xv c2VkIGJ5IFsgXSwgYW5kIGFuDQogICBhcnJheSBpcyBpbmRpY2F0ZWQgYnkgdHdvIG51bWJlcnMg aW4gYW5nbGUgYnJhY2tldHMsIDxtLi5uPiwgd2hlcmUgbQ0KICAgaW5kaWNhdGVzIHRoZSBtaW5p bWFsIG51bWJlciBvZiB2YWx1ZXMsIGFuZCBuIGlzIHRoZSBtYXhpbXVtLiAgVGhlDQogICBzeW1i b2wgKiBmb3IgbiBtZWFucyBubyB1cHBlciBib3VuZC4NCg0KMy4gIExNQVAgSW5mb3JtYXRpb24g TW9kZWwNCg0KMy4xLiAgSW5mb3JtYXRpb24gU3RydWN0dXJlDQoNCiAgIFRoZSBpbmZvcm1hdGlv biBkZXNjcmliZWQgaGVyZWluIHJlbGF0ZXMgdG8gdGhlIGluZm9ybWF0aW9uIHN0b3JlZCwNCiAg IHJlY2VpdmVkIG9yIHRyYW5zbWl0dGVkIGJ5IGEgTWVhc3VyZW1lbnQgQWdlbnQgYXMgZGVzY3Jp YmVkIHdpdGhpbg0KICAgdGhlIExNQVAgZnJhbWV3b3JrIFtJLUQuaWV0Zi1sbWFwLWZyYW1ld29y a10uDQpTaG91bGQgdGhlIGZyYW1ld29yayBiZSBub3JtYXRpdmU/IEkgYmVsaWV2ZSBzbywgc3Bl Y2lmaWNhbGx5IHdoZW4gSSBzZWUgYWxsIHRob3NlIENhcGl0YWxpemVkIHRlcm1zIHRoYXQgYXJl IG9ubHkgZGVmaW5lZCBpbiB0aGUgZnJhbWV3b3JrLg0KVGhpcyBsZWFkcyB0byBhbm90aGVyIHBv aW50LiBZb3UgbWlzcyBhIHRlcm1pbm9sb2d5IHNlY3Rpb24gYmVjYXVzZSBzb21lIHRlcm1zIGFy ZSBzcGVjaWZpYyB0byB0aGlzIGRvY3VtZW50LiBFeGFtcGxlOiBUYXNrIFN1cHByZXNzaW9uLg0K DQpBcyBzdWNoLCBzb21lIHN1YnNldHMNCiAgIG9mIHRoaXMgaW5mb3JtYXRpb24gbW9kZWwgYXJl IGFwcGxpY2FibGUgdG8gdGhlIG1lYXN1cmVtZW50DQogICBDb250cm9sbGVyLCBDb2xsZWN0b3IN CmFkZCBhICIsIg0KT3RoZXJ3aXNlIHdlIGNhbiBiZWxpZXZlIHRoYXQgdGhlIENvbGxlY3RvciBj b3VsZCBwcmUtY29uZmlndXJlIHRoZSBNQS4NCg0KYW5kIHN5c3RlbXMgdGhhdCBwcmUtY29uZmln dXJlIHRoZSBNZWFzdXJlbWVudA0KICAgQWdlbnQuICBUaGUgaW5mb3JtYXRpb24gZGVzY3JpYmVk IGluIHRoZXNlIG1vZGVscyB3aWxsIGJlIHRyYW5zbWl0dGVkDQogICBieSBwcm90b2NvbHMgdXNp bmcgaW50ZXJmYWNlcyBiZXR3ZWVuIHRoZSBNZWFzdXJlbWVudCBBZ2VudCBhbmQgc3VjaA0KICAg c3lzdGVtcyBhY2NvcmRpbmcgdG8gYSBEYXRhIE1vZGVsLg0KDQogICBGb3IgY2xhcml0eSB0aGUg aW5mb3JtYXRpb24gbW9kZWwgaXMgZGl2aWRlZCBpbnRvIHNpeCBzZWN0aW9uczoNCg0KICAgMS4g IFByZS1Db25maWd1cmF0aW9uIEluZm9ybWF0aW9uLiAgSW5mb3JtYXRpb24gcHJlLWNvbmZpZ3Vy ZWQgb24gdGhlDQogICAgICAgTWVhc3VyZW1lbnQgQWdlbnQgcHJpb3IgdG8gYW55IGNvbW11bmlj YXRpb24gd2l0aCBvdGhlcg0KICAgICAgIGNvbXBvbmVudHMgb2YgdGhlIExNQVAgYXJjaGl0ZWN0 dXJlIChpLmUuLCB0aGUgQ29udHJvbGxlciwNCiAgICAgICBDb2xsZWN0b3IgYW5kIE1lYXN1cmVt ZW50IFBlZXJzKSwgc3BlY2lmaWNhbGx5IGRldGFpbGluZyBob3cgdG8NCiAgICAgICBjb21tdW5p Y2F0ZSB3aXRoIGEgQ29udHJvbGxlciBhbmQgd2hldGhlciB0aGUgZGV2aWNlIGlzIGVuYWJsZWQN CiAgICAgICB0byBwYXJ0aWNpcGF0ZSBhcyBhbiBNQS4NCg0KICAgMi4gIENvbmZpZ3VyYXRpb24g SW5mb3JtYXRpb24uICBVcGRhdGUgb2YgdGhlIHByZS1jb25maWd1cmF0aW9uDQogICAgICAgaW5m b3JtYXRpb24gZHVyaW5nIHRoZSByZWdpc3RyYXRpb24gb2YgdGhlIE1BIG9yIHN1YnNlcXVlbnQN CiAgICAgICBjb21tdW5pY2F0aW9uIHdpdGggdGhlIENvbnRyb2xsZXIsIGFsb25nIHdpdGggdGhl IGNvbmZpZ3VyYXRpb24NCiAgICAgICBvZiBmdXJ0aGVyIHBhcmFtZXRlcnMgYWJvdXQgdGhlIE1B IChyYXRoZXIgdGhhbiB0aGUgVGFza3MgaXQNCg0KDQoNCg0KQnVyYnJpZGdlLCBldCBhbC4gICAg ICAgRXhwaXJlcyBGZWJydWFyeSAyMSwgMjAxNSAgICAgICAgICAgICAgIFtQYWdlIDRdDQoNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICBMTUFQIEluZm9ybWF0aW9uIE1vZGVsICAgICAgICAgICAg ICBBdWd1c3QgMjAxNA0KDQoNCiAgICAgICBzaG91bGQgcGVyZm9ybSkgdGhhdCB3ZXJlIG5vdCBt YW5kYXRvcnkgZm9yIHRoZSBpbml0aWFsDQogICAgICAgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRo ZSBNQSBhbmQgYSBDb250cm9sbGVyLg0KDQogICAzLiAgSW5zdHJ1Y3Rpb24gSW5mb3JtYXRpb24u ICBJbmZvcm1hdGlvbiB0aGF0IGlzIHJlY2VpdmVkIGJ5IHRoZSBNQQ0KICAgICAgIGZyb20gdGhl IENvbnRyb2xsZXIgcGVydGFpbmluZyB0byB0aGUgVGFza3MgdGhhdCBzaG91bGQgYmUNCiAgICAg ICBleGVjdXRlZC4gIFRoaXMgaW5jbHVkZXMgdGhlIHRhc2sgZXhlY3V0aW9uIFNjaGVkdWxlcyAo b3RoZXIgdGhhbg0KICAgICAgIHRoZSBDb250cm9sbGVyIGNvbW11bmljYXRpb24gU2NoZWR1bGUg c3VwcGxpZWQgYXMNCiAgICAgICAocHJlKWNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24pIGFuZCBy ZWxhdGVkIGluZm9ybWF0aW9uIHN1Y2ggYXMNCiAgICAgICB0aGUgVGFzayBDb25maWd1cmF0aW9u LCBjb21tdW5pY2F0aW9uIENoYW5uZWxzIHRvIENvbGxlY3RvcnMgYW5kDQogICAgICAgc2NoZWR1 bGUgVGltaW5nIGluZm9ybWF0aW9uLiAgSXQgYWxzbyBpbmxjdWRlcyBUYXNrIFN1cHByZXNzaW9u DQogICAgICAgaW5mb3JtYXRpb24gdGhhdCBpcyB1c2VkIHRvIG92ZXItcmlkZSBub3JtYWwgVGFz ayBleGVjdXRpb24NCiAgICAgICBkdXJpbmcgZW1lcmdlbmN5IHNpdHVhdGlvbnMuDQoNCiAgIDQu ICBMb2dnaW5nIEluZm9ybWF0aW9uLiAgSW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgZnJvbSB0aGUg TUEgdG8gdGhlDQogICAgICAgQ29udHJvbGxlciBkZXRhaWxpbmcgdGhlIHJlc3VsdHMgb2YgYW55 IGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucw0KICAgICAgIGFsb25nIHdpdGggZXJyb3IgYW5kIHN0 YXR1cyBpbmZvcm1hdGlvbiBmcm9tIHRoZSBvcGVyYXRpb24gb2YgdGhlDQogICAgICAgTUEuDQoN CiAgIDUuICBDYXBhYmlsaXR5IGFuZCBTdGF0dXMgSW5mb3JtYXRpb24uICBJbmZvcm1hdGlvbiBv biB0aGUgZ2VuZXJhbA0KICAgICAgIHN0YXR1cyBhbmQgY2FwYWJpbGl0aWVzIG9mIHRoZSBNQS4g IEZvciBleGFtcGxlLCB0aGUgc2V0IG9mDQogICAgICAgbWVhc3VyZW1lbnRzIHRoYXQgYXJlIHN1 cHBvcnRlZCBvbiB0aGUgZGV2aWNlLg0KDQogICA2LiAgUmVwb3J0aW5nIEluZm9ybWF0aW9uLiAg SW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgZnJvbSB0aGUgTUEgdG8NCiAgICAgICBvbmUgb3IgbW9y ZSBDb2xsZWN0b3JzIGluY2x1ZGluZyBtZWFzdXJlbWVudCByZXN1bHRzIGFuZCB0aGUNCiAgICAg ICBjb250ZXh0IGluIHdoaWNoIHRoZXkgd2VyZSBjb25kdWN0ZWQuDQoNCiAgIEluIGFkZGl0aW9u IHRoZSBNQSBtYXkgaG9sZCBmdXJ0aGVyIGluZm9ybWF0aW9uIG5vdCBkZXNjcmliZWQgaGVyZWlu LA0KICAgYW5kIHdoaWNoIG1heSBiZSBvcHRpb25hbGx5IHRyYW5zZmVycmVkIHRvIG9yIGZyb20g b3RoZXIgc3lzdGVtcw0KICAgaW5jbHVkaW5nIHRoZSBDb250cm9sbGVyIGFuZCBDb2xsZWN0b3Iu ICBPbmUgZXhhbXBsZSBvZiBpbmZvcm1hdGlvbg0KICAgaW4gdGhpcyBjYXRlZ29yeSBpcyBzdWJz Y3JpYmVyIG9yIGxpbmUgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUNCiAgIGV4dHJhY3RlZCBieSBh IHRhc2sgYW5kIHJlcG9ydGVkIGJ5IHRoZSBNQSBpbiB0aGUgcmVwb3J0aW5nDQogICBjb21tdW5p Y2F0aW9uIHRvIGEgQ29sbGVjdG9yLg0KDQogICBJdCBzaG91bGQgYWxzbyBiZSBub3RlZCB0aGF0 IHRoZSBNQSBtYXkgYmUgaW4gY29tbXVuaWNhdGlvbiB3aXRoDQpUaGUgIk1BIiBvciB0aGUgIk1B IGRldmljZSI/DQpJJ20gYXNraW5nIGJlY2F1c2UgdGhlIHJlc3Qgb2YgdGhlIHNlbnRlbmNlIHNw ZWFrcyBhYm91dCAiY29uZmlndXJpbmciLCBhbmQgd2Ugc2FpZCB0aGF0IE1BIGNhbiBvbmx5IGJl IGNvbmZpZ3VyZWQgYnkgb25lIGFuZCBvbmx5IG9uZSBDb250cm9sbGVyLg0KDQogICBvdGhlciBt YW5hZ2VtZW50IHN5c3RlbXMgd2hpY2ggbWF5IGJlIHJlc3BvbnNpYmxlIGZvciBjb25maWd1cmlu ZyBhbmQNCiAgIHJldHJpZXZpbmcgaW5mb3JtYXRpb24gZnJvbSB0aGUgTUEgZGV2aWNlLiAgU3Vj aCBzeXN0ZW1zLCB3aGVyZQ0KICAgYXZhaWxhYmxlLCBjYW4gcGVyZm9ybSBhbiBpbXBvcnRhbnQg cm9sZSBpbiB0cmFuc2ZlcnJpbmcgdGhlIHByZS0NCiAgIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRp b24gdG8gdGhlIE1BIG9yIGVuYWJsaW5nL2Rpc2FibGluZyB0aGUNCiAgIG1lYXN1cmVtZW50IGZ1 bmN0aW9uYWxpdHkgb2YgdGhlIE1BLg0KInN1Y2ggc3lzdGVtUyIgLi4uICJlbmFibGluZy9kaXNh YmxpbmcgdGhlIG1lYXN1cmVtZW50IGZ1bmN0aW9uYWxpdHkgb2YgdGhlIE1BLiINClRoaXMgaXMg bm90IHBvc3NpYmxlLiBTZWUgbXkgcHJldmlvdXMgcG9pbnQuDQoNCg0KICAgVGhlIEluZm9ybWF0 aW9uIE1vZGVsIGlzIGRpdmlkZWQgaW50byBzdWItc2VjdGlvbnMgZm9yIGEgbnVtYmVyIG9mDQog ICByZWFzb25zLiAgRmlyc3RseSB0aGUgZ3JvdXBpbmcgb2YgaW5mb3JtYXRpb24gZmFjaWxpdGF0 ZXMgcmVhZGVyDQogICB1bmRlcnN0YW5kaW5nLiAgU2Vjb25kbHksIHRoZSBwYXJ0aWN1bGFyIGdy b3VwaW5ncyBjaG9zZW4gYXJlDQogICBleHBlY3RlZCB0byBtYXAgdG8gZGlmZmVyZW50IHByb3Rv Y29scyBvciBkaWZmZXJlbnQgdHJhbnNtaXNzaW9ucw0KICAgd2l0aGluIHRob3NlIHByb3RvY29s cy4NCg0KICAgVGhlIGdyYW51bGFyaXR5IG9mIGRhdGEgdHJhbnNtaXR0ZWQgaW4gZWFjaCBvcGVy YXRpb24gb2YgdGhlIENvbnRyb2wNCiAgIGFuZCBSZXBvcnQgUHJvdG9jb2xzIGlzIG5vdCBkaWN0 YXRlZCBieSB0aGUgSW5mb3JtYXRpb24gTW9kZWwuICBGb3INCg0KDQoNCkJ1cmJyaWRnZSwgZXQg YWwuICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjEsIDIwMTUgICAgICAgICAgICAgICBbUGFnZSA1 XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgTE1BUCBJbmZvcm1hdGlvbiBNb2RlbCAgICAg ICAgICAgICAgQXVndXN0IDIwMTQNCg0KDQogICBleGFtcGxlLCB0aGUgSW5zdHJ1Y3Rpb24gb2Jq ZWN0IG1heSBiZSBkZWxpdmVyZWQgaW4gYSBzaW5nbGUNCiAgIG9wZXJhdGlvbi4gIEFsdGVybmF0 aXZlbHksIFNjaGVkdWxlcyBhbmQgVGFzayBDb25maWd1cmF0aW9ucyBtYXkgYmUNCiAgIHNlcGFy YXRlZCBvciBldmVuIGVhY2ggU2NoZHVsZS9UYXNrIENvbmZpZ3VyYXRpb24gbWF5IGJlIGRlbGl2 ZXJlZA0KICAgaW5kaXZpZHVhbGx5LiAgU2ltaWxhcmx5IHRoZSBJbmZvcm1hdGlvbiBNb2RlbCBk b2VzIG5vdCBkaWN0YXRlDQogICB3aGV0aGVyIGRhdGEgaXMgcmVhZCwgd3JpdGUsIG9yIHJlYWQv d3JpdGUuICBGb3IgZXhhbXBsZSwgc29tZQ0KICAgQ29udHJvbCBQcm90b2NvbHMgbWF5IGhhdmUg dGhlIGFiaWxpdHkgdG8gcmVhZCBiYWNrIENvbmZpZ3VyYXRpb24gYW5kDQogICBJbnN0cnVjdGlv biBpbmZvcm1hdGlvbiB3aGljaCBoYXZlIGJlZW4gcHJldmlvc3VseSBzZXQgb24gdGhlIE1BLg0K ICAgTGFzdGx5LCB3aGlsZSBzb21lIHByb3RvY29scyBtYXkgc2ltcGx5IG92ZXJ3cml0ZSBpbmZv cm1hdGlvbiAoZm9yDQogICBleGFtcGxlIHJlZnJlc2hpbmcgdGhlIGVudGlyZSBJbnN0cnVjdGlv biBJbmZvcm1hdGlvbiksIG90aGVyDQogICBwcm90b2NvbHMgbWF5IGhhdmUgdGhlIGFiaWxpdHkg dG8gdXBkYXRlIG9yIGRlbGV0ZSBzZWxlY3RlZCBpdGVtcyBvZg0KICAgaW5mb3JtYXRpb24uDQoN CiAgIFRoZSBpbmZvcm1hdGlvbiBpbiB0aGVzZSBzaXggc2VjdGlvbnMgaXMgY2FwdHVyZWQgYnkg YSBudW1iZXIgb2YNCiAgIGNvbW1vbiBpbmZvcm1hdGlvbiBvYmplY3RzLiAgVGhlc2Ugb2JqZWN0 cyBhcmUgYWxzbyBkZXNjcmliZWQgbGF0ZXINCiAgIGluIHRoaXMgZG9jdW1lbnQgYW5kIGNvbXBy aXNlIG9mOg0KDQogICAxLiAgU2NoZWR1bGVzLiAgQSBzZXQgb2YgU2NoZWR1bGVzIHRlbGwgdGhl IE1BIHRvIGRvIHNvbWV0aGluZy4NCiAgICAgICBXaXRob3V0IGEgU2NoZWR1bGUgbm8gVGFzayAo ZnJvbSBhIG1lYXN1cmVtZW50IHRvIHJlcG9ydGluZyBvcg0KICAgICAgIGNvbW11bmljYXRpbmcg d2l0aCB0aGUgQ29udHJvbGxlcikgaXMgZXZlciBleGVjdXRlZC4gIFNjaGVkdWxlcw0KICAgICAg IGFyZSB1c2VkIHdpdGhpbiB0aGUgSW5zdHJ1Y3Rpb24gdG8gc3BlY2lmeSB3aGF0IHRhc2tzIHNo b3VsZCBiZQ0KICAgICAgIHBlcmZvcm1lZCwgd2hlbiwgYW5kIGhvdyB0byBkaXJlY3QgdGhlaXIg cmVzdWx0cy4gIEEgU2NoZWR1bGUgaXMNCiAgICAgICBhbHNvIHVzZWQgd2l0aGluIHRoZSBwcmUt Q29uZmlndXJhdGlvbiBhbmQgQ29uZmlndXJhdGlvbg0KICAgICAgIGluZm9ybWF0aW9uIGluIG9y ZGVyIHRvIGV4ZWN1dGUgdGhlIFRhc2sgb3IgVGFza3MgcmVxdWlyZWQgdG8NCiAgICAgICBjb21t dW5pY2F0ZSB3aXRoIHRoZSBDb250cm9sbGVyLg0KDQogICAyLiAgQ2hhbm5lbHMuICBBIHNldCBv ZiBDaGFubmVsIG9iamVjdHMgYXJlIHVzZWQgdG8gY29tbXVuaWNhdGUgd2l0aA0KICAgICAgIGEg bnVtYmVyIG9mIGVuZHBvaW50cyAoaS5lLiB0aGUgQ29udHJvbGxlciBhbmQgQ29sbGVjdG9ycyku DQpPTEQ6IChpLmUuIHRoZSBDb250cm9sbGVyIGFuZCBDb2xsZWN0b3JzKS4NCk5FVzogKHRoZSBD b250cm9sbGVyLCBDb2xsZWN0b3JzLCBhbmQgTUFzKS4NCg0KVGhlc2UgYXJlIHRoZSBvbmx5IDMg cG9zc2liaWxpdGllcywgcmlnaHQ/DQpMb2dnaW5nIGFsd2F5cyBnb2VzIHRvIHRoZSBDb2xsZWN0 b3IsIHJpZ2h0Pw0KDQoNCkVhY2gNCiAgICAgICBDaGFubmVsIG9iamVjdCBjb250YWlucyB0aGUg aW5mb3JtYXRpb24gcmVxdWlyZWQgZm9yIHRoZQ0KICAgICAgIGNvbW11bmljYXRpb24gd2l0aCBh IHNpbmdsZSBlbmRwb2ludCBzdWNoIGFzIHRoZSB0YXJnZXQgbG9jYXRpb24NCiAgICAgICBhbmQg c2VjdXJpdHkgZGV0YWlscy4gIENoYW5uZWxzIGFyZSByZWZlcmVuY2VkIGZyb20gd2l0aGluDQog ICAgICAgU2NoZWR1bGVzIGluIG9yZGVyIHRvIHNheSBob3cgVGFza3Mgc2hvdWxkIGNvbW11bmlj YXRlLg0KDQogICAzLiAgVGFzayBDb25maWd1cmF0aW9ucy4gIEEgc2V0IG9mIFRhc2sgQ29uZmln dXJhdGlvbnMgaXMgdXNlZCB0bw0KICAgICAgIGNvbmZpZ3VyZSB0aGUgVGFza3MgdGhhdCBhcmUg cnVuIGJ5IHRoZSBNQS4gIFRoaXMgaW5jbHVkZXMgdGhlDQogICAgICAgcmVnaXN0cnkgZW50cnkg Zm9yIHRoZSBUYXNrIGFuZCBhbnkgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzLg0KICAgICAgIFRh c2sgQ29uZmlndXJhdGlvbnMgYXJlIHJlZmVyZW5jZWQgZnJvbSBhIFNjaGVkdWxlIGluIG9yZGVy IHRvDQogICAgICAgc3BlY2lmeSB3aGF0IFRhc2tzIHRoZSBNQSBzaG91bGQgZXhlY3V0ZS4NCg0K ICAgNC4gIFRpbWluZ3MuICBBIHNldCBvZiBUaW1pbmcgb2JqZWN0cyB0aGF0IGNhbiBiZSByZWZl cmVuY2VkIGZyb20gdGhlDQogICAgICAgU2NoZWR1bGVzLiAgRWFjaCBTY2hlZHVsZSBhbHdheXMg cmVmZXJlbmNlcyBleGFjdGx5IG9uZSBUaW1pbmcNCiAgICAgICBvYmplY3QuICBBIFRpbWluZyBv YmplY3Qgc3BlY2ZpZXMgZWl0aGVyIGEgc2luZ2xldG9uIG9yIHNlcmllcyBvZg0KICAgICAgIHRp bWUgZXZlbnRzLiAgVGhleSBhcmUgdXNlZCB0byBpbmRpY2F0ZSB3aGVuIFRhc2tzIHNob3VsZCBi ZQ0KICAgICAgIGV4ZWN1dGVkLg0KDQogICBUaGUgZm9sbG93aW5nIGRpYWdyYW0gaWxsdXN0cmF0 ZXMgdGhlIHN0cnVjdHVyZSBpbiB3aGljaCB0aGVzZSBjb21tb24NCiAgIGluZm9ybWF0aW9uIG9i amVjdHMgYXJlIHJlZmVyZW5jZWQuICBUaGUgcmVmZXJlbmNlcyBhcmUgYWNoaWV2ZWQgYnkNCiAg IGVhY2ggb2JqZWN0IChDaGFubmVsLCBUYXNrIENvbmZpZ3VyYXRpb24sIFRpbWluZykgYmVpbmcg Z2l2ZW4gYSBzaG9ydA0KDQoNCg0KDQpCdXJicmlkZ2UsIGV0IGFsLiAgICAgICBFeHBpcmVzIEZl YnJ1YXJ5IDIxLCAyMDE1ICAgICAgICAgICAgICAgW1BhZ2UgNl0NCg0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgIExNQVAgSW5mb3JtYXRpb24gTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDE0 DQoNCg0KICAgdGV4dCBuYW1lIHRoYXQgaXMgdXNlZCBieSBvdGhlciBvYmplY3RzLiAgVGhlIG9i amVjdHMgc2hvd24gaW4NCiAgIHBhcmVudGhlc2lzIGFyZSBwYXJ0IG9mIHRoZSBpbnRlcm5hbCBv YmplY3Qgc3RydWN0dXJlIG9mIGEgU2NoZWR1bGUuDQoNCiAgICAgICAgICBTY2hlZHVsZQ0KICAg ICAgICAgICAgICB8LS0tLS0tLS0tLT4gVGltaW5nDQogICAgICAgICAgICAgIHwtLS0tLS0tLS0t PiAoU2NoZWR1bGVkIFRhc2tzKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 LS0tLS0tLS0tLT4gVGFzayBDb25maWd1cmF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwtLS0tLS0tLS0tPiAoVGFzayBDaGFubmVscyBhbmQgZG93bnN0cmVhbSBUYXNr cykNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwtLS0tLS0tLS0tPiBDaGFubmVscw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0+IERvd25zdHJlYW0gVGFza3MNClBsZWFz ZSBudW1iZXIgdGhlIGZpZ3VyZXMuDQoNCldoeSBpcyBvbmx5ICJjb25maWd1cmF0aW9uIiBtZW50 aW9uZWQgaW4gdGhlIGZpZ3VyZT8NCkkgdW5kZXJzdG9vZCB0aGF0IGV2ZXJ5dGhpbmcgaXMgbm93 IGEgdGFzazoNCiAgICBjb250cm9sbGVyIGNvbW11bmljYXRpb24NCiAgICByZXBvcnRpbmcNCiAg ICBtZWFzdXJlbWVudA0KICAgIGRhdGEgYWdncmVnYXRpb24NCiAgICAuLi4NClRoaXMgd2FzIGNv bmZ1c2luZyB0byBtZS4NCg0KDQoNCg0KICAgSXQgc2hvdWxkIGJlIGNsZWFyIHRoYXQgdGhlIHRv cC1sZXZlbCBiYWhhdmlvdXIgb2YgYW4gTUEgaXMgc2ltcGx5IHRvDQogICBleGVjdXRlIFNjaGVk dWxlcy4gIEV2ZXJ5IGFjdGlvbiByZWZlcmVuY2VkIGJ5IGEgU2NoZWR1bGUgaXMgZGVmaW5lZA0K ICAgYXMgYSBUYXNrLiAgQXMgc3VjaCwgdGhlc2UgYWN0aW9ucyBhcmUgY29uZmlndXJlZCB0aHJv dWdoIFRhc2sNCiAgIENvbmZpZ3VyYXRpb25zIGFuZCBleGVjdXRlZCBhY2NvcmRpbmcgdG8gdGhl IFRpbWluZyByZWZlcmVuY2VkIGJ5IHRoZQ0KICAgU2NoZWR1bGUgaW4gd2hpY2ggdGhleSBhcHBl YXIuICBUYXNrcyBjYW4gaW1wbGVtZW50IGEgdmFyaWV0eSBvZg0KICAgZGlmZmVyZW50IHR5cGVz IG9mIGFjdGlvbnMuICBXaGlsZSBpbiB0ZXJtcyBvZiB0aGUgSW5mb3JtYXRpb24gTW9kZWwsDQog ICBhbGwgVGFza3MgaGF2ZSB0aGUgc2FtZSBzdHJ1Y3R1cmUsIGl0IGNhbiBoZWxwIGNvbmNlcHR1 YWxseSB0byB0aGluaw0KICAgb2YgZGlmZmVyZW50IFRhc2sgY2F0ZWdvcmllczoNCg0KICAgMS4g IE1lYXN1cmVtZW50IFRhc2tzDQoNCiAgICAgICBBLiAgTWVhc3VyZW1lbnQgVGFza3MgbWVhc3Vy ZSBzb21lIGFzcGVjdCBvZiBuZXR3b3JrIHBlcmZvcm1hbmNlDQogICAgICAgICAgIG9yIHRyYWZm aWMNCg0KICAgICAgIEIuICBEYXRhIENhcHR1cmUgVGFza3MgY2FwdHVyZSBhbmQgYW5hbHlzZSBw YXNzaXZlIGluZm9ybWF0aW9uDQpXaHkgY2FwdHVyZT8gV2UgY2FuIGFuYWx5c2Ugd2l0aG91dCBj YXB0dXJlLg0KICAgICAgICAgICBzdG9yZWQgb24gdGhlIE1BIGRldmljZSBzdWNoIGFzIGNvdW50 ZXJzIGFuZCBkZXZpY2UvbmV0d29yaw0KICAgICAgICAgICBzdGF0dXMgaW5mb3JtYXRpb24NCg0K V2h5IG5vdCB0cmFmZmljPw0KRnJvbSB0aGUgY2hhcnRlcjoNCkJvdGggYWN0aXZlIGFuZCBwYXNz aXZlIG1lYXN1cmVtZW50cyBhcmUgaW4gc2NvcGUsIGFsdGhvdWdoIHRoZXJlIG1heSBiZSBkaWZm ZXJlbmNlcyBpbiB0aGVpciBhcHBsaWNhYmlsaXR5IHRvIHNwZWNpZmljIHVzZSBjYXNlcywgb3Ig aW4gdGhlIHNlY3VyaXR5IG1lYXN1cmVzIG5lZWRlZCBhY2NvcmRpbmcgdG8gdGhlIHRocmVhdHMg c3BlY2lmaWMgdG8gZWFjaCBtZWFzdXJlbWVudCBjYXRlZ29yeQ0KDQoNCg0KICAgMi4gIERhdGEg VHJhbnNmZXIgVGFza3MNCg0KICAgICAgIEEuICBSZXBvcnRpbmcgVGFza3MgcmVwb3J0IHRoZSBy ZXN1bHRzIG9yIE1lYXN1cmVtZW50IFRhc2tzIHRvDQogICAgICAgICAgIENvbGxlY3RvcnMNCiJS ZXBvcnRpbmcgVGFza3MgcmVwb3J0IE1lYXN1cmVtZW50IFRhc2tzIHRvIENvbGxlY3RvcnMiDQpS ZWFsbHk/IFNvIHRoZSBDb250cm9sbGVyIGNvbmZpZ3VyZXMgdGhlIFJlcG9ydGluZyBUYXNrcyBv biB0aGUgTUEsIGFuZCB0aGUgTUEgcmVwb3J0cyB0aGVtIHRvIHRoZSBDb2xsZWN0b3I/DQoNCk1h eWJlIHlvdSBtZWFudD8NCiAgICAgICBBLiAgUmVwb3J0aW5nIFRhc2tzIHJlcG9ydCB0aGUgcmVz dWx0cyBvZiBNZWFzdXJlbWVudCBUYXNrcyB0bw0KICAgICAgICAgICBDb2xsZWN0b3JzDQoNCg0K ICAgICAgIEIuICBDb250cm9sIFRhc2socykgaW1wbGVtZW50IHRoZSBDb250cm9sIFByb3RvY29s IGFuZA0KICAgICAgICAgICBjb21tdW5pY2F0ZSB3aXRoIHRoZSBDb250cm9sbGVyLiAgRGVwZW5k aW5nIG9uIHRoZSBDb250cm9sDQogICAgICAgICAgIFByb3RvY29sIHRoaXMgbWF5IGJlIGEgbnVt YmVyIG9mIHNwZWNpYWxpc3QgdGFza3Mgc3VjaCBhczoNCldoYXQgaXMgInRoaXMiPw0KDQogICAg ICAgICAgIENvbmZpZ3VyYXRpb24gVGFzazsgSW5zdHJ1Y3Rpb24gVGFzazsgU3VwcHJlc3Npb24g VGFzazsNCiAgICAgICAgICAgQ2FwYWJpbGl0aWVzIFRhc2s7IExvZ2dpbmcgVGFzayBldGMuDQoN CiAgIDMuICBEYXRhIEFuYWx5c2lzIFRhc2tzIGNhbiBleGlzdCB0byBhbmFseXNlIGRhdGEgZnJv bSBvdGhlcg0KICAgICAgIE1lYXN1cmVtZW50IFRhc2tzIGxvY2FsbHkgb24gdGhlIE1BDQoNCiAg IDQuICBEYXRhIE1hbmFnZW1lbnQgVGFza3MgbWF5IGV4aXN0IHRvIGNsZWFuLXVwLCBmaWx0ZXIg b3IgY29tcHJlc3MNCiAgICAgICBkYXRhIG9uIHRoZSBNQSBzdWNoIGFzIE1lYXN1cmVtZW50IFRh c2sgcmVzdWx0cw0KDQoNCg0KDQoNCg0KQnVyYnJpZGdlLCBldCBhbC4gICAgICAgRXhwaXJlcyBG ZWJydWFyeSAyMSwgMjAxNSAgICAgICAgICAgICAgIFtQYWdlIDddDQoNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICBMTUFQIEluZm9ybWF0aW9uIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAx NA0KDQoNCjMuMi4gIFByZS1Db25maWd1cmF0aW9uIEluZm9ybWF0aW9uDQoNCiAgIFRoaXMgaW5m b3JtYXRpb24gaXMgdGhlIG1pbmltYWwgaW5mb3JtYXRpb24gdGhhdCBuZWVkcyB0byBiZSBwcmUt DQogICBjb25maWd1cmVkIHRvIHRoZSBNQSBpbiBvcmRlciBmb3IgaXQgdG8gc3VjY2Vzc2Z1bGx5 IGNvbW11bmljYXRlIHdpdGgNCiAgIGEgQ29udHJvbGxlciBkdXJpbmcgdGhlIHJlZ2lzdHJhdGlv biBwcm9jZXNzLg0KSW4gc2VjdGlvbiAzLjEsIHdlIGxlYXJuZWQ6DQoNCiAgIDEuICBQcmUtQ29u ZmlndXJhdGlvbiBJbmZvcm1hdGlvbi4gIEluZm9ybWF0aW9uIHByZS1jb25maWd1cmVkIG9uIHRo ZQ0KDQogICAgICAgTWVhc3VyZW1lbnQgQWdlbnQgcHJpb3IgdG8gYW55IGNvbW11bmljYXRpb24g d2l0aCBvdGhlcg0KDQogICAgICAgY29tcG9uZW50cyBvZiB0aGUgTE1BUCBhcmNoaXRlY3R1cmUg KGkuZS4sIHRoZSBDb250cm9sbGVyLA0KDQogICAgICAgQ29sbGVjdG9yIGFuZCBNZWFzdXJlbWVu dCBQZWVycyksIHNwZWNpZmljYWxseSBkZXRhaWxpbmcgaG93IHRvDQoNCiAgICAgICBjb21tdW5p Y2F0ZSB3aXRoIGEgQ29udHJvbGxlciBhbmQgd2hldGhlciB0aGUgZGV2aWNlIGlzIGVuYWJsZWQN Cg0KICAgICAgIHRvIHBhcnRpY2lwYXRlIGFzIGFuIE1BLg0KU28gdGhlIHByZS1jb25maWd1cmF0 aW9uIGluZm9ybWF0aW9uIGlzIG9ubHkgZm9yIHRoZSBDb250cm9sbGVyIGNvbW11bmljYXRpb24g KEkgZ3Vlc3Mgc28pIG9yIGFsc28gZm9yIHRoZSBjb2xsZWN0b3IgYW5kIG1lYXN1cmVtZW50IHBl ZXJzPw0KDQpUaGUgcHJlLWNvbmZpZ3VyYXRpb24NCiAgIGluZm9ybWF0aW9uIGlzIGEgc3Vic2V0 IG9mIHRoZSBDb25maWd1cmF0aW9uIEluZm9ybWF0aW9uIGFsb25nIHdpdGgNCiAgIHNvbWUgcGFy YW1ldGVycyB0aGF0IGFyZSBub3QgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIExNQVAgZnJhbWV3 b3JrDQogICAoc3VjaCBhcyB0aGUgdGhlIGRldmljZSBpZGVudGlmaWVyIGFuZCBkZXZpY2Ugc2Vj dXJpdHkgY3JlZGVudGlhbHMpLg0KSSBjYW4ndCBwYXJzZSAibm90IHVuZGVyIHRoZSBjb250cm9s IG9mIHRoZSBMTUFQIGZyYW1ld29yayINCg0KICAgVGhpcyBwcmUtY29uZmlndXJhdGlvbiBpbmZv cm1hdGlvbiBuZWVkcyB0byBpbmNsdWRlIGEgVVJMIG9mIHRoZQ0KICAgaW5pdGlhbCBDb250cm9s bGVyIHdoZXJlIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gY2FuIGJlIHJldHJpZXZlZA0KT0xE OiByZXRyaWV2ZWQNCk5FVzogY29tbXVuaWNhdGVkDQpORVcgKGFsdGVybmF0aXZlKTogcHVsbGVk IG9yIHB1c2hlZA0KDQpKdXN0aWZpY2F0aW9uOiB0aGUgbmV4dCBwYXJhZ3JhcGhzIG1ha2UgdGhl IGRpc3RpbmN0aW9uLg0KDQogICBhbG9uZyB3aXRoIHRoZSBzZWN1cml0eSBpbmZvcm1hdGlvbiBy ZXF1aXJlZCBmb3IgdGhlIGNvbW11bmljYXRpb24NCiAgIGluY2x1ZGluZyB0aGUgY2VydGlmaWNh dGUgb2YgdGhlIENvbnRyb2xsZXIgKG9yIHRoZSBjZXJ0aWZpY2F0ZSBvZg0KICAgdGhlIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IHdoaWNoIHdhcyB1c2VkIHRvIGlzc3VlIHRoZSBjZXJ0aWZpY2F0 ZQ0KICAgZm9yIHRoZSBDb250cm9sbGVyKS4gIEFsbCB0aGlzIGlzIGV4cHJlc3NlZCBhcyBhIENo YW5uZWwuICBXaGlsZQ0KICAgbXVsdGlwbGUgQ2hhbm5lbHMgbWF5IGJlIHByb3ZpZGVkIGluIHRo ZSBwcmUtY29uZmlndXJhdGlvbg0KICAgaW5mb3JtYXRpb24gdGhleSBtdXN0IGFsbCBiZSBhc3Nv Y2lhdGVkIHdpdGggYSBzaW5nbGUgQ29udHJvbGxlcg0KICAgKGUuZy4gb3ZlciBkaWZmZXJlbnQg aW50ZXJmYWNlcyBvciBuZXR3b3JrIHByb3RvY29scykuDQoNCiAgIFdoZXJlIHRoZSBNQSBwdWxs cyBpbmZvcm1hdGlvbiBmcm9tIHRoZSBDb250cm9sbGVyLCB0aGUgUHJlLQ0KICAgQ29uZmlndXJh dGlvbiBJbmZvcm1hdGlvbiBhbHNvIG5lZWRzIHRvIGNvbnRhaW4gdGhlIHRpbWluZyBvZiB0aGUN CiAgIGNvbW11bmljYXRpb24gd2l0aCB0aGUgQ29udHJvbGxlciBhcyB3ZWxsIGFzIHRoZSBuYXR1 cmUgb2YgdGhlDQogICBjb21tdW5pY2F0aW9uIGl0c2VsZiAoc3VjaCBhcyB0aGUgcHJvdG9jb2wg YW5kIGRhdGEgdG8gYmUNCiAgIHRyYW5zZmVyZWQpLiAgVGhlIHRpbWluZyBpcyBnaXZlbiBhcyBh IFNjaGVkdWxlIHRoYXQgZXhlY3V0ZXMgdGhlDQogICBUYXNrKHMpIHJlc3BvbnNpYmxlIGZvciBj b21tdW5pY2F0aW9uIHdpdGggdGhlIENvbnRyb2xsZXIuICBJdCBpcw0KICAgdGhpcyBUYXNrIChv ciBUYXNrcykgdGhhdCBpbXBsZW1lbnQgdGhlIENvbnRyb2wgcHJvdG9jb2wgYmV0d2VlbiB0aGUN CiAgIE1BIGFuZCB0aGUgQ29udHJvbGxlci4gIFRoZSBUYXNrKHMpIG1heSB0YWtlIGFkZGl0aW9u YWwgcGFyYW1ldGVycyBpbg0KICAgd2hpY2ggY2FzZSBhIFRhc2sgQ29uZmlndXJhdGlvbiBjYW4g YWxzbyBiZSBpbmNsdWRlZC4NCg0KICAgRXZlbiB3aGVyZSBpbmZvcm1hdGlvbiBpcyBwdXNoZWQg dG8gdGhlIE1BIGZyb20gdGhlIENvbnRyb2xsZXINCiAgIChyYXRoZXIgdGhhbiBwdWxsZWQgYnkg dGhlIE1BKSwgYSBTY2hlZHVsZSBzdGlsbCBuZWVkcyB0byBiZQ0KICAgc3VwcGxpZWQuICBJbiB0 aGlzIGNhc2UgdGhlIFNjaGVkdWxlIHdpbGwgc2ltcGx5IGV4ZWN1dGUgYSBDb250cm9sbGVyDQog ICBsaXN0ZW5lciB0YXNrIHdoZW4gdGhlIE1BIGlzIHN0YXJ0ZWQuICBBIENoYW5uZWwgaXMgc3Rp bGwgcmVxdWlyZWQNCiAgIGZvciB0aGUgTUEgdG8gZXN0YWJsaXNoIHNlY3VyZSBjb21tdW5pY2F0 aW9uIHdpdGggdGhlIENvbnRyb2xsZXIuDQoNCiAgIEl0IGNhbiBiZSBzZWVuIHRoYXQgdGhlc2Ug Q2hhbm5lbHMsIFNjaGVkdWxlcyBhbmQgVGFzayBDb25maWd1cmF0aW9ucw0KICAgZm9yIHRoZSBp bml0aWFsIE1BLUNvbnRyb2xsZXIgY29tbXVuaWNhdGlvbiBhcmUgbm8gZGlmZmVyZW50IGluIHRl cm1zDQogICBvZiB0aGUgSW5mb3JtYXRpb24gTW9kZWwgdG8gYW55IG90aGVyIENoYW5uZWwsIFNj aGVkdWxlIG9yIFRhc2sNCiAgIENvbmZpZ3VyYXRpb24gdGhhdCBtaWdodCBleGVjdXRlIGEgTWVh c3VyZW1lbnQgVGFzayBvciByZXBvcnQgdGhlDQogICBtZWFzdXJlbWVudCByZXN1bHRzIChhcyBk ZXNjcmliZWQgbGF0ZXIpLg0KDQogICBUaGUgTUEgbWF5IGJlIHByZS1jb25maWd1cmVkIHdpdGgg YW4gTUEgSUQsIG9yIG1heSB1c2UgYSBEZXZpY2UgSUQgaW4NCiAgIHRoZSBpbml0aWFsIENvbnRy b2xsZXIgY29udGFjdCBiZWZvcmUgaXQgaXMgYXNzaWduZWQgYW4gTUEgSUQuDQpBZ2FpbiwgSSdt IGNvbmZ1c2VkIGJ5IHRoaXMgaW5pdGlhbCBDb250cm9sbGVyLg0KDQoNClRoZQ0KICAgRGV2aWNl IElEIG1heSBiZSBhIE1BQyBhZGRyZXNzIG9yIHNvbWUgb3RoZXIgZGV2aWNlIGlkZW50aWZpZXIN CiAgIGV4cHJlc3NlZCBhcyBhIFVSTi4gIElmIHRoZSBNQSBJRCBpcyBub3QgcHJvdmlkZWQgYXQg dGhpcyBzdGFnZSB0aGVuDQogICBpdCBtdXN0IGJlIHByb3ZpZGVkIGJ5IHRoZSBDb250cm9sbGVy IGR1cmluZyBDb25maWd1cmF0aW9uLg0KDQogICBEZXRhaWwgb2YgdGhlIGluZm9ybWF0aW9uIG1v ZGVsIGVsZW1lbnRzOg0KDQoNCg0KQnVyYnJpZGdlLCBldCBhbC4gICAgICAgRXhwaXJlcyBGZWJy dWFyeSAyMSwgMjAxNSAgICAgICAgICAgICAgIFtQYWdlIDhdDQoNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICBMTUFQIEluZm9ybWF0aW9uIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAxNA0K DQoNCi8vIE1BIHByZS1jb25maWd1cmF0aW9uIG1pbmltYWwgaW5mb3JtYXRpb24gdG8gY29tbXVu aWNhdGUgaW5pdGlhbGx5IHdpdGggQ29udHJvbGxlcg0KDQpvYmplY3Qgew0KICAgIFt1dWlkICAg ICAgICAgICAgICAgIG1hLWFnZW50LWlkO10NCiAgICAgbWEtdGFzay1vYmogICAgICAgICBtYS1j b250cm9sLXRhc2tzPDEuLio+Ow0KICAgICBtYS1jaGFubmVsLW9iaiAgICAgIG1hLWNvbnRyb2wt Y2hhbm5lbHM8MS4uKj47DQogICAgIG1hLXNjaGVkdWxlLW9iaiAgICAgbWEtY29udHJvbC1zY2hl ZHVsZXM8MS4uKj47DQogICAgW3VybiAgICAgICAgICAgICAgICAgbWEtZGV2aWNlLWlkO10NCiAg ICAgY3JlZGVudGlhbHMgICAgICAgICBtYS1jcmVkZW50aWFsczsNCn0gbWEtY29uZmlnLW9iajsN Cg0KICAgVGhlIGRldGFpbCBvZiB0aGUgQ2hhbm5lbCBhbmQgU2NoZWR1bGUgb2JqZWN0cyBhcmUg ZGVzY3JpYmVkIGxhdGVyDQogICBzaW5jZSB0aGV5IGFyZSBjb21tb24gdG8gc2V2ZXJhbCBwYXJ0 cyBvZiB0aGUgaW5mb3JtYXRpb24gbW9kZWwuDQoNCjMuMy4gIENvbmZpZ3VyYXRpb24gSW5mb3Jt YXRpb24NCg0KICAgRHVyaW5nIHJlZ2lzdHJhdGlvbiBvciBhdCBhbnkgbGF0ZXIgcG9pbnQgYXQg d2hpY2ggdGhlIE1BIGNvbnRhY3RzDQogICB0aGUgQ29udHJvbGxlciAob3IgdmljZS12ZXJzYSks IHRoZSBjaG9pY2Ugb2YgQ29udHJvbGxlciwNCiJUaGUgY2hvaWNlIG9mIENvbnRyb2xsZXIiLCBk byB5b3Ugd2FudCB0byBzYXkgImFuIGFsdGVybmF0ZSBDb250cm9sbGVyIiwgYmVjYXVzZSBhdCB0 aGlzIHBvaW50IHRoZSBNQSBpcyBhbHJlYWR5IGluIGNvbnRhY3Qgd2l0aCB0aGUgQ29udHJvbGxl ci4NCg0KZGV0YWlscyBmb3INCiAgIHRoZSB0aW1pbmcgb2YgY29tbXVuaWNhdGlvbiB3aXRoIHRo ZSBDb250cm9sbGVyIG9yIHBhcmFtZXRlcnMgZm9yIHRoZQ0KICAgY29tbXVuaWNhdGlvbiBUYXNr KHMpIGNhbiBiZSBjaGFuZ2VkIChhcyBjYXB0dXJlZCBieSB0aGUgQ2hhbm5lbHMsDQogICBTY2hl ZHVsZXMgYW5kIFRhc2sgQ29uZmlndXJhdGlvbnMgb2JqZWN0cykuICBGb3IgZXhhbXBsZSB0aGUg cHJlLQ0KICAgY29uZmlndXJlZCBDb250cm9sbGVyIChzcGVjaWZpZWQgYXMgYSBDaGFubmVsIG9y IENoYW5uZWxzKSBtYXkgYmUNCiAgIHJlcGxhY2VkIHdpdGggYSBzcGVjaWZpYyBDb250cm9sbGVy IHRoYXQgaXMgbW9yZSBhcHByb3ByaWF0ZSB0byB0aGUNCiAgIE1BIGRldmljZSB0eXBlLCBsb2Nh dGlvbiBvciBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIG5ldHdvcmsgKGUuZy4NCiAgIGFjY2VzcyB0 ZWNobm9sb2d5IHR5cGUgb3IgYnJvYWRiYW5kIHByb2R1Y3QpLiAgVGhlIGluaXRpYWwNCiAgIGNv bW11bmljYXRpb24gU2NoZWR1bGUgbWF5IGJlIHJlcGxhY2VkIHdpdGggb25lIG1vcmUgcmVsZXZh bnQgdG8NCiAgIHJvdXRpbmUgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiB0aGUgTUEgYW5kIHRoZSBD b250cm9sbGVyLg0KDQogICBXaGlsZSBzb21lIENvbnRyb2wgcHJvdG9jb2xzIGFuZCB1c2VzIG1h eSBvbmx5IHVzZSBhIHNpbmdsZSBTY2hlZHVsZSwNCiAgIG90aGVyIHByb3RvY29scyBhbmQgdXNl cyBtYXkgdXNlcyBzZXZlcmFsIFNjaGVkdWxlcyAoYW5kIHJlbGF0ZWQgZGF0YQ0KICAgdHJhbnNm ZXIgVGFza3MpIHRvIHVwZGF0ZSB0aGUgQ29uZmlndXJhdGlvbiBJbmZvcm1hdGlvbiwgdHJhbnNm ZXIgdGhlDQogICBJbnN0cnVjdGlvbiBJbmZvcm1hdGlvbiwgdHJhbnNmZXIgQ2FwYWJpbGl0eSBh bmQgU3RhdHVzIEluZm9ybWF0aW9uDQogICBhbmQgc2VuZCBvdGhlciBpbmZvcm1hdGlvbiB0byB0 aGUgQ29udHJvbGxlciBzdWNoIGFzIGxvZyBvciBlcnJvcg0KICAgbm90aWZpY2F0aW9ucy4gIE11 bHRpcGxlIENoYW5uZWxzIG1heSBiZSB1c2VkIHRvIGNvbW11bmljYXRlIHdpdGggdGhlDQogICBz YW1lIENvbnRyb2xsZXIgb3ZlciBtdWx0aXBsZSBpbnRlcmZhY2VzIChlLmcuIHRvIHNlbmQgbG9n Z2luZw0KICAgaW5mb3JtYXRpb24gb3ZlciBhIGRpZmZlcmVudCBuZXR3b3JrKS4NCg0KICAgSW4g YWRkaXRpb24gdGhlIE1BIHdpbGwgYmUgZ2l2ZW4gZnVydGhlciBpdGVtcyBvZiBpbmZvcm1hdGlv biB0aGF0DQogICByZWxhdGUgc3BlY2lmaWNhbGx5IHRvIHRoZSBNQSByYXRoZXIgdGhhbiB0aGUg bWVhc3VyZW1lbnRzIGl0IGlzIHRvDQogICBjb25kdWN0IG9yIGhvdyB0byByZXBvcnQgcmVzdWx0 cy4gIFRoZSBhc3NpZ25tZW50IG9mIGFuIElEIHRvIHRoZSBNQQ0KICAgaXMgbWFuZGF0b3J5LiAg SWYgdGhlIE1BIEFnZW50IElEIHdhcyBub3Qgb3B0aW9uYWxseSBwcm92aWRlZCBkdXJpbmcNCiAg IHRoZSBwcmUtY29uZmlndXJhdGlvbiB0aGVuIG9uZSBtdXN0IGJlIHByb3ZpZGVkIGJ5IHRoZSBD b250cm9sbGVyDQogICBkdXJpbmcgQ29uZmlndXJhdGlvbi4gIE9wdGlvbmFsbHkgYSBHcm91cCBJ RCBtYXkgYWxzbyBiZSBnaXZlbiB3aGljaA0KICAgaWRlbnRpZmllcyBhIGdyb3VwIG9mIGludGVy ZXN0IHRvIHdoaWNoIHRoYXQgTUEgYmVsb25ncy4gIEZvciBleGFtcGxlDQogICB0aGUgZ3JvdXAg Y291bGQgcmVwcmVzZW50IGFuIElTUCwgYnJvYWRiYW5kIHByb2R1Y3QsIHRlY2hub2xvZ3ksDQog ICBtYXJrZXQgY2xhc3NpZmljYXRpb24sIGdlb2dyYXBoaWMgcmVnaW9uLCBvciBhIGNvbWJpbmF0 aW9uIG9mDQogICBtdWx0aXBsZSBzdWNoIGNoYXJhY3RlcmlzdGljcy4gIFdoZXJlIHRoZSBNZWFz dXJlbWVudCBHcm91cCBJRCBpcyBzZXQNCiAgIGFuIGFkZGl0aW9uYWwgZmxhZyAodGhlIFJlcG9y dCBNQSBJRCBmbGFnKSBpcyByZXF1aXJlZCB0byBjb250cm9sDQoNCg0KDQpCdXJicmlkZ2UsIGV0 IGFsLiAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIxLCAyMDE1ICAgICAgICAgICAgICAgW1BhZ2Ug OV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIExNQVAgSW5mb3JtYXRpb24gTW9kZWwgICAg ICAgICAgICAgIEF1Z3VzdCAyMDE0DQoNCg0KICAgd2hldGhlciB0aGUgTWVhc3VyZW1lbnQgQWdl bnQgSUQgaXMgYWxzbyB0byBiZSByZXBvcnRlZC4gIFRoZQ0KICAgcmVwb3J0aW5nIG9mIGEgR3Jv dXAgSUQgd2l0aG91dCB0aGUgTUEgSUQgYWxsb3dzIHRoZSBNQSB0byByZW1haW4NCiAgIGFub255 bW91cywgd2hpY2ggbWF5IGJlIHBhcnRpY3VsYXJseSB1c2VmdWwgdG8gcHJldmVudCB0cmFja2lu ZyBvZg0KICAgbW9iaWxlIE1BIGRldmljZXMuDQoNCiAgIE9wdGlvbmFsbHkgYW4gTUEgY2FuIGFs c28gYmUgY29uZmlndXJlZCB0byBzdG9wIGV4ZWN1dGluZyBhbnkNCiAgIEluc3RydWN0aW9uIFNj aGVkdWxlIGlmIHRoZSBDb250cm9sbGVyIGlzIHVucmVhY2hhYmxlLiAgVGhpcyBjYW4gYmUNCiAg IHVzZWQgYXMgYSBmYWlsLXNhZmUgdG8gc3RvcCBNZWFzdXJlbWVudCBhbmQgb3RoZXIgVGFza3Mg YmVpbmcNCiAgIGNvbmR1Y3RlZCB3aGVuIHRoZXJlIGlzIGRvdWJ0IHRoYXQgdGhlIEluc3RydWN0 aW9uIEluZm9ybWF0aW9uIGlzDQogICBzdGlsbCB2YWxpZC4gIFRoaXMgaXMgc2ltcGx5IHJlcHJl c2VudGVkIGFzIGEgdGltZSB3aW5kb3cgaW4NCiAgIG1pbGxpc2Vjb25kcyBzaW5jZSB0aGUgbGFz dCBjb21tdW5pY2F0aW9uIHdpdGggdGhlIENvbnRyb2xsZXIgYWZ0ZXINCiAgIHdoaWNoIEluc3Ry dWN0aW9uIFNjaGVkdWxlcyBhcmUgdG8gYmUgc3VzcGVuZGVkLiAgVGhlIGFwcHJvcHJpYXRlDQog ICB2YXVlIG9mIHRoZSB0aW1lIHdpbmRvdyB3aWxsIGRlcGVuZCBvbiB0aGUgc3BlY2lmaWVkIGNv bW11bmljYXRpb24NCnZhbHVlDQoNCiAgIFNjaGVkdWxlIHdpdGggdGhlIENvbnRyb2xsZXIgYW5k IHRoZSBkdXJhdGlvbiBmb3Igd2hpY2ggdGhlIHN5c3RlbSBpcw0KICAgd2lsbGluZyB0byB0b2xl cmF0ZSBjb250aW51ZWQgb3BlcmF0aW9uIHdpdGggcG90ZW50aWFsbHkgc3RhbGUNCiAgIEluc3Ry dWN0aW9uIEluZm9ybWF0aW9uLg0KDQogICBXaGlsZSBwcmUtY29uZmlndXJhdGlvbiBpcyBwZXJz aXN0ZW50IHVwb24gZGV2aWNlIHJlc2V0IG9yIHBvd2VyDQogICBjeWNsZSBkdWUgdG8gaXRzIHZl cnkgbmF0dXJlLCB0aGUgcGVyc2lzdGVuY3kgb2YgdGhlIGFkZHRpb25hbA0KICAgY29uZmlndXJh dGlvbiBpbmZvcm1hdGlvbiBtYXkgYmUgY29udHJvbCBwcm90b2NvbCBkZXBlbmRlbnQuDQpXaHkg IkNvbnRyb2wgUHJvdG9jb2wiIGRlcGVuZGVudD8NCldoeSBpc24ndCB0aGUgcGVyc2lzdGVuY2Ug SU0gKG9yIERNKSBzcGVjaWZpYz8NCg0KU29tZQ0KICAgcHJvdG9jb2xzIG1heSBhc3N1bWUgdGhh dCByZXNldCBkZXZpY2VzIHdpbGwgcmV2ZXJ0IGJhY2sgdG8gdGhlaXINCiAgIHByZS1jb25maWd1 cmF0aW9uIHN0YXRlLCB3aGlsZSBvdGhlciBwcm90b2NvbHMgbWF5IGFzc3VtZSB0aGF0IGFsbA0K ICAgY29uZmlndXJhdGlvbiBhbmQgaW5zdHJ1Y3Rpb24gaW5mb3JtYXRpb24gaXMgaGVsZCBpbiBw ZXJzaXN0ZW50DQogICBzdG9yYWdlLg0KDQogICBJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCBjb250 cm9sIHNoZWR1bGVzIGFuZCB0YXNrcyBjYW5ub3QgYmUNCiAgIHN1cHByZXNzZWQgYXMgZXZpZGVu Y2VkIGJ5IHRoZSBsYWNrIG9mIHN1cHByZXNzaW9uIGluZm9ybWF0aW9uIGluIHRoZQ0KICAgQ29u ZmlndXJhdGlvbi4gIFRoZSBjb250cm9sIHNjaGVkdWxlIG11c3Qgb25seSByZWZlcmVuY2UgdGFz a3MgbGlzdGVkDQogICBhcyBjb250cm9sIHRhc2tzLiAgQW55IHN1cHByZXNzLWJ5LWRlZmF1bHQg ZmxhZyBhZ2FpbnN0IGNvbnRyb2wgdGFza3MNCiAgIHdpbGwgYmUgaWdub3JlZC4NCg0KICAgRGV0 YWlsIG9mIHRoZSBhZGRpdGlvbmFsIGFuZCB1cGRhdGVkIGluZm9ybWF0aW9uIG1vZGVsIGVsZW1l bnRzOg0KDQogICAvLyBNQSBDb25maWd1cmF0aW9uDQoNCiAgIG9iamVjdCB7DQogICAgICAgdXVp ZCAgICAgICAgICAgICAgICBtYS1hZ2VudC1pZDsNCiAgICAgIFttYS10YXNrLW9iaiAgICAgICAg IG1hLWNvbnRyb2wtdGFza3M8MC4uKj47XQ0KICAgICAgIG1hLWNoYW5uZWwtb2JqICAgICAgbWEt Y29udHJvbC1jaGFubmVsczwxLi4qPjsNCiAgICAgIFttYS1zY2hlZHVsZS1vYmogICAgbWEtY29u dHJvbC1zY2hlZHVsZXM8MC4uKj5dOw0KICAgICAgW3VybiAgICAgICAgICAgICAgICAgbWEtZGV2 aWNlLWlkO10NCiAgICAgICBjcmVkZW50aWFscyAgICAgICAgIG1hLWNyZWRlbnRpYWxzOw0KICAg ICAgW3N0cmluZyAgICAgICAgICAgICAgbWEtZ3JvdXAtaWQ7XQ0KICAgICAgW2Jvb2xlYW4gICAg ICAgICAgICAgbWEtcmVwb3J0LW1hLWlkLWZsYWc7XQ0KICAgICAgW2ludCAgICAgICAgICAgICAg ICAgbWEtY29udHJvbC1jaGFubmVsLWZhaWx1cmUtdGhyZXNob2xkO10NCiAgIH0gbWEtY29uZmln LW9iajsNCg0KVGhhdCdzIHdoZXJlIEkgYXJyaXZlZC4NCg0KQW5kIG5vdywgdGltZSBmb3IgYSBH dWlubmVzcyBvciB0d28uIEknbSBpbiBEdWJsaW4gYWZ0ZXIgYWxsIDotKQ0KDQpSZWdhcmRzLCBC ZW5vaXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CmxtYXAgbWFpbGluZyBsaXN0DQpsbWFwQGlldGYub3JnPG1haWx0bzpsbWFwQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sbWFwDQoNCg== --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D4135F72CA7EMV67UKRDdoma_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p bHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Ymx1ZTsNCglmb250LXdlaWdodDpub3JtYWw7DQoJ Zm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLUdCIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRp diBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5IaSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjpibHVlJz5JIHRoaW5rIHRoZSB0ZXh0IEJlbm9pdCB3YXMgY29tbWVudGlu ZyBvbiBpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz4mbHQ7Jmx0 Ozwvc3Bhbj4mbmJzcDsmbmJzcDsgMi4mbmJzcDsgQ2hhbm5lbHMuJm5ic3A7IEEgc2V0IG9mIENo YW5uZWwgb2JqZWN0cyBhcmUgdXNlZCB0byBjb21tdW5pY2F0ZSB3aXRoIDxicj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBudW1iZXIgb2YgZW5kcG9pbnRzIChpLmUuIHRo ZSBDb250cm9sbGVyIGFuZCBDb2xsZWN0b3JzKS4mbmJzcDsgPG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjpibHVlJz4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOmJsdWUnPkJlbm9pdCBpcyByaWdodCB0aGF0IHRoaXMgY291bGQgYmUgd3JpdHRlbiBi ZXR0ZXIuIFBlcmhhcHMgc2ltcGx5IHF1b3RlIHRoZSBkZWZpbml0aW9uIGZyb20gdGhlIGZyYW1l d29yazo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIGxhbmc9RU4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Q2hhbm5lbDogQSBiaS1kaXJlY3Rpb25hbCBs b2dpY2FsIGNvbm5lY3Rpb24gdGhhdCBpcyBkZWZpbmVkIGJ5IGE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxz cGFuIGxhbmc9RU4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+wqDCoCBzcGVjaWZpYyBDb250cm9sbGVyIGFuZCBNQSwgb3IgQ29sbGVjdG9yIGFuZCBN QSwgcGx1cyBhc3NvY2lhdGVkPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7CoMKgIHNlY3VyaXR5Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5HcmVnIOKA kyB5ZXMuIFJlcG9ydHMgKG9mIG1lYXN1cmVtZW50cykgZ28gdG8gdGhlIGNvbGxlY3Rvci4gTG9n Z2luZyBpbmZvcm1hdGlvbiDigJMgaW5mbyBhYm91dCB0aGUgb3BlcmF0aW9uIG9mIHRoZSBNQSB0 aGF0IG1heSBiZSB1c2VmdWwgZm9yIGRlYnVnZ2luZyDigJMgZ29lcyB0byB0aGUgQ29udHJvbGxl ci4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkJl c3Qgd2lzaGVzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5waGlsPC9zcGFuPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBj bGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9u IEJlaGFsZiBPZiA8L2I+R3JlZyBNaXJza3k8YnI+PGI+U2VudDo8L2I+IDE3IFNlcHRlbWJlciAy MDE0IDEyOjQxPGJyPjxiPlRvOjwvYj4gQmVub2l0IENsYWlzZTxicj48Yj5DYzo8L2I+IGxtYXBA aWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbbG1hcF0gRmVlZGJhY2sgb24gZHJhZnQt aWV0Zi1sbWFwLWluZm9ybWF0aW9uLW1vZGVsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPkhpIEJlbm9pdCw8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+b24ganVzdCBvbmUgcXVlc3Rpb246PG86cD48L286cD48L3A+PGRpdiBzdHlsZT0n bWFyZ2luLWxlZnQ6MzAuMHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+TG9nZ2luZyBhbHdheXMgZ29l cyB0byB0aGUgQ29sbGVjdG9yLCByaWdodD88bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+QWNjb3JkaW5nIHRvIExNQVAgZnJhbWV3b3JrIGRvY3VtZW50IExvZ2dpbmcgZ29l cyBvdmVyIENvbnRyb2wsIG5vdCBSZXBvcnQgQ2hhbm5lbDo8bzpwPjwvbzpwPjwvcD48cHJlPsKg wqAgQ29udHJvbCBDaGFubmVsOiBBIENoYW5uZWwgYmV0d2VlbiBhIENvbnRyb2xsZXIgYW5kIGEg TUEgb3ZlciB3aGljaDxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgIEluc3RydWN0aW9uIE1lc3Nh Z2VzIGFuZCBDYXBhYmlsaXRpZXMsIEZhaWx1cmUgYW5kIExvZ2dpbmc8bzpwPjwvbzpwPjwvcHJl PjxwcmUgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz7CoMKgIEluZm9ybWF0aW9uIGFyZSBz ZW50LjxvOnA+PC9vOnA+PC9wcmU+PHByZT5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wcmU+PHByZT5H cmVnPG86cD48L286cD48L3ByZT48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gU3VuLCBTZXAgMTQsIDIwMTQgYXQgMTE6MzggUE0sIEJl bm9pdCBDbGFpc2UgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmJjbGFpc2VAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQn PkRlYXIgYWxsLDxicj48YnI+U2luY2Ugd2Ugd2lsbCBiZSBzcGVuZGluZyB0aW1lIG9uIGRyYWZ0 LWlldGYtbG1hcC1pbmZvcm1hdGlvbi1tb2RlbCB0b21vcnJvdywgaGVyZSBpcyBzb21lIG1vcmUg ZmVlZGJhY2suIEkgaGF2ZW4ndCBoYWQgdGhlIHRpbWUgdG8gcmV2aWV3IGl0IGFsbCwgc28gaGVy ZSBpcyBwYXJ0IDEuPGJyPklmIHNvbWUgcG9pbnRzIHdlcmUgYWxyZWFkeSBkaXNjdXNzZWQsIGRv bid0IGhlc2l0YXRlIHRvIGxldCBtZSBrbm93LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1 b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxwIGNsYXNz PU1zb05vcm1hbD5OZXR3b3JrIFdvcmtpbmcgR3JvdXAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVC4gQnVyYnJpZGdlIDxicj5JbnRlcm5l dC1EcmFmdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBQLiBFYXJkbGV5IDxicj5JbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCVCA8YnI+RXhw aXJlczogRmVicnVhcnkgMjEsIDIwMTUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgTS4gQmFnbnVsbyA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVuaXZlcnNpZGFkIENhcmxvcyBJSUkgZGUgTWFk cmlkIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSi4g U2Nob2Vud2FlbGRlciA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiA8YnI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1Z3VzdCAyMCwgMjAxNCA8 YnI+PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW5mb3JtYXRpb24gTW9kZWwgZm9y IExhcmdlLVNjYWxlIE1lYXN1cmVtZW50IFBsYXRmb3JtcyAoTE1BUCkgPGJyPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC1pZXRmLWxtYXAtaW5mb3Jt YXRpb24tbW9kZWwtMDIgPG86cD48L286cD48L3A+PC9ibG9ja3F1b3RlPjxwIGNsYXNzPU1zb05v cm1hbD5XaGF0IGRvZXMgTE1BUCBzdGFuZCBmb3I/PGJyPkluIHRoZSB1c2UgY2FzZXMgZHJhZnQs IGl0IHNheXMgJnF1b3Q7TGFyZ2Utc2NhbGUgTWVhc3VyZW1lbnQgb2YgQnJvYWRiYW5kIFBlcmZv cm1hbmNlIChMTUFQKSZxdW90Ozxicj5Cb3RoIHRoZSBmcmFtZXdvcmsgYW5kIHRoZSBpbmZvcm1h dGlvbiBtb2RlbCBzYXk6IExhcmdlLVNjYWxlIE1lYXN1cmVtZW50IFBsYXRmb3JtcyAoTE1BUCk8 YnI+PGJyPjxicj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPkFic3RyYWN0 IDxicj48YnI+Jm5ic3A7Jm5ic3A7IFRoaXMgSW5mb3JtYXRpb24gTW9kZWwgYXBwbGllcyB0byB0 aGUgTWVhc3VyZW1lbnQgQWdlbnQgd2l0aGluIGEgPGJyPiZuYnNwOyZuYnNwOyBMYXJnZS1TY2Fs ZSBNZWFzdXJlbWVudCBQbGF0Zm9ybS4mbmJzcDsgQXMgc3VjaCBpdCBvdXRsaW5lcyB0aGUgPGJy PiZuYnNwOyZuYnNwOyBpbmZvcm1hdGlvbiB0aGF0IGlzIChwcmUtKWNvbmZpZ3VyZWQgb24gdGhl IE1BIG9yIGV4aXN0cyBpbiA8YnI+Jm5ic3A7Jm5ic3A7IGNvbW11bmljYXRpb25zIHdpdGggYSBD b250cm9sbGVyIG9yIENvbGxlY3RvciB3aXRoaW4gYW4gTE1BUCA8YnI+Jm5ic3A7Jm5ic3A7IGZy YW1ld29yay4mbmJzcDsgVGhlIHB1cnBvc2Ugb2Ygc3VjaCBhbiBJbmZvcm1hdGlvbiBNb2RlbCBp cyB0byBwcm92aWRlIGEgPGJyPiZuYnNwOyZuYnNwOyBwcm90b2NvbCBhbmQgZGV2aWNlIGluZGVw ZW5kZW50IHZpZXcgb2YgdGhlIE1BIHRoYXQgY2FuIGJlIDxicj4mbmJzcDsmbmJzcDsgaW1wbGVt ZW50ZWQgdmlhIG9uZSBvciBtb3JlIENvbnRyb2wgYW5kIFJlcG9ydCBwcm90b2NvbHMuIDxicj48 YnI+UmVxdWlyZW1lbnRzIExhbmd1YWdlIDxicj48YnI+Jm5ic3A7Jm5ic3A7IFRoZSBrZXkgd29y ZHMgJnF1b3Q7TVVTVCZxdW90OywgJnF1b3Q7TVVTVCBOT1QmcXVvdDssICZxdW90O1JFUVVJUkVE JnF1b3Q7LCAmcXVvdDtTSEFMTCZxdW90OywgJnF1b3Q7U0hBTEwgTk9UJnF1b3Q7LCA8YnI+Jm5i c3A7Jm5ic3A7ICZxdW90O1NIT1VMRCZxdW90OywgJnF1b3Q7U0hPVUxEIE5PVCZxdW90OywgJnF1 b3Q7UkVDT01NRU5ERUQmcXVvdDssICZxdW90O01BWSZxdW90OywgYW5kICZxdW90O09QVElPTkFM JnF1b3Q7IGluIHRoaXMgPGJyPiZuYnNwOyZuYnNwOyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJw cmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4gPGJyPjxicj5TdGF0dXMg b2YgVGhpcyBNZW1vIDxicj48YnI+Jm5ic3A7Jm5ic3A7IFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMg c3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUgPGJyPiZuYnNwOyZuYnNwOyBw cm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LiA8YnI+PGJyPiZuYnNwOyZuYnNwOyBJbnRl cm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZyA8YnI+Jm5ic3A7Jm5ic3A7IFRhc2sgRm9yY2UgKElFVEYpLiZuYnNwOyBOb3RlIHRoYXQg b3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgPGJyPiZuYnNwOyZuYnNwOyB3b3JraW5n IGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuJm5ic3A7IFRoZSBsaXN0IG9mIGN1cnJlbnQg SW50ZXJuZXQtIDxicj4mbmJzcDsmbmJzcDsgRHJhZnRzIGlzIGF0IDxhIGhyZWY9Imh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8iIHRhcmdldD0iX2JsYW5rIj5odHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvPC9hPi4gPGJyPjxicj4mbmJz cDsmbmJzcDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiBzaXggbW9udGhzIDxicj4mbmJzcDsmbmJzcDsgYW5kIG1heSBiZSB1cGRhdGVk LCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgPGJyPiZu YnNwOyZuYnNwOyB0aW1lLiZuYnNwOyBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5l dC1EcmFmdHMgYXMgcmVmZXJlbmNlIDxicj4mbmJzcDsmbmJzcDsgbWF0ZXJpYWwgb3IgdG8gY2l0 ZSB0aGVtIG90aGVyIHRoYW4gYXMgJnF1b3Q7d29yayBpbiBwcm9ncmVzcy4mcXVvdDsgPGJyPjxi cj4mbmJzcDsmbmJzcDsgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBGZWJydWFy eSAyMSwgMjAxNS4gPGJyPjxicj48YnI+PGJyPjxicj48YnI+PGJyPkJ1cmJyaWRnZSwgZXQgYWwu Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgRmVicnVhcnkgMjEs IDIwMTUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1BhZ2UgMV0gPGJyPsKgPGJyPkludGVy bmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IExNQVAgSW5mb3JtYXRpb24gTW9kZWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg QXVndXN0IDIwMTQgPGJyPjxicj48YnI+Q29weXJpZ2h0IE5vdGljZSA8YnI+PGJyPiZuYnNwOyZu YnNwOyBDb3B5cmlnaHQgKGMpIDIwMTQgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRp ZmllZCBhcyB0aGUgPGJyPiZuYnNwOyZuYnNwOyBkb2N1bWVudCBhdXRob3JzLiZuYnNwOyBBbGwg cmlnaHRzIHJlc2VydmVkLiA8YnI+PGJyPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGlzIHN1 YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsIDxicj4mbmJzcDsmbmJz cDsgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cyA8YnI+Jm5ic3A7Jm5ic3A7 ICg8YSBocmVmPSJodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8iIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm88L2E+KSBpbiBlZmZl Y3Qgb24gdGhlIGRhdGUgb2YgPGJyPiZuYnNwOyZuYnNwOyBwdWJsaWNhdGlvbiBvZiB0aGlzIGRv Y3VtZW50LiZuYnNwOyBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cyA8YnI+Jm5ic3A7Jm5i c3A7IGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rp b25zIHdpdGggcmVzcGVjdCA8YnI+Jm5ic3A7Jm5ic3A7IHRvIHRoaXMgZG9jdW1lbnQuJm5ic3A7 IENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QgPGJyPiZu YnNwOyZuYnNwOyBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmli ZWQgaW4gU2VjdGlvbiA0LmUgb2YgPGJyPiZuYnNwOyZuYnNwOyB0aGUgVHJ1c3QgTGVnYWwgUHJv dmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMgPGJyPiZuYnNwOyZu YnNwOyBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuIDxicj48YnI+VGFi bGUgb2YgQ29udGVudHMgPGJyPjxicj4mbmJzcDsmbmJzcDsgMS4mbmJzcDsgSW50cm9kdWN0aW9u Jm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5i c3A7Jm5ic3A7IDMgPGJyPiZuYnNwOyZuYnNwOyAyLiZuYnNwOyBOb3RhdGlvbiZuYnNwOyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsmbmJz cDsgNCA8YnI+Jm5ic3A7Jm5ic3A7IDMuJm5ic3A7IExNQVAgSW5mb3JtYXRpb24gTW9kZWwmbmJz cDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNwOyA0IDxi cj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMy4xLiZuYnNwOyBJbmZvcm1hdGlvbiBTdHJ1Y3R1 cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsmbmJzcDsgNCA8YnI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMuMi4mbmJzcDsgUHJlLUNvbmZpZ3VyYXRpb24gSW5m b3JtYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7Jm5ic3A7IDggPGJyPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzLjMuJm5ic3A7IENvbmZpZ3VyYXRpb24gSW5mb3JtYXRp b24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNwOyA5IDxicj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMy40LiZuYnNwOyBJbnN0cnVjdGlvbiBJbmZvcm1hdGlvbiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgMTEgPGJyPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAzLjUuJm5ic3A7IExvZ2dpbmcgSW5mb3JtYXRpb24gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyAxMyA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDMuNi4mbmJzcDsgQ2FwYWJpbGl0eSBhbmQgU3RhdHVzIEluZm9ybWF0aW9uIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDE1IDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg My43LiZuYnNwOyBSZXBvcnRpbmcgSW5mb3JtYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4mbmJzcDsgMTcgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzLjguJm5i c3A7IFNjaGVkdWxlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiZuYnNwOyAxOCA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMuOS4mbmJzcDsgQ2hh bm5lbHMmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4mbmJzcDsgMjEgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzLjEwLiBUYXNrIENvbmZp Z3VyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgMjIg PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzLjExLiBUaW1pbmcgSW5mb3JtYXRpb24mbmJz cDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyAyMyA8YnI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMuMTEuMS4mbmJzcDsgUGVyaW9kaWMg VGltaW5nJm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDI0 IDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMy4xMS4yLiZuYnNwOyBD YWxlbmRhciBUaW1pbmcmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4m bmJzcDsgMjUgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzLjExLjMu Jm5ic3A7IE9uZS1PZmYgVGltaW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4mbmJzcDsgMjYgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzLjEx LjQuJm5ic3A7IEltbWVkaWF0ZSBUaW1pbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4mbmJzcDsgMjYgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAz LjExLjUuJm5ic3A7IFN0YXJ0dXAgVGltaW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4mbmJzcDsgMjYgPGJyPiZuYnNwOyZuYnNwOyA0LiZuYnNwOyBJQU5BIENvbnNpZGVy YXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDI2 IDxicj4mbmJzcDsmbmJzcDsgNS4mbmJzcDsgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyAyNiA8YnI+Jm5ic3A7Jm5ic3A7 IDYuJm5ic3A7IEFwcGVuZGl4OiBKU09OIEV4YW1wbGUmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyAyNyA8YnI+Jm5ic3A7Jm5ic3A7IDcuJm5ic3A7IEFj a25vd2xlZGdlbWVudHMmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiZuYnNwOyAzNSA8YnI+Jm5ic3A7Jm5ic3A7IDguJm5ic3A7IFJlZmVyZW5jZXMmbmJz cDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNw OyAzNSA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDguMS4mbmJzcDsgTm9ybWF0aXZlIFJl ZmVyZW5jZXMmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsg MzUgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA4LjIuJm5ic3A7IEluZm9ybWF0aXZlIFJl ZmVyZW5jZXMmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDM1 IDxicj4mbmJzcDsmbmJzcDsgQXV0aG9ycycgQWRkcmVzc2VzJm5ic3A7IC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyAzNSA8YnI+PGJyPjxicj48YnI+ PGJyPjxicj48YnI+PGJyPkJ1cmJyaWRnZSwgZXQgYWwuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgRmVicnVhcnkgMjEsIDIwMTUmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgW1BhZ2UgMl0gPGJyPsKgPGJyPkludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExNQVAgSW5mb3Jt YXRpb24gTW9kZWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXVndXN0IDIwMTQgPGJyPjxicj48YnI+ MS4mbmJzcDsgSW50cm9kdWN0aW9uIDxicj48YnI+Jm5ic3A7Jm5ic3A7IEEgbGFyZ2Utc2NhbGUg bWVhc3VyZW1lbnQgcGxhdGZvcm0gaXMgYSBjb2xsZWN0aW9uIG9mIGNvbXBvbmVudHMgdGhhdCA8 YnI+Jm5ic3A7Jm5ic3A7IHdvcmsgaW4gYSBjb29yZGluYXRlZCBmYXNoaW9uIHRvIHBlcmZvcm0g bWVhc3VyZW1lbnRzIGZyb20gYSBsYXJnZSA8YnI+Jm5ic3A7Jm5ic3A7IG51bWJlciBvZiB2YW50 YWdlIHBvaW50cy4mbmJzcDsgVGhlIG1haW4gY29tcG9uZW50cyBvZiBhIGxhcmdlLXNjYWxlIDxi cj4mbmJzcDsmbmJzcDsgbWVhc3VyZW1lbnQgcGxhdGZvcm0gYXJlIHRoZSBNZWFzdXJlbWVudCBB Z2VudHMgKGhlcmVhZnRlciBNQXMpLCB0aGUgPGJyPiZuYnNwOyZuYnNwOyBDb250cm9sbGVyKHMp IGFuZCB0aGUgQ29sbGVjdG9yKHMpLiA8YnI+PGJyPiZuYnNwOyZuYnNwOyBUaGUgTUFzIGFyZSB0 aGUgZWxlbWVudHMgYWN0dWFsbHkgcGVyZm9ybWluZyB0aGUgbWVhc3VyZW1lbnRzLiZuYnNwOyBU aGUgPGJyPiZuYnNwOyZuYnNwOyBNQXMgYXJlIGNvbnRyb2xsZWQgYnkgZXhhY3RseSBvbmUgQ29u dHJvbGxlciBhdCBhIHRpbWUgYW5kIHRoZSA8YnI+Jm5ic3A7Jm5ic3A7IENvbGxlY3RvcnMgZ2F0 aGVyIHRoZSByZXN1bHRzIGdlbmVyYXRlZCBieSB0aGUgTUFzLiZuYnNwOyBJbiBhIG51dHNoZWxs LCA8YnI+Jm5ic3A7Jm5ic3A7IHRoZSBub3JtYWwgb3BlcmF0aW9uIG9mIGEgbGFyZ2Utc2NhbGUg bWVhc3VyZW1lbnQgcGxhdGZvcm0gc3RhcnRzIDxicj4mbmJzcDsmbmJzcDsgd2l0aCB0aGUgQ29u dHJvbGxlciBpbnN0cnVjdGluZyBhIHNldCBvZiBvbmUgb3IgbW9yZSBNQXMgdG8gcGVyZm9ybSBh IDxicj4mbmJzcDsmbmJzcDsgc2V0IG9mIG9uZSBvciBtb3JlIE1lYXN1cmVtZW50IFRhc2tzIGF0 IGEgY2VydGFpbiBwb2ludCBpbiB0aW1lLiZuYnNwOyBUaGUgPGJyPiZuYnNwOyZuYnNwOyBNQXMg ZXhlY3V0ZSB0aGUgaW5zdHJ1Y3Rpb25zIGZyb20gYSBDb250cm9sbGVyLCBhbmQgb25jZSB0aGV5 IGhhdmUgPGJyPiZuYnNwOyZuYnNwOyBkb25lIHNvLCB0aGV5IHJlcG9ydCB0aGUgcmVzdWx0cyBv ZiB0aGUgbWVhc3VyZW1lbnRzIHRvIG9uZSBvciBtb3JlIDxicj4mbmJzcDsmbmJzcDsgQ29sbGVj dG9ycy4mbmJzcDsgVGhlIG92ZXJhbGwgZnJhbWV3b3JrIGZvciBhIExhcmdlIE1lYXN1cmVtZW50 IHBsYXRmb3JtIDxicj4mbmJzcDsmbmJzcDsgYXMgdXNlZCBpbiB0aGlzIGRvY3VtZW50IGlzIGRl c2NyaWJlZCBpbiBkZXRhaWwgaW4gPGJyPiZuYnNwOyZuYnNwOyBbSS1ELmlldGYtbG1hcC1mcmFt ZXdvcmtdLiA8YnI+PGJyPiZuYnNwOyZuYnNwOyBBIGxhcmdlLXNjYWxlIG1lYXN1cmVtZW50IHBs YXRmb3JtIGludm9sdmVzIGJhc2ljYWxseSB0aHJlZSA8YnI+Jm5ic3A7Jm5ic3A7IHByb3RvY29s cywgbmFtZWx5LCBhIENvbnRyb2wgcHJvdG9jb2wgYmV0d2VlbiBhIENvbnRyb2xsZXIgYW5kIHRo ZSA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Q29udHJvbCBQcm90b2NvbDxicj48 YnI+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOyZuYnNwOyBNQXMsIGEg UmVwb3J0IHByb3RvY29sIGJldHdlZW4gdGhlIE1BcyBhbmQgdGhlIENvbGxlY3RvcihzKSBhbmQg PGJyPiZuYnNwOyZuYnNwOyBzZXZlcmFsIG1lYXN1cmVtZW50IHByb3RvY29scyBiZXR3ZWVuIHRo ZSBNQXMgYW5kIE1lYXN1cmVtZW50IFBlZXJzIDxicj4mbmJzcDsmbmJzcDsgKE1QcyksIHVzZWQg dG8gYWN0dWFsbHkgcGVyZm9ybSB0aGUgbWVhc3VyZW1lbnRzLiZuYnNwOyBJbiBhZGRpdGlvbiBz b21lIDxicj4mbmJzcDsmbmJzcDsgaW5mb3JtYXRpb24gaXMgcmVxdWlyZWQgdG8gYmUgY29uZmln dXJlZCBvbiB0aGUgTUEgcHJpb3IgdG8gYW55IDxicj4mbmJzcDsmbmJzcDsgY29tbXVuaWNhdGlv biB3aXRoIHRoZSBpbml0aWFsIENvbnRyb2xsZXIuIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD4mcXVvdDtpbml0aWFsJnF1b3Q7IGNvbmZ1c2VkIG1lLjxicj5JdCdzIG9ubHkgbGF0 ZXIgKHNlY3Rpb24gMy4zKSB0aGF0IEkgdW5kZXJzdG9vZCB0aGF0IHRoZSBDb250cm9sbGVyIGNv dWxkIGJlIGNoYW5nZWQuPGJyPkNhbmRpZGF0ZSBmb3IgcmVtb3ZhbCwgaW1wcm92ZW1lbnQsIG9y IGZvcndhcmQgcmVmZXJlbmNlPzxicj48YnI+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxicj4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBpbmZvcm1hdGlv biBtb2RlbCBmb3IgYm90aCB0aGUgQ29udHJvbCBhbmQgPGJyPiZuYnNwOyZuYnNwOyB0aGUgUmVw b3J0IHByb3RvY29sIGFsb25nIHdpdGggcHJlLWNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gdGhh dCBpcyA8YnI+Jm5ic3A7Jm5ic3A7IHJlcXVpcmVkIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD5hZGQgJnF1b3Q7b24gdGhlIE1BJnF1b3Q7PGJyPjxicj48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+YmVmb3JlIGNvbW11bmljYXRpbmcgd2l0aCB0aGUgQ29udHJvbGxl ciwgYnJvYWRseSBuYW1lZCBhcyA8YnI+Jm5ic3A7Jm5ic3A7IHRoZSBMTUFQIEluZm9ybWF0aW9u IE1vZGVsLiZuYnNwOyBUaGUgbWVhc3VyZW1lbnQgcHJvdG9jb2xzIGFyZSBvdXQgb2YgdGhlIDxi cj4mbmJzcDsmbmJzcDsgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gPGJyPjxicj4mbmJzcDsmbmJz cDsgQXMgZGVmaW5lZCBpbiBbUkZDMzQ0NF0sIHRoZSBMTUFQIElNIGRlZmluZXMgdGhlIGNvbmNl cHRzIGludm9sdmVkIGluIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5JTSA9IElu Zm9ybWF0aW9uIE1vZGVsIDxicj50aGlzIGlzIHRoZSBmaXJzdCBvY2N1cnJlbmNlLjxicj48YnI+ PGJyPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDsgYSBsYXJn ZS1zY2FsZSBtZWFzdXJlbWVudCBwbGF0Zm9ybSBhdCBhIGhpZ2ggbGV2ZWwgb2YgYWJzdHJhY3Rp b24sIDxicj4mbmJzcDsmbmJzcDsgaW5kZXBlbmRlbnQgb2YgYW55IHNwZWNpZmljIGltcGxlbWVu dGF0aW9uIG9yIGFjdHVhbCBwcm90b2NvbCB1c2VkIHRvIDxicj4mbmJzcDsmbmJzcDsgZXhjaGFu Z2UgdGhlIGluZm9ybWF0aW9uLiZuYnNwOyBJdCBpcyBleHBlY3RlZCB0aGF0IHRoZSBwcm9wb3Nl ZCA8YnI+Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIG1vZGVsIGNhbiBiZSB1c2VkIHdpdGggZGlm ZmVyZW50IHByb3RvY29scyBpbiBkaWZmZXJlbnQgPGJyPiZuYnNwOyZuYnNwOyBtZWFzdXJlbWVu dCBwbGF0Zm9ybSBhcmNoaXRlY3R1cmVzIGFuZCBhY3Jvc3MgZGlmZmVyZW50IHR5cGVzIG9mIE1B IDxicj4mbmJzcDsmbmJzcDsgZGV2aWNlcyAoZS5nLiwgaG9tZSBnYXRld2F5LCBzbWFydHBob25l LCBQQywgcm91dGVyKS4gPGJyPjxicj4mbmJzcDsmbmJzcDsgVGhlIGRlZmluaXRpb24gb2YgYW4g SW5mb3JtYXRpb24gTW9kZWwgc2VydmVzIGEgbnVtYmVyIG9mIHB1cnBvc2VzOiA8YnI+PGJyPiZu YnNwOyZuYnNwOyAxLiZuYnNwOyBUbyBndWlkZSB0aGUgc3RhbmRhcmRpc2F0aW9uIG9mIG9uZSBv ciBtb3JlIENvbnRyb2wgYW5kIFJlcG9ydCA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHByb3RvY29sIGFuZCBkYXRhIG1vZGVsIGltcGxlbWVudGF0aW9ucyA8YnI+PGJy Pjxicj48YnI+PGJyPjxicj5CdXJicmlkZ2UsIGV0IGFsLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBFeHBpcmVzIEZlYnJ1YXJ5IDIxLCAyMDE1Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFtQYWdlIDNdIDxicj7CoDxicj5JbnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMTUFQIEluZm9y bWF0aW9uIE1vZGVsJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1Z3VzdCAyMDE0IDxicj48YnI+PGJy PiZuYnNwOyZuYnNwOyAyLiZuYnNwOyBUbyBlbmFibGUgaGlnaC1sZXZlbCBpbnRlci1vcGVyYWJp bGl0eSBiZXR3ZWVuIGRpZmZlcmVudCBDb250cm9sIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgYW5kIFJlcG9ydCBwcm90b2NvbHMgYnkgZmFjaWxpdGF0aW5nIHRyYW5z bGF0aW9uIGJldHdlZW4gdGhlaXIgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyByZXNwZWN0aXZlIGRhdGEgbW9kZWxzIHN1Y2ggdGhhdCBhIENvbnRyb2xsZXIgY291bGQg aW5zdHJ1Y3Qgc3ViLSA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBv cHVsYXRpb25zIG9mIE1BcyB1c2luZyBkaWZmZXJlbnQgcHJvdG9jb2xzIDxicj48YnI+Jm5ic3A7 Jm5ic3A7IDMuJm5ic3A7IFRvIGZvcm0gYWdyZWVtZW50IG9mIHdoYXQgaW5mb3JtYXRpb24gbmVl ZHMgdG8gYmUgaGVsZCBieSBhbiBNQSA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGFuZCBwYXNzZWQgb3ZlciB0aGUgQ29udHJvbCBhbmQgUmVwb3J0IGludGVyZmFjZXMg YW5kIHN1cHBvcnQgdGhlIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg ZnVuY3Rpb25hbGl0eSBkZXNjcmliZWQgaW4gdGhlIExNQVAgZnJhbWV3b3JrIDxicj48YnI+Jm5i c3A7Jm5ic3A7IDQuJm5ic3A7IEVuYWJsZSBleGlzdGluZyBwcm90b2NvbHMgYW5kIGRhdGEgbW9k ZWxzIHRvIGJlIGFzc2Vzc2VkIGZvciA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRoZWlyIHN1aXRhYmlsaXR5IGFzIHBhcnQgb2YgYSBsYXJnZS1zY2FsZSBtZWFzdXJl bWVudCBzeXN0ZW0gPGJyPjxicj4yLiZuYnNwOyBOb3RhdGlvbiA8YnI+PGJyPiZuYnNwOyZuYnNw OyBUaGlzIGRvY3VtZW50IHVzZSBhbiBvYmplY3Qtb3JpZW50ZWQgcHJvZ3JhbW1pbmctbGlrZSBu b3RhdGlvbiB0byA8YnI+Jm5ic3A7Jm5ic3A7IGRlZmluZSB0aGUgcGFyYW1ldGVycyAobmFtZXMv dmFsdWVzKSBvZiB0aGUgb2JqZWN0cyBvZiB0aGUgPGJyPiZuYnNwOyZuYnNwOyBpbmZvcm1hdGlv biBtb2RlbC4mbmJzcDsgQW4gb3B0aW9uYWwgZmllbGQgaXMgZW5jbG9zZWQgYnkgWyBdLCBhbmQg YW4gPGJyPiZuYnNwOyZuYnNwOyBhcnJheSBpcyBpbmRpY2F0ZWQgYnkgdHdvIG51bWJlcnMgaW4g YW5nbGUgYnJhY2tldHMsICZsdDttLi5uJmd0Oywgd2hlcmUgbSA8YnI+Jm5ic3A7Jm5ic3A7IGlu ZGljYXRlcyB0aGUgbWluaW1hbCBudW1iZXIgb2YgdmFsdWVzLCBhbmQgbiBpcyB0aGUgbWF4aW11 bS4mbmJzcDsgVGhlIDxicj4mbmJzcDsmbmJzcDsgc3ltYm9sICogZm9yIG4gbWVhbnMgbm8gdXBw ZXIgYm91bmQuIDxicj48YnI+My4mbmJzcDsgTE1BUCBJbmZvcm1hdGlvbiBNb2RlbCA8YnI+PGJy PjMuMS4mbmJzcDsgSW5mb3JtYXRpb24gU3RydWN0dXJlIDxicj48YnI+Jm5ic3A7Jm5ic3A7IFRo ZSBpbmZvcm1hdGlvbiBkZXNjcmliZWQgaGVyZWluIHJlbGF0ZXMgdG8gdGhlIGluZm9ybWF0aW9u IHN0b3JlZCwgPGJyPiZuYnNwOyZuYnNwOyByZWNlaXZlZCBvciB0cmFuc21pdHRlZCBieSBhIE1l YXN1cmVtZW50IEFnZW50IGFzIGRlc2NyaWJlZCB3aXRoaW4gPGJyPiZuYnNwOyZuYnNwOyB0aGUg TE1BUCBmcmFtZXdvcmsgW0ktRC5pZXRmLWxtYXAtZnJhbWV3b3JrXS4mbmJzcDsgPG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlNob3VsZCB0aGUgZnJhbWV3b3JrIGJlIG5vcm1hdGl2 ZT8gSSBiZWxpZXZlIHNvLCBzcGVjaWZpY2FsbHkgd2hlbiBJIHNlZSBhbGwgdGhvc2UgQ2FwaXRh bGl6ZWQgdGVybXMgdGhhdCBhcmUgb25seSBkZWZpbmVkIGluIHRoZSBmcmFtZXdvcmsuPGJyPlRo aXMgbGVhZHMgdG8gYW5vdGhlciBwb2ludC4gWW91IG1pc3MgYSB0ZXJtaW5vbG9neSBzZWN0aW9u IGJlY2F1c2Ugc29tZSB0ZXJtcyBhcmUgc3BlY2lmaWMgdG8gdGhpcyBkb2N1bWVudC4gRXhhbXBs ZTogVGFzayBTdXBwcmVzc2lvbi48YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD5BcyBzdWNoLCBzb21lIHN1YnNldHMgPGJyPiZuYnNwOyZuYnNwOyBvZiB0aGlzIGluZm9y bWF0aW9uIG1vZGVsIGFyZSBhcHBsaWNhYmxlIHRvIHRoZSBtZWFzdXJlbWVudCA8YnI+Jm5ic3A7 Jm5ic3A7IENvbnRyb2xsZXIsIENvbGxlY3RvciA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+YWRkIGEgJnF1b3Q7LCZxdW90Ozxicj5PdGhlcndpc2Ugd2UgY2FuIGJlbGlldmUgdGhh dCB0aGUgQ29sbGVjdG9yIGNvdWxkIHByZS1jb25maWd1cmUgdGhlIE1BLjxicj48YnI+PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPmFuZCBzeXN0ZW1zIHRoYXQgcHJlLWNvbmZpZ3Vy ZSB0aGUgTWVhc3VyZW1lbnQgPGJyPiZuYnNwOyZuYnNwOyBBZ2VudC4mbmJzcDsgVGhlIGluZm9y bWF0aW9uIGRlc2NyaWJlZCBpbiB0aGVzZSBtb2RlbHMgd2lsbCBiZSB0cmFuc21pdHRlZCA8YnI+ Jm5ic3A7Jm5ic3A7IGJ5IHByb3RvY29scyB1c2luZyBpbnRlcmZhY2VzIGJldHdlZW4gdGhlIE1l YXN1cmVtZW50IEFnZW50IGFuZCBzdWNoIDxicj4mbmJzcDsmbmJzcDsgc3lzdGVtcyBhY2NvcmRp bmcgdG8gYSBEYXRhIE1vZGVsLiA8YnI+PGJyPiZuYnNwOyZuYnNwOyBGb3IgY2xhcml0eSB0aGUg aW5mb3JtYXRpb24gbW9kZWwgaXMgZGl2aWRlZCBpbnRvIHNpeCBzZWN0aW9uczogPGJyPjxicj4m bmJzcDsmbmJzcDsgMS4mbmJzcDsgUHJlLUNvbmZpZ3VyYXRpb24gSW5mb3JtYXRpb24uJm5ic3A7 IEluZm9ybWF0aW9uIHByZS1jb25maWd1cmVkIG9uIHRoZSA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1lYXN1cmVtZW50IEFnZW50IHByaW9yIHRvIGFueSBjb21tdW5p Y2F0aW9uIHdpdGggb3RoZXIgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBjb21wb25lbnRzIG9mIHRoZSBMTUFQIGFyY2hpdGVjdHVyZSAoaS5lLiwgdGhlIENvbnRyb2xs ZXIsIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29sbGVjdG9yIGFu ZCBNZWFzdXJlbWVudCBQZWVycyksIHNwZWNpZmljYWxseSBkZXRhaWxpbmcgaG93IHRvIDxicj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29tbXVuaWNhdGUgd2l0aCBhIENv bnRyb2xsZXIgYW5kIHdoZXRoZXIgdGhlIGRldmljZSBpcyBlbmFibGVkIDxicj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gcGFydGljaXBhdGUgYXMgYW4gTUEuIDxicj48 YnI+Jm5ic3A7Jm5ic3A7IDIuJm5ic3A7IENvbmZpZ3VyYXRpb24gSW5mb3JtYXRpb24uJm5ic3A7 IFVwZGF0ZSBvZiB0aGUgcHJlLWNvbmZpZ3VyYXRpb24gPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBpbmZvcm1hdGlvbiBkdXJpbmcgdGhlIHJlZ2lzdHJhdGlvbiBvZiB0 aGUgTUEgb3Igc3Vic2VxdWVudCA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGNvbW11bmljYXRpb24gd2l0aCB0aGUgQ29udHJvbGxlciwgYWxvbmcgd2l0aCB0aGUgY29u ZmlndXJhdGlvbiA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9mIGZ1 cnRoZXIgcGFyYW1ldGVycyBhYm91dCB0aGUgTUEgKHJhdGhlciB0aGFuIHRoZSBUYXNrcyBpdCA8 YnI+PGJyPjxicj48YnI+PGJyPkJ1cmJyaWRnZSwgZXQgYWwuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgRmVicnVhcnkgMjEsIDIwMTUmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgW1BhZ2UgNF0gPGJyPsKgPGJyPkludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExNQVAgSW5m b3JtYXRpb24gTW9kZWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXVndXN0IDIwMTQgPGJyPjxicj48 YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNob3VsZCBwZXJmb3JtKSB0 aGF0IHdlcmUgbm90IG1hbmRhdG9yeSBmb3IgdGhlIGluaXRpYWwgPGJyPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIE1BIGFuZCBh IENvbnRyb2xsZXIuIDxicj48YnI+Jm5ic3A7Jm5ic3A7IDMuJm5ic3A7IEluc3RydWN0aW9uIElu Zm9ybWF0aW9uLiZuYnNwOyBJbmZvcm1hdGlvbiB0aGF0IGlzIHJlY2VpdmVkIGJ5IHRoZSBNQSA8 YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZyb20gdGhlIENvbnRyb2xs ZXIgcGVydGFpbmluZyB0byB0aGUgVGFza3MgdGhhdCBzaG91bGQgYmUgPGJyPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBleGVjdXRlZC4mbmJzcDsgVGhpcyBpbmNsdWRlcyB0 aGUgdGFzayBleGVjdXRpb24gU2NoZWR1bGVzIChvdGhlciB0aGFuIDxicj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIENvbnRyb2xsZXIgY29tbXVuaWNhdGlvbiBTY2hl ZHVsZSBzdXBwbGllZCBhcyA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IChwcmUpY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbikgYW5kIHJlbGF0ZWQgaW5mb3JtYXRpb24g c3VjaCBhcyA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBUYXNr IENvbmZpZ3VyYXRpb24sIGNvbW11bmljYXRpb24gQ2hhbm5lbHMgdG8gQ29sbGVjdG9ycyBhbmQg PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzY2hlZHVsZSBUaW1pbmcg aW5mb3JtYXRpb24uJm5ic3A7IEl0IGFsc28gaW5sY3VkZXMgVGFzayBTdXBwcmVzc2lvbiA8YnI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIHRoYXQgaXMg dXNlZCB0byBvdmVyLXJpZGUgbm9ybWFsIFRhc2sgZXhlY3V0aW9uIDxicj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHVyaW5nIGVtZXJnZW5jeSBzaXR1YXRpb25zLiA8YnI+ PGJyPiZuYnNwOyZuYnNwOyA0LiZuYnNwOyBMb2dnaW5nIEluZm9ybWF0aW9uLiZuYnNwOyBJbmZv cm1hdGlvbiB0cmFuc21pdHRlZCBmcm9tIHRoZSBNQSB0byB0aGUgPGJyPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDb250cm9sbGVyIGRldGFpbGluZyB0aGUgcmVzdWx0cyBv ZiBhbnkgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgYWxvbmcgd2l0aCBlcnJvciBhbmQgc3RhdHVzIGluZm9ybWF0aW9uIGZy b20gdGhlIG9wZXJhdGlvbiBvZiB0aGUgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBNQS4gPGJyPjxicj4mbmJzcDsmbmJzcDsgNS4mbmJzcDsgQ2FwYWJpbGl0eSBhbmQg U3RhdHVzIEluZm9ybWF0aW9uLiZuYnNwOyBJbmZvcm1hdGlvbiBvbiB0aGUgZ2VuZXJhbCA8YnI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0YXR1cyBhbmQgY2FwYWJpbGl0 aWVzIG9mIHRoZSBNQS4mbmJzcDsgRm9yIGV4YW1wbGUsIHRoZSBzZXQgb2YgPGJyPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtZWFzdXJlbWVudHMgdGhhdCBhcmUgc3VwcG9y dGVkIG9uIHRoZSBkZXZpY2UuIDxicj48YnI+Jm5ic3A7Jm5ic3A7IDYuJm5ic3A7IFJlcG9ydGlu ZyBJbmZvcm1hdGlvbi4mbmJzcDsgSW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgZnJvbSB0aGUgTUEg dG8gPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvbmUgb3IgbW9yZSBD b2xsZWN0b3JzIGluY2x1ZGluZyBtZWFzdXJlbWVudCByZXN1bHRzIGFuZCB0aGUgPGJyPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb250ZXh0IGluIHdoaWNoIHRoZXkgd2Vy ZSBjb25kdWN0ZWQuIDxicj48YnI+Jm5ic3A7Jm5ic3A7IEluIGFkZGl0aW9uIHRoZSBNQSBtYXkg aG9sZCBmdXJ0aGVyIGluZm9ybWF0aW9uIG5vdCBkZXNjcmliZWQgaGVyZWluLCA8YnI+Jm5ic3A7 Jm5ic3A7IGFuZCB3aGljaCBtYXkgYmUgb3B0aW9uYWxseSB0cmFuc2ZlcnJlZCB0byBvciBmcm9t IG90aGVyIHN5c3RlbXMgPGJyPiZuYnNwOyZuYnNwOyBpbmNsdWRpbmcgdGhlIENvbnRyb2xsZXIg YW5kIENvbGxlY3Rvci4mbmJzcDsgT25lIGV4YW1wbGUgb2YgaW5mb3JtYXRpb24gPGJyPiZuYnNw OyZuYnNwOyBpbiB0aGlzIGNhdGVnb3J5IGlzIHN1YnNjcmliZXIgb3IgbGluZSBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSA8YnI+Jm5ic3A7Jm5ic3A7IGV4dHJhY3RlZCBieSBhIHRhc2sgYW5kIHJl cG9ydGVkIGJ5IHRoZSBNQSBpbiB0aGUgcmVwb3J0aW5nIDxicj4mbmJzcDsmbmJzcDsgY29tbXVu aWNhdGlvbiB0byBhIENvbGxlY3Rvci4gPGJyPjxicj4mbmJzcDsmbmJzcDsgSXQgc2hvdWxkIGFs c28gYmUgbm90ZWQgdGhhdCB0aGUgTUEgbWF5IGJlIGluIGNvbW11bmljYXRpb24gd2l0aCA8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+VGhlICZxdW90O01BJnF1b3Q7IG9yIHRoZSAm cXVvdDtNQSBkZXZpY2UmcXVvdDs/PGJyPkknbSBhc2tpbmcgYmVjYXVzZSB0aGUgcmVzdCBvZiB0 aGUgc2VudGVuY2Ugc3BlYWtzIGFib3V0ICZxdW90O2NvbmZpZ3VyaW5nJnF1b3Q7LCBhbmQgd2Ug c2FpZCB0aGF0IE1BIGNhbiBvbmx5IGJlIGNvbmZpZ3VyZWQgYnkgb25lIGFuZCBvbmx5IG9uZSBD b250cm9sbGVyLjxicj48YnI+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNw OyZuYnNwOyBvdGhlciBtYW5hZ2VtZW50IHN5c3RlbXMgd2hpY2ggbWF5IGJlIHJlc3BvbnNpYmxl IGZvciBjb25maWd1cmluZyBhbmQgPGJyPiZuYnNwOyZuYnNwOyByZXRyaWV2aW5nIGluZm9ybWF0 aW9uIGZyb20gdGhlIE1BIGRldmljZS4mbmJzcDsgU3VjaCBzeXN0ZW1zLCB3aGVyZSA8YnI+Jm5i c3A7Jm5ic3A7IGF2YWlsYWJsZSwgY2FuIHBlcmZvcm0gYW4gaW1wb3J0YW50IHJvbGUgaW4gdHJh bnNmZXJyaW5nIHRoZSBwcmUtIDxicj4mbmJzcDsmbmJzcDsgY29uZmlndXJhdGlvbiBpbmZvcm1h dGlvbiB0byB0aGUgTUEgb3IgZW5hYmxpbmcvZGlzYWJsaW5nIHRoZSA8YnI+Jm5ic3A7Jm5ic3A7 IG1lYXN1cmVtZW50IGZ1bmN0aW9uYWxpdHkgb2YgdGhlIE1BLiA8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+JnF1b3Q7c3VjaCBzeXN0ZW1TJnF1b3Q7IC4uLiAmcXVvdDtlbmFibGlu Zy9kaXNhYmxpbmcgdGhlIG1lYXN1cmVtZW50IGZ1bmN0aW9uYWxpdHkgb2YgdGhlIE1BLiZxdW90 Ozxicj5UaGlzIGlzIG5vdCBwb3NzaWJsZS4gU2VlIG15IHByZXZpb3VzIHBvaW50Ljxicj48YnI+ PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj4mbmJzcDsmbmJzcDsgVGhlIElu Zm9ybWF0aW9uIE1vZGVsIGlzIGRpdmlkZWQgaW50byBzdWItc2VjdGlvbnMgZm9yIGEgbnVtYmVy IG9mIDxicj4mbmJzcDsmbmJzcDsgcmVhc29ucy4mbmJzcDsgRmlyc3RseSB0aGUgZ3JvdXBpbmcg b2YgaW5mb3JtYXRpb24gZmFjaWxpdGF0ZXMgcmVhZGVyIDxicj4mbmJzcDsmbmJzcDsgdW5kZXJz dGFuZGluZy4mbmJzcDsgU2Vjb25kbHksIHRoZSBwYXJ0aWN1bGFyIGdyb3VwaW5ncyBjaG9zZW4g YXJlIDxicj4mbmJzcDsmbmJzcDsgZXhwZWN0ZWQgdG8gbWFwIHRvIGRpZmZlcmVudCBwcm90b2Nv bHMgb3IgZGlmZmVyZW50IHRyYW5zbWlzc2lvbnMgPGJyPiZuYnNwOyZuYnNwOyB3aXRoaW4gdGhv c2UgcHJvdG9jb2xzLiA8YnI+PGJyPiZuYnNwOyZuYnNwOyBUaGUgZ3JhbnVsYXJpdHkgb2YgZGF0 YSB0cmFuc21pdHRlZCBpbiBlYWNoIG9wZXJhdGlvbiBvZiB0aGUgQ29udHJvbCA8YnI+Jm5ic3A7 Jm5ic3A7IGFuZCBSZXBvcnQgUHJvdG9jb2xzIGlzIG5vdCBkaWN0YXRlZCBieSB0aGUgSW5mb3Jt YXRpb24gTW9kZWwuJm5ic3A7IEZvciA8YnI+PGJyPjxicj48YnI+QnVyYnJpZGdlLCBldCBhbC4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXhwaXJlcyBGZWJydWFyeSAyMSwg MjAxNSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUGFnZSA1XSA8YnI+wqA8YnI+SW50ZXJu ZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgTE1BUCBJbmZvcm1hdGlvbiBNb2RlbCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBB dWd1c3QgMjAxNCA8YnI+PGJyPjxicj4mbmJzcDsmbmJzcDsgZXhhbXBsZSwgdGhlIEluc3RydWN0 aW9uIG9iamVjdCBtYXkgYmUgZGVsaXZlcmVkIGluIGEgc2luZ2xlIDxicj4mbmJzcDsmbmJzcDsg b3BlcmF0aW9uLiZuYnNwOyBBbHRlcm5hdGl2ZWx5LCBTY2hlZHVsZXMgYW5kIFRhc2sgQ29uZmln dXJhdGlvbnMgbWF5IGJlIDxicj4mbmJzcDsmbmJzcDsgc2VwYXJhdGVkIG9yIGV2ZW4gZWFjaCBT Y2hkdWxlL1Rhc2sgQ29uZmlndXJhdGlvbiBtYXkgYmUgZGVsaXZlcmVkIDxicj4mbmJzcDsmbmJz cDsgaW5kaXZpZHVhbGx5LiZuYnNwOyBTaW1pbGFybHkgdGhlIEluZm9ybWF0aW9uIE1vZGVsIGRv ZXMgbm90IGRpY3RhdGUgPGJyPiZuYnNwOyZuYnNwOyB3aGV0aGVyIGRhdGEgaXMgcmVhZCwgd3Jp dGUsIG9yIHJlYWQvd3JpdGUuJm5ic3A7IEZvciBleGFtcGxlLCBzb21lIDxicj4mbmJzcDsmbmJz cDsgQ29udHJvbCBQcm90b2NvbHMgbWF5IGhhdmUgdGhlIGFiaWxpdHkgdG8gcmVhZCBiYWNrIENv bmZpZ3VyYXRpb24gYW5kIDxicj4mbmJzcDsmbmJzcDsgSW5zdHJ1Y3Rpb24gaW5mb3JtYXRpb24g d2hpY2ggaGF2ZSBiZWVuIHByZXZpb3N1bHkgc2V0IG9uIHRoZSBNQS4gPGJyPiZuYnNwOyZuYnNw OyBMYXN0bHksIHdoaWxlIHNvbWUgcHJvdG9jb2xzIG1heSBzaW1wbHkgb3ZlcndyaXRlIGluZm9y bWF0aW9uIChmb3IgPGJyPiZuYnNwOyZuYnNwOyBleGFtcGxlIHJlZnJlc2hpbmcgdGhlIGVudGly ZSBJbnN0cnVjdGlvbiBJbmZvcm1hdGlvbiksIG90aGVyIDxicj4mbmJzcDsmbmJzcDsgcHJvdG9j b2xzIG1heSBoYXZlIHRoZSBhYmlsaXR5IHRvIHVwZGF0ZSBvciBkZWxldGUgc2VsZWN0ZWQgaXRl bXMgb2YgPGJyPiZuYnNwOyZuYnNwOyBpbmZvcm1hdGlvbi4gPGJyPjxicj4mbmJzcDsmbmJzcDsg VGhlIGluZm9ybWF0aW9uIGluIHRoZXNlIHNpeCBzZWN0aW9ucyBpcyBjYXB0dXJlZCBieSBhIG51 bWJlciBvZiA8YnI+Jm5ic3A7Jm5ic3A7IGNvbW1vbiBpbmZvcm1hdGlvbiBvYmplY3RzLiZuYnNw OyBUaGVzZSBvYmplY3RzIGFyZSBhbHNvIGRlc2NyaWJlZCBsYXRlciA8YnI+Jm5ic3A7Jm5ic3A7 IGluIHRoaXMgZG9jdW1lbnQgYW5kIGNvbXByaXNlIG9mOiA8YnI+PGJyPiZuYnNwOyZuYnNwOyAx LiZuYnNwOyBTY2hlZHVsZXMuJm5ic3A7IEEgc2V0IG9mIFNjaGVkdWxlcyB0ZWxsIHRoZSBNQSB0 byBkbyBzb21ldGhpbmcuIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg V2l0aG91dCBhIFNjaGVkdWxlIG5vIFRhc2sgKGZyb20gYSBtZWFzdXJlbWVudCB0byByZXBvcnRp bmcgb3IgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb21tdW5pY2F0 aW5nIHdpdGggdGhlIENvbnRyb2xsZXIpIGlzIGV2ZXIgZXhlY3V0ZWQuJm5ic3A7IFNjaGVkdWxl cyA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZSB1c2VkIHdpdGhp biB0aGUgSW5zdHJ1Y3Rpb24gdG8gc3BlY2lmeSB3aGF0IHRhc2tzIHNob3VsZCBiZSA8YnI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBlcmZvcm1lZCwgd2hlbiwgYW5kIGhv dyB0byBkaXJlY3QgdGhlaXIgcmVzdWx0cy4mbmJzcDsgQSBTY2hlZHVsZSBpcyA8YnI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFsc28gdXNlZCB3aXRoaW4gdGhlIHByZS1D b25maWd1cmF0aW9uIGFuZCBDb25maWd1cmF0aW9uIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gZXhlY3V0ZSB0aGUgVGFzayBv ciBUYXNrcyByZXF1aXJlZCB0byA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGNvbW11bmljYXRlIHdpdGggdGhlIENvbnRyb2xsZXIuIDxicj48YnI+Jm5ic3A7Jm5ic3A7 IDIuJm5ic3A7IENoYW5uZWxzLiZuYnNwOyBBIHNldCBvZiBDaGFubmVsIG9iamVjdHMgYXJlIHVz ZWQgdG8gY29tbXVuaWNhdGUgd2l0aCA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGEgbnVtYmVyIG9mIGVuZHBvaW50cyAoaS5lLiB0aGUgQ29udHJvbGxlciBhbmQgQ29s bGVjdG9ycykuJm5ic3A7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5PTEQ6IChp LmUuIHRoZSBDb250cm9sbGVyIGFuZCBDb2xsZWN0b3JzKS4mbmJzcDsgPGJyPk5FVzogKHRoZSBD b250cm9sbGVyLCBDb2xsZWN0b3JzLCBhbmQgTUFzKS4mbmJzcDsgPGJyPjxicj5UaGVzZSBhcmUg dGhlIG9ubHkgMyBwb3NzaWJpbGl0aWVzLCByaWdodD8gPGJyPkxvZ2dpbmcgYWx3YXlzIGdvZXMg dG8gdGhlIENvbGxlY3RvciwgcmlnaHQ/PGJyPjxicj48YnI+PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPkVhY2ggPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBDaGFubmVsIG9iamVjdCBjb250YWlucyB0aGUgaW5mb3JtYXRpb24gcmVxdWlyZWQgZm9yIHRo ZSA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbW11bmljYXRpb24g d2l0aCBhIHNpbmdsZSBlbmRwb2ludCBzdWNoIGFzIHRoZSB0YXJnZXQgbG9jYXRpb24gPGJyPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgc2VjdXJpdHkgZGV0YWlscy4m bmJzcDsgQ2hhbm5lbHMgYXJlIHJlZmVyZW5jZWQgZnJvbSB3aXRoaW4gPGJyPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTY2hlZHVsZXMgaW4gb3JkZXIgdG8gc2F5IGhvdyBU YXNrcyBzaG91bGQgY29tbXVuaWNhdGUuIDxicj48YnI+Jm5ic3A7Jm5ic3A7IDMuJm5ic3A7IFRh c2sgQ29uZmlndXJhdGlvbnMuJm5ic3A7IEEgc2V0IG9mIFRhc2sgQ29uZmlndXJhdGlvbnMgaXMg dXNlZCB0byA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZpZ3Vy ZSB0aGUgVGFza3MgdGhhdCBhcmUgcnVuIGJ5IHRoZSBNQS4mbmJzcDsgVGhpcyBpbmNsdWRlcyB0 aGUgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWdpc3RyeSBlbnRy eSBmb3IgdGhlIFRhc2sgYW5kIGFueSBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMuIDxicj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGFzayBDb25maWd1cmF0aW9ucyBhcmUg cmVmZXJlbmNlZCBmcm9tIGEgU2NoZWR1bGUgaW4gb3JkZXIgdG8gPGJyPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZ5IHdoYXQgVGFza3MgdGhlIE1BIHNob3VsZCBl eGVjdXRlLiA8YnI+PGJyPiZuYnNwOyZuYnNwOyA0LiZuYnNwOyBUaW1pbmdzLiZuYnNwOyBBIHNl dCBvZiBUaW1pbmcgb2JqZWN0cyB0aGF0IGNhbiBiZSByZWZlcmVuY2VkIGZyb20gdGhlIDxicj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2NoZWR1bGVzLiZuYnNwOyBFYWNo IFNjaGVkdWxlIGFsd2F5cyByZWZlcmVuY2VzIGV4YWN0bHkgb25lIFRpbWluZyA8YnI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9iamVjdC4mbmJzcDsgQSBUaW1pbmcgb2Jq ZWN0IHNwZWNmaWVzIGVpdGhlciBhIHNpbmdsZXRvbiBvciBzZXJpZXMgb2YgPGJyPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aW1lIGV2ZW50cy4mbmJzcDsgVGhleSBhcmUg dXNlZCB0byBpbmRpY2F0ZSB3aGVuIFRhc2tzIHNob3VsZCBiZSA8YnI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV4ZWN1dGVkLiA8YnI+PGJyPiZuYnNwOyZuYnNwOyBUaGUg Zm9sbG93aW5nIGRpYWdyYW0gaWxsdXN0cmF0ZXMgdGhlIHN0cnVjdHVyZSBpbiB3aGljaCB0aGVz ZSBjb21tb24gPGJyPiZuYnNwOyZuYnNwOyBpbmZvcm1hdGlvbiBvYmplY3RzIGFyZSByZWZlcmVu Y2VkLiZuYnNwOyBUaGUgcmVmZXJlbmNlcyBhcmUgYWNoaWV2ZWQgYnkgPGJyPiZuYnNwOyZuYnNw OyBlYWNoIG9iamVjdCAoQ2hhbm5lbCwgVGFzayBDb25maWd1cmF0aW9uLCBUaW1pbmcpIGJlaW5n IGdpdmVuIGEgc2hvcnQgPGJyPjxicj48YnI+PGJyPjxicj5CdXJicmlkZ2UsIGV0IGFsLiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFeHBpcmVzIEZlYnJ1YXJ5IDIxLCAyMDE1 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQYWdlIDZdIDxicj7CoDxicj5JbnRlcm5ldC1E cmFmdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBMTUFQIEluZm9ybWF0aW9uIE1vZGVsJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1Z3Vz dCAyMDE0IDxicj48YnI+PGJyPiZuYnNwOyZuYnNwOyB0ZXh0IG5hbWUgdGhhdCBpcyB1c2VkIGJ5 IG90aGVyIG9iamVjdHMuJm5ic3A7IFRoZSBvYmplY3RzIHNob3duIGluIDxicj4mbmJzcDsmbmJz cDsgcGFyZW50aGVzaXMgYXJlIHBhcnQgb2YgdGhlIGludGVybmFsIG9iamVjdCBzdHJ1Y3R1cmUg b2YgYSBTY2hlZHVsZS4gPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgU2NoZWR1bGUgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 LS0tLS0tLS0tLSZndDsgVGltaW5nIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfC0tLS0tLS0t LS0mZ3Q7IChTY2hlZHVsZWQgVGFza3MpIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfC0tLS0tLS0tLS0mZ3Q7IFRhc2sgQ29uZmlndXJhdGlvbiA8YnI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwtLS0tLS0tLS0tJmd0OyAoVGFzayBDaGFubmVscyBhbmQg ZG93bnN0cmVhbSBUYXNrcykgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 LS0tLS0tLS0tLSZndDsgQ2hhbm5lbHMgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8LS0tLS0tLS0tLSZndDsgRG93bnN0cmVhbSBUYXNrcyA8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+UGxlYXNlIG51bWJlciB0aGUgZmlndXJlcy48YnI+PGJyPldoeSBpcyBv bmx5ICZxdW90O2NvbmZpZ3VyYXRpb24mcXVvdDsgbWVudGlvbmVkIGluIHRoZSBmaWd1cmU/PGJy PkkgdW5kZXJzdG9vZCB0aGF0IGV2ZXJ5dGhpbmcgaXMgbm93IGEgdGFzazo8YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IGNvbnRyb2xsZXIgY29tbXVuaWNhdGlvbjxicj4mbmJzcDsmbmJzcDsmbmJzcDsg cmVwb3J0aW5nPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBtZWFzdXJlbWVudDxicj4mbmJzcDsmbmJz cDsmbmJzcDsgZGF0YSBhZ2dyZWdhdGlvbjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgLi4uPGJyPlRo aXMgd2FzIGNvbmZ1c2luZyB0byBtZS48YnI+PGJyPjxicj48YnI+PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxicj4mbmJzcDsmbmJzcDsgSXQgc2hvdWxkIGJlIGNsZWFyIHRoYXQg dGhlIHRvcC1sZXZlbCBiYWhhdmlvdXIgb2YgYW4gTUEgaXMgc2ltcGx5IHRvIDxicj4mbmJzcDsm bmJzcDsgZXhlY3V0ZSBTY2hlZHVsZXMuJm5ic3A7IEV2ZXJ5IGFjdGlvbiByZWZlcmVuY2VkIGJ5 IGEgU2NoZWR1bGUgaXMgZGVmaW5lZCA8YnI+Jm5ic3A7Jm5ic3A7IGFzIGEgVGFzay4mbmJzcDsg QXMgc3VjaCwgdGhlc2UgYWN0aW9ucyBhcmUgY29uZmlndXJlZCB0aHJvdWdoIFRhc2sgPGJyPiZu YnNwOyZuYnNwOyBDb25maWd1cmF0aW9ucyBhbmQgZXhlY3V0ZWQgYWNjb3JkaW5nIHRvIHRoZSBU aW1pbmcgcmVmZXJlbmNlZCBieSB0aGUgPGJyPiZuYnNwOyZuYnNwOyBTY2hlZHVsZSBpbiB3aGlj aCB0aGV5IGFwcGVhci4mbmJzcDsgVGFza3MgY2FuIGltcGxlbWVudCBhIHZhcmlldHkgb2YgPGJy PiZuYnNwOyZuYnNwOyBkaWZmZXJlbnQgdHlwZXMgb2YgYWN0aW9ucy4mbmJzcDsgV2hpbGUgaW4g dGVybXMgb2YgdGhlIEluZm9ybWF0aW9uIE1vZGVsLCA8YnI+Jm5ic3A7Jm5ic3A7IGFsbCBUYXNr cyBoYXZlIHRoZSBzYW1lIHN0cnVjdHVyZSwgaXQgY2FuIGhlbHAgY29uY2VwdHVhbGx5IHRvIHRo aW5rIDxicj4mbmJzcDsmbmJzcDsgb2YgZGlmZmVyZW50IFRhc2sgY2F0ZWdvcmllczogPGJyPjxi cj4mbmJzcDsmbmJzcDsgMS4mbmJzcDsgTWVhc3VyZW1lbnQgVGFza3MgPGJyPjxicj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQS4mbmJzcDsgTWVhc3VyZW1lbnQgVGFza3Mg bWVhc3VyZSBzb21lIGFzcGVjdCBvZiBuZXR3b3JrIHBlcmZvcm1hbmNlIDxicj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3IgdHJh ZmZpYyA8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCLiZuYnNw OyBEYXRhIENhcHR1cmUgVGFza3MgY2FwdHVyZSBhbmQgYW5hbHlzZSBwYXNzaXZlIGluZm9ybWF0 aW9uIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5XaHkgY2FwdHVyZT8gV2UgY2Fu IGFuYWx5c2Ugd2l0aG91dCBjYXB0dXJlLiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHN0b3JlZCBvbiB0aGUgTUEgZGV2aWNlIHN1Y2ggYXMgY291bnRlcnMgYW5kIGRldmlj ZS9uZXR3b3JrIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgc3RhdHVzIGluZm9ybWF0aW9uIDxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48YnI+V2h5IG5vdCB0cmFmZmljPzxicj5Gcm9tIHRoZSBjaGFydGVyOiA8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Qm90aCBhY3RpdmUgYW5kIHBhc3NpdmUg bWVhc3VyZW1lbnRzIGFyZSBpbiBzY29wZSwgYWx0aG91Z2ggdGhlcmUgbWF5IGJlIGRpZmZlcmVu Y2VzIGluIHRoZWlyIGFwcGxpY2FiaWxpdHkgdG8gc3BlY2lmaWMgdXNlIGNhc2VzLCBvciBpbiB0 aGUgc2VjdXJpdHkgbWVhc3VyZXMgbmVlZGVkIGFjY29yZGluZyB0byB0aGUgdGhyZWF0cyBzcGVj aWZpYyB0byBlYWNoIG1lYXN1cmVtZW50IGNhdGVnb3J5PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxicj48YnI+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj4m bmJzcDsmbmJzcDsgMi4mbmJzcDsgRGF0YSBUcmFuc2ZlciBUYXNrcyA8YnI+PGJyPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBLiZuYnNwOyBSZXBvcnRpbmcgVGFza3MgcmVw b3J0IHRoZSByZXN1bHRzIG9yIE1lYXN1cmVtZW50IFRhc2tzIHRvIDxicj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29sbGVjdG9y cyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+JnF1b3Q7UmVwb3J0aW5nIFRhc2tz IHJlcG9ydCBNZWFzdXJlbWVudCBUYXNrcyB0byBDb2xsZWN0b3JzJnF1b3Q7PGJyPlJlYWxseT8g U28gdGhlIENvbnRyb2xsZXIgY29uZmlndXJlcyB0aGUgUmVwb3J0aW5nIFRhc2tzIG9uIHRoZSBN QSwgYW5kIHRoZSBNQSByZXBvcnRzIHRoZW0gdG8gdGhlIENvbGxlY3Rvcj88YnI+PGJyPk1heWJl IHlvdSBtZWFudD88YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEEuJm5i c3A7IFJlcG9ydGluZyBUYXNrcyByZXBvcnQgdGhlIHJlc3VsdHMgPHU+b2YgPC91Pk1lYXN1cmVt ZW50IFRhc2tzIHRvIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29sbGVjdG9ycyA8YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEIuJm5ic3A7IENvbnRyb2wgVGFzayhzKSBpbXBsZW1lbnQgdGhlIENvbnRyb2wgUHJvdG9jb2wg YW5kIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgY29tbXVuaWNhdGUgd2l0aCB0aGUgQ29udHJvbGxlci4mbmJzcDsgRGVwZW5k aW5nIG9uIHRoZSBDb250cm9sIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUHJvdG9jb2wgdGhpcyBtYXkgYmUgYSBudW1iZXIg b2Ygc3BlY2lhbGlzdCB0YXNrcyBzdWNoIGFzOiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+V2hhdCBpcyAmcXVvdDt0aGlzJnF1b3Q7Pzxicj48YnI+PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBDb25maWd1cmF0aW9uIFRhc2s7IEluc3RydWN0aW9uIFRhc2s7 IFN1cHByZXNzaW9uIFRhc2s7IDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2FwYWJpbGl0aWVzIFRhc2s7IExvZ2dpbmcgVGFz ayBldGMuIDxicj48YnI+Jm5ic3A7Jm5ic3A7IDMuJm5ic3A7IERhdGEgQW5hbHlzaXMgVGFza3Mg Y2FuIGV4aXN0IHRvIGFuYWx5c2UgZGF0YSBmcm9tIG90aGVyIDxicj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgTWVhc3VyZW1lbnQgVGFza3MgbG9jYWxseSBvbiB0aGUgTUEg PGJyPjxicj4mbmJzcDsmbmJzcDsgNC4mbmJzcDsgRGF0YSBNYW5hZ2VtZW50IFRhc2tzIG1heSBl eGlzdCB0byBjbGVhbi11cCwgZmlsdGVyIG9yIGNvbXByZXNzIDxicj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZGF0YSBvbiB0aGUgTUEgc3VjaCBhcyBNZWFzdXJlbWVudCBU YXNrIHJlc3VsdHMgPGJyPjxicj48YnI+PGJyPjxicj48YnI+PGJyPkJ1cmJyaWRnZSwgZXQgYWwu Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgRmVicnVhcnkgMjEs IDIwMTUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1BhZ2UgN10gPGJyPsKgPGJyPkludGVy bmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IExNQVAgSW5mb3JtYXRpb24gTW9kZWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg QXVndXN0IDIwMTQgPGJyPjxicj48YnI+My4yLiZuYnNwOyBQcmUtQ29uZmlndXJhdGlvbiBJbmZv cm1hdGlvbiA8YnI+PGJyPiZuYnNwOyZuYnNwOyBUaGlzIGluZm9ybWF0aW9uIGlzIHRoZSBtaW5p bWFsIGluZm9ybWF0aW9uIHRoYXQgbmVlZHMgdG8gYmUgcHJlLSA8YnI+Jm5ic3A7Jm5ic3A7IGNv bmZpZ3VyZWQgdG8gdGhlIE1BIGluIG9yZGVyIGZvciBpdCB0byBzdWNjZXNzZnVsbHkgY29tbXVu aWNhdGUgd2l0aCA8YnI+Jm5ic3A7Jm5ic3A7IGEgQ29udHJvbGxlciBkdXJpbmcgdGhlIHJlZ2lz dHJhdGlvbiBwcm9jZXNzLiZuYnNwOyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ SW4gc2VjdGlvbiAzLjEsIHdlIGxlYXJuZWQ6PG86cD48L286cD48L3A+PHByZT7CoMKgIDEuwqAg UHJlLUNvbmZpZ3VyYXRpb24gSW5mb3JtYXRpb24uwqAgSW5mb3JtYXRpb24gcHJlLWNvbmZpZ3Vy ZWQgb24gdGhlPG86cD48L286cD48L3ByZT48cHJlPsKgwqDCoMKgwqDCoCBNZWFzdXJlbWVudCBB Z2VudCBwcmlvciB0byBhbnkgY29tbXVuaWNhdGlvbiB3aXRoIG90aGVyPG86cD48L286cD48L3By ZT48cHJlPsKgwqDCoMKgwqDCoCBjb21wb25lbnRzIG9mIHRoZSBMTUFQIGFyY2hpdGVjdHVyZSAo aS5lLiwgdGhlIENvbnRyb2xsZXIsPG86cD48L286cD48L3ByZT48cHJlPsKgwqDCoMKgwqDCoCBD b2xsZWN0b3IgYW5kIE1lYXN1cmVtZW50IFBlZXJzKSwgc3BlY2lmaWNhbGx5IGRldGFpbGluZyBo b3cgdG88bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoMKgwqDCoMKgIGNvbW11bmljYXRlIHdpdGgg YSBDb250cm9sbGVyIGFuZCB3aGV0aGVyIHRoZSBkZXZpY2UgaXMgZW5hYmxlZDxvOnA+PC9vOnA+ PC9wcmU+PHByZT7CoMKgwqDCoMKgwqAgdG8gcGFydGljaXBhdGUgYXMgYW4gTUEuPG86cD48L286 cD48L3ByZT48cCBjbGFzcz1Nc29Ob3JtYWw+U28gdGhlIHByZS1jb25maWd1cmF0aW9uIGluZm9y bWF0aW9uIGlzIG9ubHkgZm9yIHRoZSBDb250cm9sbGVyIGNvbW11bmljYXRpb24gKEkgZ3Vlc3Mg c28pIG9yIGFsc28gZm9yIHRoZSBjb2xsZWN0b3IgYW5kIG1lYXN1cmVtZW50IHBlZXJzPyA8YnI+ PGJyPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5UaGUgcHJlLWNvbmZpZ3VyYXRp b24gPGJyPiZuYnNwOyZuYnNwOyBpbmZvcm1hdGlvbiBpcyBhIHN1YnNldCBvZiB0aGUgQ29uZmln dXJhdGlvbiBJbmZvcm1hdGlvbiBhbG9uZyB3aXRoIDxicj4mbmJzcDsmbmJzcDsgc29tZSBwYXJh bWV0ZXJzIHRoYXQgYXJlIG5vdCB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUgTE1BUCBmcmFtZXdv cmsgPGJyPiZuYnNwOyZuYnNwOyAoc3VjaCBhcyB0aGUgdGhlIGRldmljZSBpZGVudGlmaWVyIGFu ZCBkZXZpY2Ugc2VjdXJpdHkgY3JlZGVudGlhbHMpLiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+SSBjYW4ndCBwYXJzZSAmcXVvdDtub3QgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhl IExNQVAgZnJhbWV3b3JrJnF1b3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 YnI+Jm5ic3A7Jm5ic3A7IFRoaXMgcHJlLWNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gbmVlZHMg dG8gaW5jbHVkZSBhIFVSTCBvZiB0aGUgPGJyPiZuYnNwOyZuYnNwOyBpbml0aWFsIENvbnRyb2xs ZXIgd2hlcmUgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBjYW4gYmUgcmV0cmlldmVkIDxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5PTEQ6IHJldHJpZXZlZDxicj5ORVc6IGNvbW11 bmljYXRlZDxicj5ORVcgKGFsdGVybmF0aXZlKTogcHVsbGVkIG9yIHB1c2hlZDxicj48YnI+SnVz dGlmaWNhdGlvbjogdGhlIG5leHQgcGFyYWdyYXBocyBtYWtlIHRoZSBkaXN0aW5jdGlvbi48YnI+ PGJyPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDsgYWxvbmcg d2l0aCB0aGUgc2VjdXJpdHkgaW5mb3JtYXRpb24gcmVxdWlyZWQgZm9yIHRoZSBjb21tdW5pY2F0 aW9uIDxicj4mbmJzcDsmbmJzcDsgaW5jbHVkaW5nIHRoZSBjZXJ0aWZpY2F0ZSBvZiB0aGUgQ29u dHJvbGxlciAob3IgdGhlIGNlcnRpZmljYXRlIG9mIDxicj4mbmJzcDsmbmJzcDsgdGhlIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IHdoaWNoIHdhcyB1c2VkIHRvIGlzc3VlIHRoZSBjZXJ0aWZpY2F0 ZSA8YnI+Jm5ic3A7Jm5ic3A7IGZvciB0aGUgQ29udHJvbGxlcikuJm5ic3A7IEFsbCB0aGlzIGlz IGV4cHJlc3NlZCBhcyBhIENoYW5uZWwuJm5ic3A7IFdoaWxlIDxicj4mbmJzcDsmbmJzcDsgbXVs dGlwbGUgQ2hhbm5lbHMgbWF5IGJlIHByb3ZpZGVkIGluIHRoZSBwcmUtY29uZmlndXJhdGlvbiA8 YnI+Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIHRoZXkgbXVzdCBhbGwgYmUgYXNzb2NpYXRlZCB3 aXRoIGEgc2luZ2xlIENvbnRyb2xsZXIgPGJyPiZuYnNwOyZuYnNwOyAoZS5nLiBvdmVyIGRpZmZl cmVudCBpbnRlcmZhY2VzIG9yIG5ldHdvcmsgcHJvdG9jb2xzKS4gPGJyPjxicj4mbmJzcDsmbmJz cDsgV2hlcmUgdGhlIE1BIHB1bGxzIGluZm9ybWF0aW9uIGZyb20gdGhlIENvbnRyb2xsZXIsIHRo ZSBQcmUtIDxicj4mbmJzcDsmbmJzcDsgQ29uZmlndXJhdGlvbiBJbmZvcm1hdGlvbiBhbHNvIG5l ZWRzIHRvIGNvbnRhaW4gdGhlIHRpbWluZyBvZiB0aGUgPGJyPiZuYnNwOyZuYnNwOyBjb21tdW5p Y2F0aW9uIHdpdGggdGhlIENvbnRyb2xsZXIgYXMgd2VsbCBhcyB0aGUgbmF0dXJlIG9mIHRoZSA8 YnI+Jm5ic3A7Jm5ic3A7IGNvbW11bmljYXRpb24gaXRzZWxmIChzdWNoIGFzIHRoZSBwcm90b2Nv bCBhbmQgZGF0YSB0byBiZSA8YnI+Jm5ic3A7Jm5ic3A7IHRyYW5zZmVyZWQpLiZuYnNwOyBUaGUg dGltaW5nIGlzIGdpdmVuIGFzIGEgU2NoZWR1bGUgdGhhdCBleGVjdXRlcyB0aGUgPGJyPiZuYnNw OyZuYnNwOyBUYXNrKHMpIHJlc3BvbnNpYmxlIGZvciBjb21tdW5pY2F0aW9uIHdpdGggdGhlIENv bnRyb2xsZXIuJm5ic3A7IEl0IGlzIDxicj4mbmJzcDsmbmJzcDsgdGhpcyBUYXNrIChvciBUYXNr cykgdGhhdCBpbXBsZW1lbnQgdGhlIENvbnRyb2wgcHJvdG9jb2wgYmV0d2VlbiB0aGUgPGJyPiZu YnNwOyZuYnNwOyBNQSBhbmQgdGhlIENvbnRyb2xsZXIuJm5ic3A7IFRoZSBUYXNrKHMpIG1heSB0 YWtlIGFkZGl0aW9uYWwgcGFyYW1ldGVycyBpbiA8YnI+Jm5ic3A7Jm5ic3A7IHdoaWNoIGNhc2Ug YSBUYXNrIENvbmZpZ3VyYXRpb24gY2FuIGFsc28gYmUgaW5jbHVkZWQuIDxicj48YnI+Jm5ic3A7 Jm5ic3A7IEV2ZW4gd2hlcmUgaW5mb3JtYXRpb24gaXMgcHVzaGVkIHRvIHRoZSBNQSBmcm9tIHRo ZSBDb250cm9sbGVyIDxicj4mbmJzcDsmbmJzcDsgKHJhdGhlciB0aGFuIHB1bGxlZCBieSB0aGUg TUEpLCBhIFNjaGVkdWxlIHN0aWxsIG5lZWRzIHRvIGJlIDxicj4mbmJzcDsmbmJzcDsgc3VwcGxp ZWQuJm5ic3A7IEluIHRoaXMgY2FzZSB0aGUgU2NoZWR1bGUgd2lsbCBzaW1wbHkgZXhlY3V0ZSBh IENvbnRyb2xsZXIgPGJyPiZuYnNwOyZuYnNwOyBsaXN0ZW5lciB0YXNrIHdoZW4gdGhlIE1BIGlz IHN0YXJ0ZWQuJm5ic3A7IEEgQ2hhbm5lbCBpcyBzdGlsbCByZXF1aXJlZCA8YnI+Jm5ic3A7Jm5i c3A7IGZvciB0aGUgTUEgdG8gZXN0YWJsaXNoIHNlY3VyZSBjb21tdW5pY2F0aW9uIHdpdGggdGhl IENvbnRyb2xsZXIuIDxicj48YnI+Jm5ic3A7Jm5ic3A7IEl0IGNhbiBiZSBzZWVuIHRoYXQgdGhl c2UgQ2hhbm5lbHMsIFNjaGVkdWxlcyBhbmQgVGFzayBDb25maWd1cmF0aW9ucyA8YnI+Jm5ic3A7 Jm5ic3A7IGZvciB0aGUgaW5pdGlhbCBNQS1Db250cm9sbGVyIGNvbW11bmljYXRpb24gYXJlIG5v IGRpZmZlcmVudCBpbiB0ZXJtcyA8YnI+Jm5ic3A7Jm5ic3A7IG9mIHRoZSBJbmZvcm1hdGlvbiBN b2RlbCB0byBhbnkgb3RoZXIgQ2hhbm5lbCwgU2NoZWR1bGUgb3IgVGFzayA8YnI+Jm5ic3A7Jm5i c3A7IENvbmZpZ3VyYXRpb24gdGhhdCBtaWdodCBleGVjdXRlIGEgTWVhc3VyZW1lbnQgVGFzayBv ciByZXBvcnQgdGhlIDxicj4mbmJzcDsmbmJzcDsgbWVhc3VyZW1lbnQgcmVzdWx0cyAoYXMgZGVz Y3JpYmVkIGxhdGVyKS4gPGJyPjxicj4mbmJzcDsmbmJzcDsgVGhlIE1BIG1heSBiZSBwcmUtY29u ZmlndXJlZCB3aXRoIGFuIE1BIElELCBvciBtYXkgdXNlIGEgRGV2aWNlIElEIGluIDxicj4mbmJz cDsmbmJzcDsgdGhlIGluaXRpYWwgQ29udHJvbGxlciBjb250YWN0IGJlZm9yZSBpdCBpcyBhc3Np Z25lZCBhbiBNQSBJRC4mbmJzcDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkFn YWluLCBJJ20gY29uZnVzZWQgYnkgdGhpcyBpbml0aWFsIENvbnRyb2xsZXIuJm5ic3A7Jm5ic3A7 IDxicj48YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5UaGUgPGJyPiZu YnNwOyZuYnNwOyBEZXZpY2UgSUQgbWF5IGJlIGEgTUFDIGFkZHJlc3Mgb3Igc29tZSBvdGhlciBk ZXZpY2UgaWRlbnRpZmllciA8YnI+Jm5ic3A7Jm5ic3A7IGV4cHJlc3NlZCBhcyBhIFVSTi4mbmJz cDsgSWYgdGhlIE1BIElEIGlzIG5vdCBwcm92aWRlZCBhdCB0aGlzIHN0YWdlIHRoZW4gPGJyPiZu YnNwOyZuYnNwOyBpdCBtdXN0IGJlIHByb3ZpZGVkIGJ5IHRoZSBDb250cm9sbGVyIGR1cmluZyBD b25maWd1cmF0aW9uLiA8YnI+PGJyPiZuYnNwOyZuYnNwOyBEZXRhaWwgb2YgdGhlIGluZm9ybWF0 aW9uIG1vZGVsIGVsZW1lbnRzOiA8YnI+PGJyPjxicj48YnI+QnVyYnJpZGdlLCBldCBhbC4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXhwaXJlcyBGZWJydWFyeSAyMSwgMjAx NSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUGFnZSA4XSA8YnI+wqA8YnI+SW50ZXJuZXQt RHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgTE1BUCBJbmZvcm1hdGlvbiBNb2RlbCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBdWd1 c3QgMjAxNCA8YnI+PGJyPjxicj4vLyBNQSBwcmUtY29uZmlndXJhdGlvbiBtaW5pbWFsIGluZm9y bWF0aW9uIHRvIGNvbW11bmljYXRlIGluaXRpYWxseSB3aXRoIENvbnRyb2xsZXIgPGJyPjxicj5v YmplY3QgeyA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFt1dWlkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG1hLWFnZW50LWlkO10gPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBt YS10YXNrLW9iaiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBtYS1jb250cm9sLXRhc2tzJmx0OzEuLiomZ3Q7OyA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IG1hLWNoYW5uZWwtb2JqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hLWNvbnRy b2wtY2hhbm5lbHMmbHQ7MS4uKiZndDs7IDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWEt c2NoZWR1bGUtb2JqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hLWNvbnRyb2wtc2NoZWR1bGVz Jmx0OzEuLiomZ3Q7OyA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFt1cm4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWEtZGV2aWNlLWlkO10gPGJyPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBjcmVkZW50aWFscyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBtYS1jcmVkZW50aWFsczsgPGJyPn0gbWEtY29uZmlnLW9iajsgPGJyPjxi cj4mbmJzcDsmbmJzcDsgVGhlIGRldGFpbCBvZiB0aGUgQ2hhbm5lbCBhbmQgU2NoZWR1bGUgb2Jq ZWN0cyBhcmUgZGVzY3JpYmVkIGxhdGVyIDxicj4mbmJzcDsmbmJzcDsgc2luY2UgdGhleSBhcmUg Y29tbW9uIHRvIHNldmVyYWwgcGFydHMgb2YgdGhlIGluZm9ybWF0aW9uIG1vZGVsLiA8YnI+PGJy PjMuMy4mbmJzcDsgQ29uZmlndXJhdGlvbiBJbmZvcm1hdGlvbiA8YnI+PGJyPiZuYnNwOyZuYnNw OyBEdXJpbmcgcmVnaXN0cmF0aW9uIG9yIGF0IGFueSBsYXRlciBwb2ludCBhdCB3aGljaCB0aGUg TUEgY29udGFjdHMgPGJyPiZuYnNwOyZuYnNwOyB0aGUgQ29udHJvbGxlciAob3IgdmljZS12ZXJz YSksIHRoZSBjaG9pY2Ugb2YgQ29udHJvbGxlciwgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPiZxdW90O1RoZSBjaG9pY2Ugb2YgQ29udHJvbGxlciZxdW90OywgZG8geW91IHdhbnQg dG8gc2F5ICZxdW90O2FuIGFsdGVybmF0ZSBDb250cm9sbGVyJnF1b3Q7LCBiZWNhdXNlIGF0IHRo aXMgcG9pbnQgdGhlIE1BIGlzIGFscmVhZHkgaW4gY29udGFjdCB3aXRoIHRoZSBDb250cm9sbGVy Ljxicj48YnI+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPmRldGFpbHMgZm9yIDxi cj4mbmJzcDsmbmJzcDsgdGhlIHRpbWluZyBvZiBjb21tdW5pY2F0aW9uIHdpdGggdGhlIENvbnRy b2xsZXIgb3IgcGFyYW1ldGVycyBmb3IgdGhlIDxicj4mbmJzcDsmbmJzcDsgY29tbXVuaWNhdGlv biBUYXNrKHMpIGNhbiBiZSBjaGFuZ2VkIChhcyBjYXB0dXJlZCBieSB0aGUgQ2hhbm5lbHMsIDxi cj4mbmJzcDsmbmJzcDsgU2NoZWR1bGVzIGFuZCBUYXNrIENvbmZpZ3VyYXRpb25zIG9iamVjdHMp LiZuYnNwOyBGb3IgZXhhbXBsZSB0aGUgcHJlLSA8YnI+Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyZWQg Q29udHJvbGxlciAoc3BlY2lmaWVkIGFzIGEgQ2hhbm5lbCBvciBDaGFubmVscykgbWF5IGJlIDxi cj4mbmJzcDsmbmJzcDsgcmVwbGFjZWQgd2l0aCBhIHNwZWNpZmljIENvbnRyb2xsZXIgdGhhdCBp cyBtb3JlIGFwcHJvcHJpYXRlIHRvIHRoZSA8YnI+Jm5ic3A7Jm5ic3A7IE1BIGRldmljZSB0eXBl LCBsb2NhdGlvbiBvciBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIG5ldHdvcmsgKGUuZy4gPGJyPiZu YnNwOyZuYnNwOyBhY2Nlc3MgdGVjaG5vbG9neSB0eXBlIG9yIGJyb2FkYmFuZCBwcm9kdWN0KS4m bmJzcDsgVGhlIGluaXRpYWwgPGJyPiZuYnNwOyZuYnNwOyBjb21tdW5pY2F0aW9uIFNjaGVkdWxl IG1heSBiZSByZXBsYWNlZCB3aXRoIG9uZSBtb3JlIHJlbGV2YW50IHRvIDxicj4mbmJzcDsmbmJz cDsgcm91dGluZSBjb21tdW5pY2F0aW9ucyBiZXR3ZWVuIHRoZSBNQSBhbmQgdGhlIENvbnRyb2xs ZXIuIDxicj48YnI+Jm5ic3A7Jm5ic3A7IFdoaWxlIHNvbWUgQ29udHJvbCBwcm90b2NvbHMgYW5k IHVzZXMgbWF5IG9ubHkgdXNlIGEgc2luZ2xlIFNjaGVkdWxlLCA8YnI+Jm5ic3A7Jm5ic3A7IG90 aGVyIHByb3RvY29scyBhbmQgdXNlcyBtYXkgdXNlcyBzZXZlcmFsIFNjaGVkdWxlcyAoYW5kIHJl bGF0ZWQgZGF0YSA8YnI+Jm5ic3A7Jm5ic3A7IHRyYW5zZmVyIFRhc2tzKSB0byB1cGRhdGUgdGhl IENvbmZpZ3VyYXRpb24gSW5mb3JtYXRpb24sIHRyYW5zZmVyIHRoZSA8YnI+Jm5ic3A7Jm5ic3A7 IEluc3RydWN0aW9uIEluZm9ybWF0aW9uLCB0cmFuc2ZlciBDYXBhYmlsaXR5IGFuZCBTdGF0dXMg SW5mb3JtYXRpb24gPGJyPiZuYnNwOyZuYnNwOyBhbmQgc2VuZCBvdGhlciBpbmZvcm1hdGlvbiB0 byB0aGUgQ29udHJvbGxlciBzdWNoIGFzIGxvZyBvciBlcnJvciA8YnI+Jm5ic3A7Jm5ic3A7IG5v dGlmaWNhdGlvbnMuJm5ic3A7IE11bHRpcGxlIENoYW5uZWxzIG1heSBiZSB1c2VkIHRvIGNvbW11 bmljYXRlIHdpdGggdGhlIDxicj4mbmJzcDsmbmJzcDsgc2FtZSBDb250cm9sbGVyIG92ZXIgbXVs dGlwbGUgaW50ZXJmYWNlcyAoZS5nLiB0byBzZW5kIGxvZ2dpbmcgPGJyPiZuYnNwOyZuYnNwOyBp bmZvcm1hdGlvbiBvdmVyIGEgZGlmZmVyZW50IG5ldHdvcmspLiA8YnI+PGJyPiZuYnNwOyZuYnNw OyBJbiBhZGRpdGlvbiB0aGUgTUEgd2lsbCBiZSBnaXZlbiBmdXJ0aGVyIGl0ZW1zIG9mIGluZm9y bWF0aW9uIHRoYXQgPGJyPiZuYnNwOyZuYnNwOyByZWxhdGUgc3BlY2lmaWNhbGx5IHRvIHRoZSBN QSByYXRoZXIgdGhhbiB0aGUgbWVhc3VyZW1lbnRzIGl0IGlzIHRvIDxicj4mbmJzcDsmbmJzcDsg Y29uZHVjdCBvciBob3cgdG8gcmVwb3J0IHJlc3VsdHMuJm5ic3A7IFRoZSBhc3NpZ25tZW50IG9m IGFuIElEIHRvIHRoZSBNQSA8YnI+Jm5ic3A7Jm5ic3A7IGlzIG1hbmRhdG9yeS4mbmJzcDsgSWYg dGhlIE1BIEFnZW50IElEIHdhcyBub3Qgb3B0aW9uYWxseSBwcm92aWRlZCBkdXJpbmcgPGJyPiZu YnNwOyZuYnNwOyB0aGUgcHJlLWNvbmZpZ3VyYXRpb24gdGhlbiBvbmUgbXVzdCBiZSBwcm92aWRl ZCBieSB0aGUgQ29udHJvbGxlciA8YnI+Jm5ic3A7Jm5ic3A7IGR1cmluZyBDb25maWd1cmF0aW9u LiZuYnNwOyBPcHRpb25hbGx5IGEgR3JvdXAgSUQgbWF5IGFsc28gYmUgZ2l2ZW4gd2hpY2ggPGJy PiZuYnNwOyZuYnNwOyBpZGVudGlmaWVzIGEgZ3JvdXAgb2YgaW50ZXJlc3QgdG8gd2hpY2ggdGhh dCBNQSBiZWxvbmdzLiZuYnNwOyBGb3IgZXhhbXBsZSA8YnI+Jm5ic3A7Jm5ic3A7IHRoZSBncm91 cCBjb3VsZCByZXByZXNlbnQgYW4gSVNQLCBicm9hZGJhbmQgcHJvZHVjdCwgdGVjaG5vbG9neSwg PGJyPiZuYnNwOyZuYnNwOyBtYXJrZXQgY2xhc3NpZmljYXRpb24sIGdlb2dyYXBoaWMgcmVnaW9u LCBvciBhIGNvbWJpbmF0aW9uIG9mIDxicj4mbmJzcDsmbmJzcDsgbXVsdGlwbGUgc3VjaCBjaGFy YWN0ZXJpc3RpY3MuJm5ic3A7IFdoZXJlIHRoZSBNZWFzdXJlbWVudCBHcm91cCBJRCBpcyBzZXQg PGJyPiZuYnNwOyZuYnNwOyBhbiBhZGRpdGlvbmFsIGZsYWcgKHRoZSBSZXBvcnQgTUEgSUQgZmxh ZykgaXMgcmVxdWlyZWQgdG8gY29udHJvbCA8YnI+PGJyPjxicj48YnI+QnVyYnJpZGdlLCBldCBh bC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXhwaXJlcyBGZWJydWFyeSAy MSwgMjAxNSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUGFnZSA5XSA8YnI+wqA8YnI+SW50 ZXJuZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgTE1BUCBJbmZvcm1hdGlvbiBNb2RlbCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBBdWd1c3QgMjAxNCA8YnI+PGJyPjxicj4mbmJzcDsmbmJzcDsgd2hldGhlciB0aGUgTWVhc3Vy ZW1lbnQgQWdlbnQgSUQgaXMgYWxzbyB0byBiZSByZXBvcnRlZC4mbmJzcDsgVGhlIDxicj4mbmJz cDsmbmJzcDsgcmVwb3J0aW5nIG9mIGEgR3JvdXAgSUQgd2l0aG91dCB0aGUgTUEgSUQgYWxsb3dz IHRoZSBNQSB0byByZW1haW4gPGJyPiZuYnNwOyZuYnNwOyBhbm9ueW1vdXMsIHdoaWNoIG1heSBi ZSBwYXJ0aWN1bGFybHkgdXNlZnVsIHRvIHByZXZlbnQgdHJhY2tpbmcgb2YgPGJyPiZuYnNwOyZu YnNwOyBtb2JpbGUgTUEgZGV2aWNlcy4gPGJyPjxicj4mbmJzcDsmbmJzcDsgT3B0aW9uYWxseSBh biBNQSBjYW4gYWxzbyBiZSBjb25maWd1cmVkIHRvIHN0b3AgZXhlY3V0aW5nIGFueSA8YnI+Jm5i c3A7Jm5ic3A7IEluc3RydWN0aW9uIFNjaGVkdWxlIGlmIHRoZSBDb250cm9sbGVyIGlzIHVucmVh Y2hhYmxlLiZuYnNwOyBUaGlzIGNhbiBiZSA8YnI+Jm5ic3A7Jm5ic3A7IHVzZWQgYXMgYSBmYWls LXNhZmUgdG8gc3RvcCBNZWFzdXJlbWVudCBhbmQgb3RoZXIgVGFza3MgYmVpbmcgPGJyPiZuYnNw OyZuYnNwOyBjb25kdWN0ZWQgd2hlbiB0aGVyZSBpcyBkb3VidCB0aGF0IHRoZSBJbnN0cnVjdGlv biBJbmZvcm1hdGlvbiBpcyA8YnI+Jm5ic3A7Jm5ic3A7IHN0aWxsIHZhbGlkLiZuYnNwOyBUaGlz IGlzIHNpbXBseSByZXByZXNlbnRlZCBhcyBhIHRpbWUgd2luZG93IGluIDxicj4mbmJzcDsmbmJz cDsgbWlsbGlzZWNvbmRzIHNpbmNlIHRoZSBsYXN0IGNvbW11bmljYXRpb24gd2l0aCB0aGUgQ29u dHJvbGxlciBhZnRlciA8YnI+Jm5ic3A7Jm5ic3A7IHdoaWNoIEluc3RydWN0aW9uIFNjaGVkdWxl cyBhcmUgdG8gYmUgc3VzcGVuZGVkLiZuYnNwOyBUaGUgYXBwcm9wcmlhdGUgPGJyPiZuYnNwOyZu YnNwOyB2YXVlIG9mIHRoZSB0aW1lIHdpbmRvdyB3aWxsIGRlcGVuZCBvbiB0aGUgc3BlY2lmaWVk IGNvbW11bmljYXRpb24gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPnZhbHVlPGJy Pjxicj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7IFNjaGVk dWxlIHdpdGggdGhlIENvbnRyb2xsZXIgYW5kIHRoZSBkdXJhdGlvbiBmb3Igd2hpY2ggdGhlIHN5 c3RlbSBpcyA8YnI+Jm5ic3A7Jm5ic3A7IHdpbGxpbmcgdG8gdG9sZXJhdGUgY29udGludWVkIG9w ZXJhdGlvbiB3aXRoIHBvdGVudGlhbGx5IHN0YWxlIDxicj4mbmJzcDsmbmJzcDsgSW5zdHJ1Y3Rp b24gSW5mb3JtYXRpb24uIDxicj48YnI+Jm5ic3A7Jm5ic3A7IFdoaWxlIHByZS1jb25maWd1cmF0 aW9uIGlzIHBlcnNpc3RlbnQgdXBvbiBkZXZpY2UgcmVzZXQgb3IgcG93ZXIgPGJyPiZuYnNwOyZu YnNwOyBjeWNsZSBkdWUgdG8gaXRzIHZlcnkgbmF0dXJlLCB0aGUgcGVyc2lzdGVuY3kgb2YgdGhl IGFkZHRpb25hbCA8YnI+Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gbWF5 IGJlIGNvbnRyb2wgcHJvdG9jb2wgZGVwZW5kZW50LiZuYnNwOyA8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+V2h5ICZxdW90O0NvbnRyb2wgUHJvdG9jb2wmcXVvdDsgZGVwZW5kZW50 PyA8YnI+V2h5IGlzbid0IHRoZSBwZXJzaXN0ZW5jZSBJTSAob3IgRE0pIHNwZWNpZmljPzxicj48 YnI+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdCc+U29tZSA8YnI+Jm5ic3A7Jm5ic3A7IHByb3RvY29scyBtYXkgYXNzdW1lIHRoYXQg cmVzZXQgZGV2aWNlcyB3aWxsIHJldmVydCBiYWNrIHRvIHRoZWlyIDxicj4mbmJzcDsmbmJzcDsg cHJlLWNvbmZpZ3VyYXRpb24gc3RhdGUsIHdoaWxlIG90aGVyIHByb3RvY29scyBtYXkgYXNzdW1l IHRoYXQgYWxsIDxicj4mbmJzcDsmbmJzcDsgY29uZmlndXJhdGlvbiBhbmQgaW5zdHJ1Y3Rpb24g aW5mb3JtYXRpb24gaXMgaGVsZCBpbiBwZXJzaXN0ZW50IDxicj4mbmJzcDsmbmJzcDsgc3RvcmFn ZS4gPGJyPjxicj4mbmJzcDsmbmJzcDsgSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgY29udHJvbCBz aGVkdWxlcyBhbmQgdGFza3MgY2Fubm90IGJlIDxicj4mbmJzcDsmbmJzcDsgc3VwcHJlc3NlZCBh cyBldmlkZW5jZWQgYnkgdGhlIGxhY2sgb2Ygc3VwcHJlc3Npb24gaW5mb3JtYXRpb24gaW4gdGhl IDxicj4mbmJzcDsmbmJzcDsgQ29uZmlndXJhdGlvbi4mbmJzcDsgVGhlIGNvbnRyb2wgc2NoZWR1 bGUgbXVzdCBvbmx5IHJlZmVyZW5jZSB0YXNrcyBsaXN0ZWQgPGJyPiZuYnNwOyZuYnNwOyBhcyBj b250cm9sIHRhc2tzLiZuYnNwOyBBbnkgc3VwcHJlc3MtYnktZGVmYXVsdCBmbGFnIGFnYWluc3Qg Y29udHJvbCB0YXNrcyA8YnI+Jm5ic3A7Jm5ic3A7IHdpbGwgYmUgaWdub3JlZC4gPGJyPjxicj4m bmJzcDsmbmJzcDsgRGV0YWlsIG9mIHRoZSBhZGRpdGlvbmFsIGFuZCB1cGRhdGVkIGluZm9ybWF0 aW9uIG1vZGVsIGVsZW1lbnRzOiA8YnI+PGJyPiZuYnNwOyZuYnNwOyAvLyBNQSBDb25maWd1cmF0 aW9uIDxicj48YnI+Jm5ic3A7Jm5ic3A7IG9iamVjdCB7IDxicj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgdXVpZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBt YS1hZ2VudC1pZDsgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbbWEtdGFzay1v YmombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWEtY29u dHJvbC10YXNrcyZsdDswLi4qJmd0OztdIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgbWEtY2hhbm5lbC1vYmombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWEt Y29udHJvbC1jaGFubmVscyZsdDsxLi4qJmd0OzsgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBbbWEtc2NoZWR1bGUtb2JqJm5ic3A7Jm5ic3A7Jm5ic3A7IG1hLWNvbnRyb2wtc2No ZWR1bGVzJmx0OzAuLiomZ3Q7XTsgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBb dXJuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hLWRldmljZS1pZDtd IDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY3JlZGVudGlhbHMmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWEtY3JlZGVudGlh bHM7IDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW3N0cmluZyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBtYS1ncm91cC1pZDtdIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgW2Jvb2xlYW4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWEtcmVwb3J0LW1hLWlkLWZsYWc7XSA8YnI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtpbnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgbWEtY29udHJvbC1jaGFubmVsLWZhaWx1cmUtdGhyZXNob2xkO10gPGJy PiZuYnNwOyZuYnNwOyB9IG1hLWNvbmZpZy1vYmo7IDxicj48YnI+PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+VGhhdCdzIHdoZXJl IEkgYXJyaXZlZC48YnI+PGJyPkFuZCBub3csIHRpbWUgZm9yIGEgR3Vpbm5lc3Mgb3IgdHdvLiBJ J20gaW4gRHVibGluIGFmdGVyIGFsbCA6LSk8YnI+PGJyPlJlZ2FyZHMsIEJlbm9pdCA8bzpwPjwv bzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIu MHB0Jz48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+bG1hcCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOmxtYXBAaWV0Zi5vcmciPmxt YXBAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbG1hcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbG1hcDwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D4135F72CA7EMV67UKRDdoma_-- From nobody Mon Sep 22 05:21: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 A82411A1AB6 for ; Mon, 22 Sep 2014 05:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.605 X-Spam-Level: X-Spam-Status: No, score=-11.605 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 3VMj2vtxsart for ; Mon, 22 Sep 2014 05:21:21 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935281A1AB3 for ; Mon, 22 Sep 2014 05:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=88065; q=dns/txt; s=iport; t=1411388480; x=1412598080; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=pvHwujQN4NfQZeAVwSMnRzXbd3w58f9gYIBVBe1MZqw=; b=O8UggFfRFba0S2RGFk0XZz6GM9sGXk6riIwVkdV1/Bcees4bbIfuhLCW PxuCcsV7QqBoNOfl4CsErivJPusrUYi1qFmWoYJVkmE9bISsLEXlP5Fee lDigCRcq1LpW14xmgeIdUEn2KNAK3W63hUqbIF4JbV3pfqDYj99InqaoZ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8GAIUTIFStJssW/2dsb2JhbABWBAaCSIEZV8V2hFQBC4dLAYEhAXmEAwEBAQQBAQEXAVMEAgQRCxEEAQEKFgEBBgcJAwIBAgEVHwgBCAcMBAICAQGIOg3EDwEXjyoZORABhEsFhiAziG2GT4cHgWGFa44Gg2M7BCsBgkkBAQE X-IronPort-AV: E=Sophos;i="5.04,571,1406592000"; d="scan'208,217";a="185391837" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 22 Sep 2014 12:21:15 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8MCLEEe017872; Mon, 22 Sep 2014 12:21:14 GMT Message-ID: <5420143A.7090805@cisco.com> Date: Mon, 22 Sep 2014 14:21:14 +0200 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: philip.eardley@bt.com, lmap@ietf.org References: <53C8247C.2000509@cisco.com> <53D11873.4080603@cisco.com>, <5415C263.9080107@cisco.com> In-Reply-To: <5415C263.9080107@cisco.com> Content-Type: multipart/alternative; boundary="------------080901070403060008080704" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/FXkwlGHQApJRhHk0-CTCbmmqFWs Subject: Re: [lmap] FW: AD review of draft-ietf-lmap-use-cases-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: Mon, 22 Sep 2014 12:21:29 -0000 This is a multi-part message in MIME format. --------------080901070403060008080704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Phil, As soon as you post a new version, I'll send this draft to IETF LC. Regards, Benoit > Hi Phil, > > I'm happy with the way you addressed my feedback. > Just one point needs correction: the last one. > > Pervasive Monitoring, RFC 7528. This RFC should at least be > referenced, for example around this sentence: > > The other approach is passive measurements > > on the customer's ordinary traffic; the advantage is that it measures > > what the customer actually does, but it creates extra variability > > (different traffic mixes give different results) and especially it > > raises privacy concerns. > > It's actually my fault. Wrong reference! it should be RFC 7258 > > Regards, Benoit >> cfi - in case there needs to be any discussion during Monday's >> interim, here are the proposed resolutions to Benoit's comments. >> best wishes, >> phil >> ------------------------------------------------------------------------ >> *From:* philip.eardley@bt.com [philip.eardley@bt.com] >> *Sent:* 03 September 2014 14:20 >> *To:* bclaise@cisco.com; draft-ietf-lmap-use-cases@tools.ietf.org >> *Subject:* RE: [lmap] AD review of draft-ietf-lmap-use-cases-03 >> >> Benoit, >> >> Thank-you very much for your review. Sorry for the slow response - >> crossed wires amongst the authors >> >> I've proposed resolutions to all your comments below -- except for >> one that I don't understand >> >> <<- Section 3.1 >> >> Operators want to understand the quality of experience (QoE) of their >> broadband customers. >> >> There is a QoE reference in RFC 5481 >> >> >> >> >> [phil] This was clarified:- >> >> The QoE reference is >> actuallyhttps://tools.ietf.org/html/rfc6390#section-2.4 >> >> [to try and close the issues more rapidly, am emailing the use cases >> authors rather than lmap list.] >> >> Thanks! >> >> phil >> >> *From:*lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of *Benoit Claise >> *Sent:* 24 July 2014 15:30 >> *To:* lmap@ietf.org >> *Subject:* [lmap] AD review of draft-ietf-lmap-use-cases-03 >> >> Dear all, >> >> Here is my AD review >> >> - OLD >> >> 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 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. >> >> NEW: >> >> 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. >> >> Yes -- agree. >> >> - Section 2.1 >> >> An ISP, or indeed another network operator, needs to understand the >> performance of their networks, the performance of the suppliers >> (downstream and upstream networks), the performance of services, and >> the impact that such performance has on the experience of their >> customers. >> >> "indeed _another _network operator"? >> >> NEW: >> >> A network operator needsto understand the >> performance of their networks, the performance of the suppliers >> (downstream and upstream networks), the performance of services, and >> the impact that such performance has on the experience of their >> customers. >> >> >> - Section 2.1 >> >> Identifying, isolating and fixing problems in the network, >> services or with CPE and end user equipment. >> >> I can't parse the sentence >> >> NEW >> Identifying, isolating and fixingproblems, which may be in the network, >> with the service provider, or in theend user equipment. >> >> >> >> - Section 2.1 >> >> This sentence speaks about "services" >> >> o Identifying, isolating and fixing problems in the network, >> services or with CPE and end user equipment. >> >> Section 3.2 speaks about new services. >> So, this paragraph also includes "services": >> >> o Understanding the impact and operation of new devices and >> technology. As a new product is deployed, or a new technology >> introduced into the network, it is essential that its operation >> and impact on other services is measured. This also helps to >> quantify the advantage that the new technology is bringing and >> support the business case for larger roll-out. >> >> >> NEW: >> >> o Understanding the impact and operation of new devices, >> technology,_or services._ As a new product is deployed, or a new technology >> introduced into the network, it is essential that its operation >> and impact on other services is measured. This also helps to >> quantify the advantage that the new technology is bringing and >> support the business case for larger roll-out. >> >> I think 'services' here & in S3.2 is mainly being used in the sense >> of 'network services', which is confusing. >> >> NEW >> >> o Understanding the impact and operation of new devices and >> technology. As a new product is deployed, or a new technology >> introduced into the network, it is essential that its operation >> andits impact ismeasured. This also helps to >> quantify the advantage that the new technology is bringing and >> support the business case for larger roll-out. >> >> and in S3.2, first sentence >> >> OLD >> >> Another type of measurement is to test new capabilities and services >> >> before they are rolled out. >> >> NEW >> >> Another type of measurement is to test new capabilities >> >> before they are rolled out. >> >> >> - I'm confused by: >> >> 2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . .3 >> 2.1 Internet Service Provider (ISP) Use Case . . . . . . . . . .3 >> 2.2 Regulators . . . . . . . . . . . . . . . . . . . . . . . . .4 >> 2.3 Implementation options . . . . . . . . . . . . . . . . . . .5 >> >> What is the link between the "Implementation options" subsection and >> use cases? >> Should "implementation options" have its own section? >> >> I agree. Think it fits best as a section near the end. >> >> NEW >> >> 5 >> Implementation options . . . . . . . . . . . . . . . . . . . 12 >> >> >> 6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . >> 12 >> >> >> >> - >> >> Another approach involves implementing the measurement capability as >> a webpage or an "app" that end users are encouraged to download onto >> their mobile phone or computing device. Measurements are triggered by >> the end user, for example the user interface may have a button to >> "test my broadband now". Compared with the previous approach, the >> system is much more loosely controlled, as the panel of end users and >> the schedule of tests are determined by the end users themselves >> rather than the measurement system. It would be easier to get large- >> scale, however it is harder to get comparable benchmarks as the >> measurements are affected by the home network and also the population >> is self-selecting and so potentially biased towards those who think >> they have a problem. This could be alleviated by stimulating >> widespread downloading of the app and careful post-processing of the >> results to reduce biases. >> >> This end-user triggered measurement provides a huge advantage: it >> reflects the end-user QoE, as opposed to the broadband device QoE >> (*). In combination with LMAP measurements in the broadband device, >> the end-user triggered measurement might prove that the home network >> is the source of performance degradations. >> You might want to add those points either in section "Implementation >> options" or around the section 3.1 3rd paragraph. >> This point is partly covered in last paragraph of section 3.5 >> >> (*) except if the end-user triggered measurement is executed directly >> on the broadband device ... For example, downloading a page, or >> initiating a test from the web server on the broadband device, as you >> mentioned: >> >> There are several other possibilities. For example, as a variant on >> the first approach, the measurement capability could be implemented >> as software embedded in the home gateway, which would make it more >> viable to have the capability on every user line. As a variant on the >> second approach, the end user could initiate measurements in response >> to a request from the measurement system. >> >> NEW >> >> Another approach involves implementing the measurement capability as >> a webpage or an "app" that end users are encouraged to download onto >> their mobile phone or computing device. Measurements are triggered by >> the end user, for example the user interface may have a button to >> "test my broadband now".One advantage of this approach is that the performance is measured to the end user, rather than to the home gateway, and so includes the home network. Another difference is thatthe >> system is much more loosely controlled, as the panel of end users and >> the schedule of tests are determined by the end users themselves >> rather than the measurement system. It would be easier to get large- >> scale, however it is harder to get comparable benchmarks as the >> measurements are affected by the home network and also the population >> is self-selecting and so potentially biased towards those who think >> they have a problem. This could be alleviated by stimulating >> widespread downloading of the app and careful post-processing of the >> results to reduce biases. >> >> >> >> - In connection with the previous point, I was confused while >> reading the document. >> I don't see"end-user triggered measurement" in section 2.X next to >> the ISP and operators use case. fine, but it's still discussed >> throughout the draft. For example >> >> Measurements are triggered by >> the end user, for example the user interface may have a button to >> "test my broadband now". >> >> OR >> As a variant on the >> second approach, the end user could initiate measurements in response >> to a request from the measurement system. >> >> OR >> >> The operator really wants to understand the end-to-end service >> experience. However, the home network (Ethernet, WiFi, powerline) is >> highly variable and outside its control. To date, operators (and >> regulators) have instead measured performance from the home gateway. >> However, mobile operators clearly must include the wireless link in >> the measurement. >> >> OR >> >> The operator would like the >> end-to-end view of the service, rather than (say) just the access >> portion >> >> >> So, I've been wondering whether this end-user triggered measurement >> was in scope or not. >> I only found my answer in the conclusion section >> >> There are >> other use cases that are not the focus of the initial LMAP charter >> (although it is expected that the mechanisms developed would be >> readily applied), for example end users would like to use >> measurements to help identify problems in their home network and to >> monitor the performance of their broadband provider. >> >> You should make it very clear, upfront, that the end-user triggered >> measurement is not in scope. >> Something like section 5.6.1 End-user-controlled measurement system >> in the framework document >> >> Suggest changing S1 Introduction >> >> OLD >> >> This document describes two use cases for the Large-scale Measurement >> >> of Broadband Performance (LMAP), in particular use cases for ISPs and >> >> regulators. Although there are many other use cases for large-scale >> >> measurements systems, the two described here are the consensus >> >> starting point for defining the system. >> >> NEW >> >> This document describes two use cases for the Large-scale Measurement >> >> of Broadband Performance (LMAP). Firstly, to enable network operators to understand the performance of the network and the quality experienced by customers. Secondly, to enable regulators to provide information on the performance of the ISPs in their jurisdiction. There are other use cases that are not the focus of the initial LMAP work, for example end users would like to use measurements to help identify problems in their home network and to monitor the performance of their broadband provider; it is expected that the same mechanisms are applicable. >> >> >> - Section 3.1 >> >> Operators want to understand the quality of experience (QoE) of their >> broadband customers. >> >> There is a QoE reference in RFC 5481 >> >> I don't understand this comment, sorry. I couldn't find "QoE" in RFC5481 >> >> >> >> - Section 3.5 >> >> One example was described in [IETF85-Plenary]. The operator was >> running a measurement panel for reasons discussed in sub use case #1. >> >> Should we all review [IETF85-Plenary] to understand what sub use case >> # 1 is? ;-) >> >> This meant sub use case #1 in draft-lmap-use-cases. However, I think >> the current text can be improved. >> >> OLD >> >> One example was described in [IETF85-Plenary >> ]. >> The operator was >> >> running a measurement panel for reasons discussed in sub use case #1. >> >> It was noticed that the performance of some lines had unexpectedly >> >> degraded. This led to a detailed (off-line) investigation which >> >> discovered that a particular home gateway upgrade had caused a >> >> (mistaken!) drop in line rate. >> >> Another example is that occasionally some internal network management >> >> event (like re-routing) can be customer-affecting (of course this is >> >> unusual). This affects a whole group of customers, for instance those >> >> on the same DSLAM. Understanding this will help an operator fix the >> >> fault more rapidly and/or allow the affected customers to be informed >> >> what's happening and/or request them to re-set their home hub >> >> (required to cure some conditions). More accurate information enables >> >> the operator to reassure customers and take more rapid and effective >> >> action to cure the problem. >> >> There may also be problems unique to a single user line (e.g. copper >> >> access) that need to be identified. >> >> NEW >> >> An operator can obtain useful information without measuring the >> performance on every broadband line. By measuring a subset, the >> operator identify problems that affect a group of customers. For >> example, the issue could be at a shared point in the network topology >> (such as an exchange) or common to a vendor or equipment type >> ([IETF85-Plenary] describes a case where a particular home gateway >> upgrade had caused a (mistaken!) drop in line rate). A more extensive >> deployment of the measurement capability to every broadband line >> would enable an operator to identify issues unique to a single >> customer. Overall, large-scale measurements can help an operator help >> an operator fix the fault more rapidly and/or allow the affected >> customers to be informed what's happening. More accurate information >> enables the operator to reassure customers and take more rapid and >> effective action to cure the problem. >> >> >> - Section 4.1 >> >> The published information needs to be: >> >> o Accurate - the measurement results must be correct and not >> influenced by errors or side effects. The results should be >> reproducible and consistent over time. >> >> o Comparable - common metrics should be used across different >> ISPs and service offerings so that measurement results can be >> compared. >> >> o Meaningful - the metrics used for measurements need to reflect >> what end users value about their broadband Internet access service >> >> o Reliable - the number and distribution of measurement agents, >> and the statistical processing of the raw measurement raw data, >> needs to be appropriate >> >> >> Not sure if this was discussed, but one goal behind the regulator use >> case is to strongly suggest the ISPs to use the same metrics in their >> SLC (Service Level Contracts). >> If you ever tried to compare SLC between ISPs, well, go luck. >> This would be a nice additional 4.x section >> >> Rather than a new section, I suggest an additional sentence in the >> 2^nd para of S4.1: >> >> NEW >> >> End users need effective transparency to be able to make informed >> >> choices throughout the different stages of their relationship with >> >> ISPs, when selecting Internet access service offers, and when >> >> considering switching service offer within an ISP or to an >> >> alternative ISP. Quality information about service offers could >> >> include speed, delay, and jitter. Regulators can publish such >> >> information to facilitate end users' choice of service provider and >> >> offer. It may also encourage ISPs to use the same metrics in their >> service level contracts, which would further help end users to choose >> an ISP. Finally, transparency may help content, application, service >> and device >> >> providers develop their Internet offerings. >> >> >> >> - Pervasive Monitoring, RFC 7528. This RFC should at least be >> referenced, for example around this sentence: >> >> The other approach is passive measurements >> on the customer's ordinary traffic; the advantage is that it measures >> what the customer actually does, but it creates extra variability >> (different traffic mixes give different results) and especially it >> raises privacy concerns. >> >> >> Do you mean RFC6973? (Privacy Considerations for Internet Protocols) >> >> NEW >> >> The other approach is passive measurements >> on the customer's ordinary traffic; the advantage is that it measures >> what the customer actually does, but it creates extra variability >> (different traffic mixes give different results) and especially it >> raises privacy concerns.[RFC6973] discusses privacy considerations for Internet protocols in general, whilst [framework] discusses them specifically for large-scale measurement systems. >> >> And add to references: >> >> [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., >> >> Morris, J., Hansen, M., and R. Smith, "Privacy >> >> Considerations for Internet Protocols", RFC 6973 >> , July >> >> 2013. >> >> Regards, Benoit >> >> -- >> >> Nits spotted: >> >> S2.2 >> >> Programs /programmes (twice) >> >> S2.2, end of penultimate paragraph is missing a full stop. >> >> S3.5 Large scale measurements can help provide a more nuance view that >> >> Large-scale measurements can help provide a more nuanced view that >> >> S4.3 take away for LMAP purposes are that policy-makers are looking for >> >> take-away for LMAP purposes is that policy-makers are looking for >> >> >> >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --------------080901070403060008080704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Phil,

As soon as you post a new version, I'll send this draft to IETF LC.

Regards, Benoit
Hi Phil,

I'm happy with the way you addressed my feedback.
Just one point needs correction: the last one.
Pervasive Monitoring, RFC 7528. This RFC should at least be referenced, for example around this sentence: 
   The other approach is passive measurements
   on the customer's ordinary traffic; the advantage is that it measures
   what the customer actually does, but it creates extra variability
   (different traffic mixes give different results) and especially it
   raises privacy concerns.
It's actually my fault. Wrong reference! it should be RFC 7258

Regards, Benoit
cfi - in case there needs to be any discussion during Monday's interim, here are the proposed resolutions to Benoit's comments.
best wishes,
phil
 
From: philip.eardley@bt.com [philip.eardley@bt.com]
Sent: 03 September 2014 14:20
To: bclaise@cisco.com; draft-ietf-lmap-use-cases@tools.ietf.org
Subject: RE: [lmap] AD review of draft-ietf-lmap-use-cases-03

Benoit,

Thank-you very much for your review. Sorry for the slow response - crossed wires amongst the authors

 

I’ve proposed resolutions to all your comments below – except for one that I don’t understand

<<- Section 3.1 

   Operators want to understand the quality of experience (QoE) of their
   broadband customers.

There is a QoE reference in RFC 5481

>> 

 

[phil] This was clarified:-

The QoE reference is actually https://tools.ietf.org/html/rfc6390#section-2.4

 

[to try and close the issues more rapidly, am emailing the use cases authors rather than lmap list.]

 

Thanks!

phil

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: 24 July 2014 15:30
To: lmap@ietf.org
Subject: [lmap] AD review of draft-ietf-lmap-use-cases-03

 

Dear all,

Here is my AD review

 

- OLD

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 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.

NEW:

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.

 

Yes – agree.

 

-  Section 2.1

   An ISP, or indeed another network operator, needs to understand the
   performance of their networks, the performance of the suppliers
   (downstream and upstream networks), the performance of services, and
   the impact that such performance has on the experience of their
   customers.

"indeed another network operator"?

NEW:

   A network operator needs to understand the
   performance of their networks, the performance of the suppliers
   (downstream and upstream networks), the performance of services, and
   the impact that such performance has on the experience of their
   customers.

 

 


- Section 2.1

      Identifying, isolating and fixing problems in the network,
      services or with CPE and end user equipment. 
 
I can't parse the sentence
 
NEW
      Identifying, isolating and fixing problems, which may be in the network,
      with the service provider, or in the end user equipment. 
 


-  Section 2.1

This sentence speaks about "services"

      o Identifying, isolating and fixing problems in the network,
      services or with CPE and end user equipment. 
 
Section 3.2 speaks about new services.
So, this paragraph also includes "services":
 
      o Understanding the impact and operation of new devices and
      technology. As a new product is deployed, or a new technology
      introduced into the network, it is essential that its operation
      and impact on other services is measured. This also helps to
      quantify the advantage that the new technology is bringing and
      support the business case for larger roll-out.
 

NEW:

      o Understanding the impact and operation of new devices, 
      technology, or services. As a new product is deployed, or a new technology
      introduced into the network, it is essential that its operation
      and impact on other services is measured. This also helps to
      quantify the advantage that the new technology is bringing and
      support the business case for larger roll-out.

 

I think ‘services’ here & in S3.2 is mainly being used in the sense of ‘network services’, which is confusing.

NEW

      o Understanding the impact and operation of new devices and
      technology. As a new product is deployed, or a new technology
      introduced into the network, it is essential that its operation
      and its impact is measured. This also helps to
      quantify the advantage that the new technology is bringing and
      support the business case for larger roll-out.

 

and in S3.2, first sentence

OLD

Another type of measurement is to test new capabilities and services

   before they are rolled out.

 

NEW

Another type of measurement is to test new capabilities

   before they are rolled out.


- I'm confused by:

 2  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1 Internet Service Provider (ISP) Use Case . . . . . . . . . .  3
     2.2 Regulators . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3 Implementation options . . . . . . . . . . . . . . . . . . .  5

What is the link between the "Implementation options" subsection and use cases?
Should "implementation options" have its own section?

I agree. Think it fits best as a section near the end.

NEW

   5  Implementation options . . . . . . . . . . . . . . . . . . .  12

   6  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 12



- 

   Another approach involves implementing the measurement capability as
   a webpage or an "app" that end users are encouraged to download onto
   their mobile phone or computing device. Measurements are triggered by
   the end user, for example the user interface may have a button to
   "test my broadband now". Compared with the previous approach, the
   system is much more loosely controlled, as the panel of end users and
   the schedule of tests are determined by the end users themselves
   rather than the measurement system. It would be easier to get large-
   scale, however it is harder to get comparable benchmarks as the
   measurements are affected by the home network and also the population
   is self-selecting and so potentially biased towards those who think
   they have a problem. This could be alleviated by stimulating
   widespread downloading of the app and careful post-processing of the
   results to reduce biases.

This end-user triggered measurement provides a huge advantage: it reflects the end-user QoE, as opposed to the broadband device QoE (*).  In combination with LMAP measurements in the broadband device, the end-user triggered measurement might prove that the home network is the source of performance degradations.
You might want to add those points either in section "Implementation options" or around the section 3.1  3rd paragraph.
This point is partly covered in last paragraph of section 3.5

(*) except if the end-user triggered measurement is executed directly on the broadband device ... For example, downloading a page, or initiating a test from the web server on the broadband device, as you mentioned:

   There are several other possibilities. For example, as a variant on
   the first approach, the measurement capability could be implemented
   as software embedded in the home gateway, which would make it more
   viable to have the capability on every user line. As a variant on the
   second approach, the end user could initiate measurements in response
   to a request from the measurement system.

 

NEW

   Another approach involves implementing the measurement capability as
   a webpage or an "app" that end users are encouraged to download onto
   their mobile phone or computing device. Measurements are triggered by
   the end user, for example the user interface may have a button to
   "test my broadband now". One advantage of this approach is that the performance is measured to the end user, rather than to the home gateway, and so includes the home network. Another difference is that the
   system is much more loosely controlled, as the panel of end users and
   the schedule of tests are determined by the end users themselves
   rather than the measurement system. It would be easier to get large-
   scale, however it is harder to get comparable benchmarks as the
   measurements are affected by the home network and also the population
   is self-selecting and so potentially biased towards those who think
   they have a problem. This could be alleviated by stimulating
   widespread downloading of the app and careful post-processing of the
   results to reduce biases.

 



- In connection with the previous point,  I was confused while reading the document.
I don't see"end-user triggered measurement" in section 2.X next to the ISP and operators use case. fine, but it's still discussed throughout the draft. For example

   Measurements are triggered by
   the end user, for example the user interface may have a button to
   "test my broadband now".
 
   OR
   As a variant on the
   second approach, the end user could initiate measurements in response
   to a request from the measurement system.
 
   OR
 
   The operator really wants to understand the end-to-end service
   experience. However, the home network (Ethernet, WiFi, powerline) is
   highly variable and outside its control. To date, operators (and
   regulators) have instead measured performance from the home gateway.
   However, mobile operators clearly must include the wireless link in
   the measurement. 
 
   OR
 
   The operator would like the
   end-to-end view of the service, rather than (say) just the access
   portion
 

So, I've been wondering whether this end-user triggered measurement was in scope or not.
I only found my answer in the conclusion section

   There are
   other use cases that are not the focus of the initial LMAP charter
   (although it is expected that the mechanisms developed would be
   readily applied), for example end users would like to use
   measurements to help identify problems in their home network and to
   monitor the performance of their broadband provider.

You should make it very clear, upfront, that the end-user triggered measurement is not in scope.
Something like section 5.6.1 End-user-controlled measurement system in the framework document

Suggest changing S1 Introduction

OLD

   This document describes two use cases for the Large-scale Measurement

   of Broadband Performance (LMAP), in particular use cases for ISPs and

   regulators.  Although there are many other use cases for large-scale

   measurements systems, the two described here are the consensus

   starting point for defining the system.

NEW

   This document describes two use cases for the Large-scale Measurement

   of Broadband Performance (LMAP). Firstly, to enable network operators to understand the performance of the network and the quality experienced by customers. Secondly, to enable regulators to provide information on the performance of the ISPs in their jurisdiction. There are other use cases that are not the focus of the initial LMAP work, for example end users would like to use measurements to help identify problems in their home network and to monitor the performance of their broadband provider; it is expected that the same mechanisms are applicable.

 


- Section 3.1 

   Operators want to understand the quality of experience (QoE) of their
   broadband customers.

There is a QoE reference in RFC 5481

 

I don’t understand this comment, sorry. I couldn’t find “QoE” in RFC5481



- Section 3.5

   One example was described in [IETF85-Plenary]. The operator was
   running a measurement panel for reasons discussed in sub use case #1.

Should we all review [IETF85-Plenary] to understand what sub use case # 1 is? ;-)

This meant sub use case #1 in draft-lmap-use-cases. However, I think the current text can be improved.

 

OLD

   One example was described in [IETF85-Plenary]. The operator was

   running a measurement panel for reasons discussed in sub use case #1.

   It was noticed that the performance of some lines had unexpectedly

   degraded. This led to a detailed (off-line) investigation which

   discovered that a particular home gateway upgrade had caused a

   (mistaken!) drop in line rate.

 

   Another example is that occasionally some internal network management

   event (like re-routing) can be customer-affecting (of course this is

   unusual). This affects a whole group of customers, for instance those

   on the same DSLAM. Understanding this will help an operator fix the

   fault more rapidly and/or allow the affected customers to be informed

   what's happening and/or request them to re-set their home hub

   (required to cure some conditions). More accurate information enables

   the operator to reassure customers and take more rapid and effective

   action to cure the problem.

 

   There may also be problems unique to a single user line (e.g. copper

   access) that need to be identified.

 

NEW

 

An operator can obtain useful information without measuring the performance on every broadband line. By measuring a subset, the operator identify problems that affect a group of customers. For example, the issue could be at a shared point in the network topology (such as an exchange) or common to a vendor or equipment type ([IETF85-Plenary] describes a case where a particular home gateway upgrade had caused a (mistaken!) drop in line rate). A more extensive deployment of the measurement capability to every broadband line would enable an operator to identify issues unique to a single customer. Overall, large-scale measurements can help an operator help an operator fix the fault more rapidly and/or allow the affected customers to be informed what's happening. More accurate information enables the operator to reassure customers and take more rapid and effective action to cure the problem.

 

 


- Section 4.1

   The published information needs to be:
 
      o  Accurate - the measurement results must be correct and not
      influenced by errors or side effects. The results should be
      reproducible and consistent over time.
 
      o  Comparable - common metrics should be used across different
      ISPs and service offerings so that measurement results can be
      compared.
 
      o  Meaningful - the metrics used for measurements need to reflect
      what end users value about their broadband Internet access service
 
      o  Reliable - the number and distribution of measurement agents,
      and the statistical processing of the raw measurement raw data,
      needs to be appropriate


Not sure if this was discussed, but one goal behind the regulator use case is to strongly suggest the ISPs to use the same metrics in their SLC (Service Level Contracts).
If you ever tried to compare SLC between ISPs, well, go luck.
This would be a nice additional 4.x section

Rather than a new section, I suggest an additional sentence in the 2nd para of S4.1:

NEW

   End users need effective transparency to be able to make informed

   choices throughout the different stages of their relationship with

   ISPs, when selecting Internet access service offers, and when

   considering switching service offer within an ISP or to an

   alternative ISP. Quality information about service offers could

   include speed, delay, and jitter. Regulators can publish such

   information to facilitate end users' choice of service provider and

   offer. It may also encourage ISPs to use the same metrics in their service level contracts, which would further help end users to choose an ISP. Finally, transparency may help content, application, service and device

   providers develop their Internet offerings.

 



- Pervasive Monitoring, RFC 7528. This RFC should at least be referenced, for example around this sentence:

   The other approach is passive measurements
   on the customer's ordinary traffic; the advantage is that it measures
   what the customer actually does, but it creates extra variability
   (different traffic mixes give different results) and especially it
   raises privacy concerns.

 

Do you mean RFC6973? (Privacy Considerations for Internet Protocols)

NEW

   The other approach is passive measurements
   on the customer's ordinary traffic; the advantage is that it measures
   what the customer actually does, but it creates extra variability
   (different traffic mixes give different results) and especially it
   raises privacy concerns. [RFC6973] discusses privacy considerations for Internet protocols in general, whilst [framework] discusses them specifically for large-scale measurement systems.

 

And add to references:

 

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,

              Morris, J., Hansen, M., and R. Smith, "Privacy

              Considerations for Internet Protocols", RFC 6973, July

              2013.

 

 

 

Regards, Benoit

 

--

Nits spotted:

S2.2

Programs /programmes (twice)

 

S2.2, end of penultimate paragraph is missing a full stop.

 

S3.5 Large scale measurements can help provide a more nuance view that

è  Large-scale measurements can help provide a more nuanced view that

 

S4.3 take away for LMAP purposes are that policy-makers are looking for

è  take-away for LMAP purposes is that policy-makers are looking for



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




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

--------------080901070403060008080704-- From nobody Tue Sep 23 11:33:24 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 E7E281A88C1; Tue, 23 Sep 2014 11:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 c3-S-x3IgeuG; Tue, 23 Sep 2014 11:33:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB47C1A8882; Tue, 23 Sep 2014 11:32:49 -0700 (PDT) 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.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140923183249.10249.10815.idtracker@ietfa.amsl.com> Date: Tue, 23 Sep 2014 11:32:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/PmQDVTbzTyIWEtSo61BUpXSyqXQ Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-use-cases-04.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: Tue, 23 Sep 2014 18:33:21 -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-04.txt Pages : 16 Date : 2014-09-23 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-use-cases-04 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 Tue Sep 23 14:44:09 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 6CD601A1BD2 for ; Tue, 23 Sep 2014 14:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.266 X-Spam-Level: X-Spam-Status: No, score=-14.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 sjmDydh4xXro for ; Tue, 23 Sep 2014 14:44:03 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259131A1B13 for ; Tue, 23 Sep 2014 14:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1993; q=dns/txt; s=iport; t=1411508619; x=1412718219; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to:content-transfer-encoding; bh=cKxS9sO6xPBXNj5WScqyT+SptBcPMU5mPCJNPBMbBV8=; b=D9E4xMSG5GYCGWkvrXssAi+yw1CegNF1noGRAnGyLFloqj4Rhg7Skpr4 a0cw+t6l0wwYnDnoydTbqjGJBhKRgV7LuaJ2IojmE+yq0GG8k7tgOFChc usFK5N+lkcEvLC2BrCTrfo21kUH7Cz/e7XLuy4Dm2BN7ioQbDy8Fr1JvK k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwHAL/oIVStJssW/2dsb2JhbABgg2FTBMlWCodNASR/AXqDewkBAQQBAQE1NgoBEAshFg8JAwIBAgEVMBMBBQIBAQWFbYJICAXCZQEXkAcHgweBRAEEj0KGUocIgWGFa44Hg2Q7L4JKAQEF X-IronPort-AV: E=Sophos;i="5.04,582,1406592000"; d="scan'208";a="187396259" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 23 Sep 2014 21:43:37 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8NLhb5j025431 for ; Tue, 23 Sep 2014 21:43:37 GMT Message-ID: <5421E989.4050102@cisco.com> Date: Tue, 23 Sep 2014 23:43:37 +0200 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 CC: lmap@ietf.org References: <20140923183249.10249.10815.idtracker@ietfa.amsl.com> In-Reply-To: <20140923183249.10249.10815.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Ax0eMFItIFeXPc14U2BWV9hKtmI Subject: Re: [lmap] I-D Action: draft-ietf-lmap-use-cases-04.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 21:44:05 -0000 Dear all, The IETF LC has been requested. Regards, Benoit > 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-04.txt > Pages : 16 > Date : 2014-09-23 > > 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-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-use-cases-04 > > > 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/ > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > . > From nobody Tue Sep 23 14:47: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 52BF31A6EDA; Tue, 23 Sep 2014 14:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 pRvLBHgKh08H; Tue, 23 Sep 2014 14:47:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3066D1A01EF; Tue, 23 Sep 2014 14:47:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140923214748.12329.72074.idtracker@ietfa.amsl.com> Date: Tue, 23 Sep 2014 14:47:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/-hQoYE8EOVrNMHYeJ7FCdgMUlrQ Cc: lmap@ietf.org Subject: [lmap] Last Call: (Large-Scale Broadband Measurement Use Cases) to Informational RFC 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: Tue, 23 Sep 2014 21:47:50 -0000 The IESG has received a request from the Large-Scale Measurement of Broadband Performance WG (lmap) to consider the following document: - 'Large-Scale Broadband Measurement Use Cases' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Sep 24 08:52: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 B72651A00EA for ; Wed, 24 Sep 2014 08:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 vhKL8Tfxr6CN for ; Wed, 24 Sep 2014 08:52:37 -0700 (PDT) Received: from p01c12o148.mxlogic.net (p01c12o148.mxlogic.net [208.65.145.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB021A00C3 for ; Wed, 24 Sep 2014 08:52:37 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO p01c12o148.mxlogic.net) by p01c12o148.mxlogic.net(mxl_mta-8.1.0-0) with ESMTP id 5c8e2245.2af846616940.39058.00-557.111721.p01c12o148.mxlogic.net (envelope-from ); Wed, 24 Sep 2014 09:52:37 -0600 (MDT) X-MXL-Hash: 5422e8c54758d9e6-6f3ca493827327d5ce16bd82bea42ee8ba404495 Received: from unknown [76.164.174.81] by p01c12o148.mxlogic.net(mxl_mta-8.1.0-0) with SMTP id 258e2245.0.35875.00-329.107358.p01c12o148.mxlogic.net (envelope-from ); Wed, 24 Sep 2014 09:50:45 -0600 (MDT) X-MXL-Hash: 5422e8556b20e61d-0d2f949bb280a7a8dd5140fb042334ac35b6a784 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 10:49:47 -0500 From: KEN KO To: "trevor.burbridge@bt.com" , "lmap@ietf.org" , "david.j.thorne@bt.com" Thread-Topic: Suppression for a defined duration Thread-Index: Ac/YC730YgiLEI+0RMayR47zYV6eWQ== Date: Wed, 24 Sep 2014 15:49:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.199] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB7792D7ABEexmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=MtZG6gqe c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=yoykJ3cPgRgA:10 a=YAH] X-AnalysisOut: [MrRviK1AA:10 a=qZHQZMT3apYA:10 a=LDf1Js4lsR0A:10 a=BLceEmw] X-AnalysisOut: [cHowA:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=5nHlFfVjZt5QWRdAL2AA:9 a=CjuIK1q_8ugA:10 a=yMhMjlubAA] X-AnalysisOut: [AA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 ] X-AnalysisOut: [a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014092411); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/wl0FrvoCW1nolkdEpLO1k_gSCpI Subject: [lmap] Suppression for a defined duration X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 15:52:41 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB7792D7ABEexmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, During continued WT-304 sessions after our joint workshop last week, Dave T= horne pointed out that the Suppression object needs an optional field for d= uration of the suppression event. It does of course include optional start = and stop datetime fields, but those fields are dependent on the datetime cl= ocks in all the MAs across the network being in reasonably good synchroniza= tion. To preclude issues due to clocks being out of sync, suppression shoul= d be able to specify a fixed duration. Your thoughts? I've also included Dave in case he wants to chime in. Ken --_000_D14B7E40AEBFD54EA3AD964902DD7CB7792D7ABEexmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

During continued WT-304 sessions after our joint wor= kshop last week, Dave Thorne pointed out that the Suppression object needs = an optional field for duration of the suppression event. It does of course = include optional start and stop datetime fields, but those fields are dependent on the datetime clocks in all the M= As across the network being in reasonably good synchronization. To preclude= issues due to clocks being out of sync, suppression should be able to spec= ify a fixed duration.

 

Your thoughts? I’ve also included Dave in case= he wants to chime in.

 

Ken

 

--_000_D14B7E40AEBFD54EA3AD964902DD7CB7792D7ABEexmb1corpadtran_-- From nobody Wed Sep 24 09:10: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 B9FE41A00CD for ; Wed, 24 Sep 2014 09:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 XloOJTTLAnEK for ; Wed, 24 Sep 2014 09:10:32 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326681A01AE for ; Wed, 24 Sep 2014 09:10:15 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 6ece2245.0.1214369.00-2041.3420555.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 24 Sep 2014 16:10:15 +0000 (UTC) X-MXL-Hash: 5422ece76282fac1-4025b732e1f772b486088faeedbcea159930308d Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s8OGADcM014258 for ; Wed, 24 Sep 2014 12:10:14 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s8OGAA3T014134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Sep 2014 12:10:11 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi132.aldc.att.com (RSA Interceptor) for ; Wed, 24 Sep 2014 16:09:57 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.240]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 12:09:57 -0400 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: information-model: ma-task-capability-obj vs. elements in ma-task-obj Thread-Index: Ac/YEdxcLeiiiv28RVKbPnWSP+UhGQ== Date: Wed, 24 Sep 2014 16:09:57 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130E88998@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.203.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=LIzRtuq9 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=4zQTcsG9mnUA:10 a=O870z9mil6kA:10 a=ofMgfj31e3cA:10 a=pWN] X-AnalysisOut: [_W1hsC6MA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=XIqpo32RAAAA:8 a=TqIKuuwlReZbyErKEA8A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/6qlXlrJvPb7jyZtgY_RpPCXzyXw Subject: [lmap] information-model: ma-task-capability-obj vs. elements in ma-task-obj X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 16:10:36 -0000 I see that information-model has objects of: object { string ma-task-name; uri ma-task-registry; string ma-task-role; } ma-task-capability-obj; object { string ma-task-name; uri ma-task-registry-entry; string ma-role; name-value-pair ma-task-options<0..*>; [boolean ma-task-suppress-by-default;] // default: TRUE [string ma-task-cycle-id;] } ma-task-obj; Where the ma-task-capability-obj items can be reported up to the Controller= as capabilities, and the ma-task-obj items are what get configured. I see no correlation between ma-task-capability-obj nor to any of the eleme= nts of ma-task-obj (other than certain elements having similar names), and = no ability to create such a correlation. Furthermore, ma-task-obj has 3 ele= ments that appear almost identical to the elements of ma-task-capability-ob= j. Why doesn't ma-task-obj just have an element of type ma-task-capability-obj= instead of ma-task-name, ma-task-registry-entry, and ma-role? Wouldn't this provide for precise correlation between the reported capabili= ties and the specific capability being configured through this ma-task-obj? Barbara From nobody Wed Sep 24 14:44:48 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 216571A1A70 for ; Wed, 24 Sep 2014 14:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 KCZH7kUk0UWl for ; Wed, 24 Sep 2014 14:44:43 -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 1E0461A1A24 for ; Wed, 24 Sep 2014 14:44:27 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 857E61175; Wed, 24 Sep 2014 23:44:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id KlcX6PokhA7H; Wed, 24 Sep 2014 23:44:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 24 Sep 2014 23:44:24 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6931120036; Wed, 24 Sep 2014 23:44:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VhB8wXKOq1y6; Wed, 24 Sep 2014 23:44:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19F6D20035; Wed, 24 Sep 2014 23:44:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C42522E88A7A; Wed, 24 Sep 2014 23:44:21 +0200 (CEST) Date: Wed, 24 Sep 2014 23:44:21 +0200 From: Juergen Schoenwaelder To: KEN KO Message-ID: <20140924214421.GC25390@elstar.local> Mail-Followup-To: KEN KO , "trevor.burbridge@bt.com" , "lmap@ietf.org" , "david.j.thorne@bt.com" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/YhL8BDibjrxzwUjEabozcrV0e8c Cc: "trevor.burbridge@bt.com" , "david.j.thorne@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Suppression for a defined duration X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 21:44:46 -0000 On Wed, Sep 24, 2014 at 03:49:47PM +0000, KEN KO wrote: > Trevor, > > During continued WT-304 sessions after our joint workshop last week, Dave Thorne pointed out that the Suppression object needs an optional field for duration of the suppression event. It does of course include optional start and stop datetime fields, but those fields are dependent on the datetime clocks in all the MAs across the network being in reasonably good synchronization. To preclude issues due to clocks being out of sync, suppression should be able to specify a fixed duration. > > Your thoughts? I've also included Dave in case he wants to chime in. > I prefer to not add this. Instead, make sure boxes run ntp or something like that. The reason is: What happens if a device reboots during suppression? In that case, am I expected to be able to calculate how long the suppression continues? What if my time synchronization changes? Or is the idea that I calculate an absolute end time stamp once I receive the suppression and then I still depend on time synchronization to do the right thing? I believe we have to trust that boxes have a meaningful notion of time for basically all of the scheduling to work correctly. If clocks are unusable for suppression, then they will also be unusable to starting tasks at other scheduled times. So there better are NTP synchronized clocks. Perhaps we should add an explicit statement about this somewhere. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 24 15:23:59 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 52C661A1ADD for ; Wed, 24 Sep 2014 15:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 ufHgsoXEALVu for ; Wed, 24 Sep 2014 15:23:43 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4F41A1AD2 for ; Wed, 24 Sep 2014 15:23:42 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id e6443245.2b3421a08940.1484989.00-2440.4191104.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 24 Sep 2014 22:23:42 +0000 (UTC) X-MXL-Hash: 5423446e16f7962b-2084d33b673be3b649cb52f5a98b0c717589481c Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 96443245.0.1484958.00-2335.4190935.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 24 Sep 2014 22:23:39 +0000 (UTC) X-MXL-Hash: 5423446b037b9077-f1ad850ed5b01539c707e1047cd79577479ac8ff Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s8OMNbiv025746; Wed, 24 Sep 2014 18:23:37 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s8OMNWTl025682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2014 18:23:34 -0400 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 24 Sep 2014 22:23:15 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.240]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 18:23:15 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder , KEN KO Thread-Topic: [lmap] Suppression for a defined duration Thread-Index: Ac/YC730YgiLEI+0RMayR47zYV6eWQAVnwiAAAelqiA= Date: Wed, 24 Sep 2014 22:23:14 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130E88C75@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20140924214421.GC25390@elstar.local> In-Reply-To: <20140924214421.GC25390@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.203.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=eemKic4H c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=MYx2J-C-Cz8A:10 a=CCY5sTEGQxkA:10 a=ofMgfj31e3cA:10 a=pWN] X-AnalysisOut: [_W1hsC6MA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=XIqpo32RAAAA:8 a=fWxSDDOQVMRrSgKTAiwA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/wxiFAh-Pu67soJ9hljoMopINrWo Cc: "trevor.burbridge@bt.com" , "david.j.thorne@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Suppression for a defined duration X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 22:23:49 -0000 > > During continued WT-304 sessions after our joint workshop last week, Da= ve > Thorne pointed out that the Suppression object needs an optional field fo= r > duration of the suppression event. It does of course include optional sta= rt > and stop datetime fields, but those fields are dependent on the datetime > clocks in all the MAs across the network being in reasonably good > synchronization. To preclude issues due to clocks being out of sync, > suppression should be able to specify a fixed duration. > > > > Your thoughts? I've also included Dave in case he wants to chime in. > > >=20 > I prefer to not add this. Instead, make sure boxes run ntp or something l= ike > that. The reason is: What happens if a device reboots during suppression?= In > that case, am I expected to be able to calculate how long the suppression > continues? What if my time synchronization changes? Or is the idea that I > calculate an absolute end time stamp once I receive the suppression and > then I still depend on time synchronization to do the right thing? >=20 > I believe we have to trust that boxes have a meaningful notion of time fo= r > basically all of the scheduling to work correctly. If clocks are unusable= for > suppression, then they will also be unusable to starting tasks at other > scheduled times. So there better are NTP synchronized clocks. Perhaps we > should add an explicit statement about this somewhere. >=20 > /js I thought that since it can't be assumed that a device maintains any aspect= of its Instruction when rebooted or power-cycled, that the best practice p= rocedure would be to re-send suppression to a rebooted device. Of course, i= t's probably even less desirable to have the Controller try to figure out h= ow much of a duration is left in this case. It's easier for the Controller = to just have a static end time. Also, since it's unlikely that the Controll= er actually suppresses all MAs at the same time, it's unlikely that all MAs= would start suppressing at the same time. Duration would cause different e= nds to suppression based on when the MA actually got the message. Unless th= e Controller is calculating different duration for each device. As it relates to ntp, most devices do lose their time configuration during = power cycling, and use a "relative to start-up" time until they manage to g= et in touch with their favorite ntp server. Continued inability to communic= ate with an ntp server isn't supposed to prevent proper operation. It just = messes with timestamps on logs. But generally, if there's Internet connecti= vity that allows communication with a Controller, then there's communicatio= n with an ntp server. And we've said the MA isn't to do any Measurement Tas= ks until it registers with its Controller (so if it's rebooting it has to r= egister before it does Measurement Tasks). Hmm. I'm sort of ambivalent but tending to agree with Juergen. Barbara From nobody Wed Sep 24 23:40:13 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 3C3F71A6F8B for ; Wed, 24 Sep 2014 23:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 vqmUskdrIL4R for ; Wed, 24 Sep 2014 23:40:10 -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 A441B1A6F88 for ; Wed, 24 Sep 2014 23:40:09 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 753F21113; Thu, 25 Sep 2014 08:40:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id aVOTv0pUWUTE; Thu, 25 Sep 2014 08:40:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 25 Sep 2014 08:40:07 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AAE9920035; Thu, 25 Sep 2014 08:40:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Jo8H_w1GAJ0v; Thu, 25 Sep 2014 08:40:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5667D20036; Thu, 25 Sep 2014 08:40:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 34DAE2E88EBB; Thu, 25 Sep 2014 08:40:06 +0200 (CEST) Date: Thu, 25 Sep 2014 08:40:06 +0200 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20140925064006.GD26200@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E61130E88998@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130E88998@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/wzhXjGGHr6jvQbyD1o8hG1D4BKI Cc: "lmap@ietf.org" Subject: Re: [lmap] information-model: ma-task-capability-obj vs. elements in ma-task-obj X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 06:40:11 -0000 On Wed, Sep 24, 2014 at 04:09:57PM +0000, STARK, BARBARA H wrote: > I see that information-model has objects of: > > object { > string ma-task-name; > uri ma-task-registry; > string ma-task-role; > } ma-task-capability-obj; > > object { > string ma-task-name; > uri ma-task-registry-entry; > string ma-role; > name-value-pair ma-task-options<0..*>; > [boolean ma-task-suppress-by-default;] // default: TRUE > [string ma-task-cycle-id;] > } ma-task-obj; > > Where the ma-task-capability-obj items can be reported up to the Controller as capabilities, and the ma-task-obj items are what get configured. > I see no correlation between ma-task-capability-obj nor to any of the elements of ma-task-obj (other than certain elements having similar names), and no ability to create such a correlation. Furthermore, ma-task-obj has 3 elements that appear almost identical to the elements of ma-task-capability-obj. > > Why doesn't ma-task-obj just have an element of type ma-task-capability-obj instead of ma-task-name, ma-task-registry-entry, and ma-role? > Wouldn't this provide for precise correlation between the reported capabilities and the specific capability being configured through this ma-task-obj? For me, this would not change anything. Note that the 'name' properties have actually different scopes since I can have multiple ma-task-obj's configured for a single ma-task-capability-obj. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Sep 25 00:59:29 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 D59701A0298 for ; Thu, 25 Sep 2014 00:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DtYIRJNet6cx for ; Thu, 25 Sep 2014 00:59:25 -0700 (PDT) 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 C98B91A028E for ; Thu, 25 Sep 2014 00:59:24 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 25 Sep 2014 08:59:27 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.205]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Thu, 25 Sep 2014 08:59:10 +0100 From: To: , Date: Thu, 25 Sep 2014 08:59:09 +0100 Thread-Topic: [lmap] information-model: ma-task-capability-obj vs. elements in ma-task-obj Thread-Index: Ac/YEdxcLeiiiv28RVKbPnWSP+UhGQAhDamA Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130E88998@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130E88998@GAALPA1MSGUSRBF.ITServices.sbc.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/oTROZw4pROphUyV3G9YmXIqVYmg Subject: Re: [lmap] information-model: ma-task-capability-obj vs. elements in ma-task-obj X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 07:59:28 -0000 The intention was that the capability object would simply say something abo= ut the task/role that was installed on the MA. The task configuration objec= t would then have the configuration of various parameters. It would be poss= ible (and perhaps sensible) to link from the task configuration to the task= capability (which is what you suggest). Trevor. >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H >Sent: 24 September 2014 17:10 >To: lmap@ietf.org >Subject: [lmap] information-model: ma-task-capability-obj vs. elements in = ma- >task-obj > >I see that information-model has objects of: > > object { > string ma-task-name; > uri ma-task-registry; > string ma-task-role; > } ma-task-capability-obj; > >object { > string ma-task-name; > uri ma-task-registry-entry; > string ma-role; > name-value-pair ma-task-options<0..*>; > [boolean ma-task-suppress-by-default;] // default: TRUE > [string ma-task-cycle-id;] >} ma-task-obj; > >Where the ma-task-capability-obj items can be reported up to the Controlle= r as >capabilities, and the ma-task-obj items are what get configured. >I see no correlation between ma-task-capability-obj nor to any of the elem= ents of >ma-task-obj (other than certain elements having similar names), and no abi= lity to >create such a correlation. Furthermore, ma-task-obj has 3 elements that ap= pear >almost identical to the elements of ma-task-capability-obj. > >Why doesn't ma-task-obj just have an element of type ma-task-capability-ob= j >instead of ma-task-name, ma-task-registry-entry, and ma-role? >Wouldn't this provide for precise correlation between the reported capabil= ities >and the specific capability being configured through this ma-task-obj? >Barbara > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Sep 25 03:29: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 CA0971A6F61 for ; Thu, 25 Sep 2014 03:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 6EZnZmtm6C8C for ; Thu, 25 Sep 2014 03:29:28 -0700 (PDT) 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 E74FF1A1C04 for ; Thu, 25 Sep 2014 03:29:27 -0700 (PDT) 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, 25 Sep 2014 11:29:31 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.5]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Thu, 25 Sep 2014 11:29:25 +0100 From: To: , , Date: Thu, 25 Sep 2014 11:29:24 +0100 Thread-Topic: [lmap] Suppression for a defined duration Thread-Index: Ac/YC730YgiLEI+0RMayR47zYV6eWQAVnwiAAAelqiAACiE8kA== Message-ID: References: <20140924214421.GC25390@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E88C75@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130E88C75@GAALPA1MSGUSRBF.ITServices.sbc.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/FQjOQ4ZHScShNk_UB_AlV_7OHN4 Cc: trevor.burbridge@bt.com, david.j.thorne@bt.com, lmap@ietf.org Subject: Re: [lmap] Suppression for a defined duration 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, 25 Sep 2014 10:29:29 -0000 I don't understand what the benefit is, although I don't violently object t= o adding the suppression duration as a field. Is the situation that people are worried about where the device re-boots, t= he internal clock now thinks it's 1970, it now gets a suppress with "start = now, end 26 Sept 2014"? But there's a bigger problem - the instruction has = a start time for measurements, so it would never start measuring anyway. So= the MA has to realise something's wrong and re-set its clock anyway. =09 related topic. If the MA is in suppression and re-boots, it would probably = be nice if it's still in suppression after re-boot. Think this is hard to s= olve with things we define at the IETF - seems device /implementation depen= dent how to handle the issue (after re-boot - maybe the "suppress state" ca= n be in persistent memory, maybe the device assumes its instruction is stal= e and doesn't do any measurements until it's re-contacted the controller, e= tc.) I'd have thought the device /MA's behaviour after re-boot will be cons= istent - it isn't something that the controller will want to regularly alte= r - so don't think this needs to be part of the information model.=20 Phil > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: 24 September 2014 23:23 > To: Juergen Schoenwaelder; KEN KO > Cc: Burbridge,T,Trevor,TUB8 R; Thorne,DJ,David,TUB8 R; lmap@ietf.org > Subject: Re: [lmap] Suppression for a defined duration >=20 > > > During continued WT-304 sessions after our joint workshop last > week, > > > Dave > > Thorne pointed out that the Suppression object needs an optional > field > > for duration of the suppression event. It does of course include > > optional start and stop datetime fields, but those fields are > > dependent on the datetime clocks in all the MAs across the network > > being in reasonably good synchronization. To preclude issues due to > > clocks being out of sync, suppression should be able to specify a > fixed duration. > > > > > > Your thoughts? I've also included Dave in case he wants to chime > in. > > > > > > > I prefer to not add this. Instead, make sure boxes run ntp or > > something like that. The reason is: What happens if a device reboots > > during suppression? In that case, am I expected to be able to > > calculate how long the suppression continues? What if my time > > synchronization changes? Or is the idea that I calculate an absolute > > end time stamp once I receive the suppression and then I still depend > on time synchronization to do the right thing? > > > > I believe we have to trust that boxes have a meaningful notion of > time > > for basically all of the scheduling to work correctly. If clocks are > > unusable for suppression, then they will also be unusable to starting > > tasks at other scheduled times. So there better are NTP synchronized > > clocks. Perhaps we should add an explicit statement about this > somewhere. > > > > /js >=20 > I thought that since it can't be assumed that a device maintains any > aspect of its Instruction when rebooted or power-cycled, that the best > practice procedure would be to re-send suppression to a rebooted > device. Of course, it's probably even less desirable to have the > Controller try to figure out how much of a duration is left in this > case. It's easier for the Controller to just have a static end time. > Also, since it's unlikely that the Controller actually suppresses all > MAs at the same time, it's unlikely that all MAs would start > suppressing at the same time. Duration would cause different ends to > suppression based on when the MA actually got the message. Unless the > Controller is calculating different duration for each device. >=20 > As it relates to ntp, most devices do lose their time configuration > during power cycling, and use a "relative to start-up" time until they > manage to get in touch with their favorite ntp server. Continued > inability to communicate with an ntp server isn't supposed to prevent > proper operation. It just messes with timestamps on logs. But > generally, if there's Internet connectivity that allows communication > with a Controller, then there's communication with an ntp server. And > we've said the MA isn't to do any Measurement Tasks until it registers > with its Controller (so if it's rebooting it has to register before it > does Measurement Tasks). >=20 > Hmm. I'm sort of ambivalent but tending to agree with Juergen. > Barbara >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Sep 25 04:08:30 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 7FF7A1A6F71 for ; Thu, 25 Sep 2014 04:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_62=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.786] 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 aBnVl0DauNPG for ; Thu, 25 Sep 2014 04:08:28 -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 D6D911A1A72 for ; Thu, 25 Sep 2014 04:08:27 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9280F708; Thu, 25 Sep 2014 13:08:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UuicKTR7dQR3; Thu, 25 Sep 2014 13:08:21 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 25 Sep 2014 13:08:24 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9852420036; Thu, 25 Sep 2014 13:08:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fWZpCNNUuuTa; Thu, 25 Sep 2014 13:08:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC49C20035; Thu, 25 Sep 2014 13:08:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2C2182E895D0; Thu, 25 Sep 2014 13:08:20 +0200 (CEST) Date: Thu, 25 Sep 2014 13:08:20 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20140925110820.GA27243@elstar.local> Mail-Followup-To: philip.eardley@bt.com, bs7652@att.com, KEN.KO@adtran.com, trevor.burbridge@bt.com, david.j.thorne@bt.com, lmap@ietf.org References: <20140924214421.GC25390@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E88C75@GAALPA1MSGUSRBF.ITServices.sbc.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/oRS4T7T32n0suH5P74fk9lLR9PE Cc: trevor.burbridge@bt.com, david.j.thorne@bt.com, bs7652@att.com, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Suppression for a defined duration X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 11:08:29 -0000 Hi, as said before, all the calendar scheduling assumes that MAs have a resonable notion of time. Hence, if we make this assumption in general, why would we then have to do something extra for suppression? /js On Thu, Sep 25, 2014 at 11:29:24AM +0100, philip.eardley@bt.com wrote: > I don't understand what the benefit is, although I don't violently object to adding the suppression duration as a field. > > Is the situation that people are worried about where the device re-boots, the internal clock now thinks it's 1970, it now gets a suppress with "start now, end 26 Sept 2014"? But there's a bigger problem - the instruction has a start time for measurements, so it would never start measuring anyway. So the MA has to realise something's wrong and re-set its clock anyway. > > related topic. If the MA is in suppression and re-boots, it would probably be nice if it's still in suppression after re-boot. Think this is hard to solve with things we define at the IETF - seems device /implementation dependent how to handle the issue (after re-boot - maybe the "suppress state" can be in persistent memory, maybe the device assumes its instruction is stale and doesn't do any measurements until it's re-contacted the controller, etc.) I'd have thought the device /MA's behaviour after re-boot will be consistent - it isn't something that the controller will want to regularly alter - so don't think this needs to be part of the information model. > > Phil > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > > Sent: 24 September 2014 23:23 > > To: Juergen Schoenwaelder; KEN KO > > Cc: Burbridge,T,Trevor,TUB8 R; Thorne,DJ,David,TUB8 R; lmap@ietf.org > > Subject: Re: [lmap] Suppression for a defined duration > > > > > > During continued WT-304 sessions after our joint workshop last > > week, > > > > Dave > > > Thorne pointed out that the Suppression object needs an optional > > field > > > for duration of the suppression event. It does of course include > > > optional start and stop datetime fields, but those fields are > > > dependent on the datetime clocks in all the MAs across the network > > > being in reasonably good synchronization. To preclude issues due to > > > clocks being out of sync, suppression should be able to specify a > > fixed duration. > > > > > > > > Your thoughts? I've also included Dave in case he wants to chime > > in. > > > > > > > > > > I prefer to not add this. Instead, make sure boxes run ntp or > > > something like that. The reason is: What happens if a device reboots > > > during suppression? In that case, am I expected to be able to > > > calculate how long the suppression continues? What if my time > > > synchronization changes? Or is the idea that I calculate an absolute > > > end time stamp once I receive the suppression and then I still depend > > on time synchronization to do the right thing? > > > > > > I believe we have to trust that boxes have a meaningful notion of > > time > > > for basically all of the scheduling to work correctly. If clocks are > > > unusable for suppression, then they will also be unusable to starting > > > tasks at other scheduled times. So there better are NTP synchronized > > > clocks. Perhaps we should add an explicit statement about this > > somewhere. > > > > > > /js > > > > I thought that since it can't be assumed that a device maintains any > > aspect of its Instruction when rebooted or power-cycled, that the best > > practice procedure would be to re-send suppression to a rebooted > > device. Of course, it's probably even less desirable to have the > > Controller try to figure out how much of a duration is left in this > > case. It's easier for the Controller to just have a static end time. > > Also, since it's unlikely that the Controller actually suppresses all > > MAs at the same time, it's unlikely that all MAs would start > > suppressing at the same time. Duration would cause different ends to > > suppression based on when the MA actually got the message. Unless the > > Controller is calculating different duration for each device. > > > > As it relates to ntp, most devices do lose their time configuration > > during power cycling, and use a "relative to start-up" time until they > > manage to get in touch with their favorite ntp server. Continued > > inability to communicate with an ntp server isn't supposed to prevent > > proper operation. It just messes with timestamps on logs. But > > generally, if there's Internet connectivity that allows communication > > with a Controller, then there's communication with an ntp server. And > > we've said the MA isn't to do any Measurement Tasks until it registers > > with its Controller (so if it's rebooting it has to register before it > > does Measurement Tasks). > > > > Hmm. I'm sort of ambivalent but tending to agree with Juergen. > > Barbara > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Sep 25 05:13:42 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 C34BB1A6FBA for ; Thu, 25 Sep 2014 05:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 496Uil12RL51 for ; Thu, 25 Sep 2014 05:13:39 -0700 (PDT) Received: from p01c11o147.mxlogic.net (p01c11o147.mxlogic.net [208.65.144.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855831A0005 for ; Thu, 25 Sep 2014 05:13:39 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p01c11o147.mxlogic.net(mxl_mta-8.1.0-0) with ESMTP id 3f604245.2ac612f5d940.49923.00-563.130422.p01c11o147.mxlogic.net (envelope-from ); Thu, 25 Sep 2014 06:13:39 -0600 (MDT) X-MXL-Hash: 542406f364ae1091-93b4819e9fcb5a5b79c1be85d6761e00b4b18469 Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p01c11o147.mxlogic.net(mxl_mta-8.1.0-0) over TLS secured channel with ESMTP id 58604245.0.49007.00-297.127849.p01c11o147.mxlogic.net (envelope-from ); Thu, 25 Sep 2014 06:11:52 -0600 (MDT) X-MXL-Hash: 54240688389aadd3-81bc71edcc8f0c637f72568ccd770b1182d4fee0 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 07:11:48 -0500 From: KEN KO To: "philip.eardley@bt.com" , "bs7652@att.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [lmap] Suppression for a defined duration Thread-Index: Ac/YC730YgiLEI+0RMayR47zYV6eWQAXt3mAAAFbpQAAGVxwAAAHCMEQ Date: Thu, 25 Sep 2014 12:11:48 +0000 Message-ID: References: <20140924214421.GC25390@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E88C75@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=BffM09d2 c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=MYx2J-C-Cz8A:10 a=CCY] X-AnalysisOut: [5sTEGQxkA:10 a=qZHQZMT3apYA:10 a=LDf1Js4lsR0A:10 a=BLceEmw] X-AnalysisOut: [cHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAA] X-AnalysisOut: [A:8 a=YlVTAMxIAAAA:8 a=-t25obd99ZF9S-5rfgcA:9 a=CjuIK1q_8u] X-AnalysisOut: [gA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014092503); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/RB28kVzzXG_4MMfTOHUZ6L10vpg Cc: "trevor.burbridge@bt.com" , "david.j.thorne@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Suppression for a defined duration 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, 25 Sep 2014 12:13:41 -0000 >related topic. If the MA is in suppression and re-boots, it would probably= be nice=20 >if it's still in suppression after re-boot. Think this is hard to solve wi= th things we=20 >define at the IETF - seems device /implementation dependent how to handle = the=20 >issue (after re-boot - maybe the "suppress state" can be in persistent mem= ory,=20 >maybe the device assumes its instruction is stale and doesn't do any measu= rements=20 >until it's re-contacted the controller, etc.) I'd have thought the device = /MA's behaviour=20 >after re-boot will be consistent - it isn't something that the controller = will want to=20 >regularly alter - so don't think this needs to be part of the information = model.=20 Whether or not the MA retains state information through a reboot will be de= vice dependent. If it does, it can continue as if nothing happened. If not,= it needs to re-register. I don't see a need for any mention in the i-m. From nobody Thu Sep 25 08:48: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 17C7F1A802F for ; Thu, 25 Sep 2014 08:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.786] 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 nWpDrbLrsNWo for ; Thu, 25 Sep 2014 08:48:25 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [199.166.16.238]) by ietfa.amsl.com (Postfix) with ESMTP id 6262A1A70FF for ; Thu, 25 Sep 2014 08:48:25 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BCA26A24AD; Thu, 25 Sep 2014 11:48:24 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 7AA1EA24A4; Thu, 25 Sep 2014 11:48:24 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.143]) by SPQCCAS01.exfo.com ([10.28.36.8]) with mapi id 14.03.0174.001; Thu, 25 Sep 2014 11:48:24 -0400 From: Sharam Hakimi To: "philip.eardley@bt.com" , "bs7652@att.com" , "j.schoenwaelder@jacobs-university.de" , "KEN.KO@adtran.com" Thread-Topic: [lmap] Suppression for a defined duration Thread-Index: Ac/YC730YgiLEI+0RMayR47zYV6eWQAVnwiAAAelqiAACiE8kAALJ8Cg Date: Thu, 25 Sep 2014 15:48:23 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70FEAE54F@SPQCMBX02.exfo.com> References: <20140924214421.GC25390@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E88C75@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1018-20976.000 X-TM-AS-Result: No--28.071-5.0-31-10 X-imss-scan-details: No--28.071-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1018-20976.000 X-TMASE-Result: 10--28.071400-5.000000 X-TMASE-MatchedRID: b/1IsOqez6eZSH3Tfy06xuJ28KqpjndpQKuv8uQBDjoem8EUFBQsJW+t WVFb8XYlwc6bddZ4nC7gQhZ+/b+YqQl2fBUMKi6YzMU0F3CreX6SeMExjuIoEpTBtCYu/UKnp7u eaEkDqTPvKnsLIf24UVjCOvyt3tcryyK9Yq7IZ3JDU5wIS9P5tyEdaywSZvzORUZL9AeG8IIsxF OVdwrYLRVcb4edjreRS0GROPWxCczZPZzVxYdp+f28T9BUNXkhfiuvKi9huabqLnOUXH9QdK4pX Qw6KYDb/o2fyHmC3/FOY1K1NZTCvVkmrXvRXTvgY6Gjtu6/t32AZr6hinmLqvGlFX+1aG8JdP2a Yyh34Msxu9zpPr9ircMLIk61HnMZqE4crEou1w+aVoAi2I40/dJ178I1tpklEB/Asc4oaYEh7+j wjTI7EqDHfH8+tFuXBPC5sAZu8ke5F/6XhVIKVpmug812qIbzwLlnHU0okA39nZJIPtHyFDxrWr g4rigLt2IZ0GyubQKe33T4yJB0OcK8bCqGv6nt6ivQ8oO6nUJ949iT835bWFUnruyX6uBhHHURU 9T9TPfE+xnJKGLUxPr/wDm3k0pdfgWNZg36My/il2r2x2PwtZWr6iSXWtgPW+jwVKpqvlKg0Mwx ckOuOnnspPb1PlIzomfk7xYQGbm77rpLLmM7AqS0tsiuhkCju/1cUrTMg09K1m2DIZ1cs2l5M4v iC1cFwJY6DoKz/m65hk0Luw5dRFX2OObg5VBHnbUZkYTzXIaSTnFzEHOIwRHfiujuTbed82+ZJo KeNOU5qDlhAYEFL7lxRECWghM+Q6tklRJO9ihWdFebWIc3VsRB0bsfrpPI6T/LTDsmJmg= Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/lnGo3wH1oCVIa1Cp-0buOP3DhJA Cc: "trevor.burbridge@bt.com" , "david.j.thorne@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Suppression for a defined duration 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, 25 Sep 2014 15:48:27 -0000 I tend to agree with phil, We have a time to test which means do not test during other times. A time n= ot to test is really not necessary in my opinion. There is also the issue o= f time zones and what MAs in what time zones are under the control of the c= ontroller. A suppress should really mean to stop what was and is scheduled to test at = the time it is issued. If an MA reboots, then by default it needs to get it= s schedule from the controller because it has nothing to do at that point. Sharam=20 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Thursday, September 25, 2014 6:29 AM To: bs7652@att.com; j.schoenwaelder@jacobs-university.de; KEN.KO@adtran.com Cc: trevor.burbridge@bt.com; david.j.thorne@bt.com; lmap@ietf.org Subject: Re: [lmap] Suppression for a defined duration I don't understand what the benefit is, although I don't violently object t= o adding the suppression duration as a field. Is the situation that people are worried about where the device re-boots, t= he internal clock now thinks it's 1970, it now gets a suppress with "start = now, end 26 Sept 2014"? But there's a bigger problem - the instruction has = a start time for measurements, so it would never start measuring anyway. So= the MA has to realise something's wrong and re-set its clock anyway. =09 related topic. If the MA is in suppression and re-boots, it would probably = be nice if it's still in suppression after re-boot. Think this is hard to s= olve with things we define at the IETF - seems device /implementation depen= dent how to handle the issue (after re-boot - maybe the "suppress state" ca= n be in persistent memory, maybe the device assumes its instruction is stal= e and doesn't do any measurements until it's re-contacted the controller, e= tc.) I'd have thought the device /MA's behaviour after re-boot will be cons= istent - it isn't something that the controller will want to regularly alte= r - so don't think this needs to be part of the information model.=20 Phil > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: 24 September 2014 23:23 > To: Juergen Schoenwaelder; KEN KO > Cc: Burbridge,T,Trevor,TUB8 R; Thorne,DJ,David,TUB8 R; lmap@ietf.org > Subject: Re: [lmap] Suppression for a defined duration >=20 > > > During continued WT-304 sessions after our joint workshop last > week, > > > Dave > > Thorne pointed out that the Suppression object needs an optional > field > > for duration of the suppression event. It does of course include > > optional start and stop datetime fields, but those fields are > > dependent on the datetime clocks in all the MAs across the network > > being in reasonably good synchronization. To preclude issues due to > > clocks being out of sync, suppression should be able to specify a > fixed duration. > > > > > > Your thoughts? I've also included Dave in case he wants to chime > in. > > > > > > > I prefer to not add this. Instead, make sure boxes run ntp or > > something like that. The reason is: What happens if a device reboots > > during suppression? In that case, am I expected to be able to > > calculate how long the suppression continues? What if my time > > synchronization changes? Or is the idea that I calculate an absolute > > end time stamp once I receive the suppression and then I still depend > on time synchronization to do the right thing? > > > > I believe we have to trust that boxes have a meaningful notion of > time > > for basically all of the scheduling to work correctly. If clocks are > > unusable for suppression, then they will also be unusable to starting > > tasks at other scheduled times. So there better are NTP synchronized > > clocks. Perhaps we should add an explicit statement about this > somewhere. > > > > /js >=20 > I thought that since it can't be assumed that a device maintains any > aspect of its Instruction when rebooted or power-cycled, that the best > practice procedure would be to re-send suppression to a rebooted > device. Of course, it's probably even less desirable to have the > Controller try to figure out how much of a duration is left in this > case. It's easier for the Controller to just have a static end time. > Also, since it's unlikely that the Controller actually suppresses all > MAs at the same time, it's unlikely that all MAs would start > suppressing at the same time. Duration would cause different ends to > suppression based on when the MA actually got the message. Unless the > Controller is calculating different duration for each device. >=20 > As it relates to ntp, most devices do lose their time configuration > during power cycling, and use a "relative to start-up" time until they > manage to get in touch with their favorite ntp server. Continued > inability to communicate with an ntp server isn't supposed to prevent > proper operation. It just messes with timestamps on logs. But > generally, if there's Internet connectivity that allows communication > with a Controller, then there's communication with an ntp server. And > we've said the MA isn't to do any Measurement Tasks until it registers > with its Controller (so if it's rebooting it has to register before it > does Measurement Tasks). >=20 > Hmm. I'm sort of ambivalent but tending to agree with Juergen. > Barbara >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Sep 25 10:52: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 48D091A0222 for ; Thu, 25 Sep 2014 10:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 sRZIqDDcZBIX for ; Thu, 25 Sep 2014 10:52:45 -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 019361A014F for ; Thu, 25 Sep 2014 10:52:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 68C86716; Thu, 25 Sep 2014 19:52:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id HWI-n5RFzgOV; Thu, 25 Sep 2014 19:52:39 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 25 Sep 2014 19:52:42 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7F6A20036; Thu, 25 Sep 2014 19:52:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QE3aGhZ9FHW8; Thu, 25 Sep 2014 19:52:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBA1820035; Thu, 25 Sep 2014 19:52:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B9D372E9174B; Thu, 25 Sep 2014 19:52:41 +0200 (CEST) Date: Thu, 25 Sep 2014 19:52:41 +0200 From: Juergen Schoenwaelder To: Sharam Hakimi Message-ID: <20140925175241.GB27993@elstar.local> Mail-Followup-To: Sharam Hakimi , "philip.eardley@bt.com" , "bs7652@att.com" , "KEN.KO@adtran.com" , "trevor.burbridge@bt.com" , "david.j.thorne@bt.com" , "lmap@ietf.org" References: <20140924214421.GC25390@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E88C75@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B70FEAE54F@SPQCMBX02.exfo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B70FEAE54F@SPQCMBX02.exfo.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/hwDeCTDjgEKM78HMSSDI7ULoDcs Cc: "lmap@ietf.org" , "philip.eardley@bt.com" , "bs7652@att.com" , "KEN.KO@adtran.com" , "david.j.thorne@bt.com" , "trevor.burbridge@bt.com" Subject: Re: [lmap] Suppression for a defined duration X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 17:52:47 -0000 On Thu, Sep 25, 2014 at 03:48:23PM +0000, Sharam Hakimi wrote: > > If an MA reboots, then by default it needs to get its schedule from > the controller because it has nothing to do at that point. > Really? Is it specified anywhere that all state is ephemeral? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Sep 25 11:44: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 91DB31A87F2 for ; Thu, 25 Sep 2014 11:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 7-ssQYp_NK5E for ; Thu, 25 Sep 2014 11:44:34 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D5C1A882F for ; Thu, 25 Sep 2014 11:44:14 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id f7264245.2b342560e940.2006540.00-2416.5658915.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 25 Sep 2014 18:44:15 +0000 (UTC) X-MXL-Hash: 5424627f20b18aa3-c97ee37589fb27d1144dfb679cc6a3bf8c710e98 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 74264245.0.2005955.00-2271.5657274.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 25 Sep 2014 18:43:20 +0000 (UTC) X-MXL-Hash: 542462484430ea59-5295cd5df4fcc822a6947a5f2a0b2dcd6ce4aaf4 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s8PIhHRc028310; Thu, 25 Sep 2014 14:43:18 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s8PIh9be028191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2014 14:43:12 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 25 Sep 2014 18:42:58 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.240]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 14:42:58 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder , "Sharam Hakimi" Thread-Topic: [lmap] Suppression for a defined duration Thread-Index: Ac/YC730YgiLEI+0RMayR47zYV6eWQAVnwiAAAelqiAACiE8kAALJ8CgAA1EsoAABx2ZgA== Date: Thu, 25 Sep 2014 18:42:57 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130E8954A@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20140924214421.GC25390@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E88C75@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B70FEAE54F@SPQCMBX02.exfo.com> <20140925175241.GB27993@elstar.local> In-Reply-To: <20140925175241.GB27993@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.70.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=eemKic4H c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=qkGUSR0pWxIA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=G2khWl_Df] X-AnalysisOut: [6zVNoox-oMA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/eB7C2MBQSrZ-v3jQnCINViA1UPc Cc: "philip.eardley@bt.com" , "david.j.thorne@bt.com" , "trevor.burbridge@bt.com" , "KEN.KO@adtran.com" , "lmap@ietf.org" Subject: Re: [lmap] Suppression for a defined duration 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, 25 Sep 2014 18:44:35 -0000 > > If an MA reboots, then by default it needs to get its schedule from > > the controller because it has nothing to do at that point. > > >=20 > Really? Is it specified anywhere that all state is ephemeral? >=20 > /js Information-model says: While pre-configuration is persistent upon device reset or power cycle due to its very nature, the persistency of the additional configuration information may be control protocol dependent. Some protocols may assume that reset devices will revert back to their pre-configuration state, while other protocols may assume that all configuration and instruction information is held in persistent storage. Which to me means it may or may not be ephemeral; it is neither required to= be ephemeral, nor is it required to be persistent. I still think the safest way to handle this is for the MA to always call ho= me as part of its start-up procedure and for the Controller to always resen= d suppression (if one is in effect) whenever the MA calls home. But if ther= e is an end-to-suppression time that's known and is to be expressed in the = suppress message, I think a specific time is the best way to do it, so the = Controller isn't maintaining a "remaining duration" counter. I think "remai= ning duration" requires the Controller to have to know too much about that = particular parameter. It would mean the Controller can't just blindly send = the MA exactly what it was told to send the MA. Barbara From nobody Thu Sep 25 12:11: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 8C9841A0319 for ; Thu, 25 Sep 2014 12:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 lFe06Cn9ulUH for ; Thu, 25 Sep 2014 12:11:54 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [199.166.16.238]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7471A02A6 for ; Thu, 25 Sep 2014 12:11:54 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 71265A24AF; Thu, 25 Sep 2014 15:11:53 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 2DC88A24AA; Thu, 25 Sep 2014 15:11:53 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.143]) by SPQCCAS01.exfo.com ([10.28.36.8]) with mapi id 14.03.0174.001; Thu, 25 Sep 2014 15:11:52 -0400 From: Sharam Hakimi To: "STARK, BARBARA H" , Juergen Schoenwaelder Thread-Topic: [lmap] MA state after reset/reboot Thread-Index: AQHP2PSQ2zXP0gN7wkuf0SlBJwg0bQ== Date: Thu, 25 Sep 2014 19:11:52 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70FEAE6E8@SPQCMBX02.exfo.com> References: <20140924214421.GC25390@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E88C75@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B70FEAE54F@SPQCMBX02.exfo.com> <20140925175241.GB27993@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E8954A@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130E8954A@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1018-20976.002 X-TM-AS-Result: No--18.308-5.0-31-10 X-imss-scan-details: No--18.308-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1018-20976.002 X-TMASE-Result: 10--18.308000-5.000000 X-TMASE-MatchedRID: X4bcv0S75KkCfn/FfKnOOKt9n66zJ4RIo5KBmcJozDZD9iPiuXvzgd7j m29XRUF1fFn3reY1lZ8g/GlIw1kqH27tzvY/VhuulGudLLtRO1uL6a+kPOEFsCy+iy880c8JUVH q/AdPDerSyZunbueKNOfJxLsoWsJ8yyK9Yq7IZ3KaVoAi2I40/VPgO2JKQydYCVuEXtlNqcs5Ye ccpVIuKqp8XiOJiRtEEzXK5vGAsQR53oWE6PwjOgz4VsCc1YW+1KoSW5Ji1XtOIo0O+5ZV4TNp2 3JEnavaa033gFWpgbpzbm3g7VRYS7cNmqinIpi4ktny+SMqQ7GbKpAlY2y6ScUmcSma304TKrZB CakLMH9xtFjtYoD7XwlftiGGstuVnc7JlQRQtOOeAiCmPx4NwFsKO+9Zlb5J38LauI2fxt4qtq5 d3cxkNQP90fJP9eHt Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/A57ENAw8TdDffNqXSh-aEn9OG94 Cc: "philip.eardley@bt.com" , "david.j.thorne@bt.com" , "trevor.burbridge@bt.com" , "KEN.KO@adtran.com" , "lmap@ietf.org" Subject: Re: [lmap] MA state after reset/reboot 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, 25 Sep 2014 19:11:55 -0000 If an MA does not reconnect back to the controller after a reset/reboot, it= could miss suppression commands or even updates to its scheduled tasks. Th= is could cause major issues in the network if it does not have the latest u= pdate.=20 Seems like we diverged to another topic. I changed the thread to keep them = separate. Sharam=20 -----Original Message----- From: STARK, BARBARA H [mailto:bs7652@att.com]=20 Sent: Thursday, September 25, 2014 2:43 PM To: Juergen Schoenwaelder; Sharam Hakimi Cc: philip.eardley@bt.com; KEN.KO@adtran.com; trevor.burbridge@bt.com; davi= d.j.thorne@bt.com; lmap@ietf.org Subject: RE: [lmap] Suppression for a defined duration > > If an MA reboots, then by default it needs to get its schedule from > > the controller because it has nothing to do at that point. > > >=20 > Really? Is it specified anywhere that all state is ephemeral? >=20 > /js Information-model says: While pre-configuration is persistent upon device reset or power cycle due to its very nature, the persistency of the additional configuration information may be control protocol dependent. Some protocols may assume that reset devices will revert back to their pre-configuration state, while other protocols may assume that all configuration and instruction information is held in persistent storage. Which to me means it may or may not be ephemeral; it is neither required to= be ephemeral, nor is it required to be persistent. I still think the safest way to handle this is for the MA to always call ho= me as part of its start-up procedure and for the Controller to always resen= d suppression (if one is in effect) whenever the MA calls home. But if ther= e is an end-to-suppression time that's known and is to be expressed in the = suppress message, I think a specific time is the best way to do it, so the = Controller isn't maintaining a "remaining duration" counter. I think "remai= ning duration" requires the Controller to have to know too much about that = particular parameter. It would mean the Controller can't just blindly send = the MA exactly what it was told to send the MA. Barbara From nobody Thu Sep 25 14:07: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 A63AA1A0394 for ; Thu, 25 Sep 2014 14:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 dddmNh_UfBMf for ; Thu, 25 Sep 2014 14:07:31 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46AFE1A0395 for ; Thu, 25 Sep 2014 14:07:31 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 31484245.2b3486409940.2110886.00-2450.5955982.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 25 Sep 2014 21:07:31 +0000 (UTC) X-MXL-Hash: 542484131834bfd5-e30b4304e5640e0b970ad4e49d0e8ef4fb245f40 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id e7384245.0.2109348.00-2266.5951556.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 25 Sep 2014 21:05:03 +0000 (UTC) X-MXL-Hash: 5424837f5354b4be-b309f55f3937c7ed387d8f8ca2c7bf7eb2eff084 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s8PL522a003381; Thu, 25 Sep 2014 17:05:02 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s8PL4rXx003243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2014 17:04:57 -0400 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 25 Sep 2014 21:04:39 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.240]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 17:04:38 -0400 From: "STARK, BARBARA H" To: Sharam Hakimi , Juergen Schoenwaelder Thread-Topic: [lmap] MA state after reset/reboot Thread-Index: AQHP2PSW8GHLV8KBa0O/JqCSs7k72JwSVOkQ Date: Thu, 25 Sep 2014 21:04:38 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130E896F1@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20140924214421.GC25390@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E88C75@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B70FEAE54F@SPQCMBX02.exfo.com> <20140925175241.GB27993@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E8954A@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B70FEAE6E8@SPQCMBX02.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B70FEAE6E8@SPQCMBX02.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.70.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=eemKic4H c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=qkGUSR0pWxIA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=e9qsufxtA] X-AnalysisOut: [AAA:8 a=eJNrpioGAAAA:8 a=48vgC7mUAAAA:8 a=4Ikm5aSdaS3s-2Jl] X-AnalysisOut: [Va4A:9 a=CjuIK1q_8ugA:10 a=Hz7IrDYlS0cA:10 a=W1qU_X6G3J8A:] X-AnalysisOut: [10 a=DvnSUQUdWHYA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/gucn6Zn8_RcZRbGkSj_WZ7TQWL4 Cc: "philip.eardley@bt.com" , "david.j.thorne@bt.com" , "trevor.burbridge@bt.com" , "KEN.KO@adtran.com" , "lmap@ietf.org" Subject: Re: [lmap] MA state after reset/reboot 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, 25 Sep 2014 21:07:32 -0000 > If an MA does not reconnect back to the controller after a reset/reboot, = it > could miss suppression commands or even updates to its scheduled tasks. > This could cause major issues in the network if it does not have the late= st > update. >=20 > Seems like we diverged to another topic. I changed the thread to keep the= m > separate. >=20 > Sharam Yes. But whether an MA does or doesn't is controlled by its Instruction. Ho= w often and when and whether at start-up/reboot it does its "connect to the= Controller" task is all part of the configuration that is specific to the = operator of the Controller. It's very important that we provide the tools necessary to do things right.= It's not necessary that we be a nanny-SDO or create a nanny-standard that = keeps people from doing un-wise things. Barbara>=20 > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Thursday, September 25, 2014 2:43 PM > To: Juergen Schoenwaelder; Sharam Hakimi > Cc: philip.eardley@bt.com; KEN.KO@adtran.com; trevor.burbridge@bt.com; > david.j.thorne@bt.com; lmap@ietf.org > Subject: RE: [lmap] Suppression for a defined duration >=20 > > > If an MA reboots, then by default it needs to get its schedule from > > > the controller because it has nothing to do at that point. > > > > > > > Really? Is it specified anywhere that all state is ephemeral? > > > > /js >=20 > Information-model says: > While pre-configuration is persistent upon device reset or power > cycle due to its very nature, the persistency of the additional > configuration information may be control protocol dependent. Some > protocols may assume that reset devices will revert back to their > pre-configuration state, while other protocols may assume that all > configuration and instruction information is held in persistent > storage. >=20 > Which to me means it may or may not be ephemeral; it is neither required = to > be ephemeral, nor is it required to be persistent. >=20 > I still think the safest way to handle this is for the MA to always call = home as > part of its start-up procedure and for the Controller to always resend > suppression (if one is in effect) whenever the MA calls home. But if ther= e is > an end-to-suppression time that's known and is to be expressed in the > suppress message, I think a specific time is the best way to do it, so th= e > Controller isn't maintaining a "remaining duration" counter. I think "rem= aining > duration" requires the Controller to have to know too much about that > particular parameter. It would mean the Controller can't just blindly sen= d the > MA exactly what it was told to send the MA. > Barbara From nobody Thu Sep 25 14:26: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 3ACDA1A887A for ; Thu, 25 Sep 2014 14:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 VAjOdYkMmUAU for ; Thu, 25 Sep 2014 14:26:46 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [199.166.16.238]) by ietfa.amsl.com (Postfix) with ESMTP id 26DE01A03A9 for ; Thu, 25 Sep 2014 14:26:46 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3F38CA24AB; Thu, 25 Sep 2014 17:26:45 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 04021A24AA; Thu, 25 Sep 2014 17:26:45 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.143]) by SPQCCAS01.exfo.com ([10.28.36.8]) with mapi id 14.03.0174.001; Thu, 25 Sep 2014 17:26:44 -0400 From: Sharam Hakimi To: "STARK, BARBARA H" , Juergen Schoenwaelder Thread-Topic: [lmap] MA state after reset/reboot Thread-Index: AQHP2PSQ2zXP0gN7wkuf0SlBJwg0bZwSmccA///AtiA= Date: Thu, 25 Sep 2014 21:26:43 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70FEAE7BE@SPQCMBX02.exfo.com> References: <20140924214421.GC25390@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E88C75@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B70FEAE54F@SPQCMBX02.exfo.com> <20140925175241.GB27993@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E8954A@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B70FEAE6E8@SPQCMBX02.exfo.com> <2D09D61DDFA73D4C884805CC7865E61130E896F1@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130E896F1@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1018-20976.002 X-TM-AS-Result: No--22.008-5.0-31-10 X-imss-scan-details: No--22.008-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1018-20976.002 X-TMASE-Result: 10--22.008100-5.000000 X-TMASE-MatchedRID: oHOSwQSJZWg14gRk5bRTwWzBijri5+RVXs5nqGvDCfPlY3fh4J0VvuO/ ytE9sHcwfw5L80uEJ61pERktbiwHYKGsRI/FSUgJdOc7KAdVCk5R3sGN+j7mNDOSxJTwHVaVl1T ppRopjE5dI7nSdqcfWe4eVzila0RMX8BypS+/tEPU3m2KoscyC5Z6zKu0q4rtnQqircTOm4fGEf otTZgUJXZal8yijbYUa7FJdd6hE4DUzvcPSorAlHdrwHRqEx+D1KoSW5Ji1Xs5yqWxi+AoVY9KW 4f3sLmA8ZkZbkzMMJFrtCZlDJYIFzXsm0VXt3y/OI8QpSH7EH7RahuPwaQ1Wo1Oeo4wEgnhWBon grY5m56ivMzL14P78dvCQJvMkAdmCnaJFV4XoXaQTsyupo9izZqCl1R34jDP2m/9xxi5QYkErqz pg/UGWgEDWLTBQkhtMCrTXdITryKDBUhj8ZKlOy3CwJVRp8z6fS0Ip2eEHnym8jxRk5/juNRnEQ CUU+jzjoczmuoPCq2UTGVAhB5EbQ== Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/gfIUxHOB7kxbC5HSuFhGirWjHQ4 Cc: "philip.eardley@bt.com" , "david.j.thorne@bt.com" , "trevor.burbridge@bt.com" , "KEN.KO@adtran.com" , "lmap@ietf.org" Subject: Re: [lmap] MA state after reset/reboot 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, 25 Sep 2014 21:26:48 -0000 Barbara, I am not saying that we do not allow the wise/unwise user to control their = destiny. I was suggesting that default state should have the MA check back = with the controller after reboot/reset. I believe that We have to have a de= fault state for this. Sharam -----Original Message----- From: STARK, BARBARA H [mailto:bs7652@att.com]=20 Sent: Thursday, September 25, 2014 5:05 PM To: Sharam Hakimi; Juergen Schoenwaelder Cc: philip.eardley@bt.com; KEN.KO@adtran.com; trevor.burbridge@bt.com; davi= d.j.thorne@bt.com; lmap@ietf.org Subject: RE: [lmap] MA state after reset/reboot > If an MA does not reconnect back to the controller after a reset/reboot, = it > could miss suppression commands or even updates to its scheduled tasks. > This could cause major issues in the network if it does not have the late= st > update. >=20 > Seems like we diverged to another topic. I changed the thread to keep the= m > separate. >=20 > Sharam Yes. But whether an MA does or doesn't is controlled by its Instruction. Ho= w often and when and whether at start-up/reboot it does its "connect to the= Controller" task is all part of the configuration that is specific to the = operator of the Controller. It's very important that we provide the tools necessary to do things right.= It's not necessary that we be a nanny-SDO or create a nanny-standard that = keeps people from doing un-wise things. Barbara>=20 > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Thursday, September 25, 2014 2:43 PM > To: Juergen Schoenwaelder; Sharam Hakimi > Cc: philip.eardley@bt.com; KEN.KO@adtran.com; trevor.burbridge@bt.com; > david.j.thorne@bt.com; lmap@ietf.org > Subject: RE: [lmap] Suppression for a defined duration >=20 > > > If an MA reboots, then by default it needs to get its schedule from > > > the controller because it has nothing to do at that point. > > > > > > > Really? Is it specified anywhere that all state is ephemeral? > > > > /js >=20 > Information-model says: > While pre-configuration is persistent upon device reset or power > cycle due to its very nature, the persistency of the additional > configuration information may be control protocol dependent. Some > protocols may assume that reset devices will revert back to their > pre-configuration state, while other protocols may assume that all > configuration and instruction information is held in persistent > storage. >=20 > Which to me means it may or may not be ephemeral; it is neither required = to > be ephemeral, nor is it required to be persistent. >=20 > I still think the safest way to handle this is for the MA to always call = home as > part of its start-up procedure and for the Controller to always resend > suppression (if one is in effect) whenever the MA calls home. But if ther= e is > an end-to-suppression time that's known and is to be expressed in the > suppress message, I think a specific time is the best way to do it, so th= e > Controller isn't maintaining a "remaining duration" counter. I think "rem= aining > duration" requires the Controller to have to know too much about that > particular parameter. It would mean the Controller can't just blindly sen= d the > MA exactly what it was told to send the MA. > Barbara From nobody Fri Sep 26 06:59:46 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 416A81A6FC7 for ; Fri, 26 Sep 2014 06:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 TpSbAwVjdoDh for ; Fri, 26 Sep 2014 06:59:43 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2DF1A87D4 for ; Fri, 26 Sep 2014 06:59:43 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id f4175245.2b5feea70940.2470845.00-2488.6949375.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 26 Sep 2014 13:59:43 +0000 (UTC) X-MXL-Hash: 5425714f411f02db-6c04ece43761ada109103b329617e889afd633c2 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 17f65245.0.2465912.00-2356.6935320.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 26 Sep 2014 13:51:46 +0000 (UTC) X-MXL-Hash: 54256f722736f59e-7bb94844f4cb779457bc620bdec0c52b3bfa66c6 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s8QDpiYV008575; Fri, 26 Sep 2014 09:51:45 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s8QDpcwM008415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2014 09:51:43 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 26 Sep 2014 13:51:26 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.240]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 09:51:25 -0400 From: "STARK, BARBARA H" To: Sharam Hakimi , Juergen Schoenwaelder Thread-Topic: [lmap] MA state after reset/reboot Thread-Index: AQHP2PSW8GHLV8KBa0O/JqCSs7k72JwSVOkQgABLCYCAAMr+UA== Date: Fri, 26 Sep 2014 13:51:26 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130E89B6D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20140924214421.GC25390@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E88C75@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B70FEAE54F@SPQCMBX02.exfo.com> <20140925175241.GB27993@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E8954A@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B70FEAE6E8@SPQCMBX02.exfo.com> <2D09D61DDFA73D4C884805CC7865E61130E896F1@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B70FEAE7BE@SPQCMBX02.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B70FEAE7BE@SPQCMBX02.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.34.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=LIzRtuq9 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=vI5bsOgWt84A:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=e9qsufxtA] X-AnalysisOut: [AAA:8 a=eJNrpioGAAAA:8 a=48vgC7mUAAAA:8 a=vT81Rik6U_Bqot5w] X-AnalysisOut: [6HsA:9 a=CjuIK1q_8ugA:10 a=Hz7IrDYlS0cA:10 a=W1qU_X6G3J8A:] X-AnalysisOut: [10 a=DvnSUQUdWHYA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/c0RUvMHIXzrWaxD4qSTGmH-78Rg Cc: "philip.eardley@bt.com" , "david.j.thorne@bt.com" , "trevor.burbridge@bt.com" , "KEN.KO@adtran.com" , "lmap@ietf.org" Subject: Re: [lmap] MA state after reset/reboot X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 13:59:45 -0000 > Barbara, > I am not saying that we do not allow the wise/unwise user to control thei= r > destiny. I was suggesting that default state should have the MA check bac= k > with the controller after reboot/reset. I believe that We have to have a > default state for this. >=20 > Sharam I disagree.=20 1. The "default" schedule is determined by pre-configuration. Pre-configura= tion may be done as "factory default", via a management protocol, user inte= rface, etc. (the nebulous bootstrap mechanism). I learned long ago that try= ing to define unnecessary globally-applicable defaults for higher layer stu= ff like this was a bad idea. Vendors and providers readily ignore such defa= ult recommendations whenever it suits their purposes, and there are rarely = interoperability or other dire consequences when they do. Most are competen= t enough to figure out for themselves how to properly pre-configure their d= evices. The ones that aren't competent are eligible for Darwin awards. 2. The desired behavior is protocol-dependent. I think the current text in information-model has the right level of detail= : Where the MA pulls information from the Controller, the Pre- Configuration Information also needs to contain the timing of the communication with the Controller as well as the nature of the communication itself (such as the protocol and data to be transferred). The timing is given as a Schedule that executes the Task(s) responsible for communication with the Controller. It is this Task (or Tasks) that implement the Control protocol between the MA and the Controller. The Task(s) may take additional parameters in which case a Task Configuration can also be included. Even where information is pushed to the MA from the Controller (rather than pulled by the MA), a Schedule still needs to be supplied. In this case the Schedule will simply execute a Controller listener task when the MA is started. A Channel is still required for the MA to establish secure communication with the Controller. Barbara =20 > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Thursday, September 25, 2014 5:05 PM > To: Sharam Hakimi; Juergen Schoenwaelder > Cc: philip.eardley@bt.com; KEN.KO@adtran.com; trevor.burbridge@bt.com; > david.j.thorne@bt.com; lmap@ietf.org > Subject: RE: [lmap] MA state after reset/reboot >=20 > > If an MA does not reconnect back to the controller after a > > reset/reboot, it could miss suppression commands or even updates to its > scheduled tasks. > > This could cause major issues in the network if it does not have the > > latest update. > > > > Seems like we diverged to another topic. I changed the thread to keep > > them separate. > > > > Sharam >=20 > Yes. But whether an MA does or doesn't is controlled by its Instruction. = How > often and when and whether at start-up/reboot it does its "connect to the > Controller" task is all part of the configuration that is specific to the= operator > of the Controller. >=20 > It's very important that we provide the tools necessary to do things righ= t. It's > not necessary that we be a nanny-SDO or create a nanny-standard that > keeps people from doing un-wise things. > Barbara> >=20 > > -----Original Message----- > > From: STARK, BARBARA H [mailto:bs7652@att.com] > > Sent: Thursday, September 25, 2014 2:43 PM > > To: Juergen Schoenwaelder; Sharam Hakimi > > Cc: philip.eardley@bt.com; KEN.KO@adtran.com; > trevor.burbridge@bt.com; > > david.j.thorne@bt.com; lmap@ietf.org > > Subject: RE: [lmap] Suppression for a defined duration > > > > > > If an MA reboots, then by default it needs to get its schedule > > > > from the controller because it has nothing to do at that point. > > > > > > > > > > Really? Is it specified anywhere that all state is ephemeral? > > > > > > /js > > > > Information-model says: > > While pre-configuration is persistent upon device reset or power > > cycle due to its very nature, the persistency of the additional > > configuration information may be control protocol dependent. Some > > protocols may assume that reset devices will revert back to their > > pre-configuration state, while other protocols may assume that all > > configuration and instruction information is held in persistent > > storage. > > > > Which to me means it may or may not be ephemeral; it is neither > > required to be ephemeral, nor is it required to be persistent. > > > > I still think the safest way to handle this is for the MA to always > > call home as part of its start-up procedure and for the Controller to > > always resend suppression (if one is in effect) whenever the MA calls > > home. But if there is an end-to-suppression time that's known and is > > to be expressed in the suppress message, I think a specific time is > > the best way to do it, so the Controller isn't maintaining a > > "remaining duration" counter. I think "remaining duration" requires > > the Controller to have to know too much about that particular > > parameter. It would mean the Controller can't just blindly send the MA > exactly what it was told to send the MA. > > Barbara From nobody Fri Sep 26 09:37: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 B24A21A8A88 for ; Fri, 26 Sep 2014 09:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 V8zgMKDi8DwT for ; Fri, 26 Sep 2014 09:37:10 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [199.166.16.238]) by ietfa.amsl.com (Postfix) with ESMTP id 0067E1A8A92 for ; Fri, 26 Sep 2014 09:36:52 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 24F7AA24DD; Fri, 26 Sep 2014 12:36:52 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id D2005A24D8; Fri, 26 Sep 2014 12:36:51 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.143]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Fri, 26 Sep 2014 12:36:51 -0400 From: Sharam Hakimi To: "STARK, BARBARA H" , Juergen Schoenwaelder Thread-Topic: [lmap] MA state after reset/reboot Thread-Index: AQHP2PSQ2zXP0gN7wkuf0SlBJwg0bZwSmccA///AtiCAAViWAP//5xvQ Date: Fri, 26 Sep 2014 16:36:51 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70FEAEB5B@SPQCMBX02.exfo.com> References: <20140924214421.GC25390@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E88C75@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B70FEAE54F@SPQCMBX02.exfo.com> <20140925175241.GB27993@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130E8954A@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B70FEAE6E8@SPQCMBX02.exfo.com> <2D09D61DDFA73D4C884805CC7865E61130E896F1@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B70FEAE7BE@SPQCMBX02.exfo.com> <2D09D61DDFA73D4C884805CC7865E61130E89B6D@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130E89B6D@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1018-20976.006 X-TM-AS-Result: No--28.001-5.0-31-10 X-imss-scan-details: No--28.001-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1018-20976.006 X-TMASE-Result: 10--28.001400-5.000000 X-TMASE-MatchedRID: IDdx3MBO6EA14gRk5bRTwUhEDfw/93BuyeUl7aCTy8jxxaAXDrCns3/s DLdkieHypS+ppf4aK3l36j1DqLiz4sFeWQ9rEC3VSHCU59h5KrEIjen4m7yaqk4K0IMk2m3Gk8h XlB6VKy3weU23Zzx/pURkz6Z0F4pZoB+xacuTKy37NyIwHnhtdxtPDNiPbNC6NAvA6fJJE7W5nY r+rIak1m0ddGA3I8RGqTP2jzHAK21tS5L7Qk43V7dQIb8hCnY+guwtqyXlE6FrEoFtNYg0C5PU+ 67ZzHnC0JQiyAYRtPEpW5WIjBhq2E9yJAiyTb0L8MLN9e5BfRbkZG6efts4UIKwF4K/wIz99P9h BP3swlCrcA4Rr4tU+DBRxgXv6s5qEixF6+4ewSDzh2yKdnl7WClayzmQ9QV0HF5gWd5iOUmLZFT 8IXHexd4i9KLmxagJe712glgbcbQg75kom1bQDZpWgCLYjjT9JFqxHS9Lk0l94HxmQFPHyz4hXW 7B+PPhhvkZrH51PXvob70i7p0XgvVgCcrBliQMsaPcs3T4TL0sCc2iFTIxraTsE8Z/jrr+ZwKfT 86BI+EsGXhPFcB9DG60MM1T0J7ZzMuituH4rKtpR7+L0B6mEyDPOgHqOrGCTiKNDvuWVeEISTZB wG8Oqv5U774GRiCDRq0wjiD0NCHVFtf7bVfns0+4wmL9kCTxgGa+oYp5i6oApcWP0ORPeKPFjJE Fr+ol4Z/vCGGy3v6nmxwscwVeE90H8LFZNFG7JQhrLH5KSJ0= Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/kF6i51k1NbfGjFLBMw1w8NhiY-4 Cc: "philip.eardley@bt.com" , "david.j.thorne@bt.com" , "trevor.burbridge@bt.com" , "KEN.KO@adtran.com" , "lmap@ietf.org" Subject: Re: [lmap] MA state after reset/reboot X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 16:37:13 -0000 Barbara, There are two issues here: 1- the default configuration 2- The default state of the variable that tells the MA what to do after res= et/reboot. I agree that a default configuration can be pre programmed by the user(ISP)= and the state of the variable that tells the MA what it should do after re= set/reboot would need to have changed to "use internal configuration" The default state of the variable that tells the MA what to do after reset/= reboot should default to "Check with the MC". Having the MA to revert back to pre configured task configuration has the d= anger of not heeding to a suppress command that was issued before the reset= /reboot, but that is for the user to determine. Thanks, Sharam -----Original Message----- From: STARK, BARBARA H [mailto:bs7652@att.com]=20 Sent: Friday, September 26, 2014 9:51 AM To: Sharam Hakimi; Juergen Schoenwaelder Cc: philip.eardley@bt.com; KEN.KO@adtran.com; trevor.burbridge@bt.com; davi= d.j.thorne@bt.com; lmap@ietf.org Subject: RE: [lmap] MA state after reset/reboot > Barbara, > I am not saying that we do not allow the wise/unwise user to control thei= r > destiny. I was suggesting that default state should have the MA check bac= k > with the controller after reboot/reset. I believe that We have to have a > default state for this. >=20 > Sharam I disagree.=20 1. The "default" schedule is determined by pre-configuration. Pre-configura= tion may be done as "factory default", via a management protocol, user inte= rface, etc. (the nebulous bootstrap mechanism). I learned long ago that try= ing to define unnecessary globally-applicable defaults for higher layer stu= ff like this was a bad idea. Vendors and providers readily ignore such defa= ult recommendations whenever it suits their purposes, and there are rarely = interoperability or other dire consequences when they do. Most are competen= t enough to figure out for themselves how to properly pre-configure their d= evices. The ones that aren't competent are eligible for Darwin awards. 2. The desired behavior is protocol-dependent. I think the current text in information-model has the right level of detail= : Where the MA pulls information from the Controller, the Pre- Configuration Information also needs to contain the timing of the communication with the Controller as well as the nature of the communication itself (such as the protocol and data to be transferred). The timing is given as a Schedule that executes the Task(s) responsible for communication with the Controller. It is this Task (or Tasks) that implement the Control protocol between the MA and the Controller. The Task(s) may take additional parameters in which case a Task Configuration can also be included. Even where information is pushed to the MA from the Controller (rather than pulled by the MA), a Schedule still needs to be supplied. In this case the Schedule will simply execute a Controller listener task when the MA is started. A Channel is still required for the MA to establish secure communication with the Controller. Barbara =20 > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Thursday, September 25, 2014 5:05 PM > To: Sharam Hakimi; Juergen Schoenwaelder > Cc: philip.eardley@bt.com; KEN.KO@adtran.com; trevor.burbridge@bt.com; > david.j.thorne@bt.com; lmap@ietf.org > Subject: RE: [lmap] MA state after reset/reboot >=20 > > If an MA does not reconnect back to the controller after a > > reset/reboot, it could miss suppression commands or even updates to its > scheduled tasks. > > This could cause major issues in the network if it does not have the > > latest update. > > > > Seems like we diverged to another topic. I changed the thread to keep > > them separate. > > > > Sharam >=20 > Yes. But whether an MA does or doesn't is controlled by its Instruction. = How > often and when and whether at start-up/reboot it does its "connect to the > Controller" task is all part of the configuration that is specific to the= operator > of the Controller. >=20 > It's very important that we provide the tools necessary to do things righ= t. It's > not necessary that we be a nanny-SDO or create a nanny-standard that > keeps people from doing un-wise things. > Barbara> >=20 > > -----Original Message----- > > From: STARK, BARBARA H [mailto:bs7652@att.com] > > Sent: Thursday, September 25, 2014 2:43 PM > > To: Juergen Schoenwaelder; Sharam Hakimi > > Cc: philip.eardley@bt.com; KEN.KO@adtran.com; > trevor.burbridge@bt.com; > > david.j.thorne@bt.com; lmap@ietf.org > > Subject: RE: [lmap] Suppression for a defined duration > > > > > > If an MA reboots, then by default it needs to get its schedule > > > > from the controller because it has nothing to do at that point. > > > > > > > > > > Really? Is it specified anywhere that all state is ephemeral? > > > > > > /js > > > > Information-model says: > > While pre-configuration is persistent upon device reset or power > > cycle due to its very nature, the persistency of the additional > > configuration information may be control protocol dependent. Some > > protocols may assume that reset devices will revert back to their > > pre-configuration state, while other protocols may assume that all > > configuration and instruction information is held in persistent > > storage. > > > > Which to me means it may or may not be ephemeral; it is neither > > required to be ephemeral, nor is it required to be persistent. > > > > I still think the safest way to handle this is for the MA to always > > call home as part of its start-up procedure and for the Controller to > > always resend suppression (if one is in effect) whenever the MA calls > > home. But if there is an end-to-suppression time that's known and is > > to be expressed in the suppress message, I think a specific time is > > the best way to do it, so the Controller isn't maintaining a > > "remaining duration" counter. I think "remaining duration" requires > > the Controller to have to know too much about that particular > > parameter. It would mean the Controller can't just blindly send the MA > exactly what it was told to send the MA. > > Barbara From nobody Sun Sep 28 13:20:14 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 83A951A1BEB for ; Sun, 28 Sep 2014 13:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.685 X-Spam-Level: X-Spam-Status: No, score=-7.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] 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 Ls97MOLl_rJh for ; Sun, 28 Sep 2014 13:20:07 -0700 (PDT) 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 F3EB61A1BE9 for ; Sun, 28 Sep 2014 13:20:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcNAAltKFSHCzIm/2dsb2JhbABggkgjI1NbthEGm0kCexYBAXEJhAUBAQMSCxBeAQwJFVYmAQQbGogcAZoihGygFoYSiVuDZoEdBZFlkz6NYoNjgjSBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,615,1406606400"; d="scan'208,217"; a="73896486" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Sep 2014 16:19:55 -0400 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; 28 Sep 2014 16:19:53 -0400 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, 28 Sep 2014 22:19:52 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: IETF 91: call for agenda items Thread-Index: Ac/bWY7HzxXyycm1Rd+Joeee9HSe7w== Date: Sun, 28 Sep 2014 20:19:51 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8AF7D6@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_9904FB1B0159DA42B0B887B7FA8119CA5C8AF7D6AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/evUEaRE2tdkTLJ2jHTMaltcygqA Subject: [lmap] IETF 91: call for agenda items X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 20:20:12 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8AF7D6AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have entered a request for a meeting at IETF 91, same duration as at IET= F 90. Please send your requests and proposals for the agenda. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8AF7D6AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have entered a request for a meeting at IETF 91, = same duration as at IETF 90.

 

Please send your requests and proposals for the agen= da.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8AF7D6AZFFEXMB04globa_--