From nobody Tue Sep 1 04:20:01 2015 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 9987F1B4239 for ; Tue, 1 Sep 2015 04:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G76nfupX6N49 for ; Tue, 1 Sep 2015 04:19:58 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628631B6550 for ; Tue, 1 Sep 2015 04:19:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CZAgA2ieVV/xUHmMZaAxkBAQGCUyxUaQaDHbsKAQmBd4V7AhyBGTgUAQEBAQEBAYEKhCMBAQEBAxIREToLDAICAgEIDQECAQQBAQECAgYdAwICAhkXFAEHAQgCBA4FCBqIDAEMp2OKV5UWAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSBHoVVhHmEWhYLEAcGDIJXL4EUBYcrjhYBhQaJOEaDbIMTjXGDbBcPg39xAYFHgQUBAQE X-IPAS-Result: A2CZAgA2ieVV/xUHmMZaAxkBAQGCUyxUaQaDHbsKAQmBd4V7AhyBGTgUAQEBAQEBAYEKhCMBAQEBAxIREToLDAICAgEIDQECAQQBAQECAgYdAwICAhkXFAEHAQgCBA4FCBqIDAEMp2OKV5UWAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSBHoVVhHmEWhYLEAcGDIJXL4EUBYcrjhYBhQaJOEaDbIMTjXGDbBcPg39xAYFHgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,448,1437451200"; d="scan'208";a="133931048" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Sep 2015 07:19:57 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 01 Sep 2015 07:19:56 -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; Tue, 1 Sep 2015 13:19:55 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [lmap] FW: IETF 94 - Working Group/BOF/IRTF Scheduling Thread-Index: AQHQ3wtPTR6q9teFlEaRcijXYp7eYp4nkbHg Date: Tue, 1 Sep 2015 11:19:54 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB09A47@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CAFF744@AZ-FFEXMB04.global.avaya.com> <20150825075434.GC81550@elstar.local> In-Reply-To: <20150825075434.GC81550@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] FW: IETF 94 - Working Group/BOF/IRTF Scheduling 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, 01 Sep 2015 11:20:00 -0000 SGkgSnVlcmdlbiwNCg0KU29ycnkgZm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlICh2YWNhdGlvbiBl eGN1c2UpIGFuZCB0aGFua3MgZm9yIGxldHRpbmcgdXMga25vdyBhYm91dCB5b3VyIHNjaGVkdWxl LiBXZSdsbCB0cnkgdG8gYWNjb21tb2RhdGUgeW91ciByZXF1ZXN0IGFuZCBhc2sgZm9yIHJlbW90 ZSBwYXJ0aWNpcGF0aW9uIGZhY2lsaXRpZXMuIA0KDQpSZWdhcmRzLA0KDQpEYW4NCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBb bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtDQo+IHVuaXZlcnNpdHkuZGVdDQo+IFNlbnQ6 IFR1ZXNkYXksIEF1Z3VzdCAyNSwgMjAxNSAxMDo1NSBBTQ0KPiBUbzogUm9tYXNjYW51LCBEYW4g KERhbikNCj4gQ2M6IGxtYXBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtsbWFwXSBGVzogSUVU RiA5NCAtIFdvcmtpbmcgR3JvdXAvQk9GL0lSVEYgU2NoZWR1bGluZw0KPiANCj4gRGFuLA0KPiAN Cj4gSSBhbSBiYWNrIGZyb20gdmFjYXRpb24gYW5kIEkgaG9wZSB0byBmaW5kIHRpbWUgdG8gbG9v ayBhdCB0aGUgTE1BUCBpc3N1ZXMgaW4NCj4gdGhlIGNvbWluZyBkYXlzLiBSZWdhcmRpbmcgdGhl IExNQVAgbWVldGluZyBhdCBJRVRGIDk0LCBJIG5lZWQgdG8gbGV0IHlvdQ0KPiBrbm93IHRoYXQg SSBkbyBub3QgcGxhbiB0byB0cmF2ZWwgdG8gSmFwYW4uDQo+IA0KPiBGb3IgcmVtb3RlIHBhcnRp Y2lwYXRpb24gZnJvbSBFdXJvcGUsIGl0IHdvdWxkIGhlbHAgaWYgdGhlIG1lZXRpbmcgaXMNCj4g c2NoZWR1bGVkIGluIHRoZSBsYXRlIGFmdGVybm9vbiAoWW9rb2hhbWEgdGltZSkgYW5kIGl0IHdv dWxkIGJlIG5pY2UgdG8NCj4gYXZvaWQgVGh1cnNkYXkgYW5kIEZyaWRheSBsYXRlIGFmdGVybm9v biAoc2luY2UgSSBoYXZlIHRlYWNoaW5nIG9ibGlnYXRpb25zDQo+IG9uIGJvdGggZGF5cyAtIHdl bGwgRnJpZGF5IGFmdGVybm9vbiBkb2VzIG5vdCBtYXR0ZXIgSUVURiB3aXNlIEkgZ3Vlc3MpLiBJ IGRvDQo+IG5vdCBrbm93IGlmIHlvdSBhbHNvIGhhdmUgdG8gYWNjb21vZGF0ZSByZW1vdGUgcGFy dGljaXBhbnRzIGZyb20gb3RoZXINCj4gcmVnaW9ucyBvZiB0aGUgd29ybGQuDQo+IA0KPiAvanMN Cj4gDQo+IE9uIFdlZCwgQXVnIDE5LCAyMDE1IGF0IDA0OjM3OjEzUE0gKzAwMDAsIFJvbWFzY2Fu dSwgRGFuIChEYW4pIHdyb3RlOg0KPiA+IEl0J3MgdGltZSB0byByZXF1ZXN0IG1lZXRpbmcgc2xv dHMgZm9yIElFVEYgOTQuDQo+ID4NCj4gPiBGb3IgdGhlIGxhc3QgZmV3IG1lZXRpbmdzIHdlIGFz a2VkIGZvciBvbmUgMiBvciAyLjUgaG91cnMgbWVldGluZyBzbG90Lg0KPiBTaG91bGQgd2UgZG8g dGhlIHNhbWUgZm9yIElFVEYgOTQ/IEFueSBwcmVmZXJlbmNlcyBjb25jZXJuaW5nIHRoZSBtZWV0 aW5nDQo+IGRheT8gQW55IG5ldyBjb25mbGljdHM/DQo+ID4NCj4gPiBUaGFua3MgYW5kIFJlZ2Fy ZHMsDQo+ID4NCj4gPiBEYW4NCj4gPg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+ID4gRnJvbTogV0dDaGFpcnMgW21haWx0bzp3Z2NoYWlycy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSUVURg0KPiA+ID4gQWdlbmRhDQo+ID4gPiBTZW50OiBUdWVzZGF5 LCBBdWd1c3QgMDQsIDIwMTUgMjozNiBBTQ0KPiA+ID4gVG86IFdvcmtpbmcgR3JvdXAgQ2hhaXJz DQo+ID4gPiBDYzogaXJzZ0BpcnRmLm9yZw0KPiA+ID4gU3ViamVjdDogSUVURiA5NCAtIFdvcmtp bmcgR3JvdXAvQk9GL0lSVEYgU2NoZWR1bGluZw0KPiA+ID4NCj4gPiA+DQo+ID4gPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+ID4gSUVURiA5NCDigJMgWW9rb2hhbWEsIEphcGFuDQo+ID4gPiBNZWV0aW5nIERhdGVz OiBOb3ZlbWJlciAxLTYsIDIwMTUNCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPg0KPiA+ID4gV2UgYXJl IGFjY2VwdGluZyBzY2hlZHVsaW5nIHJlcXVlc3RzIGZvciBhbGwgV29ya2luZyBHcm91cHMsIEJP RnMsDQo+ID4gPiBhbmQgUmVzZWFyY2ggR3JvdXBzIHN0YXJ0aW5nIHRvZGF5Lg0KPiA+ID4NCj4g PiA+IFRoZSBtaWxlc3RvbmVzIGFuZCBkZWFkbGluZXMgZm9yIHNjaGVkdWxpbmctcmVsYXRlZCBh Y3Rpdml0aWVzIGFyZSBhcw0KPiBmb2xsb3dzOg0KPiA+ID4gQ3V0LW9mZiBkYXRlcyBhcmUgc3Vi amVjdCB0byBjaGFuZ2UuDQo+ID4gPg0KPiA+ID4g4oCiCTIwMTUtMDgtMDMgKE1vbmRheSk6IFdv cmtpbmcgR3JvdXAgYW5kIEJPRiBzY2hlZHVsaW5nIGJlZ2lucy4gVG8NCj4gPiA+IHJlcXVlc3Qg YSBXb3JraW5nIEdyb3VwIHNlc3Npb24sIHVzZSB0aGUgSUVURiBNZWV0aW5nIFNlc3Npb24NCj4g PiA+IFJlcXVlc3QgVG9vbC4NCj4gPiA+IOKAogkyMDE1LTA5LTE4IChGcmlkYXkpOiBDdXQtb2Zm IGRhdGUgZm9yIHJlcXVlc3RzIHRvIHNjaGVkdWxlIFdvcmtpbmcNCj4gPiA+IEdyb3VwIG1lZXRp bmdzIGF0IFVUQyAyMzo1OS4gVG8gcmVxdWVzdCBhIFdvcmtpbmcgR3JvdXAgc2Vzc2lvbiwgdXNl DQo+ID4gPiB0aGUgSUVURiBNZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBUb29sLg0KPiA+ID4g4oCi CTIwMTUtMDktMTggKEZyaWRheSk6IEN1dC1vZmYgZGF0ZSBmb3IgQk9GIHByb3Bvc2FsIHJlcXVl c3RzIHRvIEFyZWENCj4gPiA+IERpcmVjdG9ycyBhdCBVVEMgMjM6NTkuIFRvIHJlcXVlc3QgYSBC T0YsIHBsZWFzZSBzZWUgaW5zdHJ1Y3Rpb25zIG9uDQo+ID4gPiBSZXF1ZXN0aW5nIGEgQk9GLg0K PiA+ID4g4oCiCTIwMTUtMDktMjUgKEZyaWRheSk6IEN1dC1vZmYgZGF0ZSBmb3IgQXJlYSBEaXJl Y3RvcnMgdG8gYXBwcm92ZSBCT0ZzDQo+ID4gPiBhdCBVVEMgMjM6NTkuDQo+ID4gPiDigKIJMjAx NS0xMC0wMiAoRnJpZGF5KTogUHJlbGltaW5hcnkgYWdlbmRhIHB1Ymxpc2hlZCBmb3IgY29tbWVu dC4NCj4gPiA+IOKAogkyMDE1LTEwLTA3IChXZWRuZXNkYXkpOiBDdXQtb2ZmIGRhdGUgZm9yIHJl cXVlc3RzIHRvIHJlc2NoZWR1bGUNCj4gPiA+IFdvcmtpbmcgR3JvdXAgYW5kIEJPRiBtZWV0aW5n cyBVVEMgMjM6NTkuDQo+ID4gPiDigKIJMjAxNS0xMC0wOSAoRnJpZGF5KTogRmluYWwgYWdlbmRh IHRvIGJlIHB1Ymxpc2hlZC4NCj4gPiA+IOKAogkyMDE1LTEwLTE5IChNb25kYXkpOiBEcmFmdCBX b3JraW5nIEdyb3VwIGFnZW5kYXMgZHVlIGJ5IFVUQw0KPiA+ID4gMjM6NTksIHVwbG9hZCB1c2lu ZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9vbC4NCj4gPiA+IOKAogkyMDE1 LTEwLTI2IChNb25kYXkpOiBSZXZpc2VkIFdvcmtpbmcgR3JvdXAgYWdlbmRhcyBkdWUgYnkgVVRD DQo+ID4gPiAyMzo1OSwgdXBsb2FkIHVzaW5nIElFVEYgTWVldGluZyBNYXRlcmlhbHMgTWFuYWdl bWVudCBUb29sLg0KPiA+ID4g4oCiCTIwMTUtMTItMDQgKEZyaWRheSk6IFByb2NlZWRpbmdzIHN1 Ym1pc3Npb24gY3V0b2ZmIGRhdGUgYnkgVVRDDQo+ID4gPiAyMzo1OSwgdXBsb2FkIHVzaW5nIElF VEYgTWVldGluZyBNYXRlcmlhbHMgTWFuYWdlbWVudCBUb29sLg0KPiA+ID4g4oCiCTIwMTUtMTIt MjEgKE1vbmRheSk6IFByb2NlZWRpbmdzIHN1Ym1pc3Npb24gY29ycmVjdGlvbnMgY3V0b2ZmDQo+ ID4gPiBkYXRlIGJ5IFVUQyAyMzo1OSwgdXBsb2FkIHVzaW5nIElFVEYgTWVldGluZyBNYXRlcmlh bHMgTWFuYWdlbWVudA0KPiBUb29sLg0KPiA+ID4NCj4gPiA+DQo+ID4NCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGxtYXAgbWFpbGluZyBs aXN0DQo+ID4gbG1hcEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsDQo+ID4NCj4gbWFu X2xpc3RpbmZvX2xtYXAmZD1CUUlEYVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9STRkekd4 UjMxDQo+IE9jTlhDSmYNCj4gPg0KPiBRenZsc2lMUWZ1Y0JYUnVjUHZkcnBocEJzRkEmbT16a0w4 WkZ2NTZINUlsSXFwQjZPQzBXWF9kN203WXVGN1QxDQo+IDR6TzJTSQ0KPiA+IHdmOCZzPWlrTU5I V0NXUW5BRFA3WFA2NjZRNXdIMnhlQ3lYSlpUam5OTmVoME91ZlEmZT0NCj4gDQo+IC0tDQo+IEp1 ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdH bWJIDQo+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4 NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMNCj4gPGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuamFjb2Jz LQ0KPiAyRHVuaXZlcnNpdHkuZGVfJmQ9QlFJRGFRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZy PUk0ZHpHeFIzMU8NCj4gY05YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09emtMOFpG djU2SDVJbElxcEI2T0MwV1hfZDdtNw0KPiBZdUY3VDE0ek8yU0l3Zjgmcz1xdjJHQ1laanZpYXZ0 RkdqQkF6bndEXzN0ZVpINzFaMmF5ZlBMME0xTXF3Jg0KPiBlPSA+DQo= From nobody Thu Sep 3 08:36:18 2015 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 F3A141B32DF for ; Thu, 3 Sep 2015 08:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ql-Id24N1ui for ; Thu, 3 Sep 2015 08:36:14 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0215C1ACDA5 for ; Thu, 3 Sep 2015 08:36:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CLAgC9Z+hV/yYyC4ddGQEBglQsgT0Ggx66MwEJh3ICHIEWOBQBAQEBAQEBfwuEIwEBAQEDEhERUQQCAQgNBAQBAQMCBh0DAgICMBQBBgEBBQMCBBMIGogMAaw+ileUWAEBAQEBBQEBAQEBAQEbgSKFU4R5hFo4BoJjL4EUBYcyhUaIWQGOQIQygxOGA4tdJoQAcYhHgQUBAQE X-IPAS-Result: A2CLAgC9Z+hV/yYyC4ddGQEBglQsgT0Ggx66MwEJh3ICHIEWOBQBAQEBAQEBfwuEIwEBAQEDEhERUQQCAQgNBAQBAQMCBh0DAgICMBQBBgEBBQMCBBMIGogMAaw+ileUWAEBAQEBBQEBAQEBAQEbgSKFU4R5hFo4BoJjL4EUBYcyhUaIWQGOQIQygxOGA4tdJoQAcYhHgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,462,1437451200"; d="scan'208";a="134341596" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Sep 2015 11:36:12 -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; 03 Sep 2015 11:36: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; Thu, 3 Sep 2015 11:36:10 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: lmap - New Meeting Session Request for IETF 94 Thread-Index: AQHQ5l21YMCsE3Yt60eKWUoO1arHKZ4q77rg Date: Thu, 3 Sep 2015 15:36:10 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB1153F@AZ-FFEXMB04.global.avaya.com> References: <20150903153208.7512.70059.idtracker@ietfa.amsl.com> In-Reply-To: <20150903153208.7512.70059.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [lmap] FW: lmap - New Meeting Session Request for IETF 94 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, 03 Sep 2015 15:36:17 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogIklFVEYgTWVldGluZyBT ZXNzaW9uIFJlcXVlc3QgVG9vbCINCj4gW21haWx0bzpzZXNzaW9uX3JlcXVlc3RfZGV2ZWxvcGVy c0BpZXRmLm9yZ10NCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAwMywgMjAxNSA2OjMyIFBN DQo+IFRvOiBzZXNzaW9uLXJlcXVlc3RAaWV0Zi5vcmcNCj4gQ2M6IGxtYXAtYWRzQGlldGYub3Jn OyBSb21hc2NhbnUsIERhbiAoRGFuKTsgamFzb24ud2VpbEB0d2NhYmxlLmNvbQ0KPiBTdWJqZWN0 OiBsbWFwIC0gTmV3IE1lZXRpbmcgU2Vzc2lvbiBSZXF1ZXN0IGZvciBJRVRGIDk0DQo+IA0KPiAN Cj4gDQo+IEEgbmV3IG1lZXRpbmcgc2Vzc2lvbiByZXF1ZXN0IGhhcyBqdXN0IGJlZW4gc3VibWl0 dGVkIGJ5IERhbiBSb21hc2NhbnUsDQo+IGEgQ2hhaXIgb2YgdGhlIGxtYXAgd29ya2luZyBncm91 cC4NCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gV29ya2luZyBHcm91cCBOYW1lOiBMYXJnZS1TY2FsZSBNZWFzdXJl bWVudCBvZiBCcm9hZGJhbmQgUGVyZm9ybWFuY2UNCj4gQXJlYSBOYW1lOiBPcGVyYXRpb25zIGFu ZCBNYW5hZ2VtZW50IEFyZWEgU2Vzc2lvbiBSZXF1ZXN0ZXI6IERhbg0KPiBSb21hc2NhbnUNCj4g DQo+IE51bWJlciBvZiBTZXNzaW9uczogMQ0KPiBMZW5ndGggb2YgU2Vzc2lvbihzKTogIDIuNSBI b3Vycw0KPiBOdW1iZXIgb2YgQXR0ZW5kZWVzOiA4MA0KPiBDb25mbGljdHMgdG8gQXZvaWQ6DQo+ ICBGaXJzdCBQcmlvcml0eTogbmV0dmMgd2VicHVzaCBzdGlyIHNpcHJlYyBwMnBzaXAgZWNyaXQg YmZjcGJpcyBwYXlsb2FkIG1tdXNpYw0KPiBzYWNtIGNsdWUgaXBwbSBibXdnIGxtYXAgbXB0Y3Ag bmV0Y29uZiBuZXRtb2Qgb3BzYXJlYSBvcHNhd2cgeHJibG9jaw0KPiBydGN3ZWIgdGNwaW5jIGF2 dGNvcmUgZWR1bmV4dCBpMm5zZiBzdXBhDQo+IA0KPiANCj4gDQo+IA0KPiBTcGVjaWFsIFJlcXVl c3RzOg0KPiAgIHBsZWFzZSBhdm9pZCBzY2hlZHVsaW5nIGluIGNvbmZsaWN0IHdpdGggdGhlIEky TlNGIGFuZCBTVVBBIFdHcyBpZg0KPiBjaGFydGVyZWQNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Thu Sep 3 08:53:48 2015 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 13DFB1B411F for ; Thu, 3 Sep 2015 08:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ymo7qAlYNoGh for ; Thu, 3 Sep 2015 08:53:45 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18CDD1B41C4 for ; Thu, 3 Sep 2015 08:53:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BVAwBBP8ZV/xUHmMZbGQGCVSxUaQaDHqZQBpM2CYFdHQqFeQIcgQo4FAEBAQEBAQF/C4QjAQEBAQIBEgsGEVEGAQgNBAQBAQMCBgsSAwIEMBQBBgEBBQQBBBMIDAsDiAQIAQynYYULilaVaAEBCAEBAQEBAQEbgSKEfYUyhCYRASA+BIIkOxIdgRQFjFWINgGFAYJphkFGg1+DC40eg2YXD4N9b4EOOoEEAQEB X-IPAS-Result: A2BVAwBBP8ZV/xUHmMZbGQGCVSxUaQaDHqZQBpM2CYFdHQqFeQIcgQo4FAEBAQEBAQF/C4QjAQEBAQIBEgsGEVEGAQgNBAQBAQMCBgsSAwIEMBQBBgEBBQQBBBMIDAsDiAQIAQynYYULilaVaAEBCAEBAQEBAQEbgSKEfYUyhCYRASA+BIIkOxIdgRQFjFWINgGFAYJphkFGg1+DC40eg2YXD4N9b4EOOoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208";a="118538022" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Sep 2015 11:52:58 -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; 03 Sep 2015 11:52: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, 3 Sep 2015 11:52:56 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: NomCom 2015: Call for nominations Thread-Index: AdDmYJebS5W9R0xdTjyOl+/ui1pqSQ== Date: Thu, 3 Sep 2015 15:52:56 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB115AB@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.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [lmap] FW: NomCom 2015: Call for nominations 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, 03 Sep 2015 15:53:47 -0000 UGxlYXNlIHNlZSBiZWxvdyB0aGUgQ2FsbCBmb3IgTm9taW5hdGlvbnMgZnJvbSBOb21Db20gMjAx NS4gUGxlYXNlIGhlbHAgTm9tQ29tIGFuZCB0aGUgSUVURiBjb21tdW5pdHkgYnkgcHJvcG9zaW5n IHRoZSBiZXN0IGNhbmRpZGF0ZXMgZm9yIHRoZSBvcGVuIHBvc2l0aW9ucy4gDQoNClRoYW5rcyBh bmQgUmVnYXJkcywNCg0KRGFuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBJRVRGLUFubm91bmNlIFttYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YNCj4gTm9tQ29tIENoYWlyIDIwMTUNCj4gU2VudDogV2VkbmVzZGF5LCBB dWd1c3QgMjYsIDIwMTUgMToxMyBQTQ0KPiBUbzogSUVURiBBbm5vdW5jZW1lbnQgTGlzdA0KPiBD YzogaWV0ZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBOb21Db20gMjAxNTogQ2FsbCBmb3Igbm9taW5h dGlvbnMNCj4gDQo+IFRoZSAyMDE1LTE2IE5vbWluYXRpbmcgQ29tbWl0dGVlIChOb21jb20pIGlz IHNlZWtpbmcgbm9taW5hdGlvbnMgZnJvbQ0KPiBub3cgdW50aWwgT2N0b2JlciA4LCAyMDE1LiBU aGUgb3BlbiBwb3NpdGlvbnMgYmVpbmcgY29uc2lkZXJlZCBieSB0aGlzIHllYXIncw0KPiBOb21j b20gY2FuIGJlIGZvdW5kIGF0IHRoZSBlbmQgb2YgdGhpcyBlbWFpbCBhbmQgYWxzbyBvbiB0aGlz IHllYXIncw0KPiBOb21jb20gd2Vic2l0ZToNCj4gDQoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9ub21jb20vMjAxNS8gDQoNCj4gDQo+IE5vbWluYXRpb25zIG1heSBiZSBtYWRlIGJ5 IHNlbGVjdGluZyB0aGUgTm9taW5hdGUgbGluayBhdCB0aGUgdG9wIG9mIHRoZQ0KPiBOb21jb20g MjAxNSBob21lIHBhZ2UsIG9yIGJ5IHZpc2l0aW5nIHRoZSBmb2xsb3dpbmcgVVJMOg0KPiANCg0K DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL25vbWNvbS8yMDE1L25vbWluYXRlLyANCg0K PiANCj4gICB7Tm90ZSB0aGF0IG5vbWluYXRpb25zIG1hZGUgdXNpbmcgdGhlIHdlYiB0b29sIHJl cXVpcmUgYW4gaWV0Zi5vcmcNCj4gICAgZGF0YXRyYWNrZXIgYWNjb3VudC4gWW91IGNhbiBjcmVh dGUgYSBkYXRhdHJhY2tlciBpZXRmLm9yZyBhY2NvdW50DQo+ICAgIGlmIHlvdSBkb24ndCBoYXZl IG9uZSBhbHJlYWR5IGJ5IHZpc2l0aW5nIHRoZSBmb2xsb3dpbmcgVVJMOg0KDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2FjY291bnRzL2NyZWF0ZS8NCg0KPiANCj4gSWYgeW91IGFyZSB1 bmFibGUgdG8gdXNlIHRoZSB3ZWIgZm9ybSwgbm9taW5hdGlvbnMgbWF5IGluc3RlYWQgYmUgbWFk ZSBieQ0KPiBlbWFpbCB0byBub21jb20xNUBpZXRmLm9yZy4gSWYgdXNpbmcgZW1haWwsIHBsZWFz ZSBpbmNsdWRlIHRoZSB3b3JkDQo+ICJOb21pbmF0ZSIgaW4gdGhlIFN1YmplY3QgYW5kIGluZGlj YXRlIGluIHRoZSBlbWFpbCB3aG8gaXMgYmVpbmcgbm9taW5hdGVkLA0KPiB0aGVpciBlbWFpbCBh ZGRyZXNzICh0byBjb25maXJtIGFjY2VwdGFuY2Ugb2YgdGhlIG5vbWluYXRpb24pLCBhbmQgdGhl DQo+IHBvc2l0aW9uIGZvciB3aGljaCB5b3UgYXJlIG1ha2luZyB0aGUgbm9taW5hdGlvbi4NCj4g SWYgeW91IGFyZSBub21pbmF0aW5nIHNvbWVvbmUgb3RoZXIgdGhhbiB5b3Vyc2VsZiwgcGxlYXNl IHRlbGwgdXMgaWYgd2UgbWF5DQo+IHRlbGwgdGhlIG5vbWluZWUgdGhhdCB5b3Ugd2VyZSB0aGUg b25lIHdobyBtYWRlIHRoZSBub21pbmF0aW9uLg0KPiBJZiB5b3Ugd2lzaCB0byBub21pbmF0ZSBz b21lb25lIHZpYSBlbWFpbCBmb3IgbW9yZSB0aGFuIG9uZSBwb3NpdGlvbiwNCj4gcGxlYXNlIHVz ZSBzZXBhcmF0ZSBlbWFpbHMgdG8gZG8gc28uDQo+IA0KPiBTZWxmLW5vbWluYXRpb24gaXMgd2Vs Y29tZSENCj4gDQo+IE5vbUNvbSAyMDE1LTE2IHdpbGwgZm9sbG93IHRoZSBwb2xpY3kgZm9yICJP cGVuIERpc2Nsb3N1cmUgb2YgV2lsbGluZw0KPiBOb21pbmVlcyIgZGVzY3JpYmVkIGluIEJDUCAx MC9SRkMgNzQzNy4gIEFzIHN0YXRlZCBpbiBSRkMgNzQzNzogIlRoZSBsaXN0IG9mDQo+IG5vbWlu ZWVzIHdpbGxpbmcgdG8gYmUgY29uc2lkZXJlZCBmb3IgcG9zaXRpb25zIHVuZGVyIHJldmlldyBp biB0aGUgY3VycmVudA0KPiBOb21jb20gY3ljbGUgaXMgbm90IGNvbmZpZGVudGlhbCIuIFdpbGxp bmcgbm9taW5lZXMgZm9yIGVhY2ggcG9zaXRpb24gd2lsbCBiZQ0KPiBsaXN0ZWQgaW4gYSBwdWJs aWNseSBhY2Nlc3NpYmxlIHdheSAtIGFueW9uZSB3aXRoIGEgZGF0YXRyYWNrZXIgYWNjb3VudCBt YXkNCj4gYWNjZXNzIHRoZSBsaXN0cy4gIEFkZGl0aW9uYWxseSwgdGhlIG5vbWluYXRpb24gZm9y bSBhc2tzIGlmIHdlIG1heSBzaGFyZSB5b3VyDQo+IG93biBuYW1lIHdpdGggdGhlIG5vbWluZWUu IEluIGFsbCBvdGhlciB3YXlzLCB0aGUgY29uZmlkZW50aWFsaXR5DQo+IHJlcXVpcmVtZW50cyBv ZiBCQ1AxMCByZW1haW4gaW4gZWZmZWN0LiAgQWxsIGZlZWRiYWNrIGFuZCBhbGwgTm9tY29tDQo+ IGRlbGliZXJhdGlvbnMgd2lsbCByZW1haW4gY29uZmlkZW50aWFsIGFuZCB3aWxsIG5vdCBiZSBk aXNjbG9zZWQuDQo+IA0KPiBUaGVyZSBpcyBhIGZpZWxkIG9uIHRoZSBmb3JtIHlvdSBjYW4gbWFy ayBpbiBvcmRlciB0byBhbGxvdyB0aGUgTm9tY29tIHRvDQo+IHRlbGwgdGhlIG5vbWluZWUgdGhh dCB5b3Ugd2VyZSB0aGUgb25lIHdobyBtYWRlIHRoZSBub21pbmF0aW9uLiBUaGlzIGlzIGENCj4g bmV3IHRoaW5nIHRoaXMgeWVhciwgYW5kIGl0IGRlZmF1bHRzIHRvIOKAnG5v4oCdIC0gd2Ugd29u 4oCZdCB0ZWxsLiBBZnRlciB0aGUNCj4gbm9taW5hdGlvbiBjeWNsZSwgd2Ugd2lsbCBldmFsdWF0 ZSB0aGUgcmVzdWx0IG9mIHRoaXMgYW5kIHJlY29tbWVuZA0KPiB3aGV0aGVyIHRoZSBuZXh0IE5v bWNvbSBzaG91bGQgZG8gc29tZXRoaW5nIGRpZmZlcmVudC4NCj4gDQo+IEluIG9yZGVyIHRvIGVu c3VyZSB0aW1lIHRvIGNvbGxlY3Qgc3VmZmljaWVudCBjb21tdW5pdHkgZmVlZGJhY2sgYWJvdXQg ZWFjaA0KPiBvZiB0aGUgd2lsbGluZyBub21pbmVlcywgbm9taW5hdGlvbnMgbXVzdCBiZSByZWNl aXZlZCBieSB0aGUgTm9tY29tIG9uIG9yDQo+IGJlZm9yZSBPY3RvYmVyIDgsIDIwMTUuDQo+IA0K PiBQbGVhc2Ugc3VibWl0IHlvdXIgbm9taW5hdGlvbnMgYXMgZWFybHkgYXMgcG9zc2libGUgZm9y IHRoZSBzYWtlIG9mIHlvdXINCj4gbm9taW5lZXMuIE5vdGUgdGhhdCBub21pbmF0aW9ucyBzaG91 bGQgbm90IHdhaXQgZm9yIG1hbmFnZW1lbnQNCj4gcGVybWlzc2lvbiwgYXMgaXQgaXMgZWFzaWVy IHRvIGRlY2xpbmUgdGhlIG5vbWluYXRpb24gdGhhbiBwdXQgb25lIGluIGxhdGUuICBXZQ0KPiBo YXZlIHNldCB0aGUgcXVlc3Rpb25uYWlyZSBzdWJtaXNzaW9uIGRlYWRsaW5lIGZvciBPY3RvYmVy IDE1LCAyMDE1Lg0KPiANCj4gVGhlIE5vbWNvbSBhcHBvaW50cyBpbmRpdmlkdWFscyB0byBmaWxs IHRoZSBvcGVuIHNsb3RzIG9uIHRoZSBJQU9DLCB0aGUgSUFCLA0KPiBhbmQgdGhlIElFU0cuIFRo ZSBsaXN0IG9mIHBlb3BsZSBhbmQgcG9zdHMgd2hvc2UgdGVybXMgZW5kIHdpdGggdGhlIE1hcmNo DQo+IDIwMTYgSUVURiBtZWV0aW5nLCBhbmQgdGh1cyB0aGUgcG9zaXRpb25zIGZvciB3aGljaCB0 aGlzIE5vbWNvbSBpcw0KPiByZXNwb25zaWJsZSwgZm9sbG93czoNCj4gDQo+IElBQjoNCj4gKiBN YXJ5IEJhcm5lcw0KPiAqIEpvZSBIaWxkZWJyYW5kDQo+ICogVGVkIEhhcmRpZQ0KPiAqIEVyaWsg Tm9yZG1hcmsNCj4gKiBCcmlhbiBUcmFtbWVsbA0KPiAqIE1hcmsgQmxhbmNoZXQNCj4gDQo+IElF U0c6DQo+IC0gQWxpc3NhIENvb3BlciwgQVJUDQo+IC0gQmFycnkgTGVpYmEsIEFSVA0KPiAtIEJy aWFuIEhhYmVybWFuLCBJbnRlcm5ldCAoKikNCj4gLSBCZW5vaXQgQ2xhaXNlLCBPJk0NCj4gLSBB bGlhIEF0bGFzLCBSb3V0aW5nDQo+IC0gS2F0aGxlZW4gTW9yaWFydHksIFNlY3VyaXR5DQo+IC0g TWFydGluIFN0aWVtZXJsaW5nLCBUcmFuc3BvcnQgKCopDQo+IA0KPiAqLSBoYXZlIGluZGljYXRl ZCB0aGF0IHRoZXkgZG8gbm90IGludGVuZCB0byBhY2NlcHQgYSByZW5vbWluYXRpb24uIFRoaXMN Cj4gaW5mb3JtYXRpb24gaXMgYWx3YXlzIHVwIHRvIGRhdGUgb24NCg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9ub21jb20vMjAxNS8NCg0KPiANCj4gUGxlYXNlIGJlIHJlc291cmNlZnVs IGluIGlkZW50aWZ5aW5nIHBvc3NpYmxlIGNhbmRpZGF0ZXMgZm9yIHRoZXNlIHBvc2l0aW9ucywN Cj4gYXMgZGV2ZWxvcGluZyBvdXIgdGFsZW50IGlzIGEgdmVyeSBjcnVjaWFsIHJlcXVpcmVtZW50 IGZvciB0aGUgSUVURiwgYW5kIGFsc28sDQo+IHBsZWFzZSBjb25zaWRlciBhY2NlcHRpbmcgYSBu b21pbmF0aW9uLiAgWW91J2xsIGZpbmQgZXh0ZW5zaXZlIGluZm9ybWF0aW9uDQo+IGFib3V0IHNw ZWNpZmljIHBvc2l0aW9ucywgZGV2ZWxvcGVkIGJ5IHRoZSBJQUIsIElFU0csIGFuZCBJQU9DLCB1 bmRlcg0KPiBpbmRpdmlkdWFsIHRhYnMgYXQ6DQo+IA0KDQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL25vbWNvbS8yMDE1L3JlcXVpcmVtZW50cy8NCg0KPiANCj4gSW4gYWRkaXRpb24gdG8g bm9taW5hdGlvbnMsIHRoZSBOb21jb20gc2Vla3MgY29tbXVuaXR5IGlucHV0IG9uIHRoZQ0KPiBw b3NpdGlvbnMgdGhlbXNlbHZlcy4gIFdlIG5lZWQgYW5kIHdlbGNvbWUgdGhlIGNvbW11bml0eSdz IHZpZXdzIGFuZA0KPiBpbnB1dCBvbiB0aGUgam9icyB3aXRoaW4gZWFjaCBvcmdhbml6YXRpb24u IElmIHlvdSBoYXZlIGlkZWFzIG9uIHRoZSBwb3NpdGlvbnMnDQo+IHJlc3BvbnNpYmlsaXRpZXMg KG1vcmUsIGxlc3MsIGRpZmZlcmVudCksIHBsZWFzZSBsZXQgdXMga25vdy4NCj4gDQo+IFBsZWFz ZSBzZW5kIHN1Z2dlc3Rpb25zIGFuZCBmZWVkYmFjayBhYm91dCB0aGlzIHRvIG5vbWNvbTE1QGll dGYub3JnLg0KPiANCj4gVGhhbmsgeW91IGZvciB5b3VyIGhlbHAgaW4gaWRlbnRpZnlpbmcgcXVh bGlmaWVkIG5vbWluZWVzIQ0KPiANCj4gSGFyYWxkIEFsdmVzdHJhbmQNCj4gTm9tY29tIENoYWly IDIwMTUtMTYNCj4gbm9tY29tLWNoYWlyLTIwMTVAaWV0Zi5vcmcsIGh0YStub21jb21AYWx2ZXN0 cmFuZC5ubw0KDQo= From nobody Tue Sep 8 22:08:30 2015 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 079921B3A82 for ; Tue, 8 Sep 2015 22:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, 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 LL39zQtQubTw for ; Tue, 8 Sep 2015 22:08:26 -0700 (PDT) Received: from BAY004-OMC2S9.hotmail.com (bay004-omc2s9.hotmail.com [65.54.190.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175301B39DD for ; Tue, 8 Sep 2015 22:08:26 -0700 (PDT) Received: from BAY167-W14 ([65.54.190.123]) by BAY004-OMC2S9.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 8 Sep 2015 22:08:25 -0700 X-TMN: [1gKN7BKHUPFkpptBSkI7fNF+0wLlqXK5FB3Qx7AQra0=] X-Originating-Email: [lingli.deng@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_c94ec9bb-f615-487b-8bfd-28a0413a560d_" From: Lingli Deng To: Kamala Subramaniam , "lmap@ietf.org" Date: Wed, 9 Sep 2015 05:08:25 +0000 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2015 05:08:25.0773 (UTC) FILETIME=[8EB59DD0:01D0EABD] Archived-At: Subject: Re: [lmap] draft-ksubram-lmap-router-buffer-sizes-01 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, 09 Sep 2015 05:08:29 -0000 --_c94ec9bb-f615-487b-8bfd-28a0413a560d_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 CgoKSGkgS2FtYWxhLCBJIGFtIGludGVyZXN0ZWQgaW4gdGhpcyBidWZmZXIgc2l6aW5nIHByb2Js ZW0uIFlvdSBtZW50aW9uZWQgdGhhdCAiIElkZWFsbHksIHdoYXQgd291bGQgYmUgcmVxdWlyZWQg aXMgYW4gYWxsIGtub3dpbmcgb3JhY2xlIHRoYXQgc2VlcyB0aGUgdHJhZmZpYyBmbG93IG9uIGFu IGVuZC10by1lbmQgbmV0d29yayBhY3Jvc3MgYWxsIGxheWVycy4iIEhvd2V2ZXIsIGl0IHNlZW1z IHRoYXQgdGhlIHByb3Bvc2VkIG1ldHJpY3Mgc28gZmFyIGNhbiBiZSBjb2xsZWN0ZWQgbG9jYWxs eSBieSBlYWNoIE1BIChpLmUuIHJvdXRlcnMpLiBBbmQgY3VyaW91c2x5IGJvdGggdGhlIHRoZXJl b3RpYyB3b3JrIHNvIGZhciBhcmUgYmFzZWQgb24gUlRUIHdoaWNoIGNhbiBub3QgYmUgY29sbGVj dGVkIGluIHRoaXMgd2F5LiBSZWdhcmRzLExpbmdsaQ0KIA0KDQogDQpGcm9tOiBrYXN1YnJhQG1p Y3Jvc29mdC5jb20NClRvOiBsbWFwQGlldGYub3JnDQpEYXRlOiBNb24sIDIwIEp1bCAyMDE1IDE0 OjEyOjAzICswMDAwDQpTdWJqZWN0OiBSZTogW2xtYXBdIGRyYWZ0LWtzdWJyYW0tbG1hcC1yb3V0 ZXItYnVmZmVyLXNpemVzLTAxDQoNCgoKCgoKCgoKRGVhciBMTUFQIFdHLAogCkEgbmV3IHZlcnNp b24gb2YgdGhpcyBkcmFmdCBoYXMgYmVlbiBwb3N0ZWQuIFRoaXMgaW5jbHVkZXMgYW4gaW5mb3Jt YXRpb24gbW9kZWwgdGhhdCBpcyBuZWVkZWQgdG8gY29sbGVjdCBlbXBpcmljYWwgZGF0YSBzdWNo IHRoYXQgdGhlIGFuYWx5c2lzIG9mIHJvdXRlciBidWZmZXIgc2l6ZXMgbmVlZGVkIGluIHRoZSBX QU4gd2lsbCBiZSBlYXNpZXIuIEFkZGl0aW9uYWxseSwKIEkgd2lsbCBhbHNvIGJlIHByZXNlbnRp bmcgc29tZSBkYXRhIHRoYXQgd2lsbCBkcml2ZSB0aGUgcG9pbnQgdGhhdCBib3RoIGEgbW9kZWws IGFzIHdlbGwgYXMgbWV0cmljcyBhcmUgbGFja2luZyB0byB0aGlzIHN0dWR5LiBZb3VyIGZlZWRi YWNrIGlzIGFwcHJlY2lhdGVkLgogClRoYW5rcywKS2FtYWxhCiAKCgpGcm9tOiBLYW1hbGEgU3Vi cmFtYW5pYW0gDQoKU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMCwgMjAxNCAxMjowNiBQTQ0KClRv OiAnbG1hcEBpZXRmLm9yZycgPGxtYXBAaWV0Zi5vcmc+DQoKU3ViamVjdDogZHJhZnQta3N1YnJh bS1sbWFwLXJvdXRlci1idWZmZXItc2l6ZXMtMDAKCgogCkRlYXIgTE1BUCBXRywKIApXZSBoYXZl IHN1Ym1pdHRlZCBhIGRyYWZ0IKGwUm91dGVyIEJ1ZmZlciBTaXplcyBpbiB0aGUgV0FOobEuIEl0 IHdpbGwgYmUgcHJlc2VudGVkIHRoaXMgVGh1cnNkYXkuIEkgd2FudGVkIHRvIHRha2UgdGhpcyBv cHBvcnR1bml0eSB0byBpbnRyb2R1Y2UgdGhpcyBkcmFmdCwgYW5kIGdldCBzb21lIGZlZWRiYWNr LiBUaGlzIGRyYWZ0IGhhcyByZWNlaXZlZCBzb21lIGlucHV0CiBmcm9tIHRoZSBBUU0gV0cuIAog ClRoZSBsbWFwLXVzZS1jYXNlcyBkcmFmdCBpcyB3aGF0IGluaXRpYXRlZCB0aGUgcmVxdWVzdCB0 byBiZSBwcmVzZW50ZWQgaW4gdGhlIExNQVAgV0cuICBMZXQgbWUgZ2V0IG1vcmUgaW4gdG8gdGhl IGRldGFpbHMgYnkgZWxhYm9yYXRpbmcgdGhlIGlzc3VlIHdpdGggZWFjaCBvZiB0aGUgNCBzdWJz ZWN0aW9ucyBpbiB0aGlzIElTUCB1c2UgY2FzZS4KIApCZWZvcmUgdGhhdCwgbWF5YmUgbGlzdGlu ZyB0aGUgZ29hbHMgd291bGQgZ2l2ZSBhIGJldHRlciBpZGVhOgoKoaQgICAgICAKRHJpdmUgZG93 biB0aGUgdW5pdCBjb3N0IGluICQvR0IgYnkgYnVpbGRpbmcgZWZmaWNpZW50IGJ1dCBjaGVhcGVy IG5ldHdvcmtzLiBEbyBvdXIgbmV0d29ya3MgcmVhbGx5IG5lZWQgdGhlIGJ1ZmZlcnMgd2UgZGVh bCB3aXRoIHRvZGF5IGF0IGhpZ2ggY29zdHM/CgqhpCAgICAgIApNYXhpbWl6ZSB0aHJvdWdocHV0 IGluIHRoZSBiYWNrYm9uZSBieSBhbHdheXMga2VlcGluZyB0aGUgbGlua3MgYnVzeSBzbyB0aGF0 IHRoZSByb3V0ZXIgYnVmZmVycyBuZXZlciB1bmRlcmZsb3cgYW5kIHRoZSByb3V0ZXIgZG9lcyBu b3QgbG9zZSB0aHJvdWdocHV0LgoKCqGkICAgICAgClRvIHRha2UgaW50byBjb25zaWRlcmF0aW9u IHZhcmlhYmxlcyBzdWNoIGFzIHtzaG9ydCBWcyBsb25nIGZsb3dzLCBwYWNrZXQgc2l6ZXMsIHF1 ZXVlIGRlcHRoL21vZGVsLCB0cmFmZmljIGNsYXNzZXMsIGV0Yy59IGFzIGZhY3RvcnMgd2hpbGUg cmVkdWNpbmcgdGhlIHdoaXN0bGVzLCBiZWxscywKIGFuZCBrbm9icyB0byBrZWVwIGl0IHNpbXBs ZSB0byBjb25maWd1cmUgYXMgd2VsbCBhcyBtYW5hZ2UuIApOb3csIGZvciB0aGUgc3Vic2VjdGlv bnM6CgqhpCAgICAgIApJZGVudGlmeWluZywgaXNvbGF0aW5nIGFuZCBmaXhpbmcgcHJvYmxlbXM6 IHdlIG9ic2VydmUgdGhhdCB0aGVyZSBhcmUgbnVtZXJvdXMgaXNzdWVzIGF0IGRpZmZlcmVudCBs YXllcnMgdGhhdCBoYXZlIGFuIGVmZmVjdCAoZGlyZWN0bHkgb3IgaW5kaXJlY3RseSkgb24gdGhl IHNpemluZwogb2Ygcm91dGVyIGJ1ZmZlcnMuIENvdWxkIHRoaXMgYmUgc29sdmVkIGJ5IGhpZ2gg bGF5ZXIgb3B0aW1pemF0aW9ucyAoRUNOLCB0d2Vha2luZyBUQ1AgZmxvd3MpLCAgb3Igc29tZXRo aW5nIGxpa2UganVzdCBhIGRpZmZlcmVudCBxdWV1aW5nIG1vZGVsLiBTdHVkeWluZyB0aGUgbmF0 dXJlIG9mIHRoZSB0cmFmZmljIHRoYXQgZXhpc3RzIGluIGFuIElTUCB3b3JsZCB0b2RheSBpcyBh biBpbXBvcnRhbnQgd2F5IHRvIGRldGVybWluZSB0aGlzLiBXaGVyZQogcmVhbGx5IGlzIHRoaXMg cHJvYmxlbT8gSXMgaXQgdGhlIHdheSB3ZSBkZXNpZ24gb3VyIG5ldHdvcmtzIGZvciBleGFtcGxl IGJ5IG5vdCB0YWtpbmcgaW50byBjb25zaWRlcmF0aW9uIGhvdyBzY2F2ZW5nZXIgY2xhc3MgcmVh bGx5IGFmZmVjdHMgdXM/CgqhpCAgICAgIApEZXNpZ24gYW5kIHBsYW5uaW5nOiBPbmUgdGhlIHBy b2JsZW0gaGFzIGJlZW4gaWRlbnRpZmllZCBpdCBiZWNvbWVzIGVhc2llciB0byBkZXNpZ24gYW5k IHBsYW4gdGhlIG5ldHdvcmtzLiBQZXJoYXBzIGFsbCB3ZSBuZWVkIGFyZSBzbWFsbCBzaXplIGJ1 ZmZlcnMgZHJpdmluZyBkb3duCiB0aGUgY29zdC4KCqGkICAgICAgClVuZGVyc3RhbmRpbmcgdGhl IHF1YWxpdHkgZXhwZXJpZW5jZWQgYnkgY3VzdG9tZXJzOiBhZ2FpbiBhIGh1Z2UgY2h1bmsgb2Yg dGhlIHN0dWR5IHdvdWxkIGhhdmUgcGFja2V0IGRpc2NhcmRzIChXQU4gZmFjaW5nLyBvdXRnb2lu ZyBlZ3Jlc3MgaW50ZXJmYWNlIHBlcmhhcHM/KS4gRG8KIHRoZSBuZXcgbWV0aG9kcyBpbnZvbHZl ZCBpbiB0aGlzIHN0dWR5IHdvcmsgYmV0dGVyIGZvciBRb1M/CgqhpCAgICAgIApVbmRlcnN0YW5k aW5nIHRoZSBpbXBhY3QgYW5kIG9wZXJhdGlvbiBvZiBuZXcgZGV2aWNlcyBhbmQgdGVjaG5vbG9n eTogbGV0oa9zIHNheSB0aGF0IHRoZSBjb25jbHVzaW9uIG9mIHRoaXMgc3R1ZHkgaXMgdGhhdCB3 ZSBkbyBub3QgbmVlZCBsYXJnZSBzaXplIGJ1ZmZlcnMgKHdlIGFyZQogdGFsa2luZyAxMjVNQiBw ZXIgcG9ydCksIHRoZW4gY2FuIHdlIGNvbnZpbmNlIHRoZSB2ZW5kb3JzIChzd2l0Y2gvcm91dGVy L2NoaXApIHRvIGdvIGRvd24gdGhhdCBwYXRoLgpUaGVyZSBoYXZlIGJlZW4gbWFueSBzdHVkaWVz IHdoaWNoIHByb3ZpZGUgdGhlb3JpZXMgdG8gd2hhdCB0aGUgc2l6ZSBzaG91bGQgYmUuIEhvd2V2 ZXIsIG1vc3Qgb2YgdGhlc2UgYXJlIHRoZW9yZXRpY2FsIGluIG5hdHVyZSBhbmQgZG8gbm90IHRh a2UgaW50byBhY2NvdW50IGFueSBlbXBpcmljYWwgZGF0YS4gV2hpbGUgd2UgY29udGludWUgdG8g bWluZSB0aGUKIGJpZyBkYXRhIGF2YWlsYWJsZSB0byB1cyB0byBmdXJ0aGVyIHN0dWR5IHRoaXMs IHdloa9kIGFsc28gbGlrZSB0byBzdGFydCBhIGRyYWZ0IHdoaWNoIHdvdWxkIGluIHRoZSBtaW5p bXVtIGVudGFpbCBhIHByb2JsZW0gc3RhdGVtZW50LCBnZXQgYW4gaWRlYSBvZiB0aGUgYW1vdW50 IG9mIGludGVyZXN0LCBhbmQgaG9wZWZ1bGx5IGxlYWQgdG8gc29tZSBjb2xsYWJvcmF0aW9uLgog ClJlZ2FyZHMsCkthbWFsYQogCgoKCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KbG1hcCBtYWlsaW5nIGxpc3QKbG1hcEBpZXRmLm9yZwpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXAKIAkJIAkgICAJCSAg --_c94ec9bb-f615-487b-8bfd-28a0413a560d_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjwvaGVhZD4NCjxib2R5IGNsYXNzPSdobW1lc3NhZ2UnPjxkaXYgZGly PSdsdHInPgoKPHN0eWxlPjwhLS0KLmhtbWVzc2FnZSBQCnsKbWFyZ2luOjBweDsKcGFkZGluZzow cHgKfQpib2R5LmhtbWVzc2FnZQp7CmZvbnQtc2l6ZTogMTJwdDsKZm9udC1mYW1pbHk6Q2FsaWJy aQp9Ci0tPjwvc3R5bGU+CjxkaXYgZGlyPSJsdHIiPkhpIEthbWFsYSw8L2Rpdj48ZGl2IGRpcj0i bHRyIj4mbmJzcDs8L2Rpdj48ZGl2IGRpcj0ibHRyIj5JIGFtIGludGVyZXN0ZWQgaW4gdGhpcyBi dWZmZXIgc2l6aW5nIHByb2JsZW0uIDwvZGl2PjxkaXYgZGlyPSJsdHIiPllvdSBtZW50aW9uZWQg dGhhdCAiIElkZWFsbHksIHdoYXQgd291bGQgYmUgcmVxdWlyZWQgaXMgYW4gYWxsIGtub3dpbmcg b3JhY2xlIHRoYXQgc2VlcyB0aGUgdHJhZmZpYyBmbG93IG9uIGFuIGVuZC10by1lbmQgbmV0d29y ayBhY3Jvc3MgYWxsIGxheWVycy4iIEhvd2V2ZXIsIGl0IHNlZW1zIHRoYXQmbmJzcDt0aGUgcHJv cG9zZWQmbmJzcDttZXRyaWNzIHNvIGZhciBjYW4gYmUgY29sbGVjdGVkIGxvY2FsbHkgYnkgZWFj aCBNQSAoaS5lLiByb3V0ZXJzKS4gQW5kIGN1cmlvdXNseSBib3RoIHRoZSB0aGVyZW90aWMgd29y ayBzbyBmYXIgYXJlIGJhc2VkIG9uIFJUVCB3aGljaCBjYW4gbm90IGJlJm5ic3A7Y29sbGVjdGVk IGluIHRoaXMgd2F5LjwvZGl2PjxkaXYgZGlyPSJsdHIiPiZuYnNwOzwvZGl2PjxkaXYgZGlyPSJs dHIiPlJlZ2FyZHMsPC9kaXY+PGRpdiBkaXI9Imx0ciI+TGluZ2xpPC9kaXY+PGRpdiBkaXI9Imx0 ciI+PGJyPiZuYnNwOzxicj48YnI+Jm5ic3A7PGJyPjwvZGl2PjxkaXYgZGlyPSJsdHIiPjxociBp ZD0ic3RvcFNwZWxsaW5nIj5Gcm9tOiBrYXN1YnJhQG1pY3Jvc29mdC5jb208YnI+VG86IGxtYXBA aWV0Zi5vcmc8YnI+RGF0ZTogTW9uLCAyMCBKdWwgMjAxNSAxNDoxMjowMyArMDAwMDxicj5TdWJq ZWN0OiBSZTogW2xtYXBdIGRyYWZ0LWtzdWJyYW0tbG1hcC1yb3V0ZXItYnVmZmVyLXNpemVzLTAx PGJyPjxicj4KCgoKPHN0eWxlPjwhLS0KLkV4dGVybmFsQ2xhc3MgcC5lY3hNc29Ob3JtYWwsIC5F eHRlcm5hbENsYXNzIGxpLmVjeE1zb05vcm1hbCwgLkV4dGVybmFsQ2xhc3MgZGl2LmVjeE1zb05v cm1hbCB7CmZvbnQtc2l6ZToxMS4wcHQ7CmZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Owp9CgouRXh0ZXJuYWxDbGFzcyBhOmxpbmssIC5FeHRlcm5hbENsYXNzIHNwYW4uZWN4TXNvSHlw ZXJsaW5rIHsKY29sb3I6IzA1NjNDMTsKdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsKfQoKLkV4 dGVybmFsQ2xhc3Mgc3Bhbi5lY3hNc29IeXBlcmxpbmtGb2xsb3dlZCB7CmNvbG9yOiM5NTRGNzI7 CnRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7Cn0KCi5FeHRlcm5hbENsYXNzIHAuZWN4TXNvTGlz dFBhcmFncmFwaCwgLkV4dGVybmFsQ2xhc3MgbGkuZWN4TXNvTGlzdFBhcmFncmFwaCwgLkV4dGVy bmFsQ2xhc3MgZGl2LmVjeE1zb0xpc3RQYXJhZ3JhcGggewpsaW5lLWhlaWdodDoxMTUlOwpmb250 LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsKfQoKLkV4dGVy bmFsQ2xhc3MgcC5lY3hNc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCAuRXh0ZXJuYWxDbGFzcyBs aS5lY3hNc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCAuRXh0ZXJuYWxDbGFzcyBkaXYuZWN4TXNv TGlzdFBhcmFncmFwaEN4U3BGaXJzdCB7CmxpbmUtaGVpZ2h0OjExNSU7CmZvbnQtc2l6ZToxMC4w cHQ7CmZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOwp9CgouRXh0ZXJuYWxDbGFzcyBw LmVjeE1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCAuRXh0ZXJuYWxDbGFzcyBsaS5lY3hNc29M aXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgLkV4dGVybmFsQ2xhc3MgZGl2LmVjeE1zb0xpc3RQYXJh Z3JhcGhDeFNwTWlkZGxlIHsKbGluZS1oZWlnaHQ6MTE1JTsKZm9udC1zaXplOjEwLjBwdDsKZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Cn0KCi5FeHRlcm5hbENsYXNzIHAuZWN4TXNv TGlzdFBhcmFncmFwaEN4U3BMYXN0LCAuRXh0ZXJuYWxDbGFzcyBsaS5lY3hNc29MaXN0UGFyYWdy YXBoQ3hTcExhc3QsIC5FeHRlcm5hbENsYXNzIGRpdi5lY3hNc29MaXN0UGFyYWdyYXBoQ3hTcExh c3QgewpsaW5lLWhlaWdodDoxMTUlOwpmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsKfQoKLkV4dGVybmFsQ2xhc3Mgc3Bhbi5lY3hFbWFpbFN0eWxlMTgg ewpmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsKY29sb3I6d2luZG93dGV4dDsKfQoK LkV4dGVybmFsQ2xhc3Mgc3Bhbi5lY3hFbWFpbFN0eWxlMTkgewpmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsKY29sb3I6IzFGNDk3RDsKfQoKLkV4dGVybmFsQ2xhc3MgLmVjeE1zb0No cERlZmF1bHQgewpmb250LXNpemU6MTAuMHB0Owp9CgouRXh0ZXJuYWxDbGFzcyBkaXYuZWN4V29y ZFNlY3Rpb24xIHsKfQoKLkV4dGVybmFsQ2xhc3Mgb2wgewp9CgouRXh0ZXJuYWxDbGFzcyB1bCB7 Cn0KCi0tPjwvc3R5bGU+CgoKPGRpdiBjbGFzcz0iZWN4V29yZFNlY3Rpb24xIj4KPHAgY2xhc3M9 ImVjeE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+RGVh ciBMTUFQIFdHLDwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48L3A+CjxwIGNsYXNzPSJl Y3hNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkEgbmV3 IHZlcnNpb24gb2YgdGhpcyBkcmFmdCBoYXMgYmVlbiBwb3N0ZWQuIFRoaXMgaW5jbHVkZXMgYW4g aW5mb3JtYXRpb24gbW9kZWwgdGhhdCBpcyBuZWVkZWQgdG8gY29sbGVjdCBlbXBpcmljYWwgZGF0 YSBzdWNoIHRoYXQgdGhlIGFuYWx5c2lzIG9mIHJvdXRlciBidWZmZXIgc2l6ZXMgbmVlZGVkIGlu IHRoZSBXQU4gd2lsbCBiZSBlYXNpZXIuIEFkZGl0aW9uYWxseSwKIEkgd2lsbCBhbHNvIGJlIHBy ZXNlbnRpbmcgc29tZSBkYXRhIHRoYXQgd2lsbCBkcml2ZSB0aGUgcG9pbnQgdGhhdCBib3RoIGEg bW9kZWwsIGFzIHdlbGwgYXMgbWV0cmljcyBhcmUgbGFja2luZyB0byB0aGlzIHN0dWR5LiBZb3Vy IGZlZWRiYWNrIGlzIGFwcHJlY2lhdGVkLjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiPlRoYW5rcyw8L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5LYW1hbGE8L3NwYW4+PC9wPgo8cCBj bGFzcz0iZWN4TXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+ PC9hPjwvcD4KPGRpdj4KPGRpdiBzdHlsZT0iYm9yZGVyLXdpZHRoOiAxcHQgbWVkaXVtIG1lZGl1 bTsgYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci1jb2xvcjogcmdiKDIyNSwg MjI1LCAyMjUpIGN1cnJlbnRDb2xvciBjdXJyZW50Q29sb3I7IHBhZGRpbmc6IDNwdCAwaW4gMGlu OyI+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBLYW1hbGEgU3VicmFtYW5p YW0gPGJyPgo8Yj5TZW50OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAxMCwgMjAxNCAxMjowNiBQTTxi cj4KPGI+VG86PC9iPiAnbG1hcEBpZXRmLm9yZycgJmx0O2xtYXBAaWV0Zi5vcmcmZ3Q7PGJyPgo8 Yj5TdWJqZWN0OjwvYj4gZHJhZnQta3N1YnJhbS1sbWFwLXJvdXRlci1idWZmZXItc2l6ZXMtMDA8 L3A+CjwvZGl2Pgo8L2Rpdj4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+Jm5ic3A7PC9wPgo8cCBj bGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAxMTIsIDE5Mik7 Ij5EZWFyIExNQVAgV0csPC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiByZ2IoMCwgMTEyLCAxOTIpOyI+Jm5ic3A7PC9zcGFuPjwvcD4KPHAgY2xh c3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMTEyLCAxOTIpOyI+ V2UgaGF2ZSBzdWJtaXR0ZWQgYSBkcmFmdCChsFJvdXRlciBCdWZmZXIgU2l6ZXMgaW4gdGhlIFdB TqGxLiBJdCB3aWxsIGJlIHByZXNlbnRlZCB0aGlzIFRodXJzZGF5LiBJIHdhbnRlZCB0byB0YWtl IHRoaXMgb3Bwb3J0dW5pdHkgdG8gaW50cm9kdWNlIHRoaXMgZHJhZnQsIGFuZCBnZXQgc29tZSBm ZWVkYmFjay4gVGhpcyBkcmFmdCBoYXMgcmVjZWl2ZWQgc29tZSBpbnB1dAogZnJvbSB0aGUgQVFN IFdHLiA8L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IHJnYigwLCAxMTIsIDE5Mik7Ij4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAxMTIsIDE5Mik7Ij5UaGUgbG1hcC11 c2UtY2FzZXMgZHJhZnQgaXMgd2hhdCBpbml0aWF0ZWQgdGhlIHJlcXVlc3QgdG8gYmUgcHJlc2Vu dGVkIGluIHRoZSBMTUFQIFdHLiAmbmJzcDtMZXQgbWUgZ2V0IG1vcmUgaW4gdG8gdGhlIGRldGFp bHMgYnkgZWxhYm9yYXRpbmcgdGhlIGlzc3VlIHdpdGggZWFjaCBvZiB0aGUgNCBzdWJzZWN0aW9u cyBpbiB0aGlzIElTUCB1c2UgY2FzZS48L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAxMTIsIDE5Mik7Ij4mbmJzcDs8L3NwYW4+PC9w Pgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAxMTIs IDE5Mik7Ij5CZWZvcmUgdGhhdCwgbWF5YmUgbGlzdGluZyB0aGUgZ29hbHMgd291bGQgZ2l2ZSBh IGJldHRlciBpZGVhOjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29MaXN0UGFyYWdyYXBoQ3hT cEZpcnN0IiBzdHlsZT0idGV4dC1pbmRlbnQ6IC0wLjI1aW47Ij4KPHNwYW4gc3R5bGU9ImNvbG9y OiByZ2IoMCwgMTEyLCAxOTIpOyBsaW5lLWhlaWdodDogMTE1JTsgZm9udC1mYW1pbHk6IFN5bWJv bDsgZm9udC1zaXplOiAxMXB0OyI+PHNwYW4+oaQ8c3BhbiBzdHlsZT0nZm9udDogN3B0L25vcm1h bCAiVGltZXMgTmV3IFJvbWFuIjsgZm9udC1zaXplLWFkanVzdDogbm9uZTsgZm9udC1zdHJldGNo OiBub3JtYWw7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMTEyLCAxOTIpOyBsaW5lLWhl aWdodDogMTE1JTsgZm9udC1zaXplOiAxMXB0OyI+RHJpdmUgZG93biB0aGUgdW5pdCBjb3N0IGlu ICQvR0IgYnkgYnVpbGRpbmcgZWZmaWNpZW50IGJ1dCBjaGVhcGVyIG5ldHdvcmtzLiBEbyBvdXIg bmV0d29ya3MgcmVhbGx5IG5lZWQgdGhlIGJ1ZmZlcnMgd2UgZGVhbCB3aXRoIHRvZGF5IGF0IGhp Z2ggY29zdHM/PC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlk ZGxlIiBzdHlsZT0idGV4dC1pbmRlbnQ6IC0wLjI1aW47Ij4KPHNwYW4gc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMTEyLCAxOTIpOyBsaW5lLWhlaWdodDogMTE1JTsgZm9udC1mYW1pbHk6IFN5bWJvbDsg Zm9udC1zaXplOiAxMXB0OyI+PHNwYW4+oaQ8c3BhbiBzdHlsZT0nZm9udDogN3B0L25vcm1hbCAi VGltZXMgTmV3IFJvbWFuIjsgZm9udC1zaXplLWFkanVzdDogbm9uZTsgZm9udC1zdHJldGNoOiBu b3JtYWw7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bh bj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMTEyLCAxOTIpOyBsaW5lLWhlaWdo dDogMTE1JTsgZm9udC1zaXplOiAxMXB0OyI+TWF4aW1pemUgdGhyb3VnaHB1dCBpbiB0aGUgYmFj a2JvbmUgYnkgYWx3YXlzIGtlZXBpbmcgdGhlIGxpbmtzIGJ1c3kgc28gdGhhdCB0aGUgcm91dGVy IGJ1ZmZlcnMgbmV2ZXIgdW5kZXJmbG93IGFuZCB0aGUgcm91dGVyIGRvZXMgbm90IGxvc2UgdGhy b3VnaHB1dC4KPC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFz dCIgc3R5bGU9InRleHQtaW5kZW50OiAtMC4yNWluOyI+CjxzcGFuIHN0eWxlPSJjb2xvcjogcmdi KDAsIDExMiwgMTkyKTsgbGluZS1oZWlnaHQ6IDExNSU7IGZvbnQtZmFtaWx5OiBTeW1ib2w7IGZv bnQtc2l6ZTogMTFwdDsiPjxzcGFuPqGkPHNwYW4gc3R5bGU9J2ZvbnQ6IDdwdC9ub3JtYWwgIlRp bWVzIE5ldyBSb21hbiI7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmU7IGZvbnQtc3RyZXRjaDogbm9y bWFsOyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDExMiwgMTkyKTsgbGluZS1oZWlnaHQ6 IDExNSU7IGZvbnQtc2l6ZTogMTFwdDsiPlRvIHRha2UgaW50byBjb25zaWRlcmF0aW9uIHZhcmlh YmxlcyBzdWNoIGFzIHtzaG9ydCBWcyBsb25nIGZsb3dzLCBwYWNrZXQgc2l6ZXMsIHF1ZXVlIGRl cHRoL21vZGVsLCB0cmFmZmljIGNsYXNzZXMsIGV0Yy59IGFzIGZhY3RvcnMgd2hpbGUgcmVkdWNp bmcgdGhlIHdoaXN0bGVzLCBiZWxscywKIGFuZCBrbm9icyB0byBrZWVwIGl0IHNpbXBsZSB0byBj b25maWd1cmUgYXMgd2VsbCBhcyBtYW5hZ2UuIDwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDExMiwgMTkyKTsiPk5vdywgZm9yIHRo ZSBzdWJzZWN0aW9uczo8L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNvTGlzdFBhcmFncmFwaEN4 U3BGaXJzdCIgc3R5bGU9InRleHQtaW5kZW50OiAtMC4yNWluOyI+CjxzcGFuIHN0eWxlPSJjb2xv cjogcmdiKDAsIDExMiwgMTkyKTsgbGluZS1oZWlnaHQ6IDExNSU7IGZvbnQtZmFtaWx5OiBTeW1i b2w7IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuPqGkPHNwYW4gc3R5bGU9J2ZvbnQ6IDdwdC9ub3Jt YWwgIlRpbWVzIE5ldyBSb21hbiI7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmU7IGZvbnQtc3RyZXRj aDogbm9ybWFsOyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDExMiwgMTkyKTsgbGluZS1o ZWlnaHQ6IDExNSU7IGZvbnQtc2l6ZTogMTFwdDsiPklkZW50aWZ5aW5nLCBpc29sYXRpbmcgYW5k IGZpeGluZyBwcm9ibGVtczogd2Ugb2JzZXJ2ZSB0aGF0IHRoZXJlIGFyZSBudW1lcm91cyBpc3N1 ZXMgYXQgZGlmZmVyZW50IGxheWVycyB0aGF0IGhhdmUgYW4gZWZmZWN0IChkaXJlY3RseSBvciBp bmRpcmVjdGx5KSBvbiB0aGUgc2l6aW5nCiBvZiByb3V0ZXIgYnVmZmVycy4gQ291bGQgdGhpcyBi ZSBzb2x2ZWQgYnkgaGlnaCBsYXllciBvcHRpbWl6YXRpb25zIChFQ04sIHR3ZWFraW5nIFRDUCBm bG93cyksICZuYnNwO29yIHNvbWV0aGluZyBsaWtlIGp1c3QgYSBkaWZmZXJlbnQgcXVldWluZyBt b2RlbC4gU3R1ZHlpbmcgdGhlIG5hdHVyZSBvZiB0aGUgdHJhZmZpYyB0aGF0IGV4aXN0cyBpbiBh biBJU1Agd29ybGQgdG9kYXkgaXMgYW4gaW1wb3J0YW50IHdheSB0byBkZXRlcm1pbmUgdGhpcy4g V2hlcmUKIHJlYWxseSBpcyB0aGlzIHByb2JsZW0/IElzIGl0IHRoZSB3YXkgd2UgZGVzaWduIG91 ciBuZXR3b3JrcyBmb3IgZXhhbXBsZSBieSBub3QgdGFraW5nIGludG8gY29uc2lkZXJhdGlvbiBo b3cgc2NhdmVuZ2VyIGNsYXNzIHJlYWxseSBhZmZlY3RzIHVzPzwvc3Bhbj48L3A+CjxwIGNsYXNz PSJlY3hNc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSIgc3R5bGU9InRleHQtaW5kZW50OiAtMC4y NWluOyI+CjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDExMiwgMTkyKTsgbGluZS1oZWlnaHQ6 IDExNSU7IGZvbnQtZmFtaWx5OiBTeW1ib2w7IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuPqGkPHNw YW4gc3R5bGU9J2ZvbnQ6IDdwdC9ub3JtYWwgIlRpbWVzIE5ldyBSb21hbiI7IGZvbnQtc2l6ZS1h ZGp1c3Q6IG5vbmU7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjog cmdiKDAsIDExMiwgMTkyKTsgbGluZS1oZWlnaHQ6IDExNSU7IGZvbnQtc2l6ZTogMTFwdDsiPkRl c2lnbiBhbmQgcGxhbm5pbmc6IE9uZSB0aGUgcHJvYmxlbSBoYXMgYmVlbiBpZGVudGlmaWVkIGl0 IGJlY29tZXMgZWFzaWVyIHRvIGRlc2lnbiBhbmQgcGxhbiB0aGUgbmV0d29ya3MuIFBlcmhhcHMg YWxsIHdlIG5lZWQgYXJlIHNtYWxsIHNpemUgYnVmZmVycyBkcml2aW5nIGRvd24KIHRoZSBjb3N0 Ljwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSIgc3R5 bGU9InRleHQtaW5kZW50OiAtMC4yNWluOyI+CjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDEx MiwgMTkyKTsgbGluZS1oZWlnaHQ6IDExNSU7IGZvbnQtZmFtaWx5OiBTeW1ib2w7IGZvbnQtc2l6 ZTogMTFwdDsiPjxzcGFuPqGkPHNwYW4gc3R5bGU9J2ZvbnQ6IDdwdC9ub3JtYWwgIlRpbWVzIE5l dyBSb21hbiI7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmU7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDExMiwgMTkyKTsgbGluZS1oZWlnaHQ6IDExNSU7 IGZvbnQtc2l6ZTogMTFwdDsiPlVuZGVyc3RhbmRpbmcgdGhlIHF1YWxpdHkgZXhwZXJpZW5jZWQg YnkgY3VzdG9tZXJzOiBhZ2FpbiBhIGh1Z2UgY2h1bmsgb2YgdGhlIHN0dWR5IHdvdWxkIGhhdmUg cGFja2V0IGRpc2NhcmRzIChXQU4gZmFjaW5nLyBvdXRnb2luZyBlZ3Jlc3MgaW50ZXJmYWNlIHBl cmhhcHM/KS4gRG8KIHRoZSBuZXcgbWV0aG9kcyBpbnZvbHZlZCBpbiB0aGlzIHN0dWR5IHdvcmsg YmV0dGVyIGZvciBRb1M/PC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb0xpc3RQYXJhZ3JhcGhD eFNwTGFzdCIgc3R5bGU9InRleHQtaW5kZW50OiAtMC4yNWluOyI+CjxzcGFuIHN0eWxlPSJjb2xv cjogcmdiKDAsIDExMiwgMTkyKTsgbGluZS1oZWlnaHQ6IDExNSU7IGZvbnQtZmFtaWx5OiBTeW1i b2w7IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuPqGkPHNwYW4gc3R5bGU9J2ZvbnQ6IDdwdC9ub3Jt YWwgIlRpbWVzIE5ldyBSb21hbiI7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmU7IGZvbnQtc3RyZXRj aDogbm9ybWFsOyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDExMiwgMTkyKTsgbGluZS1o ZWlnaHQ6IDExNSU7IGZvbnQtc2l6ZTogMTFwdDsiPlVuZGVyc3RhbmRpbmcgdGhlIGltcGFjdCBh bmQgb3BlcmF0aW9uIG9mIG5ldyBkZXZpY2VzIGFuZCB0ZWNobm9sb2d5OiBsZXShr3Mgc2F5IHRo YXQgdGhlIGNvbmNsdXNpb24gb2YgdGhpcyBzdHVkeSBpcyB0aGF0IHdlIGRvIG5vdCBuZWVkIGxh cmdlIHNpemUgYnVmZmVycyAod2UgYXJlCiB0YWxraW5nIDEyNU1CIHBlciBwb3J0KSwgdGhlbiBj YW4gd2UgY29udmluY2UgdGhlIHZlbmRvcnMgKHN3aXRjaC9yb3V0ZXIvY2hpcCkgdG8gZ28gZG93 biB0aGF0IHBhdGguPC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMTEyLCAxOTIpOyI+VGhlcmUgaGF2ZSBiZWVuIG1hbnkgc3R1ZGll cyB3aGljaCBwcm92aWRlIHRoZW9yaWVzIHRvIHdoYXQgdGhlIHNpemUgc2hvdWxkIGJlLiBIb3dl dmVyLCBtb3N0IG9mIHRoZXNlIGFyZSB0aGVvcmV0aWNhbCBpbiBuYXR1cmUgYW5kIGRvIG5vdCB0 YWtlIGludG8gYWNjb3VudCBhbnkgZW1waXJpY2FsIGRhdGEuIFdoaWxlIHdlIGNvbnRpbnVlIHRv IG1pbmUgdGhlCiBiaWcgZGF0YSBhdmFpbGFibGUgdG8gdXMgdG8gZnVydGhlciBzdHVkeSB0aGlz LCB3ZaGvZCBhbHNvIGxpa2UgdG8gc3RhcnQgYSBkcmFmdCB3aGljaCB3b3VsZCBpbiB0aGUgbWlu aW11bSBlbnRhaWwgYSBwcm9ibGVtIHN0YXRlbWVudCwgZ2V0IGFuIGlkZWEgb2YgdGhlIGFtb3Vu dCBvZiBpbnRlcmVzdCwgYW5kIGhvcGVmdWxseSBsZWFkIHRvIHNvbWUgY29sbGFib3JhdGlvbi48 L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IHJn YigwLCAxMTIsIDE5Mik7Ij4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAxMTIsIDE5Mik7Ij5SZWdhcmRzLDwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDEx MiwgMTkyKTsiPkthbWFsYTwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiZuYnNw OzwvcD4KPC9kaXY+CgoKPGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCmxtYXAgbWFpbGluZyBsaXN0CmxtYXBAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sbWFwPC9kaXY+CiAJCSAJICAgCQkgIDwvZGl2PjwvYm9k eT4NCjwvaHRtbD4= --_c94ec9bb-f615-487b-8bfd-28a0413a560d_-- From nobody Wed Sep 9 22:38:36 2015 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 513051B5E89 for ; Wed, 9 Sep 2015 22:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, 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 9vXUScNwAxIr for ; Wed, 9 Sep 2015 22:38:33 -0700 (PDT) Received: from BAY004-OMC4S12.hotmail.com (bay004-omc4s12.hotmail.com [65.54.190.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED521B5E88 for ; Wed, 9 Sep 2015 22:38:33 -0700 (PDT) Received: from BAY167-W73 ([65.54.190.201]) by BAY004-OMC4S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 9 Sep 2015 22:38:33 -0700 X-TMN: [MIAcWWsd7OB+0lN8ScUqk2OF3NIj+mJQzYcXVGVV7do=] X-Originating-Email: [lingli.deng@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_abc5300f-e922-4d7a-8e74-558079c6bd55_" From: Lingli Deng To: "lmap@ietf.org" Date: Thu, 10 Sep 2015 05:38:33 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 10 Sep 2015 05:38:33.0504 (UTC) FILETIME=[EE9D3A00:01D0EB8A] Archived-At: Cc: "rachel.huang@huawei.com" , "duanshihui@ritt.cn" Subject: [lmap] question about mPlane 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, 10 Sep 2015 05:38:35 -0000 --_abc5300f-e922-4d7a-8e74-558079c6bd55_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 IEhpIExNQVAsDQogIA0KIFdoZW4gSSByZXZpZXdlZCBtaW51dGVzIGZvciBsbWFwIHNlc3Npb24g aW4gSnVseSwgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTMvbWludXRlcy9taW51 dGVzLTkzLWxtYXANCkkgZm91bmQgdGhlIHZhbHVhYmxlIGNvbW1lbnQgZnJvbSBSb2JlcnQgS2lz dGVrZWtpIGZvciBvdXIgY29sbGFib3JhdGl2ZSBMTUFQIGRyYWZ0Lg0KSGUgbWVudGlvbmVkICJt UGxhbmUiIGlzIGRvaW5nIHByb3RvY29sIGZvciBjb2xsYWJvcmF0aXZlIG1lYXN1cmVtZW50cy4g QW5kIEkgd291bGQgbGlrZSB0byBjb250YWN0IGhpbSBmb3IgZnVydGhlciBpbmZvcm1hdGlvbi4N Cg0KSXMgdGhlcmUgQW55Ym9keSBvbiB0aGUgbGlzdCBoYXBwZW5zIHRvIGtub3cgaGlzIGVtYWls IGFkZHJlc3Mgb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBtUGxhbmU/DQogIA0KVGhhbmtzLA0K TGluZ2xpIA0KIAkJIAkgICAJCSAg --_abc5300f-e922-4d7a-8e74-558079c6bd55_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+Jm5ic3A7PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiAi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOyc+SGkgTE1BUCw8YnI+ICZuYnNwOzxicj4gV2hlbiBJIHJl dmlld2VkIG1pbnV0ZXMgZm9yIGxtYXAgc2Vzc2lvbiBpbiBKdWx5LCA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85My9taW51dGVzL21pbnV0ZXMtOTMtbG1hcCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTMvbWludXRlcy9taW51dGVzLTkzLWxtYXA8 L2E+PC9zcGFuPjxCUj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Jz5JJm5ic3A7Zm91bmQgdGhlIHZhbHVhYmxlIGNvbW1lbnQgZnJvbSA8L3NwYW4+Um9i ZXJ0IEtpc3Rla2VraSBmb3Igb3VyIGNvbGxhYm9yYXRpdmUgTE1BUCBkcmFmdC48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Jz48YnI+PC9zcGFuPkhlIG1l bnRpb25lZCAibVBsYW5lIiZuYnNwO2lzIGRvaW5nIHByb3RvY29sIGZvciBjb2xsYWJvcmF0aXZl IG1lYXN1cmVtZW50cy4gQW5kIEkgd291bGQgbGlrZSB0byBjb250YWN0IGhpbSBmb3IgZnVydGhl ciZuYnNwO2luZm9ybWF0aW9uLjxCUj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Jz48YnI+PC9zcGFuPklzIHRoZXJlIEFueWJvZHkmbmJzcDtvbiB0aGUg bGlzdCBoYXBwZW5zIHRvIGtub3cgaGlzIGVtYWlsIGFkZHJlc3Mgb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCBtUGxhbmU/PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOyc+PGJyPiAmbmJzcDs8YnI+PC9zcGFuPlRoYW5rcyw8c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Jz48YnI+PC9zcGFuPkxpbmdsaTxzcGFuIHN0 eWxlPSdmb250LWZhbWlseTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsnPiZuYnNwOzwvc3Bhbj48 QlI+IAkJIAkgICAJCSAgPC9kaXY+PC9ib2R5Pg0KPC9odG1sPg== --_abc5300f-e922-4d7a-8e74-558079c6bd55_-- From nobody Thu Sep 10 00:07:17 2015 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 E95C61B63A6 for ; Thu, 10 Sep 2015 00:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XotvjvpQZ5Er for ; Thu, 10 Sep 2015 00:07:14 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 834F91AC428 for ; Thu, 10 Sep 2015 00:07:02 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id BDFE91A0143; Thu, 10 Sep 2015 09:06:30 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Brian Trammell In-Reply-To: Date: Thu, 10 Sep 2015 09:06:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5D1B43B7-0E2A-4E76-8D80-8F1DC0B66FCB@trammell.ch> References: To: Lingli Deng X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "rachel.huang@huawei.com" , "duanshihui@ritt.cn" , "lmap@ietf.org" Subject: Re: [lmap] question about mPlane 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, 10 Sep 2015 07:07:16 -0000 hi Lingli, The mPlane protocol is described in draft-trammell-mplane-protocol-00, = and an SDK for Python 3 is available at = https://github.com/fp7mplane/protocol-ri.=20 The project's webpage (where you can see the applications we're building = on top of this platform within the scope of the research project) is at = https://www.ict-mplane.eu. Cheers, Brian (mPlane project architect hat) > On 10 Sep 2015, at 07:38, Lingli Deng wrote: >=20 > Hi LMAP, > =20 > When I reviewed minutes for lmap session in July, = https://www.ietf.org/proceedings/93/minutes/minutes-93-lmap > I found the valuable comment from Robert Kistekeki for our = collaborative LMAP draft. > He mentioned "mPlane" is doing protocol for collaborative = measurements. And I would like to contact him for further information. >=20 > Is there Anybody on the list happens to know his email address or more = information about mPlane? > =20 > Thanks, > Lingli=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Sep 11 13:01:09 2015 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 856321B50B6 for ; Fri, 11 Sep 2015 13:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQYaS70lUEON for ; Fri, 11 Sep 2015 13:01:06 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66AD51B5088 for ; Fri, 11 Sep 2015 13:01:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D3AQDoMfNV/yYyC4ddGQSCWixUaQaDJLoKAQ2BUR0KhXkCHIE7OBQBAQEBAQEBfwuEIwEBAQECARILBhFRBgEIDQQEAQEDAgYLEgMCBDAUAQYBAQUEAQQTCAwLA4gECAEMqCuFDYpYlBQBAQgBAQEBAQEBARqBIoVThHuEKhEBID4EgiQ7Eh2BFAWMd4hfAYUJRIIphk9Gg22DFI16g2wfAQFChAFxiGA6gQUBAQE X-IPAS-Result: A2D3AQDoMfNV/yYyC4ddGQSCWixUaQaDJLoKAQ2BUR0KhXkCHIE7OBQBAQEBAQEBfwuEIwEBAQECARILBhFRBgEIDQQEAQEDAgYLEgMCBDAUAQYBAQUEAQQTCAwLA4gECAEMqCuFDYpYlBQBAQgBAQEBAQEBARqBIoVThHuEKhEBID4EgiQ7Eh2BFAWMd4hfAYUJRIIphk9Gg22DFI16g2wfAQFChAFxiGA6gQUBAQE X-IronPort-AV: E=Sophos;i="5.17,513,1437451200"; d="scan'208";a="135726734" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Sep 2015 16:01:05 -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; 11 Sep 2015 16:01:04 -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; Fri, 11 Sep 2015 16:01:03 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: NomCom 2015: Second call for nominations Thread-Index: AdDszJTXOPETNWXuSu6nv6DRuTXh7w== Date: Fri, 11 Sep 2015 20:01:03 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB225B4@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.48] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [lmap] FW: NomCom 2015: Second call for nominations 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, 11 Sep 2015 20:01:08 -0000 UGxlYXNlIGZpbmQgYmVsb3cgYW4gaW1wb3J0YW50IG1lc3NhZ2UgZnJvbSBOb21jb20uIFBsZWFz ZSBoZWxwIE5vbWNvbSBpbiB0aGVpciB0YXNrIG9mIHNlbGVjdGluZyB0aGUgYmVzdCBpbmRpdmlk dWFscyBmb3IgdGhlIG9wZW4gcG9zaXRpb25zLiANCg0KVGhhbmtzIGFuZCBSZWdhcmRzLA0KDQpE YW4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElFVEYtQW5ub3Vu Y2UgW21haWx0bzppZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0K PiBOb21Db20gQ2hhaXIgMjAxNQ0KPiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAxMSwgMjAxNSA2 OjE5IFBNDQo+IFRvOiBJRVRGIEFubm91bmNlbWVudCBMaXN0DQo+IENjOiB3Z2NoYWlyc0BpZXRm Lm9yZw0KPiBTdWJqZWN0OiBOb21Db20gMjAxNTogU2Vjb25kIGNhbGwgZm9yIG5vbWluYXRpb25z DQo+IA0KPiBUaGlzIGlzIHRoZSBTRUNPTkQgY2FsbCBmb3Igbm9taW5hdGlvbnMgZm9yIHRoZSAy MDE1LTIwMTYgbm9tY29tLg0KPiANCj4gVGhlIDIwMTUtMTYgTm9taW5hdGluZyBDb21taXR0ZWUg KE5vbWNvbSkgaXMgc2Vla2luZyBub21pbmF0aW9ucyBmcm9tDQo+IG5vdyB1bnRpbCBPY3RvYmVy IDgsIDIwMTUuIFRoZSBvcGVuIHBvc2l0aW9ucyBiZWluZyBjb25zaWRlcmVkIGJ5IHRoaXMgeWVh cidzDQo+IE5vbWNvbSBjYW4gYmUgZm91bmQgYXQgdGhlIGVuZCBvZiB0aGlzIGVtYWlsIGFuZCBh bHNvIG9uIHRoaXMgeWVhcidzDQo+IE5vbWNvbSB3ZWJzaXRlOg0KPiANCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIwMTUvDQoNCj4gDQo+IE5vbWluYXRpb25zIG1heSBiZSBt YWRlIGJ5IHNlbGVjdGluZyB0aGUgTm9taW5hdGUgbGluayBhdCB0aGUgdG9wIG9mIHRoZQ0KPiBO b21jb20gMjAxNSBob21lIHBhZ2UsIG9yIGJ5IHZpc2l0aW5nIHRoZSBmb2xsb3dpbmcgVVJMOg0K PiANCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAxNS9ub21pbmF0ZS8N Cg0KPiANCj4gICB7Tm90ZSB0aGF0IG5vbWluYXRpb25zIG1hZGUgdXNpbmcgdGhlIHdlYiB0b29s IHJlcXVpcmUgYW4gaWV0Zi5vcmcNCj4gICAgZGF0YXRyYWNrZXIgYWNjb3VudC4gWW91IGNhbiBj cmVhdGUgYSBkYXRhdHJhY2tlciBpZXRmLm9yZyBhY2NvdW50DQo+ICAgIGlmIHlvdSBkb24ndCBo YXZlIG9uZSBhbHJlYWR5IGJ5IHZpc2l0aW5nIHRoZSBmb2xsb3dpbmcgVVJMOg0KDQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2FjY291bnRzL2NyZWF0ZS8NCg0KPiANCj4gSWYgeW91IGFy ZSB1bmFibGUgdG8gdXNlIHRoZSB3ZWIgZm9ybSwgbm9taW5hdGlvbnMgbWF5IGluc3RlYWQgYmUg bWFkZSBieQ0KPiBlbWFpbCB0byBub21jb20xNUBpZXRmLm9yZy4gSWYgdXNpbmcgZW1haWwsIHBs ZWFzZSBpbmNsdWRlIHRoZSB3b3JkDQo+ICJOb21pbmF0ZSIgaW4gdGhlIFN1YmplY3QgYW5kIGlu ZGljYXRlIGluIHRoZSBlbWFpbCB3aG8gaXMgYmVpbmcgbm9taW5hdGVkLA0KPiB0aGVpciBlbWFp bCBhZGRyZXNzICh0byBjb25maXJtIGFjY2VwdGFuY2Ugb2YgdGhlIG5vbWluYXRpb24pLCBhbmQg dGhlDQo+IHBvc2l0aW9uIGZvciB3aGljaCB5b3UgYXJlIG1ha2luZyB0aGUgbm9taW5hdGlvbi4N Cj4gSWYgeW91IGFyZSBub21pbmF0aW5nIHNvbWVvbmUgb3RoZXIgdGhhbiB5b3Vyc2VsZiwgcGxl YXNlIHRlbGwgdXMgaWYgd2UgbWF5DQo+IHRlbGwgdGhlIG5vbWluZWUgdGhhdCB5b3Ugd2VyZSB0 aGUgb25lIHdobyBtYWRlIHRoZSBub21pbmF0aW9uLg0KPiBJZiB5b3Ugd2lzaCB0byBub21pbmF0 ZSBzb21lb25lIHZpYSBlbWFpbCBmb3IgbW9yZSB0aGFuIG9uZSBwb3NpdGlvbiwNCj4gcGxlYXNl IHVzZSBzZXBhcmF0ZSBlbWFpbHMgdG8gZG8gc28uDQo+IA0KPiBTZWxmLW5vbWluYXRpb24gaXMg d2VsY29tZSENCj4gDQo+IE5vbUNvbSAyMDE1LTE2IHdpbGwgZm9sbG93IHRoZSBwb2xpY3kgZm9y ICJPcGVuIERpc2Nsb3N1cmUgb2YgV2lsbGluZw0KPiBOb21pbmVlcyIgZGVzY3JpYmVkIGluIEJD UCAxMC9SRkMgNzQzNy4gIEFzIHN0YXRlZCBpbiBSRkMgNzQzNzogIlRoZSBsaXN0IG9mDQo+IG5v bWluZWVzIHdpbGxpbmcgdG8gYmUgY29uc2lkZXJlZCBmb3IgcG9zaXRpb25zIHVuZGVyIHJldmll dyBpbiB0aGUgY3VycmVudA0KPiBOb21jb20gY3ljbGUgaXMgbm90IGNvbmZpZGVudGlhbCIuIFdp bGxpbmcgbm9taW5lZXMgZm9yIGVhY2ggcG9zaXRpb24gd2lsbCBiZQ0KPiBsaXN0ZWQgaW4gYSBw dWJsaWNseSBhY2Nlc3NpYmxlIHdheSAtIGFueW9uZSB3aXRoIGEgZGF0YXRyYWNrZXIgYWNjb3Vu dCBtYXkNCj4gYWNjZXNzIHRoZSBsaXN0cy4gIEFkZGl0aW9uYWxseSwgdGhlIG5vbWluYXRpb24g Zm9ybSBhc2tzIGlmIHdlIG1heSBzaGFyZSB5b3VyDQo+IG93biBuYW1lIHdpdGggdGhlIG5vbWlu ZWUuIEluIGFsbCBvdGhlciB3YXlzLCB0aGUgY29uZmlkZW50aWFsaXR5DQo+IHJlcXVpcmVtZW50 cyBvZiBCQ1AxMCByZW1haW4gaW4gZWZmZWN0LiAgQWxsIGZlZWRiYWNrIGFuZCBhbGwgTm9tY29t DQo+IGRlbGliZXJhdGlvbnMgd2lsbCByZW1haW4gY29uZmlkZW50aWFsIGFuZCB3aWxsIG5vdCBi ZSBkaXNjbG9zZWQuDQo+IA0KPiBUaGUgbGlzdCBvZiBub21pbmVlcyB3aG8gaGF2ZSBhY2NlcHRl ZCB0aGVpciBub21pbmF0aW9uIGlzIHZpc2libGUgYXQgdGhpcw0KPiBsaW5rOg0KPiANCg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAxNS9mZWVkYmFjay8NCg0KPiANCj4g VGhlcmUgaXMgYSBmaWVsZCBvbiB0aGUgZm9ybSB5b3UgY2FuIG1hcmsgaW4gb3JkZXIgdG8gYWxs b3cgdGhlIE5vbWNvbSB0bw0KPiB0ZWxsIHRoZSBub21pbmVlIHRoYXQgeW91IHdlcmUgdGhlIG9u ZSB3aG8gbWFkZSB0aGUgbm9taW5hdGlvbi4gVGhpcyBpcyBhDQo+IG5ldyB0aGluZyB0aGlzIHll YXIsIGFuZCBpdCBkZWZhdWx0cyB0byDigJxub+KAnSAtIHdlIHdvbuKAmXQgdGVsbC4gQWZ0ZXIg dGhlDQo+IG5vbWluYXRpb24gY3ljbGUsIHdlIHdpbGwgZXZhbHVhdGUgdGhlIHJlc3VsdCBvZiB0 aGlzIGFuZCByZWNvbW1lbmQNCj4gd2hldGhlciB0aGUgbmV4dCBOb21jb20gc2hvdWxkIGRvIHNv bWV0aGluZyBkaWZmZXJlbnQuDQo+IA0KPiBJbiBvcmRlciB0byBlbnN1cmUgdGltZSB0byBjb2xs ZWN0IHN1ZmZpY2llbnQgY29tbXVuaXR5IGZlZWRiYWNrIGFib3V0IGVhY2gNCj4gb2YgdGhlIHdp bGxpbmcgbm9taW5lZXMsIG5vbWluYXRpb25zIG11c3QgYmUgcmVjZWl2ZWQgYnkgdGhlIE5vbWNv bSBvbiBvcg0KPiBiZWZvcmUgT2N0b2JlciA4LCAyMDE1Lg0KPiANCj4gUGxlYXNlIHN1Ym1pdCB5 b3VyIG5vbWluYXRpb25zIGFzIGVhcmx5IGFzIHBvc3NpYmxlIGZvciB0aGUgc2FrZSBvZiB5b3Vy DQo+IG5vbWluZWVzLiBOb3RlIHRoYXQgbm9taW5hdGlvbnMgc2hvdWxkIG5vdCB3YWl0IGZvciBt YW5hZ2VtZW50DQo+IHBlcm1pc3Npb24sIGFzIGl0IGlzIGVhc2llciB0byBkZWNsaW5lIHRoZSBu b21pbmF0aW9uIHRoYW4gcHV0IG9uZSBpbiBsYXRlLiAgV2UNCj4gaGF2ZSBzZXQgdGhlIHF1ZXN0 aW9ubmFpcmUgc3VibWlzc2lvbiBkZWFkbGluZSBmb3IgT2N0b2JlciAxNSwgMjAxNS4NCj4gDQo+ IFRoZSBOb21jb20gYXBwb2ludHMgaW5kaXZpZHVhbHMgdG8gZmlsbCB0aGUgb3BlbiBzbG90cyBv biB0aGUgSUFPQywgdGhlIElBQiwNCj4gYW5kIHRoZSBJRVNHLiBUaGUgbGlzdCBvZiBwZW9wbGUg YW5kIHBvc3RzIHdob3NlIHRlcm1zIGVuZCB3aXRoIHRoZSBNYXJjaA0KPiAyMDE2IElFVEYgbWVl dGluZywgYW5kIHRodXMgdGhlIHBvc2l0aW9ucyBmb3Igd2hpY2ggdGhpcyBOb21jb20gaXMNCj4g cmVzcG9uc2libGUsIGZvbGxvd3M6DQo+IA0KPiBJQUI6DQo+ICogTWFyeSBCYXJuZXMNCj4gKiBK b2UgSGlsZGVicmFuZA0KPiAqIFRlZCBIYXJkaWUNCj4gKiBFcmlrIE5vcmRtYXJrDQo+ICogQnJp YW4gVHJhbW1lbGwNCj4gKiBNYXJjIEJsYW5jaGV0DQo+IA0KPiBJRVNHOg0KPiAtIEFsaXNzYSBD b29wZXIsIEFSVA0KPiAtIEJhcnJ5IExlaWJhLCBBUlQNCj4gLSBCcmlhbiBIYWJlcm1hbiwgSW50 ZXJuZXQgKCopDQo+IC0gQmVub2l0IENsYWlzZSwgTyZNDQo+IC0gQWxpYSBBdGxhcywgUm91dGlu Zw0KPiAtIEthdGhsZWVuIE1vcmlhcnR5LCBTZWN1cml0eQ0KPiAtIE1hcnRpbiBTdGllbWVybGlu ZywgVHJhbnNwb3J0ICgqKQ0KPiANCj4gKi0gaGF2ZSBpbmRpY2F0ZWQgdGhhdCB0aGV5IGRvIG5v dCBpbnRlbmQgdG8gYWNjZXB0IGEgcmVub21pbmF0aW9uLiBUaGlzDQo+IGluZm9ybWF0aW9uIGlz IGFsd2F5cyB1cCB0byBkYXRlIG9uDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbm9t Y29tLzIwMTUvDQoNCj4gDQo+IFBsZWFzZSBiZSByZXNvdXJjZWZ1bCBpbiBpZGVudGlmeWluZyBw b3NzaWJsZSBjYW5kaWRhdGVzIGZvciB0aGVzZSBwb3NpdGlvbnMsDQo+IGFzIGRldmVsb3Bpbmcg b3VyIHRhbGVudCBpcyBhIHZlcnkgY3J1Y2lhbCByZXF1aXJlbWVudCBmb3IgdGhlIElFVEYsIGFu ZCBhbHNvLA0KPiBwbGVhc2UgY29uc2lkZXIgYWNjZXB0aW5nIGEgbm9taW5hdGlvbi4gIFlvdSds bCBmaW5kIGV4dGVuc2l2ZSBpbmZvcm1hdGlvbg0KPiBhYm91dCBzcGVjaWZpYyBwb3NpdGlvbnMs IGRldmVsb3BlZCBieSB0aGUgSUFCLCBJRVNHLCBhbmQgSUFPQywgdW5kZXINCj4gaW5kaXZpZHVh bCB0YWJzIGF0Og0KPiANCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAx NS9yZXF1aXJlbWVudHMvDQoNCj4gDQo+IEluIGFkZGl0aW9uIHRvIG5vbWluYXRpb25zLCB0aGUg Tm9tY29tIHNlZWtzIGNvbW11bml0eSBpbnB1dCBvbiB0aGUNCj4gcG9zaXRpb25zIHRoZW1zZWx2 ZXMuICBXZSBuZWVkIGFuZCB3ZWxjb21lIHRoZSBjb21tdW5pdHkncyB2aWV3cyBhbmQNCj4gaW5w dXQgb24gdGhlIGpvYnMgd2l0aGluIGVhY2ggb3JnYW5pemF0aW9uLiBJZiB5b3UgaGF2ZSBpZGVh cyBvbiB0aGUgcG9zaXRpb25zJw0KPiByZXNwb25zaWJpbGl0aWVzIChtb3JlLCBsZXNzLCBkaWZm ZXJlbnQpLCBwbGVhc2UgbGV0IHVzIGtub3cuDQo+IA0KPiBQbGVhc2Ugc2VuZCBzdWdnZXN0aW9u cyBhbmQgZmVlZGJhY2sgYWJvdXQgdGhpcyB0byBub21jb20xNUBpZXRmLm9yZy4NCj4gDQo+IFRo YW5rIHlvdSBmb3IgeW91ciBoZWxwIGluIGlkZW50aWZ5aW5nIHF1YWxpZmllZCBub21pbmVlcyEN Cj4gDQo+IEhhcmFsZCBBbHZlc3RyYW5kDQo+IE5vbWNvbSBDaGFpciAyMDE1LTE2DQo+IG5vbWNv bS1jaGFpci0yMDE1QGlldGYub3JnLCBodGErbm9tY29tQGFsdmVzdHJhbmQubm8NCg0K From nobody Wed Sep 16 03:06:13 2015 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 E6AC71B3B07 for ; Wed, 16 Sep 2015 03:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id me5MHjO1xCDp for ; Wed, 16 Sep 2015 03:06:09 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 442561B3B28 for ; Wed, 16 Sep 2015 03:05:43 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 25FAAA81D21B3 for ; Wed, 16 Sep 2015 10:05:39 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t8GA5dqx005624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 16 Sep 2015 10:05:39 GMT 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.03.0195.001; Wed, 16 Sep 2015 06:05:39 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: Review of draft-ietf-lmap-information-model-06: Action Destinations and tie with the Regisrry output Thread-Index: AdDPh+iOhRyNd6zRSrWArkmZBvcTWgg3tjVg Date: Wed, 16 Sep 2015 10:05:38 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC250DF3@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC250DF3US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action Destinations and tie with the Regisrry output 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, 16 Sep 2015 10:06:12 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC250DF3US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In light of the Virtual meeting next week I thought I would regenerate an o= pen issue I have with the latest information model that I haven't seen disc= ussion on. BR, Tim From: Carey, Timothy (Timothy) Sent: Wednesday, August 05, 2015 9:06 AM To: 'lmap@ietf.org' Subject: Review of draft-ietf-lmap-information-model-06: Action Destination= s and tie with the Regisrry output Juergen, In previous information models we linked the Registry's outputs with the do= wnstream tasks. In LMAP IM-06 draft we now have a concept of an ActionDestination which des= cribes which schedules are invoked based on the task's output selection. Ho= wever we do not link back the task output to the ActionDestination via para= meter in the ActionDestination object (maybe called Output?). Did I miss un= derstand the intent of the ActionDestination and its linkage? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC250DF3US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In light of the Virtual meeting next = week I thought I would regenerate an open issue I have with the latest info= rmation model that I haven’t seen discussion on.

 

BR,

Tim

 

From: Carey, T= imothy (Timothy)
Sent: Wednesday, August 05, 2015 9:06 AM
To: 'lmap@ietf.org'
Subject: Review of draft-ietf-lmap-information-model-06: Action Dest= inations and tie with the Regisrry output

 

Juergen,

 

In previous information models we linked the Regist= ry’s outputs with the downstream tasks.

 

In LMAP IM-06 draft we now have a concept of an Act= ionDestination which describes which schedules are invoked based on the tas= k’s output selection. However we do not link back the task output to the ActionDestination via parameter in the ActionDestination obj= ect (maybe called Output?). Did I miss understand the intent of the ActionD= estination and its linkage?

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC250DF3US70UWXCHMBA05z_-- From nobody Wed Sep 16 03:08:14 2015 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 0A6EE1B3B1C for ; Wed, 16 Sep 2015 03:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIqqj3-3Iuu9 for ; Wed, 16 Sep 2015 03:08:11 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 1576D1B3B13 for ; Wed, 16 Sep 2015 03:08:11 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id E9CF28FCBA5E for ; Wed, 16 Sep 2015 10:08:05 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t8GA87CW004195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 16 Sep 2015 10:08:07 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 16 Sep 2015 06:08:05 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the information model Thread-Index: AdDJRJl94Hgt5QTGRLCN+LS+Jyv9tgnIu5Aw Date: Wed, 16 Sep 2015 10:08:03 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC250E1F@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC250E1FUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the 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, 16 Sep 2015 10:08:13 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC250E1FUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In light of the Virtual meeting next week I thought I would regenerate an o= pen issue I have with the latest information model that I haven't seen disc= ussion on. BR, Tim From: Carey, Timothy (Timothy) Sent: Tuesday, July 28, 2015 9:49 AM To: lmap@ietf.org Subject: draft-ietf-lmap-information-model-06: Reinsert Task Capabilities a= nd ma conditions back into the information model Juergen, In draft 05 we removed the ability for a measurement agent to report its me= trics that it supports. We need to add * ma-task-capability-obj ma-supported-tasks<0..*>; * [ma-condition-obj ma-conditions<0..*>;] They were in the ma-status-obj. --_000_9966516C6EB5FC4381E05BF80AA55F77DC250E1FUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In light of the Virtual meeting next = week I thought I would regenerate an open issue I have with the latest info= rmation model that I haven’t seen discussion on.

 

BR,

Tim

 

 

From: Carey, T= imothy (Timothy)
Sent: Tuesday, July 28, 2015 9:49 AM
To: lmap@ietf.org
Subject: draft-ietf-lmap-information-model-06: Reinsert Task Capabil= ities and ma conditions back into the information model

 

Juergen,

 

In draft 05 we removed the ability for a measuremen= t agent to report its metrics that it supports.

We need to add

·         ma-task-capability-obj  ma-supported-t= asks<0..*>;

·         [ma-condition-obj    &n= bsp;   ma-conditions<0..*>;]

 

They were in the ma-status-obj.

--_000_9966516C6EB5FC4381E05BF80AA55F77DC250E1FUS70UWXCHMBA05z_-- From nobody Wed Sep 16 03:09:41 2015 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 9CD401B3AE8 for ; Wed, 16 Sep 2015 03:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpOVjTj4P9Pl for ; Wed, 16 Sep 2015 03:09:37 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 6841A1B3B1D for ; Wed, 16 Sep 2015 03:09:37 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 4063C3E56C184 for ; Wed, 16 Sep 2015 10:09:33 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t8GA9Yds009202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 16 Sep 2015 10:09:34 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Wed, 16 Sep 2015 06:09:33 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: draft-ietf-lmap-information-model-06: New additions for Schedule Object Thread-Index: AdDJYFlq3tM0y3QZSgSEd/aa1KX54QnB2gwQ Date: Wed, 16 Sep 2015 10:09:32 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC250E2C@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC250E2CUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] draft-ietf-lmap-information-model-06: New additions for Schedule Object 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, 16 Sep 2015 10:09:39 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC250E2CUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In light of the Virtual meeting next week I thought I would regenerate an o= pen issue I have with the latest information model that I haven't seen disc= ussion on. BR, Tim From: Carey, Timothy (Timothy) Sent: Tuesday, July 28, 2015 1:08 PM To: lmap@ietf.org Subject: draft-ietf-lmap-information-model-06: New additions for Schedule O= bject Juergen, To help with the controller timeout, I added an indicator to the schedule i= n TR-069 that shows if the Schedule should be used for MA Control actions. = Likewise I added a status parameter to tell if the Schedule is currently op= erationally disabled. Do you think we can add these to the information model? Status string - The current operational state of the Schedule. Enumeration of: * Enabled * Disabled-MA-ControllerTimout * Disabled-Other * Error (OPTIONAL) The Error value MAY be used by the CPE to indicate a locally defined error = condition. UseForMAControl boolean W This parameter defines if the Schedule is to be used for Actions that speci= fic to the BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC250E2CUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In light of the Virtual meeting next = week I thought I would regenerate an open issue I have with the latest info= rmation model that I haven’t seen discussion on.

 

BR,

Tim

 

 

From: Carey, T= imothy (Timothy)
Sent: Tuesday, July 28, 2015 1:08 PM
To: lmap@ietf.org
Subject: draft-ietf-lmap-information-model-06: New additions for Sch= edule Object

 

Juergen,

 

To help with the controller timeout, I added an ind= icator to the schedule in TR-069 that shows if the Schedule should be used = for MA Control actions. Likewise I added a status parameter to tell if the Schedule is currently operationally disabled.

 

Do you think we can add these to the information mo= del?

 

Status

string

-

The current operational state of the Schedule. Enume= ration of:

  • Enabled
    • Disabled-MA-ControllerTimout=
  • Disabled-Other<= /li>
  • Error (OPTIONAL)<= /span>

The Error value MAY be used by the = CPE to indicate a locally defined error condition.

 

 

UseForMAControl

boolean

W

This parameter defines if the Schedule= is to be used for Actions that specific to the 

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC250E2CUS70UWXCHMBA05z_-- From nobody Wed Sep 16 03:11:04 2015 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 0A8DE1B3B29 for ; Wed, 16 Sep 2015 03:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sb6IRe4cxSuZ for ; Wed, 16 Sep 2015 03:11:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 2C87C1B3B27 for ; Wed, 16 Sep 2015 03:10:59 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 75FAFFEEF0B71 for ; Wed, 16 Sep 2015 10:10:54 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t8GAAt34007966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 16 Sep 2015 10:10:56 GMT 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.03.0195.001; Wed, 16 Sep 2015 06:10:55 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: draft-ietf-lmap-information-model-06: Report - Task problems Thread-Index: AdDJTiWlq6CgRjNjQa2l4WuYorZC5wnGc34w Date: Wed, 16 Sep 2015 10:10:54 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC250E5A@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC250E5AUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Report - Task problems 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, 16 Sep 2015 10:11:02 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC250E5AUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In light of the Virtual meeting next week I thought I would regenerate an o= pen issue I have with the latest information model that I haven't seen disc= ussion on. BR, Tim From: Carey, Timothy (Timothy) Sent: Tuesday, July 28, 2015 10:58 AM To: lmap@ietf.org Subject: draft-ietf-lmap-information-model-06: Report - Task problems Juergen, 1) In the ma-report-task-obj, you have the [ma-option-obj ma-repor= t-scheduled-task-options<0..*>]. So do we mean options for MA, the Action o= r the Task? I think we mean the Task here. We also need Action conditions f= or the report right? 2) Use of Registry entry in the Report task; Is this really for a metric= (RegistryEntry) in the task (probably); what about Role of the metric; do = we report on each role/registryentry for the task? (probably) . BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC250E5AUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In light of the Virtual meeting next = week I thought I would regenerate an open issue I have with the latest info= rmation model that I haven’t seen discussion on.

 

BR,

Tim

 

 

From: Carey, T= imothy (Timothy)
Sent: Tuesday, July 28, 2015 10:58 AM
To: lmap@ietf.org
Subject: draft-ietf-lmap-information-model-06: Report - Task problem= s

 

Juergen,

 

1)    In the ma-report-task-obj, you have the [ma= -option-obj       ma-report-scheduled-task-op= tions<0..*>]. So do we mean options for MA, the Action or the Task? I= think we mean the Task here. We also need Action conditions for the report right?

2)    Use of Registry entry in the Report task; I= s this really for a metric (RegistryEntry) in the task (probably); what abo= ut Role of the metric; do we report on each role/registryentry for the task? (probably) .

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC250E5AUS70UWXCHMBA05z_-- From nobody Wed Sep 16 03:11:27 2015 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 D44731B3B2D for ; Wed, 16 Sep 2015 03:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdl5eC5_q4wH for ; Wed, 16 Sep 2015 03:11:24 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 C1A1C1B3B28 for ; Wed, 16 Sep 2015 03:11:23 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 1567CA81AC192 for ; Wed, 16 Sep 2015 10:11:18 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t8GABIlx027425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 16 Sep 2015 10:11:20 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 16 Sep 2015 06:11:19 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: draft-ietf-lmap-information-model-06: Task status object Thread-Index: AdDJRQeckwPfXIUiS+mGVFuobOgxDAnIvujw Date: Wed, 16 Sep 2015 10:11:18 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC250E65@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC250E65US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Task status object 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, 16 Sep 2015 10:11:26 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC250E65US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In light of the Virtual meeting next week I thought I would regenerate an o= pen issue I have with the latest information model that I haven't seen disc= ussion on. BR, Tim From: Carey, Timothy (Timothy) Sent: Tuesday, July 28, 2015 9:53 AM To: lmap@ietf.org Subject: draft-ietf-lmap-information-model-06: Task status object Juergen, In the ma-task-status object you have multiple role with a single registry = entry for a task. Your description in ma-task-status-obj doesn't seem to ad= d up. What if we have a task with multiple metrics (registry entries)? You also have a list of roles - but a registry entry would only be executed= under 1 role. What is the unique functional key of a task status object now - Task Name, = RegistryEntry, Role? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC250E65US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In light of the Virtual meeting next = week I thought I would regenerate an open issue I have with the latest info= rmation model that I haven’t seen discussion on.

 

BR,

Tim

 

 

From: Carey, T= imothy (Timothy)
Sent: Tuesday, July 28, 2015 9:53 AM
To: lmap@ietf.org
Subject: draft-ietf-lmap-information-model-06: Task status object

 

Juergen,

 

 

In the ma-task-status object you have multiple role= with a single registry entry for a task. Your description in ma-task-statu= s-obj doesn’t seem to add up.

 

What if we have a task with multiple metrics (regis= try entries)?

 

You also have a list of roles – but a registr= y entry would only be executed under 1 role.

 

 

What is the unique functional key of a task status = object now – Task Name, RegistryEntry, Role?

 

BR,

Tim

 

 

 

--_000_9966516C6EB5FC4381E05BF80AA55F77DC250E65US70UWXCHMBA05z_-- From nobody Wed Sep 16 03:12:34 2015 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 9FF011A6F3A for ; Wed, 16 Sep 2015 03:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8WVTRDje_ft for ; Wed, 16 Sep 2015 03:12:30 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 87F411A6F34 for ; Wed, 16 Sep 2015 03:12:30 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id B9ED68E188933 for ; Wed, 16 Sep 2015 10:12:26 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t8GACRHs014426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 16 Sep 2015 10:12:27 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Wed, 16 Sep 2015 06:12:26 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: Review of draft-ietf-lmap-information-model-06: Disabling schedules on controller timeout Thread-Index: AdDIoT1fxEvI3zkiRMmSUQt9jimZMQAZr7wQCdgLSkA= Date: Wed, 16 Sep 2015 10:12:24 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC250E74@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC22667F@US70UWXCHMBA05.zam.alcatel-lucent.com> <244dbae6d49b4142a441f0e5534d9b56@rew09926dag03c.domain1.systemhost.net> In-Reply-To: <244dbae6d49b4142a441f0e5534d9b56@rew09926dag03c.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC250E74US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Disabling schedules on controller timeout 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, 16 Sep 2015 10:12:32 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC250E74US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In light of the Virtual meeting next week I thought I would regenerate an o= pen issue I have with the latest information model that I haven't seen disc= ussion on. BR, Tim From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Tuesday, July 28, 2015 2:37 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: Review of draft-ietf-lmap-information-model-06: Disabling sche= dules on controller timeout I think this isn't possible. The Control and Instruction schedules are held= separately and the Control schedules cannot be suppressed. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: 27 July 2015 20:20 To: lmap@ietf.org Subject: [lmap] Review of draft-ietf-lmap-information-model-06: Disabling s= chedules on controller timeout Juergen, I was updating the TR-069 model and still have some questions about the dis= abling of schedules. What happens if I disable a schedule but the schedule references an action = that is MA communication specific AND say an instruction? It really sounds like we are disabling actions not schedules... It certainl= y would be much easier. BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC250E74US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In light of the Virtual meeting next = week I thought I would regenerate an open issue I have with the latest info= rmation model that I haven’t seen discussion on.

 

BR,

Tim

 

 

From: trevor.b= urbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Tuesday, July 28, 2015 2:37 AM
To: Carey, Timothy (Timothy); lmap@ietf.org
Subject: RE: Review of draft-ietf-lmap-information-model-06: Disabli= ng schedules on controller timeout

 

I think= this isn’t possible. The Control and Instruction schedules are held = separately and the Control schedules cannot be suppressed.

&n= bsp;

Trevor.=

&n= bsp;

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 27 July 2015 20:20
To: lmap@ietf.org
Subject: [lmap] Review of draft-ietf-lmap-information-model-06: Disa= bling schedules on controller timeout

 

Juergen,

 

I was updating the TR-069 model and still have some= questions about the disabling of schedules.

 

What happens if I disable a schedule but the schedu= le references an action that is MA communication specific AND say an instru= ction?

 

It really sounds like we are disabling actions not = schedules… It certainly would be much easier.

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC250E74US70UWXCHMBA05z_-- From nobody Wed Sep 16 03:15:52 2015 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 5BCA41A0111 for ; Wed, 16 Sep 2015 03:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rr0r4KY46LhH for ; Wed, 16 Sep 2015 03:15:44 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 7AD981A0117 for ; Wed, 16 Sep 2015 03:15:42 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id C124AAF833567 for ; Wed, 16 Sep 2015 10:15:37 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t8GAFcrq014264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 16 Sep 2015 10:15:39 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Wed, 16 Sep 2015 06:15:39 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: Review of draft-ietf-lmap-information-model-06: Action Execution Mode questions Thread-Index: AdDIopjZyz/Kw0xSTYWzPqJYAgTc7QnxgHiw Date: Wed, 16 Sep 2015 10:15:37 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC250EA5@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC250EA5US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action Execution Mode questions 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, 16 Sep 2015 10:15:49 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC250EA5US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In light of the Virtual meeting next week I thought I would regenerate an o= pen issue I have with the latest information model that I haven't seen disc= ussion on. BR, Tim From: Carey, Timothy (Timothy) Sent: Monday, July 27, 2015 2:30 PM To: lmap@ietf.org Subject: Review of draft-ietf-lmap-information-model-06: Action Execution M= ode questions Juergen, In reviewing this draft for the TR-069 model update I had a question on the= Execution mode. We say there are 3 modes - Sequential, Parallel and Pipelined. For sequential - What is the value that orders the list? I don't see an ord= ering the action or indication that this is an ordered list of actions. For pipelining - I don't understand this mode - are we saying that this is = a Sequential mode plus all the outputs for executing Action are inputted to= the next Action in the Sequence or is the Pipeline mode somehow relevant f= or Output destinations? If so why wouldn't pipeline simply be sequential or= paralled with output destinations? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC250EA5US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In light of the Virtual meeting next = week I thought I would regenerate an open issue I have with the latest info= rmation model that I haven’t seen discussion on.

 

BR,

Tim

 

 

From: Carey, T= imothy (Timothy)
Sent: Monday, July 27, 2015 2:30 PM
To: lmap@ietf.org
Subject: Review of draft-ietf-lmap-information-model-06: Action Exec= ution Mode questions

 

Juergen,

 

In reviewing this draft for the TR-069 model update= I had a question on the Execution mode.

We say there are 3 modes – Sequential, Parall= el and Pipelined.

For sequential – What is the value that order= s the list? I don’t see an ordering the action or indication that thi= s is an ordered list of actions.

 

For pipelining – I don’t understand thi= s mode – are we saying that this is a Sequential mode plus all the ou= tputs for executing Action are inputted to the next Action in the Sequence or is the Pipeline mode somehow relevant for Output destinations? If so wh= y wouldn’t pipeline simply be sequential or paralled with output dest= inations?

 

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC250EA5US70UWXCHMBA05z_-- From nobody Wed Sep 16 12:03:52 2015 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 609E31A9036 for ; Wed, 16 Sep 2015 12:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.138 X-Spam-Level: ** X-Spam-Status: No, score=2.138 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3y9wJThozfN for ; Wed, 16 Sep 2015 12:03:51 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) (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 D0F571A9032 for ; Wed, 16 Sep 2015 12:03:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id 7359B145CC6; Wed, 16 Sep 2015 16:03:48 -0300 (BRT) X-Virus-Scanned: Debian amavisd-new at mail.nic.br Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctLJ3tgvRvb3; Wed, 16 Sep 2015 16:03:47 -0300 (BRT) Received: from 5.140.net.registro.br (unknown [IPv6:2001:12ff:0:5::140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 3797C145C7F; Wed, 16 Sep 2015 16:03:47 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1442430227; bh=9CyobQ2gMJoUx1EsHK+DJB2tZaTYrvikwVRLZO17X64=; h=From:Subject:Date:Cc:To:From; b=bAPiuKzcM0bh6G9MOzZLhVSzHty7bpQsaggCDZD9X/75dOQGYaR6Ewr7mOfh3FjyJ bsVM/2cb/LMGLcF+0iikeCMsMqmWPYNq3j3O4vv+/SL0tOrcmzmGslSNGGly0RqV/w 985qYbZCmfTABLrzQeL72zGssHcjTGZlr0dw2K28= From: Holger Wiehen Content-Type: multipart/alternative; boundary="Apple-Mail=_D9FEE417-019C-4EF9-AF42-5DB504E723DA" Date: Wed, 16 Sep 2015 16:03:47 -0300 Message-Id: <434D830D-7592-4237-8AF2-2B5A869146C2@nic.br> To: lmap@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br 3797C145C7F Archived-At: Cc: Fabricio Tamusiunas Subject: [lmap] Standard for coordination between MAs 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, 16 Sep 2015 19:03:52 -0000 --Apple-Mail=_D9FEE417-019C-4EF9-AF42-5DB504E723DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi. At NIC.br , Brazilian=E2=80=99s network information = center, we are constructing a measurement system that performs active = traffic measurement, to monitor broadband access networks. In this = context, we are migrating to an LMAP architecture. Beyond LMAP=E2=80=99s = scope our use case requires some control and reporting between pairs of = MAs. We would like to architect this inter-MA coordination in an standards = compliant way. Our evaluation of IPPM standards like OWAMP and TWAMP = showed that currently there is no control or report protocol between = MA=E2=80=99s solving this problem in a sufficiently generic way, as the = former 2 standards are tied to specific measurement models. We think a standard for inter-MA communication, is a missing piece to = deliver on LMAP=E2=80=99s vision of coordinated large scale = measurements. =20 Would it be possible to work on such a standard in the LMAP WG, to = ensure a consistent point of view?=20 Our team would like to initiate this effort and to collaborate with the = WG. Please comment on our suggestion. Regards, Holger Wiehen. Holger Wiehen=20 Project Analyst SIMET - Internet Traffic Measurement Systems=20 +55 11 5509-3537 R.: 4114=20 www.nic.br --Apple-Mail=_D9FEE417-019C-4EF9-AF42-5DB504E723DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi.

At NIC.br, Brazilian=E2=80=99s network information center, = we are constructing a measurement system that performs active traffic = measurement, to monitor broadband access networks. In this context, we = are migrating to an LMAP architecture. Beyond LMAP=E2=80=99s scope our = use case requires some control and reporting between pairs of = MAs.

We would = like to architect this inter-MA coordination in an standards compliant = way. Our evaluation of IPPM standards like OWAMP and TWAMP showed that = currently there is no control or report protocol between MA=E2=80=99s = solving this problem in a sufficiently generic way, as the former 2 = standards are tied to specific measurement models.

We think a standard for = inter-MA communication, is a missing piece to deliver on LMAP=E2=80=99s = vision of coordinated large scale measurements.     =  

Would = it be possible to work on such a standard in the LMAP WG, to ensure a = consistent point of view? 
Our team would like = to initiate this effort and to collaborate with the WG.

Please comment on our = suggestion.

Regards,

Holger Wiehen.



3D"NIC.br Holger Wiehen
Project = Analyst
= SIMET - Internet Traffic Measurement Systems 
 +55 11 5509-3537 R.: 4114
= www.nic.br



= --Apple-Mail=_D9FEE417-019C-4EF9-AF42-5DB504E723DA-- From nobody Wed Sep 16 13:00:17 2015 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 90E271A0399 for ; Wed, 16 Sep 2015 13:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvJNQLTolynt for ; Wed, 16 Sep 2015 13:00:11 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4FC1A037B for ; Wed, 16 Sep 2015 13:00:11 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 2A1D61223C0; Wed, 16 Sep 2015 16:26:12 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id E087BF0495; Wed, 16 Sep 2015 16:00:10 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Wed, 16 Sep 2015 16:00:10 -0400 From: "MORTON, ALFRED C (AL)" To: Holger Wiehen , "lmap@ietf.org" Date: Wed, 16 Sep 2015 16:00:09 -0400 Thread-Topic: [lmap] Standard for coordination between MAs Thread-Index: AdDwsnlotNFMY7WUTv6zpiywsocJlQABgcwQ Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB45814F1@NJFPSRVEXG0.research.att.com> References: <434D830D-7592-4237-8AF2-2B5A869146C2@nic.br> In-Reply-To: <434D830D-7592-4237-8AF2-2B5A869146C2@nic.br> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D0BB45814F1NJFPSRVEXG0re_" MIME-Version: 1.0 Archived-At: Cc: Fabricio Tamusiunas Subject: Re: [lmap] Standard for coordination between MAs 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, 16 Sep 2015 20:00:14 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D0BB45814F1NJFPSRVEXG0re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSG9sZ2VyLA0KDQpDYW4geW91IGdpdmUgYSBzcGVjaWZpYyBleGFtcGxlIG9mIE1BIHRvIE1B IGNvbW11bmljYXRpb24gdGhhdDoNCg0KDQotICAgY2Fubm90IGJlIGFjY29tcGxpc2hlZCB0aHJv dWdoIHBhcmFsbGVsIENvbnRyb2xsZXIvUmVwb3J0ZXIgdG8gTUEgQ29tbXVuaWNhdGlvbnMNCg0K LSAgIGNhbm5vdCBiZSBhY2NvbXBsaXNoZWQgYnkgZXh0ZW5kaW5nIE9XQU1QIG9yIFRXQU1QIENv bnRyb2wgYW5kIEZldGNoDQoNCnByb3RvY29scw0KDQpJZiBzbywgdGhhdOKAmXMgYSBzdGFydGlu ZyBwbGFjZSBmb3IgZGlzY3Vzc2lvbiBvZiB0aGUgcHJvYmxlbS4NCnRoYW5rcywNCkFsDQoNCkZy b206IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIb2xn ZXIgV2llaGVuDQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxNiwgMjAxNSAzOjA0IFBNDQpU bzogbG1hcEBpZXRmLm9yZw0KQ2M6IEZhYnJpY2lvIFRhbXVzaXVuYXMNClN1YmplY3Q6IFtsbWFw XSBTdGFuZGFyZCBmb3IgY29vcmRpbmF0aW9uIGJldHdlZW4gTUFzDQoNCkhpLg0KDQpBdCBOSUMu YnI8aHR0cDovL05JQy5icj4sIEJyYXppbGlhbuKAmXMgbmV0d29yayBpbmZvcm1hdGlvbiBjZW50 ZXIsIHdlIGFyZSBjb25zdHJ1Y3RpbmcgYSBtZWFzdXJlbWVudCBzeXN0ZW0gdGhhdCBwZXJmb3Jt cyBhY3RpdmUgdHJhZmZpYyBtZWFzdXJlbWVudCwgdG8gbW9uaXRvciBicm9hZGJhbmQgYWNjZXNz IG5ldHdvcmtzLiBJbiB0aGlzIGNvbnRleHQsIHdlIGFyZSBtaWdyYXRpbmcgdG8gYW4gTE1BUCBh cmNoaXRlY3R1cmUuIEJleW9uZCBMTUFQ4oCZcyBzY29wZSBvdXIgdXNlIGNhc2UgcmVxdWlyZXMg c29tZSBjb250cm9sIGFuZCByZXBvcnRpbmcgYmV0d2VlbiBwYWlycyBvZiBNQXMuDQoNCldlIHdv dWxkIGxpa2UgdG8gYXJjaGl0ZWN0IHRoaXMgaW50ZXItTUEgY29vcmRpbmF0aW9uIGluIGFuIHN0 YW5kYXJkcyBjb21wbGlhbnQgd2F5LiBPdXIgZXZhbHVhdGlvbiBvZiBJUFBNIHN0YW5kYXJkcyBs aWtlIE9XQU1QIGFuZCBUV0FNUCBzaG93ZWQgdGhhdCBjdXJyZW50bHkgdGhlcmUgaXMgbm8gY29u dHJvbCBvciByZXBvcnQgcHJvdG9jb2wgYmV0d2VlbiBNQeKAmXMgc29sdmluZyB0aGlzIHByb2Js ZW0gaW4gYSBzdWZmaWNpZW50bHkgZ2VuZXJpYyB3YXksIGFzIHRoZSBmb3JtZXIgMiBzdGFuZGFy ZHMgYXJlIHRpZWQgdG8gc3BlY2lmaWMgbWVhc3VyZW1lbnQgbW9kZWxzLg0KDQpXZSB0aGluayBh IHN0YW5kYXJkIGZvciBpbnRlci1NQSBjb21tdW5pY2F0aW9uLCBpcyBhIG1pc3NpbmcgcGllY2Ug dG8gZGVsaXZlciBvbiBMTUFQ4oCZcyB2aXNpb24gb2YgY29vcmRpbmF0ZWQgbGFyZ2Ugc2NhbGUg bWVhc3VyZW1lbnRzLg0KDQpXb3VsZCBpdCBiZSBwb3NzaWJsZSB0byB3b3JrIG9uIHN1Y2ggYSBz dGFuZGFyZCBpbiB0aGUgTE1BUCBXRywgdG8gZW5zdXJlIGEgY29uc2lzdGVudCBwb2ludCBvZiB2 aWV3Pw0KT3VyIHRlYW0gd291bGQgbGlrZSB0byBpbml0aWF0ZSB0aGlzIGVmZm9ydCBhbmQgdG8g Y29sbGFib3JhdGUgd2l0aCB0aGUgV0cuDQoNClBsZWFzZSBjb21tZW50IG9uIG91ciBzdWdnZXN0 aW9uLg0KDQpSZWdhcmRzLA0KDQpIb2xnZXIgV2llaGVuLg0KDQoNCg0KW2h0dHA6Ly9uaWMuYnIv YXNzaW5hdHVyYS9hc3NpbmF0dXJhLW5pYy1sZy5wbmddSG9sZ2VyIFdpZWhlbg0KUHJvamVjdCBB bmFseXN0DQpTSU1FVCAtIEludGVybmV0IFRyYWZmaWMgTWVhc3VyZW1lbnQgU3lzdGVtcw0KKzU1 IDExIDU1MDktMzUzNyBSLjogNDExNA0Kd3d3Lm5pYy5icjxodHRwOi8vbmljLmJyPg0KDQoNCg== --_000_4AF73AA205019A4C8A1DDD32C034631D0BB45814F1NJFPSRVEXG0re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAg MCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUg MCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiSGVs dmV0aWNhIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFs Ow0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiSGVs dmV0aWNhIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFs Ow0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90 dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 fQ0KcC5ib2xkLCBsaS5ib2xkLCBkaXYuYm9sZA0KCXttc28tc3R5bGUtbmFtZTpib2xkOw0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglmb250LXdlaWdodDpib2xk O30NCnAuaXRhbGljLCBsaS5pdGFsaWMsIGRpdi5pdGFsaWMNCgl7bXNvLXN0eWxlLW5hbWU6aXRh bGljOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglmb250LXN0 eWxlOml0YWxpYzt9DQpzcGFuLmJvbGQxDQoJe21zby1zdHlsZS1uYW1lOmJvbGQxOw0KCWZvbnQt ZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazsNCglmb250LXdl aWdodDpib2xkOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNDQ5MjA0OTMxOw0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo4Mzc3NDIwNzYgLTIwNDA4NzUzNjQg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDow Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDoyNC43NXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo2MC43NXB0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDo5Ni43NXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEzMi43NXB0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDoxNjguNzVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu LWxlZnQ6MjA0Ljc1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjQwLjc1cHQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjI3Ni43NXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoz MTIuNzVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48 L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsYWNrIHZsaW5rPWJsYWNrPjxkaXYgY2xhc3M9 V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz5IaSBIb2xnZXIsPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPkNhbiB5 b3UgZ2l2ZSBhIHNwZWNpZmljIGV4YW1wbGUgb2YgTUEgdG8gTUEgY29tbXVuaWNhdGlvbiB0aGF0 OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9 J21hcmdpbi1sZWZ0OjI0Ljc1cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVs MSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48c3BhbiBzdHlsZT0nbXNv LWxpc3Q6SWdub3JlJz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+ Y2Fubm90IGJlIGFjY29tcGxpc2hlZCB0aHJvdWdoIHBhcmFsbGVsIENvbnRyb2xsZXIvUmVwb3J0 ZXIgdG8gTUEgQ29tbXVuaWNhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv TGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6MjQuNzVwdDt0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6Ymxh Y2snPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBw dCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciO2NvbG9yOmJsYWNrJz5jYW5ub3QgYmUgYWNjb21wbGlzaGVkIGJ5IGV4dGVuZGluZyBP V0FNUCBvciBUV0FNUCBDb250cm9sIGFuZCBGZXRjaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDoyNC43NXB0Jz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJs YWNrJz5wcm90b2NvbHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29s b3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtj b2xvcjpibGFjayc+SWYgc28sIHRoYXTigJlzIGEgc3RhcnRpbmcgcGxhY2UgZm9yIGRpc2N1c3Np b24gb2YgdGhlIHByb2JsZW0uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci O2NvbG9yOmJsYWNrJz50aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciO2NvbG9yOmJsYWNrJz5BbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFs PjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IGxtYXAgW21haWx0bzpsbWFwLWJv dW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+SG9sZ2VyIFdpZWhlbjxicj48Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTYsIDIwMTUgMzowNCBQTTxicj48Yj5Ubzo8 L2I+IGxtYXBAaWV0Zi5vcmc8YnI+PGI+Q2M6PC9iPiBGYWJyaWNpbyBUYW11c2l1bmFzPGJyPjxi PlN1YmplY3Q6PC9iPiBbbG1hcF0gU3RhbmRhcmQgZm9yIGNvb3JkaW5hdGlvbiBiZXR3ZWVuIE1B czxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SGkuPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+QXQgPGEgaHJlZj0iaHR0cDovL05JQy5iciI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1z ZXJpZiInPk5JQy5icjwvc3Bhbj48L2E+LCBCcmF6aWxpYW7igJlzIG5ldHdvcmsgaW5mb3JtYXRp b24gY2VudGVyLCB3ZSBhcmUgY29uc3RydWN0aW5nIGEgbWVhc3VyZW1lbnQgc3lzdGVtIHRoYXQg cGVyZm9ybXMgYWN0aXZlIHRyYWZmaWMgbWVhc3VyZW1lbnQsIHRvIG1vbml0b3IgYnJvYWRiYW5k IGFjY2VzcyBuZXR3b3Jrcy4gSW4gdGhpcyBjb250ZXh0LCB3ZSBhcmUgbWlncmF0aW5nIHRvIGFu IExNQVAgYXJjaGl0ZWN0dXJlLiBCZXlvbmQgTE1BUOKAmXMgc2NvcGUgb3VyIHVzZSBjYXNlIHJl cXVpcmVzIHNvbWUgY29udHJvbCBhbmQgcmVwb3J0aW5nIGJldHdlZW4gcGFpcnMgb2YgTUFzLjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPldlIHdvdWxkIGxpa2UgdG8gYXJj aGl0ZWN0IHRoaXMgaW50ZXItTUEgY29vcmRpbmF0aW9uIGluIGFuIHN0YW5kYXJkcyBjb21wbGlh bnQgd2F5LiBPdXIgZXZhbHVhdGlvbiBvZiBJUFBNIHN0YW5kYXJkcyBsaWtlIE9XQU1QIGFuZCBU V0FNUCBzaG93ZWQgdGhhdCBjdXJyZW50bHkgdGhlcmUgaXMgbm8gY29udHJvbCBvciByZXBvcnQg cHJvdG9jb2wgYmV0d2VlbiBNQeKAmXMgc29sdmluZyB0aGlzIHByb2JsZW0gaW4gYSBzdWZmaWNp ZW50bHkgZ2VuZXJpYyB3YXksIGFzIHRoZSBmb3JtZXIgMiBzdGFuZGFyZHMgYXJlIHRpZWQgdG8g c3BlY2lmaWMgbWVhc3VyZW1lbnQgbW9kZWxzLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPldlIHRoaW5rIGEgc3RhbmRhcmQgZm9yIGludGVyLU1BIGNvbW11bmljYXRpb24s IGlzIGEgbWlzc2luZyBwaWVjZSB0byBkZWxpdmVyIG9uIExNQVDigJlzIHZpc2lvbiBvZiBjb29y ZGluYXRlZCBsYXJnZSBzY2FsZSBtZWFzdXJlbWVudHMuICZuYnNwOyAmbmJzcDsgJm5ic3A7PG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+V291bGQgaXQgYmUgcG9zc2libGUg dG8gd29yayBvbiBzdWNoIGEgc3RhbmRhcmQgaW4gdGhlIExNQVAgV0csIHRvIGVuc3VyZSBhIGNv bnNpc3RlbnQgcG9pbnQgb2Ygdmlldz8mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5PdXIgdGVhbSB3b3VsZCBsaWtlIHRvIGluaXRpYXRlIHRoaXMgZWZm b3J0IGFuZCB0byBjb2xsYWJvcmF0ZSB3aXRoIHRoZSBXRy48bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5QbGVhc2UgY29tbWVudCBvbiBvdXIgc3VnZ2VzdGlvbi48bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPkhvbGdlciBXaWVoZW4uPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGltZyBib3JkZXI9MCBpZD0iX3gwMDAwX2kxMDI1IiBz cmM9Imh0dHA6Ly9uaWMuYnIvYXNzaW5hdHVyYS9hc3NpbmF0dXJhLW5pYy1sZy5wbmciIGFsdD0i TklDLmJyIHwgIj48c3BhbiBjbGFzcz1ib2xkMT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0 Jz5Ib2xnZXIgV2llaGVuPC9zcGFuPjwvc3Bhbj4gPGJyPjxpPlByb2plY3QgQW5hbHlzdDwvaT48 YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwi c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPlNJTUVUIC0gSW50ZXJuZXQgVHJhZmZpYyBNZWFzdXJl bWVudCBTeXN0ZW1zJm5ic3A7PGJyPis1NSA8c3BhbiBjbGFzcz1ib2xkMT4xMSA1NTA5LTM1Mzc8 L3NwYW4+IFIuOiA8c3BhbiBjbGFzcz1ib2xkMT40MTE0IDwvc3Bhbj48L3NwYW4+PGJyPjxhIGhy ZWY9Imh0dHA6Ly9uaWMuYnIiPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz53d3cubmljLmJyPC9zcGFuPjwvYj48L2E+ PGJyPjxicj48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_4AF73AA205019A4C8A1DDD32C034631D0BB45814F1NJFPSRVEXG0re_-- From nobody Thu Sep 17 15:03:25 2015 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 A88B81A8821 for ; Thu, 17 Sep 2015 15:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1a-T5gUmGKi for ; Thu, 17 Sep 2015 15:03:22 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [200.160.4.5]) (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 DAB051A87EB for ; Thu, 17 Sep 2015 15:03:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id 6150B145EA8 for ; Thu, 17 Sep 2015 19:03:19 -0300 (BRT) X-Virus-Scanned: Debian amavisd-new at mail.nic.br Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TtqNMWng3Df for ; Thu, 17 Sep 2015 19:03:15 -0300 (BRT) Received: from 5.140.net.registro.br (unknown [IPv6:2001:12ff:0:5::140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 5E6CE145EEF for ; Thu, 17 Sep 2015 19:03:15 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1442527395; bh=t621iF1ff43x24LDDSkIlSm+E0uH8hy9RehWD6Dm1m0=; h=From:Subject:Date:References:To:In-Reply-To:From; b=KDyF8yfBc+M4suDFvo2NudRfJ1O4GvzdTpIdKki8MeA4jSapDSKuoYFXlZVWhKIv7 cpFKTyKwbr2dBe0PuuTQnymg4Sicj0kwx2sUuGgdbh56Wn03QMXMOg8j/ilM1u9qUf 4gRGoxkReVdFgteB3XbnoP74ZevqQBQnSH6rn/Ro= From: Holger Wiehen Content-Type: multipart/alternative; boundary="Apple-Mail=_46EDD860-263D-479A-ACC1-9667C9736849" Message-Id: <55D149D8-329D-4D95-89A0-7E4621F16417@nic.br> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Date: Thu, 17 Sep 2015 19:03:14 -0300 References: <434D830D-7592-4237-8AF2-2B5A869146C2@nic.br> <4AF73AA205019A4C8A1DDD32C034631D0BB45814F1@NJFPSRVEXG0.research.att.com> To: lmap@ietf.org In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB45814F1@NJFPSRVEXG0.research.att.com> X-Mailer: Apple Mail (2.2104) DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br 5E6CE145EEF Archived-At: Subject: Re: [lmap] Standard for coordination between MAs 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, 17 Sep 2015 22:03:24 -0000 --Apple-Mail=_46EDD860-263D-479A-ACC1-9667C9736849 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Al. Thank's for your reply. I will try illustrate our idea of MA Communications with 2 example use = cases. One example would be a MA initiated by a human user, executing = measurements against a remote MA. Results obtained on the remote MA = should be presented to the end user (local MA), with low delay. I understand that pushing results to a MA could not be solved with the = report flow specified by LMAP. In an end user focused use case, = exchanging reports directly between MAs, would allow for quick and = resilient reporting to users. This reporting would be in addition to the = usual report submission to the LMAP collector. A second use case is a MA responding active measurements initiated by = another MA. Our responding MA receives its configuration from the LMAP = controller, but once it is set up, it does not depend on the control = channel in order to respond to measurements initiated by a remote MA. = The responding MA receives parameters specific to a single measurement = session, from the initiating MA. Coordinating active measurements = directly between MAs would increase resilience and reduce timing issues. A limitation I see with OWAMP is the requirement of synchronised clocks, = not guaranteed with MAs executed on arbitrary devices, controlled by an = end user. Also its concepts like a send schedule, with pre-defined send = intervals, and tracking of individual packages, are tailored towards = latency and loss measurement. I am not able to identify an extension for = bandwidth measurements, based on these concepts.=20 A protocol for MA Communications, on top of LMAP=E2=80=99s current = scope, would provide a solution following LMAP=E2=80=99s concepts and = extend its information model in a consistent way. Your opinion would be very welcome. Thank=E2=80=99s. Holger. > On Sep 16, 2015, at 5:00 PM, MORTON, ALFRED C (AL) = wrote: >=20 > Hi Holger, > =20 > Can you give a specific example of MA to MA communication that: > =20 > - cannot be accomplished through parallel Controller/Reporter to MA = Communications > - cannot be accomplished by extending OWAMP or TWAMP Control and = Fetch > protocols > =20 > If so, that=E2=80=99s a starting place for discussion of the problem. > thanks, > Al > =20 > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Holger Wiehen > Sent: Wednesday, September 16, 2015 3:04 PM > To: lmap@ietf.org > Cc: Fabricio Tamusiunas > Subject: [lmap] Standard for coordination between MAs > =20 > Hi. > =20 > At NIC.br , Brazilian=E2=80=99s network information = center, we are constructing a measurement system that performs active = traffic measurement, to monitor broadband access networks. In this = context, we are migrating to an LMAP architecture. Beyond LMAP=E2=80=99s = scope our use case requires some control and reporting between pairs of = MAs. > =20 > We would like to architect this inter-MA coordination in an standards = compliant way. Our evaluation of IPPM standards like OWAMP and TWAMP = showed that currently there is no control or report protocol between = MA=E2=80=99s solving this problem in a sufficiently generic way, as the = former 2 standards are tied to specific measurement models. > =20 > We think a standard for inter-MA communication, is a missing piece to = deliver on LMAP=E2=80=99s vision of coordinated large scale = measurements. =20 > =20 > Would it be possible to work on such a standard in the LMAP WG, to = ensure a consistent point of view?=20 > Our team would like to initiate this effort and to collaborate with = the WG. > =20 > Please comment on our suggestion. > =20 > Regards, > =20 > Holger Wiehen. > =20 > =20 > =20 > Holger Wiehen=20 > Project Analyst > SIMET - Internet Traffic Measurement Systems=20 > +55 11 5509-3537 R.: 4114=20 > www.nic.br --Apple-Mail=_46EDD860-263D-479A-ACC1-9667C9736849 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Al.

Thank's for your reply.

I will try illustrate = our idea of MA Communications with 2 example use cases.

One example would be a = MA initiated by a human user, executing measurements against a remote = MA. Results obtained on the remote MA should be presented to the end = user (local MA), with low delay.

I understand that pushing results to a = MA could not be solved with the report flow specified by LMAP. In an end = user focused use case, exchanging reports directly between MAs, would = allow for quick and resilient reporting to users. This reporting would = be in addition to the usual report submission to the LMAP = collector.

A = second use case is a MA responding active measurements initiated by = another MA. Our responding MA receives its configuration from the LMAP = controller, but once it is set up, it does not depend on the control = channel in order to respond to measurements initiated by a remote MA. = The responding MA receives parameters specific to a single measurement = session, from the initiating MA. Coordinating active measurements = directly between MAs would increase resilience and reduce timing = issues.

A = limitation I see with OWAMP is the requirement of synchronised clocks, = not guaranteed with MAs executed on arbitrary devices, controlled by an = end user. Also its concepts like a send schedule, with pre-defined send = intervals, and tracking of individual packages, are tailored towards = latency and loss measurement. I am not able to identify an extension for = bandwidth measurements, based on these concepts. 

A protocol for MA = Communications, on top of LMAP=E2=80=99s current scope, would provide a = solution following LMAP=E2=80=99s concepts and extend its information = model in a consistent way.


Your opinion would be = very welcome.


Thank=E2=80=99s.


Holger.





On Sep 16, 2015, at 5:00 PM, MORTON, ALFRED C (AL) <acmorton@att.com> = wrote:

Hi = Holger,
 
Can = you give a specific example of MA to MA communication that:
 
-   cannot = be accomplished through parallel Controller/Reporter to MA = Communications
-   cannot = be accomplished by extending OWAMP or TWAMP Control and Fetch
protocols
 
If so, that=E2=80=99s a starting = place for discussion of the problem.
thanks,
Al
 
From: lmap [mailto:lmap-bounces@ietf.org] On Behalf = Of Holger = Wiehen
Sent: Wednesday, September 16, = 2015 3:04 PM
To: lmap@ietf.org
Cc: Fabricio Tamusiunas
Subject: [lmap] Standard for = coordination between MAs
 
Hi.
 
At NIC.br, Brazilian=E2=80=99s network information = center, we are constructing a measurement system that performs active = traffic measurement, to monitor broadband access networks. In this = context, we are migrating to an LMAP architecture. Beyond LMAP=E2=80=99s = scope our use case requires some control and reporting between pairs of = MAs.
 
We would like to architect this inter-MA coordination = in an standards compliant way. Our evaluation of IPPM standards like = OWAMP and TWAMP showed that currently there is no control or report = protocol between MA=E2=80=99s solving this problem in a sufficiently = generic way, as the former 2 standards are tied to specific measurement = models.
 
We think a standard for inter-MA communication, is a = missing piece to deliver on LMAP=E2=80=99s vision of coordinated large = scale measurements.      
 
Would it be possible to work on such a = standard in the LMAP WG, to ensure a consistent point of view? 
Our team would like to initiate this effort and to = collaborate with the WG.
 
Please comment on our suggestion.
 
Regards,
 
Holger Wiehen.
 
 
 

3D"NIC.brHolger Wiehen 
Project Analyst
SIMET - Internet = Traffic Measurement Systems 
+55 11 5509-3537 R.: 4114 
www.nic.br


= --Apple-Mail=_46EDD860-263D-479A-ACC1-9667C9736849-- From nobody Fri Sep 18 08:33:20 2015 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 0C4FA1B2DF0; Fri, 18 Sep 2015 08:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fKgEjKs18no; Fri, 18 Sep 2015 08:33:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id AD4101B2DED; Fri, 18 Sep 2015 08:33:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1A149180092; Fri, 18 Sep 2015 08:32:39 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150918153239.1A149180092@rfc-editor.org> Date: Fri, 18 Sep 2015 08:32:39 -0700 (PDT) Archived-At: Cc: lmap@ietf.org, rfc-editor@rfc-editor.org Subject: [lmap] RFC 7594 on A Framework for Large-Scale Measurement of Broadband Performance (LMAP) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 15:33:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7594 Title: A Framework for Large-Scale Measurement of Broadband Performance (LMAP) Author: P. Eardley, A. Morton, M. Bagnulo, T. Burbridge, P. Aitken, A. Akhter Status: Informational Stream: IETF Date: September 2015 Mailbox: philip.eardley@bt.com, acmorton@att.com, marcelo@it.uc3m.es, trevor.burbridge@bt.com, paitken@brocade.com, aakhter@gmail.com Pages: 55 Characters: 131972 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-lmap-framework-14.txt URL: https://www.rfc-editor.org/info/rfc7594 DOI: http://dx.doi.org/10.17487/RFC7594 Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. This document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (Large-Scale Measurement of Broadband Performance). This document is a product of the Large-Scale Measurement of Broadband Performance Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Sep 18 12:13:07 2015 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 C94CC1B32BF for ; Fri, 18 Sep 2015 12:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iISg3a0fTC-j for ; Fri, 18 Sep 2015 12:13:04 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3373D1B32B9 for ; Fri, 18 Sep 2015 12:13:04 -0700 (PDT) X-SENDER-IP: 10.64.163.157 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.17,554,1437451200"; d="scan'208";a="779663596" Received: from unknown (HELO exchpapp16.corp.twcable.com) ([10.64.163.157]) by cdpipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 18 Sep 2015 15:10:19 -0400 Received: from EXCHPAPP11.corp.twcable.com (10.64.163.152) by exchpapp16.corp.twcable.com (10.64.163.157) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 18 Sep 2015 15:13:01 -0400 Received: from EXCHPAPP11.corp.twcable.com ([169.254.97.52]) by exchpapp11.corp.twcable.com ([10.245.162.16]) with mapi id 15.00.1104.000; Fri, 18 Sep 2015 15:13:01 -0400 From: "Weil, Jason" To: "lmap@ietf.org" Thread-Topic: RFC 7594 on A Framework for Large-Scale Measurement of Broadband Performance (LMAP) Thread-Index: AQHQ8kYJPaitV3rfPUW/RjsaNT4HzQ== Date: Fri, 18 Sep 2015 19:13:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.239] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21824.002 x-tm-as-result: No--47.259000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lmap] RFC 7594 on A Framework for Large-Scale Measurement of Broadband Performance (LMAP) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 19:13:05 -0000 Congrats everyone for their work on getting the LMAP Framework published! Jason On 9/18/15, 11:32 AM, "lmap on behalf of rfc-editor@rfc-editor.org" wrote: >A new Request for Comments is now available in online RFC libraries. > > > RFC 7594 > > Title: A Framework for Large-Scale Measurement > of Broadband Performance (LMAP) > Author: P. Eardley, > A. Morton, > M. Bagnulo, > T. Burbridge, > P. Aitken, > A. Akhter > Status: Informational > Stream: IETF > Date: September 2015 > Mailbox: philip.eardley@bt.com, > acmorton@att.com, > marcelo@it.uc3m.es, > trevor.burbridge@bt.com, > paitken@brocade.com, > aakhter@gmail.com > Pages: 55 > Characters: 131972 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-lmap-framework-14.txt > > URL: https://www.rfc-editor.org/info/rfc7594 > > DOI: http://dx.doi.org/10.17487/RFC7594 > >Measuring broadband service on a large scale requires a description >of the logical architecture and standardisation of the key protocols >that coordinate interactions between the components. This document >presents an overall framework for large-scale measurements. It also >defines terminology for LMAP (Large-Scale Measurement of Broadband >Performance). > >This document is a product of the Large-Scale Measurement of Broadband >Performance Working Group of the IETF. > > >INFORMATIONAL: This memo provides information for the Internet community. >It does not specify an Internet standard of any kind. Distribution of >this memo is unlimited. > >This announcement is sent to the IETF-Announce and rfc-dist lists. >To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > >For searching the RFC series, see https://www.rfc-editor.org/search >For downloading RFCs, see https://www.rfc-editor.org/rfc.html > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution. > > >The RFC Editor Team >Association Management Solutions, LLC > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Sat Sep 19 23:56:17 2015 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 1DC1D1B3E42 for ; Sat, 19 Sep 2015 23:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNblH3GZDWTc for ; Sat, 19 Sep 2015 23:56:14 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90B21B3E44 for ; Sat, 19 Sep 2015 23:56:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DvAQBcV/5V/xUHmMZdGQEBAYJcLFRpBr07AQ2Bc4YBAoEbOBQBAQEBAQEBfwuEIwEBAQEDEihLBAIBCA0EAwEBAQsUCQchERQJCAIEEwgah3cDEgGrQplGDYRqAQEBAQYBAQEBAQEBARqGdYR7gT2BE4FpIzgGgxKBFAWVZAGFEIYHAYQBhwSKRIc/HwEBQoJDgT5xiC46gQUBAQE X-IPAS-Result: A2DvAQBcV/5V/xUHmMZdGQEBAYJcLFRpBr07AQ2Bc4YBAoEbOBQBAQEBAQEBfwuEIwEBAQEDEihLBAIBCA0EAwEBAQsUCQchERQJCAIEEwgah3cDEgGrQplGDYRqAQEBAQYBAQEBAQEBARqGdYR7gT2BE4FpIzgGgxKBFAWVZAGFEIYHAYQBhwSKRIc/HwEBQoJDgT5xiC46gQUBAQE X-IronPort-AV: E=Sophos;i="5.17,561,1437451200"; d="scan'208";a="137250279" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Sep 2015 02:56:13 -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; 20 Sep 2015 02:56:13 -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; Sun, 20 Sep 2015 08:56:12 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [lmap] RFC 7594 on A Framework for Large-Scale Measurement of Broadband Performance (LMAP) Thread-Index: AQHQ8idbvKddVdi6lU2RCiWbFx+0+Z5E/itg Date: Sun, 20 Sep 2015 06:56:11 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB28577@AZ-FFEXMB04.global.avaya.com> References: <20150918153239.1A149180092@rfc-editor.org> In-Reply-To: <20150918153239.1A149180092@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] RFC 7594 on A Framework for Large-Scale Measurement of Broadband Performance (LMAP) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2015 06:56:16 -0000 Special thanks to the authors and congratulations to the WG for the publica= tion of the LMAP Framework RFC.=20 Regards, Dan > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of rfc-editor@rfc- > editor.org > Sent: Friday, September 18, 2015 6:33 PM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: lmap@ietf.org; rfc-editor@rfc-editor.org > Subject: [lmap] RFC 7594 on A Framework for Large-Scale Measurement of > Broadband Performance (LMAP) >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7594 >=20 > Title: A Framework for Large-Scale Measurement > of Broadband Performance (LMAP) > Author: P. Eardley, > A. Morton, > M. Bagnulo, > T. Burbridge, > P. Aitken, > A. Akhter > Status: Informational > Stream: IETF > Date: September 2015 > Mailbox: philip.eardley@bt.com, > acmorton@att.com, > marcelo@it.uc3m.es, > trevor.burbridge@bt.com, > paitken@brocade.com, > aakhter@gmail.com > Pages: 55 > Characters: 131972 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-lmap-framework-14.txt >=20 =3D From nobody Sun Sep 20 00:10:00 2015 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 A0B861B3EC6 for ; Sun, 20 Sep 2015 00:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtV-wtjWP0Zv for ; Sun, 20 Sep 2015 00:09:58 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C40C11B3EC3 for ; Sun, 20 Sep 2015 00:09:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DvAQDdWv5V/xUHmMZdGQGCPSEsVG+9OwENh3QCgRs4FAEBAQEBAQF/C4QlAQEDEhteAQwJFVYmAQQbGogMAaY2hQ6ePQwBH4Z1iTYBAR+DUIEUBZVkAY5ThDWDFZIDHwEBQoQBiR86gQUBAQE X-IPAS-Result: A2DvAQDdWv5V/xUHmMZdGQGCPSEsVG+9OwENh3QCgRs4FAEBAQEBAQF/C4QlAQEDEhteAQwJFVYmAQQbGogMAaY2hQ6ePQwBH4Z1iTYBAR+DUIEUBZVkAY5ThDWDFZIDHwEBQoQBiR86gQUBAQE X-IronPort-AV: E=Sophos;i="5.17,561,1437451200"; d="scan'208,217";a="137251264" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Sep 2015 03:09:57 -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; 20 Sep 2015 03:09:56 -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; Sun, 20 Sep 2015 03:09:55 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: about current work, future work and the 9/29 interim meeting Thread-Index: AdDzc1mZa8vXvIfGQkWkC3STCOYdjw== Date: Sun, 20 Sep 2015 07:09:55 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB2858F@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.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CB2858FAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] about current work, future work and the 9/29 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: Sun, 20 Sep 2015 07:09:59 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CB2858FAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is a reminder that we have the next interim meeting of the LMAP WG sch= eduled for 9/29. We expect requests for agenda items. I see several threads on the WG mail list about future work, but too little= activity on the current chartered work. There were not too many comments a= nd discussions about the Information Model, Data Model, or LMAP protocol do= cuments. What are the plans of the editors for the interim? As discussed at IETF 93 - we need to progress the current chartered items f= irst. It's OK to discuss about future work and make individual submissions,= but no re-chartering will be discussed until the majority of the current d= ocumented are submitted to the IESG. Please focus on these. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5CB2858FAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

This is a reminder that we have the next interim mee= ting of the LMAP WG scheduled for 9/29.

 

We expect requests for agenda items.

 

I see several threads on the WG mail list about futu= re work, but too little activity on the current chartered work. There were = not too many comments and discussions about the Information Model, Data Mod= el, or LMAP protocol documents. What are the plans of the editors for the interim?

 

As discussed at IETF 93 – we need to progress = the current chartered items first. It’s OK to discuss about future wo= rk and make individual submissions, but no re-chartering will be discussed = until the majority of the current documented are submitted to the IESG. Please focus on these.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CB2858FAZFFEXMB04globa_-- From nobody Mon Sep 21 01:39:37 2015 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 57A0D1A8A62 for ; Mon, 21 Sep 2015 01:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20U9AKbj1ZE9 for ; Mon, 21 Sep 2015 01:39:34 -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 94B331A8A61 for ; Mon, 21 Sep 2015 01:39:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 60B6D1107; Mon, 21 Sep 2015 10:39:33 +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 whx83GGFynaV; Mon, 21 Sep 2015 10:39:32 +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, 21 Sep 2015 10:39:32 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 430662004E; Mon, 21 Sep 2015 10:39:32 +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 3GRrGlWlS-EE; Mon, 21 Sep 2015 10:39:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47C8E20048; Mon, 21 Sep 2015 10:39:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5111D37274E6; Mon, 21 Sep 2015 10:39:29 +0200 (CEST) Date: Mon, 21 Sep 2015 10:39:28 +0200 From: Juergen Schoenwaelder To: Holger Wiehen Message-ID: <20150921083928.GB11184@elstar.local> Mail-Followup-To: Holger Wiehen , lmap@ietf.org References: <434D830D-7592-4237-8AF2-2B5A869146C2@nic.br> <4AF73AA205019A4C8A1DDD32C034631D0BB45814F1@NJFPSRVEXG0.research.att.com> <55D149D8-329D-4D95-89A0-7E4621F16417@nic.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55D149D8-329D-4D95-89A0-7E4621F16417@nic.br> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] Standard for coordination between MAs 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, 21 Sep 2015 08:39:36 -0000 On Thu, Sep 17, 2015 at 07:03:14PM -0300, Holger Wiehen wrote: > Hi Al. > > Thank's for your reply. > > I will try illustrate our idea of MA Communications with 2 example use cases. > > One example would be a MA initiated by a human user, executing measurements against a remote MA. Results obtained on the remote MA should be presented to the end user (local MA), with low delay. > > I understand that pushing results to a MA could not be solved with the report flow specified by LMAP. In an end user focused use case, exchanging reports directly between MAs, would allow for quick and resilient reporting to users. This reporting would be in addition to the usual report submission to the LMAP collector. Can you provide a concrete example where this is useful? Can anyone on the Internet use the MA for measurements? If not, how do you establish a trust relationship? > A second use case is a MA responding active measurements initiated by another MA. Our responding MA receives its configuration from the LMAP controller, but once it is set up, it does not depend on the control channel in order to respond to measurements initiated by a remote MA. The responding MA receives parameters specific to a single measurement session, from the initiating MA. Coordinating active measurements directly between MAs would increase resilience and reduce timing issues. Can you provide a concrete example where this is useful? How do you establish a trust relationship? /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 21 05:03:15 2015 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 76CF31A6FF5 for ; Mon, 21 Sep 2015 05:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRd0BxK9BfmN for ; Mon, 21 Sep 2015 05:03:12 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 7CBBC1A6FED for ; Mon, 21 Sep 2015 05:03:10 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 3BB74612F2D12; Mon, 21 Sep 2015 12:03:05 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t8LC36cU022331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Sep 2015 12:03:07 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 21 Sep 2015 08:03:06 -0400 From: "Carey, Timothy (Timothy)" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Thread-Topic: [lmap] about current work, future work and the 9/29 interim meeting Thread-Index: AQHQ89ae69nUvJgAU0iXN+RtbyZQfZ5G4u7Q Date: Mon, 21 Sep 2015 12:03:06 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC254DBB@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CB2858F@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CB2858F@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.16] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC254DBBUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] about current work, future work and the 9/29 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: Mon, 21 Sep 2015 12:03:14 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC254DBBUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dan, I released at least 6 comments on the Information model that I would like a= ddressed since I haven't had responses - these are in the archives. BR Tim From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Sunday, September 20, 2015 2:10 AM To: lmap@ietf.org Subject: [lmap] about current work, future work and the 9/29 interim meetin= g Hi, This is a reminder that we have the next interim meeting of the LMAP WG sch= eduled for 9/29. We expect requests for agenda items. I see several threads on the WG mail list about future work, but too little= activity on the current chartered work. There were not too many comments a= nd discussions about the Information Model, Data Model, or LMAP protocol do= cuments. What are the plans of the editors for the interim? As discussed at IETF 93 - we need to progress the current chartered items f= irst. It's OK to discuss about future work and make individual submissions,= but no re-chartering will be discussed until the majority of the current d= ocumented are submitted to the IESG. Please focus on these. Thanks and Regards, Dan --_000_9966516C6EB5FC4381E05BF80AA55F77DC254DBBUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan,

 

I released at least 6 comments on the= Information model that I would like addressed since I haven’t had re= sponses – these are in the archives.

 

BR

Tim

 

From: Romascan= u, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Sunday, September 20, 2015 2:10 AM
To: lmap@ietf.org
Subject: [lmap] about current work, future work and the 9/29 interim= meeting

 

Hi,

 

This is a reminder that we have the next interim mee= ting of the LMAP WG scheduled for 9/29.

 

We expect requests for agenda items.

 

I see several threads on the WG mail list about futu= re work, but too little activity on the current chartered work. There were = not too many comments and discussions about the Information Model, Data Mod= el, or LMAP protocol documents. What are the plans of the editors for the interim?

 

As discussed at IETF 93 – we need to progress = the current chartered items first. It’s OK to discuss about future wo= rk and make individual submissions, but no re-chartering will be discussed = until the majority of the current documented are submitted to the IESG. Please focus on these.

 

Thanks and Regards,

 

Dan

 

--_000_9966516C6EB5FC4381E05BF80AA55F77DC254DBBUS70UWXCHMBA05z_-- From nobody Mon Sep 21 05:08:54 2015 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 280FD1A7013 for ; Mon, 21 Sep 2015 05:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyIvWPaqhcsl for ; Mon, 21 Sep 2015 05:08:52 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85411A700F for ; Mon, 21 Sep 2015 05:08:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DwAQDy8v9V/yYyC4ddGQEBAYI7ISxUaQa9PAENh3QCgTY4FAEBAQEBAQGBCoQjAQEBAQMSG1wCAQgNBAQBAQsdBzIUCQgBAQQBEggaiAwBq2qeUQEBAQEBAQEBAQEBAQEBAQEBAQEBAReGdYR7hDsBAR83AYMYgRQFlWQBjlOENYMVkgMfAQFChAFxiC46gQUBAQE X-IPAS-Result: A2DwAQDy8v9V/yYyC4ddGQEBAYI7ISxUaQa9PAENh3QCgTY4FAEBAQEBAQGBCoQjAQEBAQMSG1wCAQgNBAQBAQsdBzIUCQgBAQQBEggaiAwBq2qeUQEBAQEBAQEBAQEBAQEBAQEBAQEBAReGdYR7hDsBAR83AYMYgRQFlWQBjlOENYMVkgMfAQFChAFxiC46gQUBAQE X-IronPort-AV: E=Sophos;i="5.17,567,1437451200"; d="scan'208,217";a="137363690" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Sep 2015 08:08:48 -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; 21 Sep 2015 08:08:48 -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; Mon, 21 Sep 2015 14:08:46 +0200 From: "Romascanu, Dan (Dan)" To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" Thread-Topic: [lmap] about current work, future work and the 9/29 interim meeting Thread-Index: AdDzc1mZa8vXvIfGQkWkC3STCOYdjwBE6boAAAhRRIA= Date: Mon, 21 Sep 2015 12:08:45 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB2A655@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CB2858F@AZ-FFEXMB04.global.avaya.com> <9966516C6EB5FC4381E05BF80AA55F77DC254DBB@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC254DBB@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CB2A655AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] about current work, future work and the 9/29 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: Mon, 21 Sep 2015 12:08:54 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CB2A655AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Indeed. I expect the authors of draft-ietf-lmap-information-model to addres= s these. Same for the other two documents (protocol and YANG data model) Regards, Dan From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: Monday, September 21, 2015 3:03 PM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: RE: [lmap] about current work, future work and the 9/29 interim me= eting Dan, I released at least 6 comments on the Information model that I would like a= ddressed since I haven't had responses - these are in the archives. BR Tim From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Sunday, September 20, 2015 2:10 AM To: lmap@ietf.org Subject: [lmap] about current work, future work and the 9/29 interim meetin= g Hi, This is a reminder that we have the next interim meeting of the LMAP WG sch= eduled for 9/29. We expect requests for agenda items. I see several threads on the WG mail list about future work, but too little= activity on the current chartered work. There were not too many comments a= nd discussions about the Information Model, Data Model, or LMAP protocol do= cuments. What are the plans of the editors for the interim? As discussed at IETF 93 - we need to progress the current chartered items f= irst. It's OK to discuss about future work and make individual submissions,= but no re-chartering will be discussed until the majority of the current d= ocumented are submitted to the IESG. Please focus on these. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5CB2A655AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Indeed. I expect the aut=
hors of draft-ietf-lmap-information-model=
 to address these. Same for the other two documents (protocol and YANG data=
 model)
 =

Regards,
 =

Dan

 

From: Carey, T= imothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: Monday, September 21, 2015 3:03 PM
To: Romascanu, Dan (Dan); lmap@ietf.org
Subject: RE: [lmap] about current work, future work and the 9/29 int= erim meeting

 

Dan,

 

I released at least 6 comments on the= Information model that I would like addressed since I haven’t had re= sponses – these are in the archives.

 

BR

Tim

 

From: Romascan= u, Dan (Dan) [mailto:dromasca@avaya.c= om]
Sent: Sunday, September 20, 2015 2:10 AM
To: lmap@ietf.org
Subject: [lmap] about current work, future work and the 9/29 interim= meeting

 

Hi,

 

This is a reminder that we have the next interim mee= ting of the LMAP WG scheduled for 9/29.

 

We expect requests for agenda items.

 

I see several threads on the WG mail list about futu= re work, but too little activity on the current chartered work. There were = not too many comments and discussions about the Information Model, Data Mod= el, or LMAP protocol documents. What are the plans of the editors for the interim?

 

As discussed at IETF 93 – we need to progress = the current chartered items first. It’s OK to discuss about future wo= rk and make individual submissions, but no re-chartering will be discussed = until the majority of the current documented are submitted to the IESG. Please focus on these.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CB2A655AZFFEXMB04globa_-- From nobody Wed Sep 23 02:37:30 2015 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 CB96C1A21BC for ; Wed, 23 Sep 2015 02:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIfIQVOAgWn6 for ; Wed, 23 Sep 2015 02:37:27 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D011A1AC9 for ; Wed, 23 Sep 2015 02:37:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CWAwBBP8ZV/xUHmMZbGQSCMSEsIzFvqW4GBZMxCYFYIgELhXcCgSY4FAEBAQEBAQF/C4QlAQEDEhteARUVViYBBBsaiAwBDKdhhQugPgELARsEhh+JaQEBHy2COQxBHYEUBZULAZVbkQQXD4N9gX06gQQBAQE X-IPAS-Result: A2CWAwBBP8ZV/xUHmMZbGQSCMSEsIzFvqW4GBZMxCYFYIgELhXcCgSY4FAEBAQEBAQF/C4QlAQEDEhteARUVViYBBBsaiAwBDKdhhQugPgELARsEhh+JaQEBHy2COQxBHYEUBZULAZVbkQQXD4N9gX06gQQBAQE X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208,217";a="121241224" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Sep 2015 05:37:24 -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; 23 Sep 2015 05:37:23 -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; Wed, 23 Sep 2015 05:37:22 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: draft agenda for the 9/29 LMAP WG interim meeting Thread-Index: AdD143GL1XKUc6rzTTKVNU+ASZHHow== Date: Wed, 23 Sep 2015 09:37:21 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB2D8BF@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.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CB2D8BFAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] draft agenda for the 9/29 LMAP WG 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: Wed, 23 Sep 2015 09:37:29 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CB2D8BFAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have uploaded the draft agenda of for the 9/29 LMAP WG interim meeting at= https://www.ietf.org/proceedings/interim/2015/09/29/lmap/agenda/agenda-int= erim-2015-lmap-3. The scope of the interim should be on the three chartered work items: 3. LMAP Information Model - (Trevor, Juergen, 50 min) 4. LMAP YANG Data Model - (Juergen, 20 min) 5. LMAP Protocol - (Juergen, 20 min) I do not see however much progress or discussions on the mail list on this,= with the exception of the comments made by Tim Carey which need to be addr= essed. No new I-Ds where submitted since IETF 93. Jason and me would like t= o hear from the authors and the other editors what are their plans and how = they would like to use the meeting time. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5CB2D8BFAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have uploaded the draft agenda of for the 9/29 LMA= P WG interim meeting at https://www.ietf.org/proceedings/interim/2015/09/29/lmap/agenda/agenda-inte= rim-2015-lmap-3.

 

The scope of the interim should be on the three char= tered work items:

 

3. LMAP Information Model - (Trevor, Juergen, = 50 min)

 

4. LMAP YANG Data Model - (Juergen, 20 min)

 

5. LMAP Protocol - (Juergen, 20 min)

 

 

I do not see however much progress or discussions on= the mail list on this, with the exception of the comments made by Tim Care= y which need to be addressed. No new I-Ds where submitted since IETF 93. Ja= son and me would like to hear from the authors and the other editors what are their plans and how they would = like to use the meeting time.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CB2D8BFAZFFEXMB04globa_-- From nobody Wed Sep 23 06:47:33 2015 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 8C6A11A6FF2 for ; Wed, 23 Sep 2015 06:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pwpu4-vuP8L for ; Wed, 23 Sep 2015 06:47:30 -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 792D21A6F39 for ; Wed, 23 Sep 2015 06:47:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 44BF79E4; Wed, 23 Sep 2015 15:47:29 +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 ZrUzzxSJJsbG; Wed, 23 Sep 2015 15:47:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Sep 2015 15:47:27 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C61A320054; Wed, 23 Sep 2015 15:47:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WwRIc4DDsLuw; Wed, 23 Sep 2015 15:47:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D89D02004E; Wed, 23 Sep 2015 15:47:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E72C637574FA; Wed, 23 Sep 2015 15:47:24 +0200 (CEST) Date: Wed, 23 Sep 2015 15:47:24 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150923134724.GB1945@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77DC22667F@US70UWXCHMBA05.zam.alcatel-lucent.com> <244dbae6d49b4142a441f0e5534d9b56@rew09926dag03c.domain1.systemhost.net> <9966516C6EB5FC4381E05BF80AA55F77DC250E74@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC250E74@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Disabling schedules on controller timeout 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, 23 Sep 2015 13:47:32 -0000 Hi, we (Vaibhav and me) looked into the issue and it seems one possible solution is to handle lost communication to a controller similar to the default suppression. Hence our proposal is to add a boolean flag to the ma-task-obj that indicates whether the task will be disabled if communication to the controller has stopped. The default will be true. ma-task-auto-disable: A boolean flag indicating whether the task will be disabled if the communication with the controller has timed out. The default value of the flag is true. The description of ma-controller-timeout will then be updated to say that all actions refering to tasks where ma-task-auto-disable is true will not be executed anymore. /js On Wed, Sep 16, 2015 at 10:12:24AM +0000, Carey, Timothy (Timothy) wrote: > Hi, > > In light of the Virtual meeting next week I thought I would regenerate an open issue I have with the latest information model that I haven't seen discussion on. > > BR, > Tim > > > From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] > Sent: Tuesday, July 28, 2015 2:37 AM > To: Carey, Timothy (Timothy); lmap@ietf.org > Subject: RE: Review of draft-ietf-lmap-information-model-06: Disabling schedules on controller timeout > > I think this isn't possible. The Control and Instruction schedules are held separately and the Control schedules cannot be suppressed. > > Trevor. > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy) > Sent: 27 July 2015 20:20 > To: lmap@ietf.org > Subject: [lmap] Review of draft-ietf-lmap-information-model-06: Disabling schedules on controller timeout > > Juergen, > > I was updating the TR-069 model and still have some questions about the disabling of schedules. > > What happens if I disable a schedule but the schedule references an action that is MA communication specific AND say an instruction? > > It really sounds like we are disabling actions not schedules... It certainly would be much easier. > > BR, > Tim > _______________________________________________ > 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 Wed Sep 23 06:59:52 2015 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 8A6911B3269 for ; Wed, 23 Sep 2015 06:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAwT1sEGcoPo for ; Wed, 23 Sep 2015 06:59:49 -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 D00A01B3267 for ; Wed, 23 Sep 2015 06:59:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9B48372F; Wed, 23 Sep 2015 15:59:47 +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 ojumT0gBgjW3; Wed, 23 Sep 2015 15:59:46 +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, 23 Sep 2015 15:59:46 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62AB320054; Wed, 23 Sep 2015 15:59:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JzUCL5zqNLRY; Wed, 23 Sep 2015 15:59:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C096C2004E; Wed, 23 Sep 2015 15:59:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BE40D3757592; Wed, 23 Sep 2015 15:59:43 +0200 (CEST) Date: Wed, 23 Sep 2015 15:59:43 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150923135943.GC1945@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77DC226694@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC226694@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action Execution Mode questions 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, 23 Sep 2015 13:59:50 -0000 On Mon, Jul 27, 2015 at 07:29:47PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > In reviewing this draft for the TR-069 model update I had a question on the Execution mode. > We say there are 3 modes - Sequential, Parallel and Pipelined. > For sequential - What is the value that orders the list? I don't see an ordering the action or indication that this is an ordered list of actions. > Yes, it is an ordered list. We searched through the document and it turns out we sometimes use 'list' when we mean 'ordered list' but we also use 'list' sometimes where all we need is an 'unordered set'. Our proposal is that we go through the whole document replacing 'list' with either 'ordered list' or ''unordered set' to make the distinction clear. > For pipelining - I don't understand this mode - are we saying that this is a Sequential mode plus all the outputs for executing Action are inputted to the next Action in the Sequence or is the Pipeline mode somehow relevant for Output destinations? If so why wouldn't pipeline simply be sequential or paralled with output destinations? > The former. A pipelined schedule with actions a1, a2, and a3 means that a1 is executed and feeds its output as input to a2 which feeds its output as input to a3. Note that pipelined does not imply sequential execution; all actions can run concurrently and the pipeline controls the data flow and thus the progress they can make. Like in a Unix shell pipeline. /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 23 07:07:05 2015 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 DA2FB1A1BCB for ; Wed, 23 Sep 2015 07:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn0eoF14iCdm for ; Wed, 23 Sep 2015 07:07:03 -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 D1CC81A1BC0 for ; Wed, 23 Sep 2015 07:07: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 96F72FE6; Wed, 23 Sep 2015 16:07:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id YxADMT8fkGdA; Wed, 23 Sep 2015 16:07: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; Wed, 23 Sep 2015 16:07:01 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E108B20053; Wed, 23 Sep 2015 16:07:00 +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 hu8HmO3RM9I5; Wed, 23 Sep 2015 16:07:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A05312004E; Wed, 23 Sep 2015 16:06:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8C2AD37575D2; Wed, 23 Sep 2015 16:06:59 +0200 (CEST) Date: Wed, 23 Sep 2015 16:06:59 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150923140659.GD1945@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77DC2266C0@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC2266C0@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Actions 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, 23 Sep 2015 14:07:05 -0000 On Mon, Jul 27, 2015 at 07:41:10PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > If Actions are now considered stand-alone entities outside the schedule. Shouldn't the MA have a list of Actions available like Tasks and CommunicationChannels? > I do not think that actions are considered stand-alone entities. Actions exist as part of a schedule. /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 23 07:13:56 2015 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 2C02F1A1B6E for ; Wed, 23 Sep 2015 07:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kRr1XseMwti for ; Wed, 23 Sep 2015 07:13:51 -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 80E731A1B6F for ; Wed, 23 Sep 2015 07:13:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4CA778EE; Wed, 23 Sep 2015 16:13:50 +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 SwgapYijFyaS; Wed, 23 Sep 2015 16:13:49 +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, 23 Sep 2015 16:13:49 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 37C1020053; Wed, 23 Sep 2015 16:13:49 +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 Q0ytdZcIUqP2; Wed, 23 Sep 2015 16:13:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D17652004E; Wed, 23 Sep 2015 16:13:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D4375375762C; Wed, 23 Sep 2015 16:13:44 +0200 (CEST) Date: Wed, 23 Sep 2015 16:13:44 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150923141342.GE1945@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77DC226710@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC226710@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: draft-ietf-lmap-information-model-06 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, 23 Sep 2015 14:13:54 -0000 Tim, we have removed the notion of multiple outputs and we have simplified the model such that outputs can only be fed into another schedule (but not into an action of a schedule). The new model is that measurement tasks will tag results and if certain tags are not needed, you filter the output based on the tags. /js On Mon, Jul 27, 2015 at 08:23:01PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > I was looking at the definition of ma-action-destinations. I don't understand what we did here. > > It used to be the case that a registry entry can define outputs that were pipelined to a scheduled action. Now I it looks like it is a schedule. > > However previously we said: > An empty list means that all outputs defined by the Action's task registry are invoked. - this is missing from you draft - what do we do with an empty list? > > Likewise we actually defined the output number to a list of Schedules - I didn't see that modeled in the simple list of schedules. > > BR, > Tim > _______________________________________________ > 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 Wed Sep 23 07:25:34 2015 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 A691C1A21B5 for ; Wed, 23 Sep 2015 07:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sH9r2LH-VrdQ for ; Wed, 23 Sep 2015 07:25:31 -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 375B61A1EEE for ; Wed, 23 Sep 2015 07:25:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 02CFE93D; Wed, 23 Sep 2015 16:25:30 +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 ECSTdU3q2zJv; Wed, 23 Sep 2015 16:25:29 +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, 23 Sep 2015 16:25:29 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 160C320053; Wed, 23 Sep 2015 16:25:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bskqVNoRSLvX; Wed, 23 Sep 2015 16:25:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8517B2004E; Wed, 23 Sep 2015 16:25:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9C05437576AD; Wed, 23 Sep 2015 16:25:26 +0200 (CEST) Date: Wed, 23 Sep 2015 16:25:26 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150923142526.GF1945@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77DC226720@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC226720@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Instructions and measurement suppression 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, 23 Sep 2015 14:25:32 -0000 On Mon, Jul 27, 2015 at 08:46:12PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > In IETF93 you asked if instruction object had any meaning. > Well they are used to hold measurement suppression. So if we remove the Instruction object we need a place to hold the instructions measurement suppression. > I believe this is a misunderstanding. As far as I recall, my question concerned the term Instruction Task. And I still think we should go through the document to see whether we can remove this term (as well as the other 'specialist tasks' mentioned under 2.B. on page 8). I think this should actually become: B. Control Tasks implement the Control Protocol and communicate with the Controller. We also don't detail that reporting tasks could be more complex internally since this does not matter from the information model's point of view. /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 23 07:52:36 2015 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 3CEE01A6F51 for ; Wed, 23 Sep 2015 07:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeIlS6-zKI6x for ; Wed, 23 Sep 2015 07:52:34 -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 E93081A6F44 for ; Wed, 23 Sep 2015 07:52:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B4CE1733; Wed, 23 Sep 2015 16:52:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UW3HQ8sJmLPk; Wed, 23 Sep 2015 16:52:32 +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, 23 Sep 2015 16:52:32 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D748A20053; Wed, 23 Sep 2015 16:52:31 +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 JzJnJf0uj1yg; Wed, 23 Sep 2015 16:52:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 460152004E; Wed, 23 Sep 2015 16:52:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1223E3757729; Wed, 23 Sep 2015 16:52:29 +0200 (CEST) Date: Wed, 23 Sep 2015 16:52:29 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150923145229.GG1945@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77DC227456@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC227456@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the information model 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, 23 Sep 2015 14:52:35 -0000 On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > In draft 05 we removed the ability for a measurement agent to report its metrics that it supports. > We need to add > > * ma-task-capability-obj ma-supported-tasks<0..*>; > > * [ma-condition-obj ma-conditions<0..*>;] > > They were in the ma-status-obj. You are correct. There currently is no 'list' of tasks that are supported by a device anymore and we may have to put this back in. We changed the reporting of runtime failures to make them more useful. See the ma-task-status-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 Wed Sep 23 08:15:20 2015 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 482601A6F67 for ; Wed, 23 Sep 2015 08:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExRvOUR0SoZZ for ; Wed, 23 Sep 2015 08:15:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2F41A6FDD for ; Wed, 23 Sep 2015 08:14:49 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BAF909F5; Wed, 23 Sep 2015 17:14:48 +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 A5fBAnThyfmO; Wed, 23 Sep 2015 17:14:47 +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, 23 Sep 2015 17:14:47 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7BDC420053; Wed, 23 Sep 2015 17:14:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vyGNuhBqVuW5; Wed, 23 Sep 2015 17:14:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F78C2004E; Wed, 23 Sep 2015 17:14:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 642FF3757775; Wed, 23 Sep 2015 17:14:45 +0200 (CEST) Date: Wed, 23 Sep 2015 17:14:44 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150923151443.GH1945@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77DC22745E@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC22745E@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Task status object 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, 23 Sep 2015 15:15:19 -0000 On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > > In the ma-task-status object you have multiple role with a single registry entry for a task. Your description in ma-task-status-obj doesn't seem to add up. > > What if we have a task with multiple metrics (registry entries)? > > You also have a list of roles - but a registry entry would only be executed under 1 role. My understanding is that a registry entry has at most one role defined (draft-ietf-ippm-metric-registry-04 section 7.3.6). Hence, it seems the ma-task-role is not really needed and should be removed. Al Morton said that a task may generate a single packet train that is used to obtain multiple metrics. This is why we allow multiple references to the registry and we expect that tasks will not implement impossible combinations. > What is the unique functional key of a task status object now - Task Name, RegistryEntry, Role? I think the key is the ma-task-name: ma-task-name: A name uniquely identifying a 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 23 08:20:29 2015 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 E58D91A700E for ; Wed, 23 Sep 2015 08:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCsBJVT3DTAd for ; Wed, 23 Sep 2015 08:20: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 EBEE31A700F for ; Wed, 23 Sep 2015 08:20:25 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B78ED88D; Wed, 23 Sep 2015 17:20:24 +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 0Kdh_fP77gzg; Wed, 23 Sep 2015 17:20:23 +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, 23 Sep 2015 17:20:23 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0D0220053; Wed, 23 Sep 2015 17:20:23 +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 5xWvqCw7r3_g; Wed, 23 Sep 2015 17:20: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 5419B2004E; Wed, 23 Sep 2015 17:20:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3D0DF37577AF; Wed, 23 Sep 2015 17:20:22 +0200 (CEST) Date: Wed, 23 Sep 2015 17:20:22 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150923152022.GA2358@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77DC2276A6@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC2276A6@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Report - Task problems 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, 23 Sep 2015 15:20:29 -0000 On Tue, Jul 28, 2015 at 03:57:47PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > > 1) In the ma-report-task-obj, you have the [ma-option-obj ma-report-scheduled-task-options<0..*>]. So do we mean options for MA, the Action or the Task? I think we mean the Task here. We also need Action conditions for the report right? The ma-report-task-obj looks like this: object { string ma-report-task-name; [uri ma-report-task-registry-entries<1..*>;] [ma-option-obj ma-report-task-options<0..*>]; [ma-option-obj ma-report-task-action-options<0..*>]; [string ma-report-task-cycle-id;] [string ma-report-task-column-labels<0..*>;] [ma-report-row-obj ma-report-task-rows<0..*>;] } ma-report-task-obj; It carries both the task options as well as the action options. I do not understand what you mean with 'Action conditions'. > 2) Use of Registry entry in the Report task; Is this really for a metric (RegistryEntry) in the task (probably); what about Role of the metric; do we report on each role/registryentry for the task? (probably) . My understanding is that the registry entry identifies the role and hence reporting the registry entry should be sufficient. /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 23 08:38:35 2015 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 453451A6FD8 for ; Wed, 23 Sep 2015 08:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_az5SM_euo9 for ; Wed, 23 Sep 2015 08:38:33 -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 0EF441A6FD1 for ; Wed, 23 Sep 2015 08:38:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CE4998B2; Wed, 23 Sep 2015 17:38:31 +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 D4OTCJs817mc; Wed, 23 Sep 2015 17:38:30 +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, 23 Sep 2015 17:38:30 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCD5120053; Wed, 23 Sep 2015 17:38:30 +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 RetaPHJd4YC7; Wed, 23 Sep 2015 17:38:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7CC802004E; Wed, 23 Sep 2015 17:38:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2D37837577F3; Wed, 23 Sep 2015 17:38:29 +0200 (CEST) Date: Wed, 23 Sep 2015 17:38:29 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150923153829.GB2358@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77DC22793D@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC22793D@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: New additions for Schedule Object 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, 23 Sep 2015 15:38:34 -0000 Tim, I agree that we should add more status objects that report the state of things that can have a state. In the current model, schedules can be suppressed so that should be reported. /js On Tue, Jul 28, 2015 at 06:08:04PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > To help with the controller timeout, I added an indicator to the schedule in TR-069 that shows if the Schedule should be used for MA Control actions. Likewise I added a status parameter to tell if the Schedule is currently operationally disabled. > > Do you think we can add these to the information model? > > Status > > string > > - > > The current operational state of the Schedule. Enumeration of: > > * Enabled > * Disabled-MA-ControllerTimout > * Disabled-Other > * Error (OPTIONAL) > The Error value MAY be used by the CPE to indicate a locally defined error condition. > > > > UseForMAControl > > boolean > > W > > This parameter defines if the Schedule is to be used for Actions that specific to the > > > BR, > Tim > _______________________________________________ > 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 Wed Sep 23 08:44:47 2015 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 E206F1A8035 for ; Wed, 23 Sep 2015 08:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxC1QuVjkV0S for ; Wed, 23 Sep 2015 08:44:44 -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 958981A7020 for ; Wed, 23 Sep 2015 08:44:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 607048EE; Wed, 23 Sep 2015 17:44: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 AMBUe3JUNk9s; Wed, 23 Sep 2015 17:44:42 +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, 23 Sep 2015 17:44:42 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 402512005E; Wed, 23 Sep 2015 17:44: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 VZmxHtCsX0JD; Wed, 23 Sep 2015 17:44:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 75E4B2005C; Wed, 23 Sep 2015 17:44:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 57A253757852; Wed, 23 Sep 2015 17:44:38 +0200 (CEST) Date: Wed, 23 Sep 2015 17:44:38 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150923154438.GC2358@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77DC22D001@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC22D001@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action Destinations and tie with the Regisrry output 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, 23 Sep 2015 15:44:46 -0000 Tim, the information model currently assumes that results are tagged. A task producing multiple 'outputs' would tag them to distinguish them. How all this links to the registry is, honestly speaking, somewhat unclear to me since I do not really understand how the registry itself works. It would help me a lot if draft-ietf-ippm-metric-registry-04 would contain a collection of example registry entries. /js On Wed, Aug 05, 2015 at 02:06:24PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > In previous information models we linked the Registry's outputs with the downstream tasks. > > In LMAP IM-06 draft we now have a concept of an ActionDestination which describes which schedules are invoked based on the task's output selection. However we do not link back the task output to the ActionDestination via parameter in the ActionDestination object (maybe called Output?). Did I miss understand the intent of the ActionDestination and its linkage? > > BR, > Tim > _______________________________________________ > 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 Wed Sep 23 09:36:07 2015 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 6FD341A1B0D for ; Wed, 23 Sep 2015 09:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuMRWHIIAK7K for ; Wed, 23 Sep 2015 09:36:03 -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 F397C1A1ABE for ; Wed, 23 Sep 2015 09:36: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 96D621B73; Wed, 23 Sep 2015 18:36:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id j6WaxmfmH8sH; Wed, 23 Sep 2015 18:35:58 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Sep 2015 18:35:53 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 396A9201D9; Wed, 23 Sep 2015 18:25:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0Ytmju0pL4UW; Wed, 23 Sep 2015 18:25:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AEB50201AC; Wed, 23 Sep 2015 18:25:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 53E1F3757964; Wed, 23 Sep 2015 18:25:28 +0200 (CEST) Date: Wed, 23 Sep 2015 18:25:27 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20150923162526.GD2358@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA5CB2D8BF@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CB2D8BF@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft agenda for the 9/29 LMAP WG interim meeting 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, 23 Sep 2015 16:36:05 -0000 On Wed, Sep 23, 2015 at 09:37:21AM +0000, Romascanu, Dan (Dan) wrote: > Hi, > > I have uploaded the draft agenda of for the 9/29 LMAP WG interim meeting at https://www.ietf.org/proceedings/interim/2015/09/29/lmap/agenda/agenda-interim-2015-lmap-3. > > The scope of the interim should be on the three chartered work items: > > 3. LMAP Information Model - (Trevor, Juergen, 50 min) > > 4. LMAP YANG Data Model - (Juergen, 20 min) > > 5. LMAP Protocol - (Juergen, 20 min) > > > I do not see however much progress or discussions on the mail list on this, with the exception of the comments made by Tim Carey which need to be addressed. No new I-Ds where submitted since IETF 93. Jason and me would like to hear from the authors and the other editors what are their plans and how they would like to use the meeting time. > I was hoping NETMOD would not take so much of my time anymore but I was wrong with that prediction. I am doing priority queuing now and unfortunately this affects progress in LMAP (but other IETF related stuff is even more affected). Concerning the agenda, I do not think we need much time for the data model or the protocol work since there were no discussions on the list. There will be updates coming to align with information model updates but I do not think we need to discuss these edits during the interim. We should focus on the information model related questions, mostly raised by Tim. And I like to thank Tim for raising these questions - reviews and questions are a valuable contribution to make things better and I apologize for late responses. In addition, it would really help me if some IPPM people can explain how the registry actually works. A few example registry entries would help me a lot. I know this request comes a bit late so I am not sure we can get registry co-authors into the call. But it would really help me to figure out how the bits and pieces fit together. So perhaps reallocate the data model and protocol time to a discussion how the IPPM registry works together with the information 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 Wed Sep 23 09:52:03 2015 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 223B31A7028 for ; Wed, 23 Sep 2015 09:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCiUn8cn5mWA for ; Wed, 23 Sep 2015 09:52:00 -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 5B6261A6FFB for ; Wed, 23 Sep 2015 09:52:00 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 27B291B69 for ; Wed, 23 Sep 2015 18:51:59 +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 ifiYpVEqp4nd for ; Wed, 23 Sep 2015 18:51:57 +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, 23 Sep 2015 18:51:57 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F2F920053 for ; Wed, 23 Sep 2015 18:51:57 +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 ZKdvEcFew9_t; Wed, 23 Sep 2015 18:51:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2132A2004E; Wed, 23 Sep 2015 18:51:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3EED83757A24; Wed, 23 Sep 2015 18:51:54 +0200 (CEST) Date: Wed, 23 Sep 2015 18:51:54 +0200 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20150923165154.GE2358@elstar.local> Mail-Followup-To: lmap@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [lmap] suppression and disables due to controller lost 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, 23 Sep 2015 16:52:02 -0000 Hi, it seems we have meanwhile two not really consistent mechanisms to disable tasks. The first one originated from the suppression discussions. The second one from the desire to ensure that MAs stop sending measurement traffic if they lost contact to a controller. In both cases, we finally disable something but the way this is done is not fully consistent. Furthermore, we have built in limitations and a lack of flexibility. Right now, an instruction has exactly one suppression object and this object can do immediate suppression or it can do suppression during a certain time period. Since there is only one suppression object, you can only suppress during one time period, you can't provision multiple time periods during which want to suppress. There are multiple ways to express which tasks / schedules are affected by suppression (and this is actually quite complex since tasks also have attributes whether they belong to the default set of tasks that may be suppressed). For the case when we loose connectivity to a controller, we have a separate meachanism to select the tasks and actions that are affected by this. What I propose is to revise all this into a single mechanism. The core of the proposal is to bind 'disablement' to an event and to allow multiple ma-suppression-objs. The ma-suppression-obj would become something like this: object { string ma-suppression-name; ma-event-obj ma-suppression-event; [boolean ma-suppression-stop-running;] [string ma-suppression-task-names<0..*>;] [string ma-suppression-schedule-names<0..*>;] } ma-suppression-obj; We already have extensible event sources and adding an event that models 'controller-connectivity-lost' is quite straight-forward. We would have to change ma-task-suppress-by-default from a boolean to something that indicates for which events a task suppresses by default and the default value for this would be a wildcard 'ALL'. This change means that we have one mechanism to deal with suppression and lost contact to a controller. It allows all the flexibility we have available already to define time based suppression schedules. It allows to provision multiple suppressions, e.g. for new year evening and say superbowl time (which you can't do right now - there is only one suppression object). And it allows future extensions; for example, you might have suppressions configured that kick in when a device starts to use 5G connectivity instead of wifi. There are probably some details that still need to be worked out but it seems to me that unifying the way how we handle suppression and reaction to loss of connectivity to a controller is making the model cleaner and at the same time more extensible and powerful. /js (sorry for the length) -- 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 23 10:01:40 2015 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 4ACAF1A82E2 for ; Wed, 23 Sep 2015 10:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 P8ynl2gvib9a for ; Wed, 23 Sep 2015 10:01:37 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC401A8034 for ; Wed, 23 Sep 2015 10:01:36 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id 0FDCD1215CC; Wed, 23 Sep 2015 13:27:58 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 9116EE4811; Wed, 23 Sep 2015 12:59:56 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Wed, 23 Sep 2015 13:01:35 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , "Carey, Timothy (Timothy)" Date: Wed, 23 Sep 2015 13:01:35 -0400 Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Task status object Thread-Index: AdD2ErAdKbQBfhhIR1KhEMyVgmofzAADKb6Q Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB4581BBB@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC22745E@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923151443.GH1945@elstar.local> In-Reply-To: <20150923151443.GH1945@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Task status object 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, 23 Sep 2015 17:01:39 -0000 Al chimes-in below: > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, September 23, 2015 11:15 AM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Task status > object >=20 > On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) > wrote: > > Juergen, > > > > > > In the ma-task-status object you have multiple role with a single > registry entry for a task. Your description in ma-task-status-obj > doesn't seem to add up. > > > > What if we have a task with multiple metrics (registry entries)? > > > > You also have a list of roles - but a registry entry would only be > executed under 1 role. >=20 > My understanding is that a registry entry has at most one role defined > (draft-ietf-ippm-metric-registry-04 section 7.3.6). Hence, it seems the > ma-task-role is not really needed and should be removed. [ACM]=20 I think this is a change from previous text, and not in a good way. If we have to duplicate registry entries just to indicate a single fixed ro= le from two possible roles, then we haven't used the Run-Time parameters=20 correctly or efficiently, in my opinion. Yes, we need to give the set of possible roles for each metric *in the entr= y*. These roles need to map to the reference text in the Method of measurement. OTOH, I can see vendors building systems that only support one of two roles= , which is fine. I'd rather that this limitation was handled in protocols, and not by duplicating registry entries to modify a single column, "Role". >=20 > Al Morton said that a task may generate a single packet train that is > used to obtain multiple metrics. This is why we allow multiple > references to the registry and we expect that tasks will not implement > impossible combinations. [ACM]=20 Thank you for that. I would like to see the YANG model synchronized with this feature in the information model (unless I've missed it somehow). regards, Al >=20 > > What is the unique functional key of a task status object now - Task > Name, RegistryEntry, Role? >=20 > I think the key is the ma-task-name: >=20 > ma-task-name: A name uniquely identifying a task. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Sep 23 10:28:29 2015 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 DE5301A8706 for ; Wed, 23 Sep 2015 10:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8cTLWghJPjV for ; Wed, 23 Sep 2015 10:28:26 -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 150AA1A874C for ; Wed, 23 Sep 2015 10:28:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D1F9393D; Wed, 23 Sep 2015 19:28:24 +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 0aZmn5uIRprS; Wed, 23 Sep 2015 19:28:23 +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, 23 Sep 2015 19:28:23 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1BB6920053; Wed, 23 Sep 2015 19:28:23 +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 Z2ghBi_PJ7Pp; Wed, 23 Sep 2015 19:28:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 860D32004E; Wed, 23 Sep 2015 19:28:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8FF123757B1A; Wed, 23 Sep 2015 19:28:20 +0200 (CEST) Date: Wed, 23 Sep 2015 19:28:20 +0200 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20150923172819.GA2696@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77DC22745E@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923151443.GH1945@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D0BB4581BBB@NJFPSRVEXG0.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB4581BBB@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "Carey, Timothy \(Timothy\)" , "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Task status object 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, 23 Sep 2015 17:28:28 -0000 On Wed, Sep 23, 2015 at 01:01:35PM -0400, MORTON, ALFRED C (AL) wrote: > Al chimes-in below: > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Wednesday, September 23, 2015 11:15 AM > > To: Carey, Timothy (Timothy) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Task status > > object > > > > On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) > > wrote: > > > Juergen, > > > > > > > > > In the ma-task-status object you have multiple role with a single > > registry entry for a task. Your description in ma-task-status-obj > > doesn't seem to add up. > > > > > > What if we have a task with multiple metrics (registry entries)? > > > > > > You also have a list of roles - but a registry entry would only be > > executed under 1 role. > > > > My understanding is that a registry entry has at most one role defined > > (draft-ietf-ippm-metric-registry-04 section 7.3.6). Hence, it seems the > > ma-task-role is not really needed and should be removed. > [ACM] > I think this is a change from previous text, and not in a good way. > If we have to duplicate registry entries just to indicate a single fixed role > from two possible roles, then we haven't used the Run-Time parameters > correctly or efficiently, in my opinion. > > Yes, we need to give the set of possible roles for each metric *in the entry*. > These roles need to map to the reference text in the Method of measurement. > > OTOH, I can see vendors building systems that only support one of two roles, > which is fine. I'd rather that this limitation was handled in protocols, > and not by duplicating registry entries to modify a single column, "Role". So are you saying the text in section 7.3.6 of the registry is wrong? Or is my understanding of that text wrong? I admit that I do not find the text very clear. In implementations I am familiar with, the role is often simply passed as an argument when you invoke a measurement program (and hence it would not be a separate explicit task attribute either). > > Al Morton said that a task may generate a single packet train that is > > used to obtain multiple metrics. This is why we allow multiple > > references to the registry and we expect that tasks will not implement > > impossible combinations. > [ACM] > Thank you for that. > I would like to see the YANG model synchronized with this feature in the > information model (unless I've missed it somehow). In the YANG data model (draft-ietf-lmap-yang-01), the registry is a leaf-list and not a simple leaf, hence it can point to multiple registry entries. /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 23 10:31:04 2015 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 7D05D1A875E for ; Wed, 23 Sep 2015 10:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 m6gbvmLZh8PU for ; Wed, 23 Sep 2015 10:31:01 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 037621A8755 for ; Wed, 23 Sep 2015 10:31:01 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 846E9121E5A; Wed, 23 Sep 2015 13:57:22 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-azure.research.att.com (Postfix) with ESMTP id AD43EE051C; Wed, 23 Sep 2015 13:31:00 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Wed, 23 Sep 2015 13:31:00 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , "Romascanu, Dan (Dan)" Date: Wed, 23 Sep 2015 13:30:59 -0400 Thread-Topic: [lmap] draft agenda for the 9/29 LMAP WG interim meeting Thread-Index: AdD2HfonNHCBaLFJQa+YaunTeBbNyAABVpEQ Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB4581BD5@NJFPSRVEXG0.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CB2D8BF@AZ-FFEXMB04.global.avaya.com> <20150923162526.GD2358@elstar.local> In-Reply-To: <20150923162526.GD2358@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft agenda for the 9/29 LMAP WG 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: Wed, 23 Sep 2015 17:31:03 -0000 Another chime from Al follows: > -----Original Message----- Juergen wrote: ... > Concerning the agenda, I do not think we need much time for the data > model or the protocol work since there were no discussions on the list. > There will be updates coming to align with information model updates but > I do not think we need to discuss these edits during the interim. [ACM]=20 I agree, if you align to cover my registry related comment from a few minut= es ago ;-) >=20 > We should focus on the information model related questions, mostly > raised by Tim. And I like to thank Tim for raising these questions - > reviews and questions are a valuable contribution to make things better > and I apologize for late responses. [ACM]=20 +1 >=20 > In addition, it would really help me if some IPPM people can explain how > the registry actually works. =20 [ACM]=20 The reality is that the registry IPPM people are also LMAP people, for the most part. > A few example registry entries would help > me a lot. I know this request comes a bit late so I am not sure we can > get registry co-authors into the call.=20 [ACM]=20 Ask and you shall receive: https://tools.ietf.org/html/draft-morton-ippm-initial-registry-00 We've been working on versions of initial registry entries since the Interi= m meeting in Dublin last year. No one has commented yet. In fact, only Barbara has commented on the registry itself: https://tools.ietf.org/html/draft-ietf-ippm-metric-registry-04 > But it would really help me to > figure out how the bits and pieces fit together. So perhaps reallocate > the data model and protocol time to a discussion how the IPPM registry > works together with the information model. >=20 [ACM] That's fine with me.=20 I wonder who will get the action item/agenda assignment. =3D80 regards, Al From nobody Wed Sep 23 10:32:15 2015 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 1A21B1A8776 for ; Wed, 23 Sep 2015 10:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTDOKKDttaS1 for ; Wed, 23 Sep 2015 10:32:13 -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 ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82731A875E for ; Wed, 23 Sep 2015 10:32:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D9BAA3Q8ZV/xUHmMZbGQEBglQsgT0GqW4Gkz+HfQKBJjoSAQEBAQEBAYEKhCMBAQEBAxIoPwwEAgEIDQgNFAkHMhQRAQEEAQ0FCBqIDAGsdaA6AQEBAQEBBAEBAQEBAQEBARmGH4UyhFgxB4MYgRQFlQsBlVuRBBcPg31vgUiBBAEBAQ X-IPAS-Result: A2D9BAA3Q8ZV/xUHmMZbGQEBglQsgT0GqW4Gkz+HfQKBJjoSAQEBAQEBAYEKhCMBAQEBAxIoPwwEAgEIDQgNFAkHMhQRAQEEAQ0FCBqIDAGsdaA6AQEBAQEBBAEBAQEBAQEBARmGH4UyhFgxB4MYgRQFlQsBlVuRBBcPg31vgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208";a="143366448" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 Sep 2015 13:32:11 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 23 Sep 2015 13:32:11 -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; Wed, 23 Sep 2015 19:32:09 +0200 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , Juergen Schoenwaelder Thread-Topic: [lmap] draft agenda for the 9/29 LMAP WG interim meeting Thread-Index: AdD143GL1XKUc6rzTTKVNU+ASZHHowAKD+OAAAJJ6oAABDZJ8A== Date: Wed, 23 Sep 2015 17:32:08 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB2E1DA@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CB2D8BF@AZ-FFEXMB04.global.avaya.com> <20150923162526.GD2358@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D0BB4581BD5@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB4581BD5@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft agenda for the 9/29 LMAP WG 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: Wed, 23 Sep 2015 17:32:14 -0000 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > But it would really help me to > > figure out how the bits and pieces fit together. So perhaps reallocate > > the data model and protocol time to a discussion how the IPPM registry > > works together with the information model. > > >=20 > [ACM] That's fine with me. > I wonder who will get the action item/agenda assignment. =3D80 >=20 What about Al Morton?=20 Dan From nobody Wed Sep 23 10:58:28 2015 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 4203E1A8A62 for ; Wed, 23 Sep 2015 10:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TrXklvH8YI3L for ; Wed, 23 Sep 2015 10:58:24 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5071A89E9 for ; Wed, 23 Sep 2015 10:57:14 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 239E0120E4C; Wed, 23 Sep 2015 14:23:18 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id 3F583F04B6; Wed, 23 Sep 2015 13:56:56 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Wed, 23 Sep 2015 13:56:55 -0400 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , Juergen Schoenwaelder Date: Wed, 23 Sep 2015 13:56:55 -0400 Thread-Topic: [lmap] draft agenda for the 9/29 LMAP WG interim meeting Thread-Index: AdD143GL1XKUc6rzTTKVNU+ASZHHowAKD+OAAAJJ6oAABDZJ8AAA3Y3Q Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB4581BED@NJFPSRVEXG0.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CB2D8BF@AZ-FFEXMB04.global.avaya.com> <20150923162526.GD2358@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D0BB4581BD5@NJFPSRVEXG0.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA5CB2E1DA@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CB2E1DA@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft agenda for the 9/29 LMAP WG 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: Wed, 23 Sep 2015 17:58:25 -0000 >=20 > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > But it would really help me to > > > figure out how the bits and pieces fit together. So perhaps > > > reallocate the data model and protocol time to a discussion how the > > > IPPM registry works together with the information model. > > > > > > > [ACM] That's fine with me. > > I wonder who will get the action item/agenda assignment. =3D80 > > >=20 > What about Al Morton? >=20 > Dan [ACM]=20 I'll ask him if I see him. From nobody Wed Sep 23 10:58:29 2015 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 DEDCD1A8A63 for ; Wed, 23 Sep 2015 10:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 iDe13S1c2WFi for ; Wed, 23 Sep 2015 10:58:23 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 691251A89E1 for ; Wed, 23 Sep 2015 10:57:14 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id DC4A4120363; Wed, 23 Sep 2015 14:21:48 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id 04916F04D8; Wed, 23 Sep 2015 13:55:27 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Wed, 23 Sep 2015 13:55:26 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder Date: Wed, 23 Sep 2015 13:55:25 -0400 Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Task status object Thread-Index: AdD2JUduFuTaSdoHRrCNIwMbJEkIlQAAhcuA Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB4581BEC@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC22745E@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923151443.GH1945@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D0BB4581BBB@NJFPSRVEXG0.research.att.com> <20150923172819.GA2696@elstar.local> In-Reply-To: <20150923172819.GA2696@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Carey, Timothy \(Timothy\)" , "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Task status object 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, 23 Sep 2015 17:58:26 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Wednesday, September 23, 2015 1:28 PM > To: MORTON, ALFRED C (AL) > Cc: Carey, Timothy (Timothy); lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Task status > object >=20 > On Wed, Sep 23, 2015 at 01:01:35PM -0400, MORTON, ALFRED C (AL) wrote: > > Al chimes-in below: > > > > > -----Original Message----- > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: Wednesday, September 23, 2015 11:15 AM > > > To: Carey, Timothy (Timothy) > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Task > > > status object > > > > > > On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) > > > wrote: > > > > Juergen, > > > > > > > > > > > > In the ma-task-status object you have multiple role with a single > > > registry entry for a task. Your description in ma-task-status-obj > > > doesn't seem to add up. > > > > > > > > What if we have a task with multiple metrics (registry entries)? > > > > > > > > You also have a list of roles - but a registry entry would only be > > > executed under 1 role. > > > > > > My understanding is that a registry entry has at most one role > > > defined > > > (draft-ietf-ippm-metric-registry-04 section 7.3.6). Hence, it seems > > > the ma-task-role is not really needed and should be removed. > > [ACM] > > I think this is a change from previous text, and not in a good way. > > If we have to duplicate registry entries just to indicate a single > > fixed role from two possible roles, then we haven't used the Run-Time > > parameters correctly or efficiently, in my opinion. > > > > Yes, we need to give the set of possible roles for each metric *in the > entry*. > > These roles need to map to the reference text in the Method of > measurement. > > > > OTOH, I can see vendors building systems that only support one of two > > roles, which is fine. I'd rather that this limitation was handled in > > protocols, and not by duplicating registry entries to modify a single > column, "Role". >=20 > So are you saying the text in section 7.3.6 of the registry is wrong? > Or is my understanding of that text wrong? I admit that I do not find > the text very clear. In implementations I am familiar with, the role is > often simply passed as an argument when you invoke a measurement program > (and hence it would not be a separate explicit task attribute either). [ACM]=20 I think you've understood the text correctly. I'm saying that the text is not consistent with my understanding of the agreement reached when Barbara raised the need to identify roles (which itself was an excellent observation). But we've discussed this more than once in meetings, possibly when I wasn't able to attend. IMO, we've already bent over backwards by attempting to address=20 the whole of IETF's scope of metrics. We now need to consider how all the details will be used in practice. >=20 > > > Al Morton said that a task may generate a single packet train that > > > is used to obtain multiple metrics. This is why we allow multiple > > > references to the registry and we expect that tasks will not > > > implement impossible combinations. > > [ACM] > > Thank you for that. > > I would like to see the YANG model synchronized with this feature in > > the information model (unless I've missed it somehow). >=20 > In the YANG data model (draft-ietf-lmap-yang-01), the registry is a > leaf-list and not a simple leaf, hence it can point to multiple registry > entries. >=20 > /js [ACM]=20 Great, that works for me, thanks again. Al >=20 > -- > 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 23 11:07:50 2015 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 CCCD01AC431 for ; Wed, 23 Sep 2015 11:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 UAfWT7Mgt8Uq for ; Wed, 23 Sep 2015 11:07:47 -0700 (PDT) Received: from cdpipgw02.twcable.com (unknown [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 27C7B1A8993 for ; Wed, 23 Sep 2015 11:00:59 -0700 (PDT) X-SENDER-IP: 10.136.163.146 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.17,577,1437451200"; d="scan'208";a="784802821" Received: from unknown (HELO exchpapp05dr.corp.twcable.com) ([10.136.163.146]) by cdpipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 23 Sep 2015 13:57:48 -0400 Received: from EXCHPAPP19.corp.twcable.com (10.64.163.160) by exchpapp05dr.corp.twcable.com (10.136.163.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 23 Sep 2015 14:00:56 -0400 Received: from EXCHPAPP19.corp.twcable.com ([169.254.230.1]) by exchpapp19.corp.twcable.com ([10.64.163.160]) with mapi id 15.00.1104.000; Wed, 23 Sep 2015 14:00:56 -0400 From: "Weil, Jason" To: "MORTON, ALFRED C (AL)" , Juergen Schoenwaelder , "Romascanu, Dan (Dan)" Thread-Topic: [lmap] draft agenda for the 9/29 LMAP WG interim meeting Thread-Index: AQHQ9h31O+qA/RppWUe17cjg7x3kOp5KogqA///FT4A= Date: Wed, 23 Sep 2015 18:00:55 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5CB2D8BF@AZ-FFEXMB04.global.avaya.com> <20150923162526.GD2358@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D0BB4581BD5@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB4581BD5@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.239] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21832.005 x-tm-as-result: No--54.573700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft agenda for the 9/29 LMAP WG 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: Wed, 23 Sep 2015 18:07:49 -0000 The IPPM Registry discussion is a great suggestion that Dan and I were just talking about today on a call. Al,Marcelo, or other presenter, we will give you a spot on the agenda to go over progress and overlap between the Registry and Information Model during next week=B9s Interim call. Thanks, Jason On 9/23/15, 1:30 PM, "lmap on behalf of MORTON, ALFRED C (AL)" wrote: >Another chime from Al follows: > >> -----Original Message----- >Juergen wrote: >... >> Concerning the agenda, I do not think we need much time for the data >> model or the protocol work since there were no discussions on the list. >> There will be updates coming to align with information model updates but >> I do not think we need to discuss these edits during the interim. >[ACM] >I agree, if you align to cover my registry related comment from a few >minutes ago ;-) >> >> We should focus on the information model related questions, mostly >> raised by Tim. And I like to thank Tim for raising these questions - >> reviews and questions are a valuable contribution to make things better >> and I apologize for late responses. >[ACM] >+1 >> >> In addition, it would really help me if some IPPM people can explain how >> the registry actually works. >[ACM] >The reality is that the registry IPPM people are also LMAP people, >for the most part. > >> A few example registry entries would help >> me a lot. I know this request comes a bit late so I am not sure we can >> get registry co-authors into the call. >[ACM] >Ask and you shall receive: >https://tools.ietf.org/html/draft-morton-ippm-initial-registry-00 >We've been working on versions of initial registry entries since the >Interim >meeting in Dublin last year. No one has commented yet. > >In fact, only Barbara has commented on the registry itself: >https://tools.ietf.org/html/draft-ietf-ippm-metric-registry-04 > >> But it would really help me to >> figure out how the bits and pieces fit together. So perhaps reallocate >> the data model and protocol time to a discussion how the IPPM registry >> works together with the information model. >> > >[ACM] That's fine with me. >I wonder who will get the action item/agenda assignment. =3D80 > >regards, >Al > > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Wed Sep 23 11:21:06 2015 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 6EF3C1A916E for ; Wed, 23 Sep 2015 11:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6E-Vew6WzXzn for ; Wed, 23 Sep 2015 11:21:01 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8856A1A90EA for ; Wed, 23 Sep 2015 11:19:50 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id 31440121962; Wed, 23 Sep 2015 14:46:12 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 826A0E4812; Wed, 23 Sep 2015 14:18:10 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Wed, 23 Sep 2015 14:19:49 -0400 From: "MORTON, ALFRED C (AL)" To: "Weil, Jason" , Juergen Schoenwaelder , "Romascanu, Dan (Dan)" Date: Wed, 23 Sep 2015 14:19:48 -0400 Thread-Topic: [lmap] draft agenda for the 9/29 LMAP WG interim meeting Thread-Index: AQHQ9h31O+qA/RppWUe17cjg7x3kOp5KogqA///FT4CAAAE2sA== Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB4581BF9@NJFPSRVEXG0.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CB2D8BF@AZ-FFEXMB04.global.avaya.com> <20150923162526.GD2358@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D0BB4581BD5@NJFPSRVEXG0.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft agenda for the 9/29 LMAP WG 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: Wed, 23 Sep 2015 18:21:03 -0000 > -----Original Message----- > From: Weil, Jason [mailto:jason.weil@twcable.com] > Sent: Wednesday, September 23, 2015 2:01 PM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder; Romascanu, Dan (Dan) > Cc: lmap@ietf.org > Subject: Re: [lmap] draft agenda for the 9/29 LMAP WG interim meeting >=20 > The IPPM Registry discussion is a great suggestion that Dan and I were > just talking about today on a call. >=20 > Al,Marcelo, or other presenter, we will give you a spot on the agenda to > go over progress and overlap between the Registry and Information Model > during next week=B9s Interim call. >=20 ... [ACM]=20 That's fine, but folks should come prepared having *read the registry*=20 drafts below AND this thread, plus a related thread on ippm list last week: https://mailarchive.ietf.org/arch/msg/ippm/XWxR_Pqo7OTxUIqtEZwtsbwoxfU It's most important to understand that the LMAP *-models depend on Registry Entries defining Performance Metrics to have *anything*=20 to measure and report on. So, we'll talk about the Registry Format AND the proposed initial entries as examples of the Format in action. see registry draft URLs below, Al ... > >> A few example registry entries would help me a lot. I know this > >> request comes a bit late so I am not sure we can get registry > >> co-authors into the call. > >[ACM] > >Ask and you shall receive: > > https://tools.ietf.org/html/draft-morton-ippm-initial-registry-00 > >We've been working on versions of initial registry entries since the > >Interim meeting in Dublin last year. No one has commented yet. > > > >In fact, only Barbara has commented on the registry itself: > > https://tools.ietf.org/html/draft-ietf-ippm-metric-registry-04 > > > >> But it would really help me to > >> figure out how the bits and pieces fit together. So perhaps > >> reallocate the data model and protocol time to a discussion how the > >> IPPM registry works together with the information model. > >> > > > >[ACM] That's fine with me. > >I wonder who will get the action item/agenda assignment. =3D80 > > > >regards, > >Al > > From nobody Wed Sep 23 11:30:51 2015 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 79FE41A913F for ; Wed, 23 Sep 2015 11:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 FuXmTYCDvbML for ; Wed, 23 Sep 2015 11:30:49 -0700 (PDT) Received: from s1.neomailbox.net (s1.neomailbox.net [5.148.176.57]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0254C1A9129 for ; Wed, 23 Sep 2015 11:30:48 -0700 (PDT) To: lmap@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA5CB2D8BF@AZ-FFEXMB04.global.avaya.com> <20150923162526.GD2358@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D0BB4581BD5@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D0BB4581BF9@NJFPSRVEXG0.research.att.com> From: marcelo bagnulo Message-ID: <5602EFD3.1010906@neomailbox.ch> Date: Wed, 23 Sep 2015 20:30:43 +0200 MIME-Version: 1.0 In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB4581BF9@NJFPSRVEXG0.research.att.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lmap] draft agenda for the 9/29 LMAP WG 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: Wed, 23 Sep 2015 18:30:50 -0000 I can also attend for the first 50 mins or so. El 23/09/15 a las 20:19, MORTON, ALFRED C (AL) escribió: >> -----Original Message----- >> From: Weil, Jason [mailto:jason.weil@twcable.com] >> Sent: Wednesday, September 23, 2015 2:01 PM >> To: MORTON, ALFRED C (AL); Juergen Schoenwaelder; Romascanu, Dan (Dan) >> Cc: lmap@ietf.org >> Subject: Re: [lmap] draft agenda for the 9/29 LMAP WG interim meeting >> >> The IPPM Registry discussion is a great suggestion that Dan and I were >> just talking about today on a call. >> >> Al,Marcelo, or other presenter, we will give you a spot on the agenda to >> go over progress and overlap between the Registry and Information Model >> during next week¹s Interim call. >> > ... > [ACM] > That's fine, but folks should come prepared having *read the registry* > drafts below AND this thread, plus a related thread on ippm list last week: > https://mailarchive.ietf.org/arch/msg/ippm/XWxR_Pqo7OTxUIqtEZwtsbwoxfU > > It's most important to understand that the LMAP *-models depend on > Registry Entries defining Performance Metrics to have *anything* > to measure and report on. So, we'll talk about the Registry Format > AND the proposed initial entries as examples of the Format in action. > > see registry draft URLs below, > Al > > ... >>>> A few example registry entries would help me a lot. I know this >>>> request comes a bit late so I am not sure we can get registry >>>> co-authors into the call. >>> [ACM] >>> Ask and you shall receive: >>> https://tools.ietf.org/html/draft-morton-ippm-initial-registry-00 >>> We've been working on versions of initial registry entries since the >>> Interim meeting in Dublin last year. No one has commented yet. >>> >>> In fact, only Barbara has commented on the registry itself: >>> https://tools.ietf.org/html/draft-ietf-ippm-metric-registry-04 >>> >>>> But it would really help me to >>>> figure out how the bits and pieces fit together. So perhaps >>>> reallocate the data model and protocol time to a discussion how the >>>> IPPM registry works together with the information model. >>>> >>> [ACM] That's fine with me. >>> I wonder who will get the action item/agenda assignment. =80 >>> >>> regards, >>> Al >>> > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > From nobody Wed Sep 23 14:21:36 2015 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 90ABC1B2D78 for ; Wed, 23 Sep 2015 14:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STNkoEDYj_zL for ; Wed, 23 Sep 2015 14:21:33 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [200.160.4.5]) (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 7BF741B2D77 for ; Wed, 23 Sep 2015 14:21:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id CCBC9146949; Wed, 23 Sep 2015 18:21:31 -0300 (BRT) X-Virus-Scanned: Debian amavisd-new at mail.nic.br Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFlaud0a31Yp; Wed, 23 Sep 2015 18:21:30 -0300 (BRT) Received: from 5.140.net.registro.br (unknown [IPv6:2001:12ff:0:5::140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 5657C146908; Wed, 23 Sep 2015 18:21:30 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1443043290; bh=4FiASev9oyqPCiCazmJw9gfUhCbdZrX4ne+WAm9UxQY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=QfsACNRL4lweBBSeD6V+deYVWZH+HsekXbutUsg2Xpp3R5HxwbTEG4dRam6qV3+E0 YWr/ajAEI9hIC0g+aY3vi+ETnKTPH8rFm3r9RAJCwyS9rCJMjKipZv+Nx91LvZq5Gi FVJfwnSET8FV/O54BoFEE4N79VJANevqnYl3L7ac= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Holger Wiehen In-Reply-To: <20150921083928.GB11184@elstar.local> Date: Wed, 23 Sep 2015 18:21:30 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <434D830D-7592-4237-8AF2-2B5A869146C2@nic.br> <4AF73AA205019A4C8A1DDD32C034631D0BB45814F1@NJFPSRVEXG0.research.att.com> <55D149D8-329D-4D95-89A0-7E4621F16417@nic.br> <20150921083928.GB11184@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2104) DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br 5657C146908 Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] Standard for coordination between MAs 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, 23 Sep 2015 21:21:35 -0000 J=C3=BCrgen, Thank's for your comments.=20 Your comment regarding the trust relationship, has been very valuable = for our work. Since the WG has put its focus on the chartered work items and the = interim meeting, I will hold back with the discussion about a standard = for communication between MAs. Holger Wiehen. > On Sep 21, 2015, at 5:39 AM, Juergen Schoenwaelder = wrote: >=20 > On Thu, Sep 17, 2015 at 07:03:14PM -0300, Holger Wiehen wrote: >> Hi Al. >>=20 >> Thank's for your reply. >>=20 >> I will try illustrate our idea of MA Communications with 2 example = use cases. >>=20 >> One example would be a MA initiated by a human user, executing = measurements against a remote MA. Results obtained on the remote MA = should be presented to the end user (local MA), with low delay. >>=20 >> I understand that pushing results to a MA could not be solved with = the report flow specified by LMAP. In an end user focused use case, = exchanging reports directly between MAs, would allow for quick and = resilient reporting to users. This reporting would be in addition to the = usual report submission to the LMAP collector. >=20 > Can you provide a concrete example where this is useful? Can anyone on = the > Internet use the MA for measurements? If not, how do you establish a = trust > relationship? >=20 >> A second use case is a MA responding active measurements initiated by = another MA. Our responding MA receives its configuration from the LMAP = controller, but once it is set up, it does not depend on the control = channel in order to respond to measurements initiated by a remote MA. = The responding MA receives parameters specific to a single measurement = session, from the initiating MA. Coordinating active measurements = directly between MAs would increase resilience and reduce timing issues. >=20 > Can you provide a concrete example where this is useful? How do you > establish a trust relationship? >=20 > /js >=20 > --=20 > 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 23 16:21:38 2015 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 D25941B32E7 for ; Wed, 23 Sep 2015 16:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 p0_BFb9wgx-y for ; Wed, 23 Sep 2015 16:21:35 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A14B1B32E5 for ; Wed, 23 Sep 2015 16:21:35 -0700 (PDT) Received: by ioiz6 with SMTP id z6so59262948ioi.2 for ; Wed, 23 Sep 2015 16:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=o29G1JPAEn9QtgXsTDViGM1O5l7SIJUIWz2oWQj+VyQ=; b=wyE8Dxg2v7TOD4rEnwm9hQnCUzVCcpyGqE9e7lTgJV2XsfBz+RpIjEQruh+mPUVMka XqFJnO2rNrS9G3wFXUtFARDqKPtH6P6mnYc9HKsvXD3ZOrHDsefVoGHS+3uRdqfLA124 1mE13v2o+orwuX65T6tfKnDCM5vU+exUbIH4yBMEGnZG5euBCF5eXiyEY7yNzWOxlxuh RutNv8WLfOtC/4BXYnTSzkuXQEU9MMCLbQ18Wf4IftNSVQ6gudqKbQ0ztmOQXB+8QTjz xL4X8Tg1oa55qdypMcvF8ISpT9aMgByx08AwNyTn6SCEEqZWrOjveYk4WFH9AQ3B+wOc j8hQ== X-Received: by 10.107.135.205 with SMTP id r74mr40573461ioi.54.1443050494549; Wed, 23 Sep 2015 16:21:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.174.167 with HTTP; Wed, 23 Sep 2015 16:20:55 -0700 (PDT) From: James Miller Date: Wed, 23 Sep 2015 19:20:55 -0400 Message-ID: To: Juergen Schoenwaelder , Holger Wiehen , "lmap@ietf.org" Content-Type: multipart/alternative; boundary=001a113ed29e1ee8d805207260e4 Archived-At: Cc: "Bugenhagen, Michael K" , "Weil, Jason" Subject: Re: [lmap] Standard for coordination between MAs 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, 23 Sep 2015 23:21:38 -0000 --001a113ed29e1ee8d805207260e4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Let me illustrate another use case. :: Whitebox to Smartphone Testing Consider a MA that is the client to a measurement server ("offnet server") for a large scale measurement network ("whitebox") that also serves as a measurement server for other MA's connecting via WiFI on WLAN ("smartphone"). The whitebox makes observations for a variety of performance characteristics on a fixed CABLE / FIBER / DSL connection, caches the statistics locally but also uploads them to a backend collector host. The smartphone performs tests against a whitebox to test the performance over the wireless link as well as tests to an offnet server for an end-to-end metric through the whitebox and fixed connection. The whitebox might communicate to the smartphone information about the fixed connection, such as the provider, speed tier or other, as well as the running statistics (last hours performance for upload/download and latency for example). The information collected by the smartphone combined with the information provided by the whitebox might be necessary for understanding the smartphones performance on teh WLAN separate from the backhaul fixed connection. Information might be available for the whitebox separately, but it might not be available for privacy reasons or within a time frame that satisfies an operational need for the smartphone. Trust could be established using physical access to the devices or other means. -- JamesMillerEsquire@Gmail.com "Wovon man nicht sprechen kann, dar=C3=BCber mu=C3=9F man schweigen." (What we cannot speak about we must pass over in silence. ) Ludwig Josef Johann Wittgenstein On Mon, Sep 21, 2015 at 4:39 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Sep 17, 2015 at 07:03:14PM -0300, Holger Wiehen wrote: > > Hi Al. > > > > Thank's for your reply. > > > > I will try illustrate our idea of MA Communications with 2 example use > cases. > > > > One example would be a MA initiated by a human user, executing > measurements against a remote MA. Results obtained on the remote MA shoul= d > be presented to the end user (local MA), with low delay. > > > > I understand that pushing results to a MA could not be solved with the > report flow specified by LMAP. In an end user focused use case, exchangin= g > reports directly between MAs, would allow for quick and resilient reporti= ng > to users. This reporting would be in addition to the usual report > submission to the LMAP collector. > > Can you provide a concrete example where this is useful? Can anyone on th= e > Internet use the MA for measurements? If not, how do you establish a trus= t > relationship? > > > A second use case is a MA responding active measurements initiated by > another MA. Our responding MA receives its configuration from the LMAP > controller, but once it is set up, it does not depend on the control > channel in order to respond to measurements initiated by a remote MA. The > responding MA receives parameters specific to a single measurement sessio= n, > from the initiating MA. Coordinating active measurements directly between > MAs would increase resilience and reduce timing issues. > > Can you provide a concrete example where this is useful? How do you > establish a trust relationship? > > /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 > --001a113ed29e1ee8d805207260e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me illustrate another use case.

:: = Whitebox to Smartphone Testing=C2=A0

Consider a MA= that is the client to a measurement server ("offnet server") for= a large scale measurement network ("whitebox") that also serves = as a measurement server for other MA's connecting via WiFI on WLAN (&qu= ot;smartphone").

The whitebox makes observati= ons for a variety of performance characteristics on a fixed CABLE / FIBER /= DSL connection, caches the statistics locally but also uploads them to a b= ackend collector host.

The smartphone performs tes= ts against a whitebox to test the performance over the wireless link as wel= l as tests to an offnet server for an end-to-end metric through the whitebo= x and fixed connection. =C2=A0

The whitebox might = communicate to the smartphone information about the fixed connection, such = as the provider, speed tier or other, as well as the running statistics (la= st hours performance for upload/download and latency for example).=C2=A0 Th= e information collected by the smartphone combined with the information pro= vided by the whitebox might be necessary for understanding the smartphones = performance on teh WLAN separate from the backhaul fixed connection.
<= div>
Information might be available for the whitebox separate= ly, but it might not be available for privacy reasons or within a time fram= e that satisfies an operational need for the smartphone.

Trust could be established= using physical access to the devices or other means.
--
JamesMillerEsquire@Gmail.com

"Wovon ma= n nicht sprechen kann, dar=C3=BCber mu=C3=9F man schweigen."
(What we cannot speak about we must pass over in silence. =C2=A0)
Ludwig Josef Johann Wittgenstein

On Mon, Sep 21, 2015 at 4:39 AM, Juergen Sch= oenwaelder <j.schoenwaelder@jacobs-university.de>= ; wrote:
On Thu, = Sep 17, 2015 at 07:03:14PM -0300, Holger Wiehen wrote:
> Hi Al.
>
> Thank's for your reply.
>
> I will try illustrate our idea of MA Communications with 2 example use= cases.
>
> One example would be a MA initiated by a human user, executing measure= ments against a remote MA. Results obtained on the remote MA should be pres= ented to the end user (local MA), with low delay.
>
> I understand that pushing results to a MA could not be solved with the= report flow specified by LMAP. In an end user focused use case, exchanging= reports directly between MAs, would allow for quick and resilient reportin= g to users. This reporting would be in addition to the usual report submiss= ion to the LMAP collector.

Can you provide a concrete example where this is useful? Can anyone = on the
Internet use the MA for measurements? If not, how do you establish a trust<= br> relationship?

> A second use case is a MA responding active measurements initiated by = another MA. Our responding MA receives its configuration from the LMAP cont= roller, but once it is set up, it does not depend on the control channel in= order to respond to measurements initiated by a remote MA. The responding = MA receives parameters specific to a single measurement session, from the i= nitiating MA. Coordinating active measurements directly between MAs would i= ncrease resilience and reduce timing issues.

Can you provide a concrete example where this is useful? How do you<= br> establish a trust relationship?

/js

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

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

--001a113ed29e1ee8d805207260e4-- From nobody Thu Sep 24 04:17:03 2015 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 3C7D51A1AA3 for ; Thu, 24 Sep 2015 04:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY15w3BAcQlg for ; Thu, 24 Sep 2015 04:16:59 -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 ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213F31A1A9F for ; Thu, 24 Sep 2015 04:16:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AeAwA3Q8ZV/yYyC4dYAxkBAQGCUyxUaQapbgaTNgmCBoV3AoEmOBQBAQEBAQEBgQqEIwEBAQEDEig/DAICAgEIDQECAQQBAQEKFAkHGxcUCQgBAQQOBQgaiAwBDKxpoDoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIYbhTKENwEBHyEQBwYMgwaBFAWVCwGFAYkqRoNfgwuRBBcPgg4cgVNvAYENOoEEAQEB X-IPAS-Result: A2AeAwA3Q8ZV/yYyC4dYAxkBAQGCUyxUaQapbgaTNgmCBoV3AoEmOBQBAQEBAQEBgQqEIwEBAQEDEig/DAICAgEIDQECAQQBAQEKFAkHGxcUCQgBAQQOBQgaiAwBDKxpoDoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIYbhTKENwEBHyEQBwYMgwaBFAWVCwGFAYkqRoNfgwuRBBcPgg4cgVNvAYENOoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208";a="143470707" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 Sep 2015 07:16:59 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 24 Sep 2015 07:16:57 -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; Thu, 24 Sep 2015 13:16:56 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [lmap] draft agenda for the 9/29 LMAP WG interim meeting Thread-Index: AdD143GL1XKUc6rzTTKVNU+ASZHHowAKD+OAACuksAA= Date: Thu, 24 Sep 2015 11:16:54 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB2ED97@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CB2D8BF@AZ-FFEXMB04.global.avaya.com> <20150923162526.GD2358@elstar.local> In-Reply-To: <20150923162526.GD2358@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft agenda for the 9/29 LMAP WG interim meeting X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 11:17:01 -0000 I updated the agenda at https://www.ietf.org/proceedings/interim/2015/09/29= /lmap/agenda/agenda-interim-2015-lmap-3 to reflect the changes that you req= uested.=20 Al - please confirm that you can drive the IPPM section. I put it first in = the agenda because Marcelo said that he can attend only the first 50 min.=20 Thanks and Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Wednesday, September 23, 2015 7:25 PM > To: Romascanu, Dan (Dan) > Cc: lmap@ietf.org > Subject: Re: [lmap] draft agenda for the 9/29 LMAP WG interim meeting >=20 > On Wed, Sep 23, 2015 at 09:37:21AM +0000, Romascanu, Dan (Dan) wrote: > > Hi, > > > > I have uploaded the draft agenda of for the 9/29 LMAP WG interim > meeting at https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_proceedings_interim_2015_09_29_lmap_agenda_agend > a-2Dinterim-2D2015-2Dlmap- > 2D3&d=3DBQIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiL > QfucBXRucPvdrphpBsFA&m=3D0OdW9CNquRYyYh-9qP2- > 7g6OPxhpLPz7bxvfC5-ChV0&s=3DMEMGHKOttYilRlhR_-ccqwxd- > ssMaKAXj9M_6p4MFa8&e=3D . > > > > The scope of the interim should be on the three chartered work items: > > > > 3. LMAP Information Model - (Trevor, Juergen, 50 min) > > > > 4. LMAP YANG Data Model - (Juergen, 20 min) > > > > 5. LMAP Protocol - (Juergen, 20 min) > > > > > > I do not see however much progress or discussions on the mail list on t= his, > with the exception of the comments made by Tim Carey which need to be > addressed. No new I-Ds where submitted since IETF 93. Jason and me would > like to hear from the authors and the other editors what are their plans = and > how they would like to use the meeting time. > > >=20 > I was hoping NETMOD would not take so much of my time anymore but I was > wrong with that prediction. I am doing priority queuing now and > unfortunately this affects progress in LMAP (but other IETF related stuff= is > even more affected). >=20 > Concerning the agenda, I do not think we need much time for the data > model or the protocol work since there were no discussions on the list. T= here > will be updates coming to align with information model updates but I do n= ot > think we need to discuss these edits during the interim. >=20 > We should focus on the information model related questions, mostly raised > by Tim. And I like to thank Tim for raising these questions - reviews and > questions are a valuable contribution to make things better and I apologi= ze > for late responses. >=20 > In addition, it would really help me if some IPPM people can explain how = the > registry actually works. A few example registry entries would help me a = lot. I > know this request comes a bit late so I am not sure we can get registry c= o- > authors into the call. But it would really help me to figure out how the = bits > and pieces fit together. So perhaps reallocate the data model and protoco= l > time to a discussion how the IPPM registry works together with the > information model. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > 2Duniversity.de_&d=3DBQIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3D0OdW9CNquRYyYh-9qP2- > 7g6OPxhpLPz7bxvfC5-ChV0&s=3DkFNlNmHGI6REi9GUIcB65rA- > SxCYWWB7CE4aNrN5TLc&e=3D > From nobody Thu Sep 24 06:10:47 2015 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 2B8381ACED4 for ; Thu, 24 Sep 2015 06:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvElSj_iB-Uf for ; Thu, 24 Sep 2015 06:10:43 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5881ACECF for ; Thu, 24 Sep 2015 06:10:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BWAwBBP8ZV/yYyC4dbGQSCUixUaQaDHqZQBpM2CYFdHQqFeQIcgQo4FAEBAQEBAQF/C4QjAQEBAQMSCwYRUQYBCA0IBQIGCxIDAgQwFAEGAQYEAQQTCAwLA4gMAQynYYULilaVaAsBAQEBHYEihH2FMoQmEQEgQoIkOxIdgRQFjFWINgGFAYJphkFGg1+DC40eg2YXD4N9b4EOOoEEAQEB X-IPAS-Result: A2BWAwBBP8ZV/yYyC4dbGQSCUixUaQaDHqZQBpM2CYFdHQqFeQIcgQo4FAEBAQEBAQF/C4QjAQEBAQMSCwYRUQYBCA0IBQIGCxIDAgQwFAEGAQYEAQQTCAwLA4gMAQynYYULilaVaAsBAQEBHYEihH2FMoQmEQEgQoIkOxIdgRQFjFWINgGFAYJphkFGg1+DC40eg2YXD4N9b4EOOoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208";a="121423498" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Sep 2015 09:10:40 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 24 Sep 2015 09:10:39 -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; Thu, 24 Sep 2015 15:10:38 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: Nomcom 2015: Third and FINAL call for nominations Thread-Index: AdD2ymbqRIz0wNOTR5yO+QgztrLtFw== Date: Thu, 24 Sep 2015 13:10:38 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB2F1B7@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.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [lmap] FW: Nomcom 2015: Third and FINAL call for nominations 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, 24 Sep 2015 13:10:46 -0000 SGksDQoNClBsZWFzZSBmaW5kIGJlbG93IHRoZSAzcmQgYW5kIGZpbmFsIGNhbGwgZm9yIG5vbWlu YXRpb24gZnJvbSBOb21jb20uIA0KDQpQbGVhc2UgaGVscCBieSBwcm9wb3NpbmcgdGhlIGJlc3Qg Y2FuZGlkYXRlcyBmb3IgdGhlIG9wZW4gcG9zaXRpb25zLiANCg0KVGhhbmtzIGFuZCBSZWdhcmRz LA0KDQpEYW4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElFVEYt QW5ub3VuY2UgW21haWx0bzppZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZg0KDQoNClRoaXMgaXMgdGhlIFRISVJEIGNhbGwgZm9yIG5vbWluYXRpb25zIGZvciB0aGUg MjAxNS0yMDE2IG5vbWNvbS4NCg0KVGhlIDIwMTUtMTYgTm9taW5hdGluZyBDb21taXR0ZWUgKE5v bWNvbSkgaXMgc2Vla2luZyBub21pbmF0aW9ucyBmcm9tDQpub3cgdW50aWwgT2N0b2JlciA4LCAy MDE1LiBUaGUgb3BlbiBwb3NpdGlvbnMgYmVpbmcgY29uc2lkZXJlZCBieSB0aGlzDQp5ZWFyJ3Mg Tm9tY29tIGNhbiBiZSBmb3VuZCBhdCB0aGUgZW5kIG9mIHRoaXMgZW1haWwgYW5kIGFsc28gb24g dGhpcw0KeWVhcidzIE5vbWNvbSB3ZWJzaXRlOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL25vbWNvbS8yMDE1Lw0KDQpOb21pbmF0aW9ucyBtYXkgYmUgbWFkZSBieSBzZWxlY3Rpbmcg dGhlIE5vbWluYXRlIGxpbmsgYXQgdGhlIHRvcCBvZg0KdGhlIE5vbWNvbSAyMDE1IGhvbWUgcGFn ZSwgb3IgYnkgdmlzaXRpbmcgdGhlIGZvbGxvd2luZyBVUkw6DQoNCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvbm9tY29tLzIwMTUvbm9taW5hdGUvDQoNCiAge05vdGUgdGhhdCBub21pbmF0 aW9ucyBtYWRlIHVzaW5nIHRoZSB3ZWIgdG9vbCByZXF1aXJlIGFuIGlldGYub3JnDQogICBkYXRh dHJhY2tlciBhY2NvdW50LiBZb3UgY2FuIGNyZWF0ZSBhIGRhdGF0cmFja2VyIGlldGYub3JnIGFj Y291bnQNCiAgIGlmIHlvdSBkb24ndCBoYXZlIG9uZSBhbHJlYWR5IGJ5IHZpc2l0aW5nIHRoZSBm b2xsb3dpbmcgVVJMOg0KICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9hY2NvdW50cy9j cmVhdGUvIH0NCg0KSWYgeW91IGFyZSB1bmFibGUgdG8gdXNlIHRoZSB3ZWIgZm9ybSwgbm9taW5h dGlvbnMgbWF5IGluc3RlYWQgYmUgbWFkZQ0KYnkgZW1haWwgdG8gbm9tY29tMTVAaWV0Zi5vcmcu IElmIHVzaW5nIGVtYWlsLCBwbGVhc2UgaW5jbHVkZSB0aGUgd29yZA0KIk5vbWluYXRlIiBpbiB0 aGUgU3ViamVjdCBhbmQgaW5kaWNhdGUgaW4gdGhlIGVtYWlsIHdobyBpcyBiZWluZw0Kbm9taW5h dGVkLCB0aGVpciBlbWFpbCBhZGRyZXNzICh0byBjb25maXJtIGFjY2VwdGFuY2Ugb2YgdGhlDQpu b21pbmF0aW9uKSwgYW5kIHRoZSBwb3NpdGlvbiBmb3Igd2hpY2ggeW91IGFyZSBtYWtpbmcgdGhl IG5vbWluYXRpb24uDQpJZiB5b3UgYXJlIG5vbWluYXRpbmcgc29tZW9uZSBvdGhlciB0aGFuIHlv dXJzZWxmLCBwbGVhc2UgdGVsbCB1cyBpZg0Kd2UgbWF5IHRlbGwgdGhlIG5vbWluZWUgdGhhdCB5 b3Ugd2VyZSB0aGUgb25lIHdobyBtYWRlIHRoZSBub21pbmF0aW9uLg0KSWYgeW91IHdpc2ggdG8g bm9taW5hdGUgc29tZW9uZSB2aWEgZW1haWwgZm9yIG1vcmUgdGhhbiBvbmUgcG9zaXRpb24sDQpw bGVhc2UgdXNlIHNlcGFyYXRlIGVtYWlscyB0byBkbyBzby4NCg0KU2VsZi1ub21pbmF0aW9uIGlz IHdlbGNvbWUhDQoNCk5vbUNvbSAyMDE1LTE2IHdpbGwgZm9sbG93IHRoZSBwb2xpY3kgZm9yICJP cGVuIERpc2Nsb3N1cmUgb2YgV2lsbGluZw0KTm9taW5lZXMiIGRlc2NyaWJlZCBpbiBCQ1AgMTAv UkZDIDc0MzcuICBBcyBzdGF0ZWQgaW4gUkZDIDc0Mzc6ICJUaGUNCmxpc3Qgb2Ygbm9taW5lZXMg d2lsbGluZyB0byBiZSBjb25zaWRlcmVkIGZvciBwb3NpdGlvbnMgdW5kZXIgcmV2aWV3DQppbiB0 aGUgY3VycmVudCBOb21jb20gY3ljbGUgaXMgbm90IGNvbmZpZGVudGlhbCIuIFdpbGxpbmcgbm9t aW5lZXMgZm9yDQplYWNoIHBvc2l0aW9uIHdpbGwgYmUgbGlzdGVkIGluIGEgcHVibGljbHkgYWNj ZXNzaWJsZSB3YXkgLSBhbnlvbmUNCndpdGggYSBkYXRhdHJhY2tlciBhY2NvdW50IG1heSBhY2Nl c3MgdGhlIGxpc3RzLiAgQWRkaXRpb25hbGx5LCB0aGUNCm5vbWluYXRpb24gZm9ybSBhc2tzIGlm IHdlIG1heSBzaGFyZSB5b3VyIG93biBuYW1lIHdpdGggdGhlDQpub21pbmVlLiBJbiBhbGwgb3Ro ZXIgd2F5cywgdGhlIGNvbmZpZGVudGlhbGl0eSByZXF1aXJlbWVudHMgb2YgQkNQMTANCnJlbWFp biBpbiBlZmZlY3QuICBBbGwgZmVlZGJhY2sgYW5kIGFsbCBOb21jb20gZGVsaWJlcmF0aW9ucyB3 aWxsDQpyZW1haW4gY29uZmlkZW50aWFsIGFuZCB3aWxsIG5vdCBiZSBkaXNjbG9zZWQuDQoNClRo ZSBsaXN0IG9mIG5vbWluZWVzIHdobyBoYXZlIGFjY2VwdGVkIHRoZWlyIG5vbWluYXRpb24gaXMg dmlzaWJsZSBhdA0KdGhpcyBsaW5rOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL25v bWNvbS8yMDE1L2ZlZWRiYWNrLw0KDQpUaGVyZSBpcyBhIGZpZWxkIG9uIHRoZSBmb3JtIHlvdSBj YW4gbWFyayBpbiBvcmRlciB0byBhbGxvdyB0aGUgTm9tY29tDQp0byB0ZWxsIHRoZSBub21pbmVl IHRoYXQgeW91IHdlcmUgdGhlIG9uZSB3aG8gbWFkZSB0aGUNCm5vbWluYXRpb24uIFRoaXMgaXMg YSBuZXcgdGhpbmcgdGhpcyB5ZWFyLCBhbmQgaXQgZGVmYXVsdHMgdG8g4oCcbm/igJ0gLQ0Kd2Ug d29u4oCZdCB0ZWxsLiBBZnRlciB0aGUgbm9taW5hdGlvbiBjeWNsZSwgd2Ugd2lsbCBldmFsdWF0 ZSB0aGUgcmVzdWx0DQpvZiB0aGlzIGFuZCByZWNvbW1lbmQgd2hldGhlciB0aGUgbmV4dCBOb21j b20gc2hvdWxkIGRvIHNvbWV0aGluZw0KZGlmZmVyZW50Lg0KDQpJbiBvcmRlciB0byBlbnN1cmUg dGltZSB0byBjb2xsZWN0IHN1ZmZpY2llbnQgY29tbXVuaXR5IGZlZWRiYWNrIGFib3V0DQplYWNo IG9mIHRoZSB3aWxsaW5nIG5vbWluZWVzLCBub21pbmF0aW9ucyBtdXN0IGJlIHJlY2VpdmVkIGJ5 IHRoZQ0KTm9tY29tIG9uIG9yIGJlZm9yZSBPY3RvYmVyIDgsIDIwMTUuDQpUaGlzIGlzIFRXTyBX RUVLUyBmcm9tIG5vdy4NCg0KUGxlYXNlIHN1Ym1pdCB5b3VyIG5vbWluYXRpb25zIGFzIGVhcmx5 IGFzIHBvc3NpYmxlIGZvciB0aGUgc2FrZSBvZg0KeW91ciBub21pbmVlcy4gTm90ZSB0aGF0IG5v bWluYXRpb25zIHNob3VsZCBub3Qgd2FpdCBmb3IgbWFuYWdlbWVudA0KcGVybWlzc2lvbiwgYXMg aXQgaXMgZWFzaWVyIHRvIGRlY2xpbmUgdGhlIG5vbWluYXRpb24gdGhhbiBwdXQgb25lIGluDQps YXRlLiAgV2UgaGF2ZSBzZXQgdGhlIHF1ZXN0aW9ubmFpcmUgc3VibWlzc2lvbiBkZWFkbGluZSBm b3IgT2N0b2Jlcg0KMTUsIDIwMTUuDQoNClRoZSBOb21jb20gYXBwb2ludHMgaW5kaXZpZHVhbHMg dG8gZmlsbCB0aGUgb3BlbiBzbG90cyBvbiB0aGUgSUFPQywNCnRoZSBJQUIsIGFuZCB0aGUgSUVT Ry4gVGhlIGxpc3Qgb2YgcGVvcGxlIGFuZCBwb3N0cyB3aG9zZSB0ZXJtcyBlbmQNCndpdGggdGhl IE1hcmNoIDIwMTYgSUVURiBtZWV0aW5nLCBhbmQgdGh1cyB0aGUgcG9zaXRpb25zIGZvciB3aGlj aA0KdGhpcyBOb21jb20gaXMgcmVzcG9uc2libGUsIGZvbGxvd3M6DQoNCklBQjoNCiogTWFyeSBC YXJuZXMNCiogSm9lIEhpbGRlYnJhbmQNCiogVGVkIEhhcmRpZQ0KKiBFcmlrIE5vcmRtYXJrDQoq IEJyaWFuIFRyYW1tZWxsDQoqIE1hcmMgQmxhbmNoZXQNCg0KSUVTRzoNCi0gQWxpc3NhIENvb3Bl ciwgQVJUDQotIEJhcnJ5IExlaWJhLCBBUlQNCi0gQnJpYW4gSGFiZXJtYW4sIEludGVybmV0ICgq KQ0KLSBCZW5vaXQgQ2xhaXNlLCBPJk0NCi0gQWxpYSBBdGxhcywgUm91dGluZw0KLSBLYXRobGVl biBNb3JpYXJ0eSwgU2VjdXJpdHkNCi0gTWFydGluIFN0aWVtZXJsaW5nLCBUcmFuc3BvcnQgKCop DQoNCiotIGhhdmUgaW5kaWNhdGVkIHRoYXQgdGhleSBkbyBub3QgaW50ZW5kIHRvIGFjY2VwdCBh DQpyZW5vbWluYXRpb24uIFRoaXMgaW5mb3JtYXRpb24gaXMgYWx3YXlzIHVwIHRvIGRhdGUgb24N Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIwMTUvDQoNClBsZWFzZSBiZSBy ZXNvdXJjZWZ1bCBpbiBpZGVudGlmeWluZyBwb3NzaWJsZSBjYW5kaWRhdGVzIGZvciB0aGVzZQ0K cG9zaXRpb25zLCBhcyBkZXZlbG9waW5nIG91ciB0YWxlbnQgaXMgYSB2ZXJ5IGNydWNpYWwgcmVx dWlyZW1lbnQgZm9yDQp0aGUgSUVURiwgYW5kIGFsc28sIHBsZWFzZSBjb25zaWRlciBhY2NlcHRp bmcgYSBub21pbmF0aW9uLiAgWW91J2xsDQpmaW5kIGV4dGVuc2l2ZSBpbmZvcm1hdGlvbiBhYm91 dCBzcGVjaWZpYyBwb3NpdGlvbnMsIGRldmVsb3BlZCBieSB0aGUNCklBQiwgSUVTRywgYW5kIElB T0MsIHVuZGVyIGluZGl2aWR1YWwgdGFicyBhdDoNCg0KICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL25vbWNvbS8yMDE1L3JlcXVpcmVtZW50cy8NCg0KVGhlIGZvbGxvd2luZyBwZW9wbGUg aGF2ZSBiZWVuIG5vbWluYXRlZCBhbmQgaGF2ZSBhY2NlcHRlZCB0aGVpcg0Kbm9taW5hdGlvbiBh dCB0aGlzIHRpbWU6DQoNCkFSVCBBRDoNCkJhcnJ5IExlaWJhDQpBbGlzc2EgQ29vcGVyDQoNCk1h bmFnZW1lbnQgQUQ6DQpCZW5vaXQgQ2xhaXNlDQoNClJvdXRpbmcgQUQ6DQpBbGlhIEF0bGFzDQpS dXNzIFdoaXRlDQpBY2VlIExpbmRlbQ0KSmVmZiBUYW50c3VyYQ0KDQpTZWN1cml0eSBBRDoNCkVy aWMgUmVzY29ybGENCkxlaWYgSm9oYW5zc29uDQpZb2F2IE5pcg0KS2F0aGxlZW4gTW9yaWFydHkN Cg0KVHJhbnNwb3J0IEFEOg0KTWlyamEgS3VlaGxld2luZA0KDQpJbnRlcm5ldCBBRDoNCj09PT09 PT09PT0+IE5PTkUgPD09PT09PT09PT09PQ0KDQpJQUI6DQpEYW4gUm9tYXNjYW51DQpCcmlhbiBU cmFtbWVsbA0KVGVkIEhhcmRpZQ0KTWFydGluIFRob21zb24NCkxlZSBIb3dhcmQNCkpvZSBIaWxk ZWJyYW5kDQpSb25pIEV2ZW4NClN1c2FuIEhhcmVzDQpTdGV3YXJ0IEJyeWFudA0KDQpJbiBhZGRp dGlvbiB0byBub21pbmF0aW9ucywgdGhlIE5vbWNvbSBzZWVrcyBjb21tdW5pdHkgaW5wdXQgb24g dGhlDQpwb3NpdGlvbnMgdGhlbXNlbHZlcy4gIFdlIG5lZWQgYW5kIHdlbGNvbWUgdGhlIGNvbW11 bml0eSdzIHZpZXdzIGFuZA0KaW5wdXQgb24gdGhlIGpvYnMgd2l0aGluIGVhY2ggb3JnYW5pemF0 aW9uLiBJZiB5b3UgaGF2ZSBpZGVhcyBvbiB0aGUNCnBvc2l0aW9ucycgcmVzcG9uc2liaWxpdGll cyAobW9yZSwgbGVzcywgZGlmZmVyZW50KSwgcGxlYXNlIGxldCB1cw0Ka25vdy4NCg0KUGxlYXNl IHNlbmQgc3VnZ2VzdGlvbnMgYW5kIGZlZWRiYWNrIGFib3V0IHRoaXMgdG8gbm9tY29tMTVAaWV0 Zi5vcmcuDQoNClRoYW5rIHlvdSBmb3IgeW91ciBoZWxwIGluIGlkZW50aWZ5aW5nIHF1YWxpZmll ZCBub21pbmVlcyENCg0KSGFyYWxkIEFsdmVzdHJhbmQNCk5vbWNvbSBDaGFpciAyMDE1LTE2DQpu b21jb20tY2hhaXItMjAxNUBpZXRmLm9yZywgaHRhK25vbWNvbUBhbHZlc3RyYW5kLm5vDQo= From holger@nic.br Thu Sep 24 09:51:51 2015 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 810691B2A5F for ; Thu, 24 Sep 2015 09:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.162 X-Spam-Level: X-Spam-Status: No, score=-0.162 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5-ATmyT6FA0 for ; Thu, 24 Sep 2015 09:51:50 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [200.160.4.5]) (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 D448E1B29EF for ; Thu, 24 Sep 2015 09:51:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id 1F281146AB3; Thu, 24 Sep 2015 13:51:48 -0300 (BRT) X-Virus-Scanned: Debian amavisd-new at mail.nic.br Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeKUZ-eoFkFn; Thu, 24 Sep 2015 13:51:47 -0300 (BRT) Received: from 5.140.net.registro.br (unknown [IPv6:2001:12ff:0:5::140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 24DCF146A75; Thu, 24 Sep 2015 13:51:47 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1443113507; bh=UP9v/PV93dU6a0ihCks0mEDtqaGGGHfpj+7rNtHapfk=; h=From:Subject:Date:Cc:To:From; b=Yps9pVTrWnIx9l3N2nwhjsyRg12BJAhvoc+SEnEllPp86G0LnQSRca6IeP2IxvNd/ otekXiAINVV9aoCd9Uj9cwPoGAhzEiyFNJMMruSkDqbDGq+AjtPonVIKpJ03O6Dsjo QKvfcwfLOcNh5t1Hpr29a/nosBvwS0eL5/KCsvrc= From: Holger Wiehen Content-Type: multipart/alternative; boundary="Apple-Mail=_D4CE17B9-9DAD-47B9-B710-152A7BBCC199" Date: Thu, 24 Sep 2015 13:51:46 -0300 Message-Id: <82660D27-0B52-443E-83CF-5A02E9E791BC@nic.br> To: lmap@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br 24DCF146A75 Cc: Juergen Schoenwaelder Subject: [lmap] Consider constraints for MA capabilities (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, 24 Sep 2015 16:51:51 -0000 --Apple-Mail=_D4CE17B9-9DAD-47B9-B710-152A7BBCC199 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi. Following is a suggestion to extend the concept of MA capabilities. = Maybe it is on time for the interim? The capabilities of a MA might include constraints, for the measurement = tasks it supports. The Controller should consider those constraints when = it instructs the MA. Constraints might limit the Controller=E2=80=99s = choice for task-options or for task scheduling. Three examples: - A measurement agent does support a given measurement task, but due to = limited device resources, the task configuration should respect a = maximum duration. - A measurement agent is deployed at an office location. Measurements = should occur after office hours, only.=20 - A large scale measurement network is deployed across multiple = autonomous systems. The participating organisations can decide if they = allow tests crossing AS bounderies. In the list archive, it was mentioned that the ma-task-capability-obj = will be reintroduced. Constraints could be an optional atribute of this = object: object { string ma-task-name; uri ma-task-registry; string ma-task-role; [ ma-capability-task-constraint-obj = ma-capability-task-constraints<0..*> ] [ ma-capability-schedule-constraint-obj = ma-capability-schedule-constraints<0..*> ] } ma-task-capability-obj; object { string ma-option-name; [ object ma-option-value-set<0..*>; ] [ object ma-option-value-range-start; ] [ object ma-option-value-range-end; ] } ma-capability-task-constraint-obj=20 In this case the constraint applies to a task=E2=80=99s configuration. = The constraint explicitly enumerates the allowed task-option values, or = specifies a range of allowed task-option values, given a lower and/or = upper bound. =20 A constraint on task scheduling will be more complex to model. What do you think about the notion of constraints, when announcing = capabilities of a MA? Regards, Holger Wiehen. =20 --Apple-Mail=_D4CE17B9-9DAD-47B9-B710-152A7BBCC199 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi.

Following is a suggestion to extend the = concept of MA capabilities. Maybe it is on time for the = interim?

The = capabilities of a MA might include constraints, for the measurement = tasks it supports. The Controller should consider those constraints when = it instructs the MA. Constraints might limit the Controller=E2=80=99s = choice for task-options or for task scheduling.

Three examples:
- = A measurement agent does support a given measurement task, but due to = limited device resources, the task configuration should respect a = maximum duration.
- A measurement agent is deployed = at an office location. Measurements should occur after office hours, = only. 
- A large scale measurement network is = deployed across multiple autonomous systems. The participating = organisations can decide if they allow tests  crossing AS = bounderies.


In the list archive, it was mentioned = that the ma-task-capability-obj will be reintroduced. Constraints could = be an optional atribute of this object:

 object = {
  string ma-task-name;
 = uri ma-task-registry;
  string = ma-task-role;
= [ ma-capability-task-constraint-obj = ma-capability-task-constraints<0..*> ]
[ ma-capability-schedule-constraint-obj = ma-capability-schedule-constraints<0..*> ]
 } ma-task-capability-obj;

object {
string = ma-option-name;
[ object = ma-option-value-set<0..*>; ]
= [ object ma-option-value-range-start; ]
= [ object ma-option-value-range-end; ]
} = ma-capability-task-constraint-obj 

In this case the constraint applies to = a task=E2=80=99s configuration. The constraint = explicitly enumerates the allowed task-option values, or specifies = a range of allowed task-option values, given a lower and/or upper = bound.
  
A = constraint on task scheduling will be more complex to model.

What do you think about = the notion of constraints, when announcing capabilities of a = MA?


Regards,

Holger Wiehen.  


= --Apple-Mail=_D4CE17B9-9DAD-47B9-B710-152A7BBCC199-- From nobody Fri Sep 25 04:54:41 2015 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 065B11B30A2 for ; Fri, 25 Sep 2015 04:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJkotGwXP3oR for ; Fri, 25 Sep 2015 04:54:38 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 4943F1B3096 for ; Fri, 25 Sep 2015 04:54:37 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 00E526642E8AC; Fri, 25 Sep 2015 11:54:32 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t8PBsTni027293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Sep 2015 11:54:34 GMT 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.03.0195.001; Fri, 25 Sep 2015 07:54:28 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Review of draft-ietf-lmap-information-model-06: Disabling schedules on controller timeout Thread-Index: AQHQ9gZx4X67dTHHU0+H3UqEkBvezp5NJWJw Date: Fri, 25 Sep 2015 11:54:26 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC258DC9@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC22667F@US70UWXCHMBA05.zam.alcatel-lucent.com> <244dbae6d49b4142a441f0e5534d9b56@rew09926dag03c.domain1.systemhost.net> <9966516C6EB5FC4381E05BF80AA55F77DC250E74@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923134724.GB1945@elstar.local> In-Reply-To: <20150923134724.GB1945@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Disabling schedules on controller timeout 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, 25 Sep 2015 11:54:40 -0000 Ok - that's a good approach. Thanks! Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, September 23, 2015 8:47 AM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Disabli= ng schedules on controller timeout Hi, we (Vaibhav and me) looked into the issue and it seems one possible solutio= n is to handle lost communication to a controller similar to the default su= ppression. Hence our proposal is to add a boolean flag to the ma-task-obj t= hat indicates whether the task will be disabled if communication to the con= troller has stopped. The default will be true. ma-task-auto-disable: A boolean flag indicating whether the task will be disabled if the communication with the controller has timed out. The default value of the flag is true. The description of ma-controller-timeout will then be updated to say that a= ll actions refering to tasks where ma-task-auto-disable is true will not be= executed anymore. /js On Wed, Sep 16, 2015 at 10:12:24AM +0000, Carey, Timothy (Timothy) wrote: > Hi, >=20 > In light of the Virtual meeting next week I thought I would regenerate an= open issue I have with the latest information model that I haven't seen di= scussion on. >=20 > BR, > Tim >=20 >=20 > From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] > Sent: Tuesday, July 28, 2015 2:37 AM > To: Carey, Timothy (Timothy); lmap@ietf.org > Subject: RE: Review of draft-ietf-lmap-information-model-06: Disabling=20 > schedules on controller timeout >=20 > I think this isn't possible. The Control and Instruction schedules are he= ld separately and the Control schedules cannot be suppressed. >=20 > Trevor. >=20 > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy=20 > (Timothy) > Sent: 27 July 2015 20:20 > To: lmap@ietf.org > Subject: [lmap] Review of draft-ietf-lmap-information-model-06:=20 > Disabling schedules on controller timeout >=20 > Juergen, >=20 > I was updating the TR-069 model and still have some questions about the d= isabling of schedules. >=20 > What happens if I disable a schedule but the schedule references an actio= n that is MA communication specific AND say an instruction? >=20 > It really sounds like we are disabling actions not schedules... It certai= nly would be much easier. >=20 > BR, > Tim > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --=20 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 25 04:57:25 2015 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 94EF11B30A6 for ; Fri, 25 Sep 2015 04:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sf_fTseGGYDH for ; Fri, 25 Sep 2015 04:57:22 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 1A52F1B30A2 for ; Fri, 25 Sep 2015 04:57:22 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id DAF50FBCFD76D; Fri, 25 Sep 2015 11:57:16 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t8PBvI9b032011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Sep 2015 11:57:18 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 25 Sep 2015 07:57:18 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Review of draft-ietf-lmap-information-model-06: Action Execution Mode questions Thread-Index: AQHQ9ggdZ35KSmjeX0qP+rQH1ltIu55NJlZw Date: Fri, 25 Sep 2015 11:57:16 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC258DE8@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC226694@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923135943.GC1945@elstar.local> In-Reply-To: <20150923135943.GC1945@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action Execution Mode questions 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, 25 Sep 2015 11:57:23 -0000 Juergen, Ok - both answers are fine with me. If we could update the information mode= l with the definition for pipelining that would be great. Thanks! Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, September 23, 2015 9:00 AM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action = Execution Mode questions On Mon, Jul 27, 2015 at 07:29:47PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 > In reviewing this draft for the TR-069 model update I had a question on t= he Execution mode. > We say there are 3 modes - Sequential, Parallel and Pipelined. > For sequential - What is the value that orders the list? I don't see an o= rdering the action or indication that this is an ordered list of actions. > Yes, it is an ordered list. We searched through the document and it turns o= ut we sometimes use 'list' when we mean 'ordered list' but we also use 'lis= t' sometimes where all we need is an 'unordered set'. Our proposal is that we go through the whole document replacing 'list' with either 'ordered list' or ''unordered set' to make the distinction clea= r. > For pipelining - I don't understand this mode - are we saying that this i= s a Sequential mode plus all the outputs for executing Action are inputted = to the next Action in the Sequence or is the Pipeline mode somehow relevant= for Output destinations? If so why wouldn't pipeline simply be sequential = or paralled with output destinations? > The former. A pipelined schedule with actions a1, a2, and a3 means that a1 = is executed and feeds its output as input to a2 which feeds its output as i= nput to a3. Note that pipelined does not imply sequential execution; all ac= tions can run concurrently and the pipeline controls the data flow and thus= the progress they can make. Like in a Unix shell pipeline. /js --=20 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 25 05:13:17 2015 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 D16AF1B30FE for ; Fri, 25 Sep 2015 05:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFq5r_1uHILt for ; Fri, 25 Sep 2015 05:13:15 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 27FA81B30FD for ; Fri, 25 Sep 2015 05:13:15 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 013EBB50B7889; Fri, 25 Sep 2015 12:13:10 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t8PCDBkF002423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Sep 2015 12:13:11 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 25 Sep 2015 08:13:11 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Actions Thread-Index: AQHQ9gkquUFOuH30cUWw5zwrBH+S9Z5NJ+qA Date: Fri, 25 Sep 2015 12:13:09 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC258E35@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC2266C0@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923140659.GD1945@elstar.local> In-Reply-To: <20150923140659.GD1945@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Actions 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, 25 Sep 2015 12:13:17 -0000 Juergen, Ok thanks - that was my hope as well. The current IM draft has some verbiage that could be interpreted otherwise. "It should be clear that the top-level behavior 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 Event object referenced by the Schedule in which they appear. Note, however, that Actions can have Action specific parameters." Perhaps we should say "Every Action contained by a Schedule". Also: 3.7 Common Objects: Schedules Multiple Actions in the list of a single Measurement Schedule will be executed according to the execution mode of the Schedule. Perhaps we should say " Multiple Actions contained as an ordered list withi= n a single Measurement Schedule ". Finally: Actions in different Schedules execute in parallel with such conflicts being reported in the Reporting Information where necessary. Perhaps we should say "Actions contained in different Schedules ". P.S. Also the draft as lowercase action instead of uppercase Action is some= instances. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, September 23, 2015 9:07 AM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Actions On Mon, Jul 27, 2015 at 07:41:10PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 > If Actions are now considered stand-alone entities outside the schedule. = Shouldn't the MA have a list of Actions available like Tasks and Communicat= ionChannels? > I do not think that actions are considered stand-alone entities. Actions ex= ist as part of a schedule. /js --=20 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 25 05:39:19 2015 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 AF5931B316E for ; Fri, 25 Sep 2015 05:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ4R3D7UtKOE for ; Fri, 25 Sep 2015 05:39:15 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 7EE321B316D for ; Fri, 25 Sep 2015 05:39:15 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 4C414D2CD0112; Fri, 25 Sep 2015 12:39:10 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t8PCd94I014110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Sep 2015 12:39:12 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 25 Sep 2015 08:39:09 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Simplification of multiple outputs resulting from an Action or List of Actions) Thread-Index: AQHQ948sxV3P3qZHgkSnJexcT5IdCw== Date: Fri, 25 Sep 2015 12:39:08 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC258E6A@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC226710@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923141342.GE1945@elstar.local> In-Reply-To: <20150923141342.GE1945@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Simplification of multiple outputs resulting from an Action or List of Actions) 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, 25 Sep 2015 12:39:17 -0000 Juergen, "We have removed the notion of multiple outputs and we have simplified the = model such that outputs can only be fed into another schedule (but not into= an action of a schedule)." Is Al Morton and the IPPM team ok with this modification? The only reason I ask is that the IPPM registry draft for output categories= has been unchanged since January. So are we constraining (simplifying) wha= t was agreed to previously? Remember a schedule can contain a List of Actions thus a List of Outputs. If the IPPM team is fine with the simplification; I am OK as well. The easi= er the better in my view. Juergen - So where is the "link" between the Scheduled Action's output and = the downstream Schedule? I didn't see this relationship. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, September 23, 2015 9:14 AM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] draft-ietf-lmap-information-model-06: draft-ietf-lmap-i= nformation-model-06 Tim, we have removed the notion of multiple outputs and we have simplified the m= odel such that outputs can only be fed into another schedule (but not into = an action of a schedule). The new model is that measurement tasks will tag = results and if certain tags are not needed, you filter the output based on = the tags. /js On Mon, Jul 27, 2015 at 08:23:01PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 > I was looking at the definition of ma-action-destinations. I don't unders= tand what we did here. >=20 > It used to be the case that a registry entry can define outputs that were= pipelined to a scheduled action. Now I it looks like it is a schedule. >=20 > However previously we said: > An empty list means that all outputs defined by the Action's task registr= y are invoked. - this is missing from you draft - what do we do with an emp= ty list? >=20 > Likewise we actually defined the output number to a list of Schedules - I= didn't see that modeled in the simple list of schedules. >=20 > BR, > Tim > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --=20 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 25 05:45:16 2015 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 45CCB1B3176 for ; Fri, 25 Sep 2015 05:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nISQrQ4doIK2 for ; Fri, 25 Sep 2015 05:45:13 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 677BA1B3198 for ; Fri, 25 Sep 2015 05:45:12 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id AD67742301E5E; Fri, 25 Sep 2015 12:45:08 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t8PCj9Fv014238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Sep 2015 12:45:09 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 25 Sep 2015 08:45:06 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Instructions and measurement suppression Thread-Index: AQHQ9gu0VW0oQyQ0A0KR19pDLFbHjJ5NMvBw Date: Fri, 25 Sep 2015 12:45:04 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC258E80@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC226720@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923142526.GF1945@elstar.local> In-Reply-To: <20150923142526.GF1945@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Instructions and measurement suppression 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, 25 Sep 2015 12:45:15 -0000 Juergen, Oh - sorry just so long as we don't remove the Instruction object. Instruction task as a term - Yes it doesn't add much; a Task is a task. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, September 23, 2015 9:25 AM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Instructions and = measurement suppression On Mon, Jul 27, 2015 at 08:46:12PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 > In IETF93 you asked if instruction object had any meaning. > Well they are used to hold measurement suppression. So if we remove the I= nstruction object we need a place to hold the instructions measurement supp= ression. >=20 I believe this is a misunderstanding. As far as I recall, my question conce= rned the term Instruction Task. And I still think we should go through the = document to see whether we can remove this term (as well as the other 'spec= ialist tasks' mentioned under 2.B. on page 8). I think this should actually= become: B. Control Tasks implement the Control Protocol and communicate with the Controller. We also don't detail that reporting tasks could be more complex internally = since this does not matter from the information model's point of view. /js --=20 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 25 05:51:13 2015 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 F2DC51A0010 for ; Fri, 25 Sep 2015 05:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8arXSSJOCeVr for ; Fri, 25 Sep 2015 05:51:09 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 C08D51A00DB for ; Fri, 25 Sep 2015 05:51:09 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 9C3EAD7E7BDFB; Fri, 25 Sep 2015 12:51:05 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t8PCp6Yx029816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Sep 2015 12:51:06 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 25 Sep 2015 08:51:01 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the information model Thread-Index: AQHQ9g97/2M+BXlhaEigCJzBc+neRp5NNIDQ Date: Fri, 25 Sep 2015 12:51:00 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC258EC3@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC227456@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923145229.GG1945@elstar.local> In-Reply-To: <20150923145229.GG1945@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the 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: Fri, 25 Sep 2015 12:51:12 -0000 Juergen, But the ma-status-object doesn't provide all the conditions of the MA might= be experiencing (which might be implementation specific). BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, September 23, 2015 9:52 AM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Cap= abilities and ma conditions back into the information model On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 > In draft 05 we removed the ability for a measurement agent to report its = metrics that it supports. > We need to add >=20 > * ma-task-capability-obj ma-supported-tasks<0..*>; >=20 > * [ma-condition-obj ma-conditions<0..*>;] >=20 > They were in the ma-status-obj. You are correct. There currently is no 'list' of tasks that are supported b= y a device anymore and we may have to put this back in. We changed the reporting of runtime failures to make them more useful. See = the ma-task-status-obj. /js --=20 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 25 07:09:15 2015 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 382331A1A75 for ; Fri, 25 Sep 2015 07:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7l52qhMP3jM for ; Fri, 25 Sep 2015 07:09:12 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 296111A1A72 for ; Fri, 25 Sep 2015 07:09:12 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 883E6903FB2D1; Fri, 25 Sep 2015 14:09:06 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t8PE986H029206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Sep 2015 14:09:08 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 25 Sep 2015 10:09:08 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Report - Task problems Thread-Index: AQHQ9hNgeFJT6ptTSkyYM9MXKAfBcJ5NSpjw Date: Fri, 25 Sep 2015 14:09:06 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC2590C6@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC2276A6@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923152022.GA2358@elstar.local> In-Reply-To: <20150923152022.GA2358@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Report - Task problems 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, 25 Sep 2015 14:09:14 -0000 Juergen, For the conditions - I must have been looking at something else - You are i= ndeed correct - Sorry. For the registry question - I will wait on the resolution to MA-Task-Role i= n the other thread. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, September 23, 2015 10:20 AM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Report - Task pro= blems On Tue, Jul 28, 2015 at 03:57:47PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 >=20 > 1) In the ma-report-task-obj, you have the [ma-option-obj ma-rep= ort-scheduled-task-options<0..*>]. So do we mean options for MA, the Action= or the Task? I think we mean the Task here. We also need Action conditions= for the report right? The ma-report-task-obj looks like this: object { string ma-report-task-name; [uri ma-report-task-registry-entries<1..*>;] [ma-option-obj ma-report-task-options<0..*>]; [ma-option-obj ma-report-task-action-options<0..*>]; [string ma-report-task-cycle-id;] [string ma-report-task-column-labels<0..*>;] [ma-report-row-obj ma-report-task-rows<0..*>;] } ma-report-task-obj; It carries both the task options as well as the action options. I do not un= derstand what you mean with 'Action conditions'. =20 > 2) Use of Registry entry in the Report task; Is this really for a metr= ic (RegistryEntry) in the task (probably); what about Role of the metric; d= o we report on each role/registryentry for the task? (probably) . My understanding is that the registry entry identifies the role and hence r= eporting the registry entry should be sufficient. /js --=20 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 25 07:10:55 2015 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 0F8AD1A1A76 for ; Fri, 25 Sep 2015 07:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrYQl8-GWTTB for ; Fri, 25 Sep 2015 07:10:52 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 7B8321A1A72 for ; Fri, 25 Sep 2015 07:10:52 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id A2709AC455409; Fri, 25 Sep 2015 14:10:48 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t8PEAn8B030276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Sep 2015 14:10:49 GMT 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.03.0195.001; Fri, 25 Sep 2015 10:10:46 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: New additions for Schedule Object Thread-Index: AQHQ9hXvq4JIew5ie0OIHoFSTPsdDJ5NS3Kg Date: Fri, 25 Sep 2015 14:10:45 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC2590D3@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC22793D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923153829.GB2358@elstar.local> In-Reply-To: <20150923153829.GB2358@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: New additions for Schedule Object 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, 25 Sep 2015 14:10:54 -0000 Ok - I added the below to the Schedule as a Status attributes and will awai= t what the IM includes. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, September 23, 2015 10:38 AM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] draft-ietf-lmap-information-model-06: New additions for= Schedule Object Tim, I agree that we should add more status objects that report the state of thi= ngs that can have a state. In the current model, schedules can be suppresse= d so that should be reported. /js On Tue, Jul 28, 2015 at 06:08:04PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 > To help with the controller timeout, I added an indicator to the schedule= in TR-069 that shows if the Schedule should be used for MA Control actions= . Likewise I added a status parameter to tell if the Schedule is currently = operationally disabled. >=20 > Do you think we can add these to the information model? >=20 > Status >=20 > string >=20 > - >=20 > The current operational state of the Schedule. Enumeration of: >=20 > * Enabled > * Disabled-MA-ControllerTimout > * Disabled-Other > * Error (OPTIONAL) > The Error value MAY be used by the CPE to indicate a locally defined erro= r condition. >=20 >=20 >=20 > UseForMAControl >=20 > boolean >=20 > W >=20 > This parameter defines if the Schedule is to be used for Actions that=20 > specific to the >=20 >=20 > BR, > Tim > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --=20 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 25 07:23:29 2015 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 070351A1B05 for ; Fri, 25 Sep 2015 07:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HE6y7Fw7RPsB for ; Fri, 25 Sep 2015 07:23:27 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 59B5F1A1AFC for ; Fri, 25 Sep 2015 07:23:26 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 6FD4B26F434BC; Fri, 25 Sep 2015 14:23:21 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t8PENNRs024554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Sep 2015 14:23:23 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 25 Sep 2015 10:23:23 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Review of draft-ietf-lmap-information-model-06: Action Destinations and tie with the Regisrry output Thread-Index: AQHQ9hbV28K6B38uwk+20lrSx4yoSJ5NTtcA Date: Fri, 25 Sep 2015 14:23:21 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC259120@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC22D001@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923154438.GC2358@elstar.local> In-Reply-To: <20150923154438.GC2358@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action Destinations and tie with the Regisrry output 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, 25 Sep 2015 14:23:29 -0000 Al, So what do you think about how to link the ActionDestination of another Sch= edule with the results of this Schedules Action? BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, September 23, 2015 10:45 AM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action = Destinations and tie with the Regisrry output Tim, the information model currently assumes that results are tagged. A task pro= ducing multiple 'outputs' would tag them to distinguish them. How all this links to the registry is, honestly speaking, somewhat unclear = to me since I do not really understand how the registry itself works. It wo= uld help me a lot if draft-ietf-ippm-metric-registry-04 would contain a collection of example registry entries. /js On Wed, Aug 05, 2015 at 02:06:24PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 > In previous information models we linked the Registry's outputs with the = downstream tasks. >=20 > In LMAP IM-06 draft we now have a concept of an ActionDestination which d= escribes which schedules are invoked based on the task's output selection. = However we do not link back the task output to the ActionDestination via pa= rameter in the ActionDestination object (maybe called Output?). Did I miss = understand the intent of the ActionDestination and its linkage? >=20 > BR, > Tim > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --=20 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 25 18:37:55 2015 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 8FFFA1ACD46 for ; Fri, 25 Sep 2015 18:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wT_DT75opp87 for ; Fri, 25 Sep 2015 18:37:52 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id BCDA01ACD43 for ; Fri, 25 Sep 2015 18:37:51 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id E0B7BD8367; Fri, 25 Sep 2015 22:04:19 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id 0E57FF04AB; Fri, 25 Sep 2015 21:37:48 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Fri, 25 Sep 2015 21:37:47 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Timothy)" , Juergen Schoenwaelder Date: Fri, 25 Sep 2015 21:37:46 -0400 Thread-Topic: [lmap] Review of draft-ietf-lmap-information-model-06: Action Destinations and tie with the Regisrry output Thread-Index: AQHQ9hbV28K6B38uwk+20lrSx4yoSJ5NTtcAgAC6AQA= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB48427C5@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC22D001@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923154438.GC2358@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC259120@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC259120@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action Destinations and tie with the Regisrry output X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 01:37:53 -0000 Hi Tim, I agree we need to sort-out the schedule aspects, but as a first step I want to be sure we all=20 understand how the IPPM Registry would be used by measurement Tasks and Reporting Tasks. Once we have that level of understanding, then I think we can work-out the kinks in the different Schedules, Events, Actions and Destinations Schedules... Schedule |------> Event |------> Action 1 | |------> Task Configuration | `------> Destination Schedule : : `------> Action N |------> Task Configuration `------> Destination Schedule (and see if this diagram is still correct). I don't think I'll really understand the Models and the Registry until I work through some examples of the Models (As I said, we already have examples of registry entries). I've been working on the task part of an example tonight. I'll make some mistakes, but then we'll all understand the use of the model better (*Everybody* wants examples, and a nice hat to wear in the Sun). regards, Al > -----Original Message----- > From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] > Sent: Friday, September 25, 2015 10:23 AM > To: Juergen Schoenwaelder > Cc: lmap@ietf.org; MORTON, ALFRED C (AL) > Subject: RE: [lmap] Review of draft-ietf-lmap-information-model-06: > Action Destinations and tie with the Regisrry output >=20 > Al, >=20 > So what do you think about how to link the ActionDestination of another > Schedule with the results of this Schedules Action? >=20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Wednesday, September 23, 2015 10:45 AM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: > Action Destinations and tie with the Regisrry output >=20 > Tim, >=20 > the information model currently assumes that results are tagged. A task > producing multiple 'outputs' would tag them to distinguish them. >=20 > How all this links to the registry is, honestly speaking, somewhat > unclear to me since I do not really understand how the registry itself > works. It would help me a lot if draft-ietf-ippm-metric-registry-04 > would contain a collection of example registry entries. >=20 > /js >=20 > On Wed, Aug 05, 2015 at 02:06:24PM +0000, Carey, Timothy (Timothy) > wrote: > > Juergen, > > > > In previous information models we linked the Registry's outputs with > the downstream tasks. > > > > In LMAP IM-06 draft we now have a concept of an ActionDestination > which describes which schedules are invoked based on the task's output > selection. However we do not link back the task output to the > ActionDestination via parameter in the ActionDestination object (maybe > called Output?). Did I miss understand the intent of the > ActionDestination and its linkage? > > > > BR, > > Tim >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Sat Sep 26 07:12:31 2015 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 3AD151B2E2A for ; Sat, 26 Sep 2015 07:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mj8nZWgRLyGd for ; Sat, 26 Sep 2015 07:12:27 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 684AD1B2E29 for ; Sat, 26 Sep 2015 07:12:27 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 48BEC123DA6; Sat, 26 Sep 2015 10:38:57 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id DCEFEF04CF; Sat, 26 Sep 2015 10:12:23 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Sat, 26 Sep 2015 10:12:23 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Timothy)" , Juergen Schoenwaelder Date: Sat, 26 Sep 2015 10:12:22 -0400 Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the information model Thread-Index: AQHQ9g97/2M+BXlhaEigCJzBc+neRp5NNIDQgAGluWA= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB48427CF@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC227456@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923145229.GG1945@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC258EC3@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC258EC3@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the 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: Sat, 26 Sep 2015 14:12:29 -0000 Hi Tim and Juergen, Here's a small addition to what Tim proposed: > > * ma-task-capability-obj ma-supported-tasks<0..*>; It's necessary for all non-measurement tasks to have a registry providing the details of each task (and someone needs to start that development). But for measurement Tasks, there can be multiple Performance Metric Registry entries involved now, and each task will be some combination of registered metrics.=20 So we also need ma-supported-registry-entries<0..*>;=20 and the text below (from 3.9) needs some revisions to keep-up with the latest agreements (if I've got this right): A Measurement Task Configuration is the same in information terms to any other Task Configuration. Both measurement and non-measurement Tasks have registry entries to enable the MA to uniquely identify the Task it should execute and retrieve the schema for any parameters that may be passed to the Task. Registry entries are specified as a URI and can therefore be used to identify the Task within a namespace or point to a web or local file location for the Task information. As mentioned previously, these URIs may be used to identify the Measurement Task in a public namespace [I-D.ietf-ippm-metric-registry]. Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy > (Timothy) > Sent: Friday, September 25, 2015 8:51 AM > To: Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task > Capabilities and ma conditions back into the information model >=20 > Juergen, >=20 > But the ma-status-object doesn't provide all the conditions of the MA > might be experiencing (which might be implementation specific). >=20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Wednesday, September 23, 2015 9:52 AM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task > Capabilities and ma conditions back into the information model >=20 > On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) > wrote: > > Juergen, > > > > In draft 05 we removed the ability for a measurement agent to report > its metrics that it supports. > > We need to add > > > > * ma-task-capability-obj ma-supported-tasks<0..*>; > > > > * [ma-condition-obj ma-conditions<0..*>;] > > > > They were in the ma-status-obj. >=20 > You are correct. There currently is no 'list' of tasks that are > supported by a device anymore and we may have to put this back in. >=20 > We changed the reporting of runtime failures to make them more useful. > See the ma-task-status-obj. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Sat Sep 26 09:07:04 2015 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 DDE651B2F54 for ; Sat, 26 Sep 2015 09:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsUcPRo5t7fu for ; Sat, 26 Sep 2015 09:07:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 322921A037A for ; Sat, 26 Sep 2015 09:07:00 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 209EDB5B9B69E; Sat, 26 Sep 2015 16:06:55 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t8QG6tqx018474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Sep 2015 16:06:55 GMT 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.03.0195.001; Sat, 26 Sep 2015 12:06:54 -0400 From: "Carey, Timothy (Timothy)" To: "MORTON, ALFRED C (AL)" , Juergen Schoenwaelder Thread-Topic: [lmap] Review of draft-ietf-lmap-information-model-06: Action Destinations and tie with the Regisrry output Thread-Index: AQHQ9hbV28K6B38uwk+20lrSx4yoSJ5NTtcAgAC6AQCAAPNAEA== Date: Sat, 26 Sep 2015 16:06:53 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC25A8D9@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC22D001@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923154438.GC2358@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC259120@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427C5@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB48427C5@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action Destinations and tie with the Regisrry output X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 16:07:03 -0000 Al, Great - FYI the structure for a Scheduled Action "list of destinations" no= t just one... object { string ma-action-name; string ma-action-task-name; [ma-option-obj ma-action-task-options<0..*>]; [string ma-action-destinations<0..*>;] } ma-action-obj; BR, Tim -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Friday, September 25, 2015 8:38 PM To: Carey, Timothy (Timothy); Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] Review of draft-ietf-lmap-information-model-06: Action = Destinations and tie with the Regisrry output Hi Tim, I agree we need to sort-out the schedule aspects, but as a first step I wan= t to be sure we all understand how the IPPM Registry would be used by measu= rement Tasks and Reporting Tasks. Once we have that level of understanding, then I think we can work-out the = kinks in the different Schedules, Events, Actions and Destinations Schedule= s... Schedule |------> Event |------> Action 1 | |------> Task Configuration | `------> Destination Schedule : : `------> Action N |------> Task Configuration `------> Destination Schedule (and see if this d= iagram is still correct). I don't think I'll really understand the Models and the Registry until I wo= rk through some examples of the Models (As I said, we already have examples= of registry entries). I've been working on the task part of an example ton= ight. I'll make some mistakes, but then we'll all understand the use of th= e model better (*Everybody* wants examples, and a nice hat to wear in the S= un). regards, Al > -----Original Message----- > From: Carey, Timothy (Timothy)=20 > [mailto:timothy.carey@alcatel-lucent.com] > Sent: Friday, September 25, 2015 10:23 AM > To: Juergen Schoenwaelder > Cc: lmap@ietf.org; MORTON, ALFRED C (AL) > Subject: RE: [lmap] Review of draft-ietf-lmap-information-model-06: > Action Destinations and tie with the Regisrry output >=20 > Al, >=20 > So what do you think about how to link the ActionDestination of=20 > another Schedule with the results of this Schedules Action? >=20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-=20 > university.de] > Sent: Wednesday, September 23, 2015 10:45 AM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: > Action Destinations and tie with the Regisrry output >=20 > Tim, >=20 > the information model currently assumes that results are tagged. A=20 > task producing multiple 'outputs' would tag them to distinguish them. >=20 > How all this links to the registry is, honestly speaking, somewhat=20 > unclear to me since I do not really understand how the registry itself=20 > works. It would help me a lot if draft-ietf-ippm-metric-registry-04 > would contain a collection of example registry entries. >=20 > /js >=20 > On Wed, Aug 05, 2015 at 02:06:24PM +0000, Carey, Timothy (Timothy) > wrote: > > Juergen, > > > > In previous information models we linked the Registry's outputs with > the downstream tasks. > > > > In LMAP IM-06 draft we now have a concept of an ActionDestination > which describes which schedules are invoked based on the task's output=20 > selection. However we do not link back the task output to the=20 > ActionDestination via parameter in the ActionDestination object (maybe=20 > called Output?). Did I miss understand the intent of the=20 > ActionDestination and its linkage? > > > > BR, > > Tim >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Sat Sep 26 09:16:23 2015 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 AF5BF1B2F85 for ; Sat, 26 Sep 2015 09:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jdwfzkj32X9D for ; Sat, 26 Sep 2015 09:16:20 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 530981B2F87 for ; Sat, 26 Sep 2015 09:16:20 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 9EC1FBA582216; Sat, 26 Sep 2015 16:16:14 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t8QGGEXj025246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Sep 2015 16:16:14 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Sat, 26 Sep 2015 12:16:14 -0400 From: "Carey, Timothy (Timothy)" To: "MORTON, ALFRED C (AL)" , Juergen Schoenwaelder Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the information model Thread-Index: AQHQ9g97/2M+BXlhaEigCJzBc+neRp5NNIDQgAGluWCAACTaUA== Date: Sat, 26 Sep 2015 16:16:12 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC25A906@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC227456@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923145229.GG1945@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC258EC3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427CF@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB48427CF@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the 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: Sat, 26 Sep 2015 16:16:21 -0000 Al, Indeed we do need that to be a list as you suggest but what is relationship= with the role to the list of registry entries?=20 BR, Tim -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Saturday, September 26, 2015 9:12 AM To: Carey, Timothy (Timothy); Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Cap= abilities and ma conditions back into the information model Hi Tim and Juergen, Here's a small addition to what Tim proposed: > > * ma-task-capability-obj ma-supported-tasks<0..*>; It's necessary for all non-measurement tasks to have a registry providing t= he details of each task (and someone needs to start that development). But for measurement Tasks, there can be multiple Performance Metric Registr= y entries involved now, and each task will be some combination of registere= d metrics.=20 So we also need ma-supported-registry-entries<0..*>; and the text below (from 3.9) needs some revisions to keep-up with the late= st agreements (if I've got this right): A Measurement Task Configuration is the same in information terms to any other Task Configuration. Both measurement and non-measurement Tasks have registry entries to enable the MA to uniquely identify the Task it should execute and retrieve the schema for any parameters that may be passed to the Task. Registry entries are specified as a URI and can therefore be used to identify the Task within a namespace or point to a web or local file location for the Task information. As mentioned previously, these URIs may be used to identify the Measurement Task in a public namespace [I-D.ietf-ippm-metric-registry]. Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy > (Timothy) > Sent: Friday, September 25, 2015 8:51 AM > To: Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert=20 > Task Capabilities and ma conditions back into the information model >=20 > Juergen, >=20 > But the ma-status-object doesn't provide all the conditions of the MA=20 > might be experiencing (which might be implementation specific). >=20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-=20 > university.de] > Sent: Wednesday, September 23, 2015 9:52 AM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert=20 > Task Capabilities and ma conditions back into the information model >=20 > On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) > wrote: > > Juergen, > > > > In draft 05 we removed the ability for a measurement agent to report > its metrics that it supports. > > We need to add > > > > * ma-task-capability-obj ma-supported-tasks<0..*>; > > > > * [ma-condition-obj ma-conditions<0..*>;] > > > > They were in the ma-status-obj. >=20 > You are correct. There currently is no 'list' of tasks that are=20 > supported by a device anymore and we may have to put this back in. >=20 > We changed the reporting of runtime failures to make them more useful. > See the ma-task-status-obj. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Sat Sep 26 09:51:48 2015 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 7C14A1A00E6 for ; Sat, 26 Sep 2015 09:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgmw48pNouI8 for ; Sat, 26 Sep 2015 09:51:45 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id E60491A00E0 for ; Sat, 26 Sep 2015 09:51:44 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 44656123E81; Sat, 26 Sep 2015 13:18:14 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id 80E5FF04A1; Sat, 26 Sep 2015 12:51:40 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Sat, 26 Sep 2015 12:51:40 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Timothy)" , Juergen Schoenwaelder Date: Sat, 26 Sep 2015 12:51:39 -0400 Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the information model Thread-Index: AQHQ9g97/2M+BXlhaEigCJzBc+neRp5NNIDQgAGluWCAACTaUIAABEXA Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB48427D7@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC227456@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923145229.GG1945@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC258EC3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427CF@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77DC25A906@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC25A906@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the 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: Sat, 26 Sep 2015 16:51:46 -0000 Hi Tim, =20 good question (we're having Tuesday's meeting on Saturday :-( ) I think we need some approximate hierarchy like this: Measurement Capability [ Measurement Protocol [ Protocol Roles [ ] ] Registry URI [ Method Roles [ ] ] ] so, an example would be Measurement Capability [ TWAMP [ Control-Client; Session-Sender; Server; Session-Reflector; ] Prefix:Act_IP_UDP_Round-trip_Delay_95th-percentile_Poisson [ Src; Dst; ... more URIs and Roles... ] ] for a fully capable MA. I think you can easily conjure-up how to indicate a system with less than full capabilities, or how a different Meas. Protocols could be substituted in a different meas. capability that measures the *same*=20 registered metric. Al > -----Original Message----- > From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] > Sent: Saturday, September 26, 2015 12:16 PM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task > Capabilities and ma conditions back into the information model >=20 > Al, >=20 > Indeed we do need that to be a list as you suggest but what is > relationship with the role to the list of registry entries? >=20 > BR, > Tim >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Saturday, September 26, 2015 9:12 AM > To: Carey, Timothy (Timothy); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task > Capabilities and ma conditions back into the information model >=20 > Hi Tim and Juergen, >=20 > Here's a small addition to what Tim proposed: > > > * ma-task-capability-obj ma-supported-tasks<0..*>; >=20 > It's necessary for all non-measurement tasks to have a registry > providing the details of each task (and someone needs to start that > development). >=20 > But for measurement Tasks, there can be multiple Performance Metric > Registry entries involved now, and each task will be some combination of > registered metrics. >=20 > So we also need ma-supported-registry-entries<0..*>; > and the text below (from 3.9) needs some revisions to keep-up with the > latest agreements (if I've got this right): >=20 > A Measurement Task Configuration is the same in information terms to > any other Task Configuration. Both measurement and non-measurement > Tasks have registry entries to enable the MA to uniquely identify the > Task it should execute and retrieve the schema for any parameters > that may be passed to the Task. Registry entries are specified as a > URI and can therefore be used to identify the Task within a namespace > or point to a web or local file location for the Task information. > As mentioned previously, these URIs may be used to identify the > Measurement Task in a public namespace > [I-D.ietf-ippm-metric-registry]. >=20 > Al >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy > > (Timothy) > > Sent: Friday, September 25, 2015 8:51 AM > > To: Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert > > Task Capabilities and ma conditions back into the information model > > > > Juergen, > > > > But the ma-status-object doesn't provide all the conditions of the MA > > might be experiencing (which might be implementation specific). > > > > BR, > > Tim > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Wednesday, September 23, 2015 9:52 AM > > To: Carey, Timothy (Timothy) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert > > Task Capabilities and ma conditions back into the information model > > > > On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) > > wrote: > > > Juergen, > > > > > > In draft 05 we removed the ability for a measurement agent to report > > its metrics that it supports. > > > We need to add > > > > > > * ma-task-capability-obj ma-supported-tasks<0..*>; > > > > > > * [ma-condition-obj ma-conditions<0..*>;] > > > > > > They were in the ma-status-obj. > > > > You are correct. There currently is no 'list' of tasks that are > > supported by a device anymore and we may have to put this back in. > > > > We changed the reporting of runtime failures to make them more useful. > > See the ma-task-status-obj. > > > > /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 Sat Sep 26 10:21:13 2015 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 9D4E81A034F for ; Sat, 26 Sep 2015 10:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtaVCKGARidr for ; Sat, 26 Sep 2015 10:21:10 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 290731A033B for ; Sat, 26 Sep 2015 10:21:10 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id EB4731201AC; Sat, 26 Sep 2015 13:44:17 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 85B0CE0FF5; Sat, 26 Sep 2015 13:16:02 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Sat, 26 Sep 2015 13:17:43 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Timothy)" , Juergen Schoenwaelder Date: Sat, 26 Sep 2015 13:17:43 -0400 Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Simplification of multiple outputs resulting from an Action or List of Actions) Thread-Index: AQHQ948sxV3P3qZHgkSnJexcT5IdC55PCwHA Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB48427D8@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC226710@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923141342.GE1945@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC258E6A@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC258E6A@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Simplification of multiple outputs resulting from an Action or List of Actions) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 17:21:11 -0000 I'm grappling with the current meaning of "output" here. Actions perform Tasks. Tasks produce Output.=20 Output is consumed by Destination Schedules. ma-action-destinations: An optional and possibly empty list of names of destination schedules that consume output produced by this action. So, when we allow a Task to contain multiple Metric Registry URIs, there will be a measured result for each Metric, which we would call multiple outputs in the Registry Draft. But if all the measured results are considered "one" Output in the Info Model, then we appear to be=20 synchronized on the notion of Output. Then, if the Output can be fed to another schedule, with another action to further process, or store the measured results with earlier results for later reporting, or report according to the schedule, then that will wo= rk, too. It's very difficult to gain procedural insights from an abstract model alone.=20 Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy > (Timothy) > Sent: Friday, September 25, 2015 8:39 AM > To: Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Simplification > of multiple outputs resulting from an Action or List of Actions) >=20 > >=20 > Juergen, >=20 > "We have removed the notion of multiple outputs and we have simplified > the model such that outputs can only be fed into another schedule (but > not into an action of a schedule)." >=20 > Is Al Morton and the IPPM team ok with this modification? > The only reason I ask is that the IPPM registry draft for output > categories has been unchanged since January. So are we constraining > (simplifying) what was agreed to previously? >=20 > Remember a schedule can contain a List of Actions thus a List of > Outputs. >=20 > If the IPPM team is fine with the simplification; I am OK as well. The > easier the better in my view. >=20 > Juergen - So where is the "link" between the Scheduled Action's output > and the downstream Schedule? I didn't see this relationship. >=20 > BR, > Tim >=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Wednesday, September 23, 2015 9:14 AM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: draft-ietf- > lmap-information-model-06 >=20 > Tim, >=20 > we have removed the notion of multiple outputs and we have simplified > the model such that outputs can only be fed into another schedule (but > not into an action of a schedule). The new model is that measurement > tasks will tag results and if certain tags are not needed, you filter > the output based on the tags. >=20 > /js >=20 > On Mon, Jul 27, 2015 at 08:23:01PM +0000, Carey, Timothy (Timothy) > wrote: > > Juergen, > > > > I was looking at the definition of ma-action-destinations. I don't > understand what we did here. > > > > It used to be the case that a registry entry can define outputs that > were pipelined to a scheduled action. Now I it looks like it is a > schedule. > > > > However previously we said: > > An empty list means that all outputs defined by the Action's task > registry are invoked. - this is missing from you draft - what do we do > with an empty list? > > > > Likewise we actually defined the output number to a list of Schedules > - I didn't see that modeled in the simple list of schedules. > > > > BR, > > Tim >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Sat Sep 26 12:29:20 2015 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 4C3F61A1B78 for ; Sat, 26 Sep 2015 12:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36cUeM-fsCVo for ; Sat, 26 Sep 2015 12:29:17 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 D444D1A1B73 for ; Sat, 26 Sep 2015 12:29:16 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id D18B62F94F692; Sat, 26 Sep 2015 19:29:10 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t8QJTCDv021098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Sep 2015 19:29:12 GMT 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.03.0195.001; Sat, 26 Sep 2015 15:29:12 -0400 From: "Carey, Timothy (Timothy)" To: "MORTON, ALFRED C (AL)" , Juergen Schoenwaelder Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the information model Thread-Index: AQHQ9g97/2M+BXlhaEigCJzBc+neRp5NNIDQgAGluWCAACTaUIAABEXAgAAo96A= Date: Sat, 26 Sep 2015 19:29:11 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC25AAC4@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC227456@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923145229.GG1945@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC258EC3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427CF@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77DC25A906@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427D7@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB48427D7@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the 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: Sat, 26 Sep 2015 19:29:19 -0000 Al, I am not sure where the Measurement Capability and Protocol Roles would com= e from given a set of registry entries.=20 I do think the correlation of the IM to the Registry around Tasks and Actio= ns is what is causing (at least my) confusion. Summary ------------------------------- ID | Name | URI | Description | Metric Definition ----------------------------------------- Reference Definition | Fixed Parameters | Method of Measurement --------------------------------------------------------------- Reference | Packet | Traffic | Sampling | Run-time | Role | Method | Generation | Filter | dist. | Param | | | Stream | Output ----------------------------- | Type | Reference | Units | | | Definition | | I=20 BR, Tim -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Saturday, September 26, 2015 11:52 AM To: Carey, Timothy (Timothy); Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Cap= abilities and ma conditions back into the information model Hi Tim, good question (we're having Tuesday's meeting on Saturday :-( ) I think we need some approximate hierarchy like this: Measurement Capability [ Measurement Protocol [ Protocol Roles [ ] ] Registry URI [ Method Roles [ ] ] ] so, an example would be Measurement Capability [ TWAMP [ Control-Client; Session-Sender; Server; Session-Reflector; ] Prefix:Act_IP_UDP_Round-trip_Delay_95th-percentile_Poisson [ Src; Dst; ... more URIs and Roles... ] ] for a fully capable MA. I think you can easily conjure-up how to indicate a system with less than f= ull capabilities, or how a different Meas. Protocols could be substituted i= n a different meas. capability that measures the *same* registered metric. Al > -----Original Message----- > From: Carey, Timothy (Timothy)=20 > [mailto:timothy.carey@alcatel-lucent.com] > Sent: Saturday, September 26, 2015 12:16 PM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert=20 > Task Capabilities and ma conditions back into the information model >=20 > Al, >=20 > Indeed we do need that to be a list as you suggest but what is=20 > relationship with the role to the list of registry entries? >=20 > BR, > Tim >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Saturday, September 26, 2015 9:12 AM > To: Carey, Timothy (Timothy); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert=20 > Task Capabilities and ma conditions back into the information model >=20 > Hi Tim and Juergen, >=20 > Here's a small addition to what Tim proposed: > > > * ma-task-capability-obj ma-supported-tasks<0..*>; >=20 > It's necessary for all non-measurement tasks to have a registry=20 > providing the details of each task (and someone needs to start that=20 > development). >=20 > But for measurement Tasks, there can be multiple Performance Metric=20 > Registry entries involved now, and each task will be some combination=20 > of registered metrics. >=20 > So we also need ma-supported-registry-entries<0..*>; > and the text below (from 3.9) needs some revisions to keep-up with the=20 > latest agreements (if I've got this right): >=20 > A Measurement Task Configuration is the same in information terms to > any other Task Configuration. Both measurement and non-measurement > Tasks have registry entries to enable the MA to uniquely identify the > Task it should execute and retrieve the schema for any parameters > that may be passed to the Task. Registry entries are specified as a > URI and can therefore be used to identify the Task within a namespace > or point to a web or local file location for the Task information. > As mentioned previously, these URIs may be used to identify the > Measurement Task in a public namespace > [I-D.ietf-ippm-metric-registry]. >=20 > Al >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey,=20 > > Timothy > > (Timothy) > > Sent: Friday, September 25, 2015 8:51 AM > > To: Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert=20 > > Task Capabilities and ma conditions back into the information model > > > > Juergen, > > > > But the ma-status-object doesn't provide all the conditions of the=20 > > MA might be experiencing (which might be implementation specific). > > > > BR, > > Tim > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-=20 > > university.de] > > Sent: Wednesday, September 23, 2015 9:52 AM > > To: Carey, Timothy (Timothy) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert=20 > > Task Capabilities and ma conditions back into the information model > > > > On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) > > wrote: > > > Juergen, > > > > > > In draft 05 we removed the ability for a measurement agent to=20 > > > report > > its metrics that it supports. > > > We need to add > > > > > > * ma-task-capability-obj ma-supported-tasks<0..*>; > > > > > > * [ma-condition-obj ma-conditions<0..*>;] > > > > > > They were in the ma-status-obj. > > > > You are correct. There currently is no 'list' of tasks that are=20 > > supported by a device anymore and we may have to put this back in. > > > > We changed the reporting of runtime failures to make them more useful. > > See the ma-task-status-obj. > > > > /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 Sat Sep 26 12:33:46 2015 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 E97D31A1B84 for ; Sat, 26 Sep 2015 12:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kRO9mD8U0yN for ; Sat, 26 Sep 2015 12:33:42 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 4D2FC1A1B83 for ; Sat, 26 Sep 2015 12:33:42 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 1030F79DFFA9B; Sat, 26 Sep 2015 19:33:35 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t8QJXZia032721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Sep 2015 19:33:38 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Sat, 26 Sep 2015 15:33:21 -0400 From: "Carey, Timothy (Timothy)" To: "MORTON, ALFRED C (AL)" , Juergen Schoenwaelder Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Simplification of multiple outputs resulting from an Action or List of Actions) Thread-Index: AQHQ948sxV3P3qZHgkSnJexcT5IdC55PCwHAgAAphbA= Date: Sat, 26 Sep 2015 19:33:20 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC25AAD2@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC226710@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923141342.GE1945@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC258E6A@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427D8@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB48427D8@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Simplification of multiple outputs resulting from an Action or List of Actions) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 19:33:44 -0000 Al, Yes it is very difficult at the abstract level - I think I mentioned this i= n the last thread. If we can take a concrete example (say TWAMP) and map from the Registry to = the IM for a given task (run a TWAMP test for say 2 metrics) I think that w= ill begin to alleviate the confusion. -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Saturday, September 26, 2015 12:18 PM To: Carey, Timothy (Timothy); Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Simplification of= multiple outputs resulting from an Action or List of Actions) I'm grappling with the current meaning of "output" here. Actions perform Tasks. Tasks produce Output.=20 Output is consumed by Destination Schedules. ma-action-destinations: An optional and possibly empty list of names of destination schedules that consume output produced by this action. So, when we allow a Task to contain multiple Metric Registry URIs, there wi= ll be a measured result for each Metric, which we would call multiple outpu= ts in the Registry Draft. But if all the measured results are considered "= one" Output in the Info Model, then we appear to be synchronized on the not= ion of Output. Then, if the Output can be fed to another schedule, with another action to = further process, or store the measured results with earlier results for lat= er reporting, or report according to the schedule, then that will work, too= . It's very difficult to gain procedural insights from an abstract model alon= e.=20 Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy > (Timothy) > Sent: Friday, September 25, 2015 8:39 AM > To: Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-06:=20 > Simplification of multiple outputs resulting from an Action or List of=20 > Actions) >=20 > >=20 > Juergen, >=20 > "We have removed the notion of multiple outputs and we have simplified=20 > the model such that outputs can only be fed into another schedule (but=20 > not into an action of a schedule)." >=20 > Is Al Morton and the IPPM team ok with this modification? > The only reason I ask is that the IPPM registry draft for output=20 > categories has been unchanged since January. So are we constraining > (simplifying) what was agreed to previously? >=20 > Remember a schedule can contain a List of Actions thus a List of=20 > Outputs. >=20 > If the IPPM team is fine with the simplification; I am OK as well. The=20 > easier the better in my view. >=20 > Juergen - So where is the "link" between the Scheduled Action's output=20 > and the downstream Schedule? I didn't see this relationship. >=20 > BR, > Tim >=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-=20 > university.de] > Sent: Wednesday, September 23, 2015 9:14 AM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: draft-ietf- > lmap-information-model-06 >=20 > Tim, >=20 > we have removed the notion of multiple outputs and we have simplified=20 > the model such that outputs can only be fed into another schedule (but=20 > not into an action of a schedule). The new model is that measurement=20 > tasks will tag results and if certain tags are not needed, you filter=20 > the output based on the tags. >=20 > /js >=20 > On Mon, Jul 27, 2015 at 08:23:01PM +0000, Carey, Timothy (Timothy) > wrote: > > Juergen, > > > > I was looking at the definition of ma-action-destinations. I don't > understand what we did here. > > > > It used to be the case that a registry entry can define outputs that > were pipelined to a scheduled action. Now I it looks like it is a=20 > schedule. > > > > However previously we said: > > An empty list means that all outputs defined by the Action's task > registry are invoked. - this is missing from you draft - what do we do=20 > with an empty list? > > > > Likewise we actually defined the output number to a list of=20 > > Schedules > - I didn't see that modeled in the simple list of schedules. > > > > BR, > > Tim >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Sat Sep 26 15:12:37 2015 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 77E7E1A873A for ; Sat, 26 Sep 2015 15:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VsnnxGqB2GWv for ; Sat, 26 Sep 2015 15:12:33 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6111A8739 for ; Sat, 26 Sep 2015 15:12:33 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id 53055123CEE; Sat, 26 Sep 2015 18:39:04 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 2AD6FE0FF7; Sat, 26 Sep 2015 18:10:51 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Sat, 26 Sep 2015 18:12:32 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Timothy)" , Juergen Schoenwaelder Date: Sat, 26 Sep 2015 18:12:31 -0400 Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the information model Thread-Index: AQHQ9g97/2M+BXlhaEigCJzBc+neRp5NNIDQgAGluWCAACTaUIAABEXAgAAo96CAADXToA== Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB48427D9@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC227456@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923145229.GG1945@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC258EC3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427CF@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77DC25A906@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427D7@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77DC25AAC4@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC25AAC4@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the 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: Sat, 26 Sep 2015 22:12:35 -0000 Hi Tim, The Measurement Protocol and Protocol Roles can't come from the=20 IPPM metrics registry - just like setting a single method of measurement r= ole would cause entirely duplicate entries in the registry just to change the r= ole, adding each possible protocol (TWAMP, OWAMP, ICMP, IPSLA,...) adds even more multiplication of a single entry. So, that's why we agreed not to add protocol in the registry at the workshop with BBF last year. If an MA has TWAMP capability, it certainly knows and can say so in a capabilities message. My guess is that the MAs will have one of the above measurement protocols, so it's really just a=20 matter of revealing the single choice of the developers and any limitations (e.g., this MA can only perform as a TWAMP Server&Reflector= ). hope this helps, Al > -----Original Message----- > From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] > Sent: Saturday, September 26, 2015 3:29 PM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task > Capabilities and ma conditions back into the information model >=20 > Al, >=20 > I am not sure where the Measurement Capability and Protocol Roles would > come from given a set of registry entries. > I do think the correlation of the IM to the Registry around Tasks and > Actions is what is causing (at least my) confusion. >=20 > Summary > ------------------------------- > ID | Name | URI | Description | > Metric Definition > ----------------------------------------- > Reference Definition | Fixed Parameters | Method of Measurement > --------------------------------------------------------------- > Reference | Packet | Traffic | Sampling | Run-time | Role | Method | > Generation | Filter | dist. | Param | | > | Stream | > Output > ----------------------------- > | Type | Reference | Units | > | | Definition | | >=20 >=20 > I > BR, > Tim >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Saturday, September 26, 2015 11:52 AM > To: Carey, Timothy (Timothy); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task > Capabilities and ma conditions back into the information model >=20 > Hi Tim, > good question (we're having Tuesday's meeting on Saturday :-( ) >=20 > I think we need some approximate hierarchy like this: >=20 > Measurement Capability [ > Measurement Protocol [ > Protocol Roles [ ] > ] > Registry URI [ > Method Roles [ ] > ] > ] > so, an example would be >=20 > Measurement Capability [ > TWAMP [ > Control-Client; Session-Sender; Server; Session-Reflector; > ] > Prefix:Act_IP_UDP_Round-trip_Delay_95th-percentile_Poisson [ > Src; Dst; > ... more URIs and Roles... > ] > ] > for a fully capable MA. >=20 > I think you can easily conjure-up how to indicate a system with less > than full capabilities, or how a different Meas. Protocols could be > substituted in a different meas. capability that measures the *same* > registered metric. >=20 > Al >=20 >=20 > > -----Original Message----- > > From: Carey, Timothy (Timothy) > > [mailto:timothy.carey@alcatel-lucent.com] > > Sent: Saturday, September 26, 2015 12:16 PM > > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert > > Task Capabilities and ma conditions back into the information model > > > > Al, > > > > Indeed we do need that to be a list as you suggest but what is > > relationship with the role to the list of registry entries? > > > > BR, > > Tim > > > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Saturday, September 26, 2015 9:12 AM > > To: Carey, Timothy (Timothy); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert > > Task Capabilities and ma conditions back into the information model > > > > Hi Tim and Juergen, > > > > Here's a small addition to what Tim proposed: > > > > * ma-task-capability-obj ma-supported-tasks<0..*>; > > > > It's necessary for all non-measurement tasks to have a registry > > providing the details of each task (and someone needs to start that > > development). > > > > But for measurement Tasks, there can be multiple Performance Metric > > Registry entries involved now, and each task will be some combination > > of registered metrics. > > > > So we also need ma-supported-registry-entries<0..*>; > > and the text below (from 3.9) needs some revisions to keep-up with the > > latest agreements (if I've got this right): > > > > A Measurement Task Configuration is the same in information terms > to > > any other Task Configuration. Both measurement and non-measurement > > Tasks have registry entries to enable the MA to uniquely identify > the > > Task it should execute and retrieve the schema for any parameters > > that may be passed to the Task. Registry entries are specified as > a > > URI and can therefore be used to identify the Task within a > namespace > > or point to a web or local file location for the Task information. > > As mentioned previously, these URIs may be used to identify the > > Measurement Task in a public namespace > > [I-D.ietf-ippm-metric-registry]. > > > > Al > > > > > -----Original Message----- > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, > > > Timothy > > > (Timothy) > > > Sent: Friday, September 25, 2015 8:51 AM > > > To: Juergen Schoenwaelder > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert > > > Task Capabilities and ma conditions back into the information model > > > > > > Juergen, > > > > > > But the ma-status-object doesn't provide all the conditions of the > > > MA might be experiencing (which might be implementation specific). > > > > > > BR, > > > Tim > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > university.de] > > > Sent: Wednesday, September 23, 2015 9:52 AM > > > To: Carey, Timothy (Timothy) > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert > > > Task Capabilities and ma conditions back into the information model > > > > > > On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) > > > wrote: > > > > Juergen, > > > > > > > > In draft 05 we removed the ability for a measurement agent to > > > > report > > > its metrics that it supports. > > > > We need to add > > > > > > > > * ma-task-capability-obj ma-supported-tasks<0..*>; > > > > > > > > * [ma-condition-obj ma-conditions<0..*>;] > > > > > > > > They were in the ma-status-obj. > > > > > > You are correct. There currently is no 'list' of tasks that are > > > supported by a device anymore and we may have to put this back in. > > > > > > We changed the reporting of runtime failures to make them more > useful. > > > See the ma-task-status-obj. > > > > > > /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 Sat Sep 26 15:21:57 2015 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 42DF61A8771 for ; Sat, 26 Sep 2015 15:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nPmHFaiOMMeb for ; Sat, 26 Sep 2015 15:21:53 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 74C1F1A8762 for ; Sat, 26 Sep 2015 15:21:53 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id C59941200DF; Sat, 26 Sep 2015 18:44:28 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-azure.research.att.com (Postfix) with ESMTP id 632DCE0550; Sat, 26 Sep 2015 18:17:54 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Sat, 26 Sep 2015 18:17:54 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Timothy)" , Juergen Schoenwaelder Date: Sat, 26 Sep 2015 18:17:53 -0400 Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Simplification of multiple outputs resulting from an Action or List of Actions) Thread-Index: AQHQ948sxV3P3qZHgkSnJexcT5IdC55PCwHAgAAphbCAAC1x0A== Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB48427DA@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC226710@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923141342.GE1945@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC258E6A@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427D8@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77DC25AAD2@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC25AAD2@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Simplification of multiple outputs resulting from an Action or List of Actions) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 22:21:55 -0000 Yes, I've been working on a task configuration and report task configuratio= n using TWAMP and two metrics measured by the same task for the last day or s= o. When you add that to the Registry example/initial contents draft, that's a lot to cover at the Interim. It's not the whole InfoModel picture, and maybe others will help with the r= est of a complete example so we will see what we really have here in a less abstract form. Al > -----Original Message----- > From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] > Sent: Saturday, September 26, 2015 3:33 PM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Simplification > of multiple outputs resulting from an Action or List of Actions) >=20 > Al, >=20 > Yes it is very difficult at the abstract level - I think I mentioned > this in the last thread. >=20 > If we can take a concrete example (say TWAMP) and map from the Registry > to the IM for a given task (run a TWAMP test for say 2 metrics) I think > that will begin to alleviate the confusion. >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Saturday, September 26, 2015 12:18 PM > To: Carey, Timothy (Timothy); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Simplification > of multiple outputs resulting from an Action or List of Actions) >=20 > I'm grappling with the current meaning of "output" here. >=20 > Actions perform Tasks. Tasks produce Output. > Output is consumed by Destination Schedules. >=20 > ma-action-destinations: An optional and possibly empty list of > names of destination schedules that consume > output produced by this action. >=20 > So, when we allow a Task to contain multiple Metric Registry URIs, there > will be a measured result for each Metric, which we would call multiple > outputs in the Registry Draft. But if all the measured results are > considered "one" Output in the Info Model, then we appear to be > synchronized on the notion of Output. >=20 > Then, if the Output can be fed to another schedule, with another action > to further process, or store the measured results with earlier results > for later reporting, or report according to the schedule, then that will > work, too. >=20 > It's very difficult to gain procedural insights from an abstract model > alone. >=20 > Al >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy > > (Timothy) > > Sent: Friday, September 25, 2015 8:39 AM > > To: Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: > > Simplification of multiple outputs resulting from an Action or List of > > Actions) > > > > > > > > Juergen, > > > > "We have removed the notion of multiple outputs and we have simplified > > the model such that outputs can only be fed into another schedule (but > > not into an action of a schedule)." > > > > Is Al Morton and the IPPM team ok with this modification? > > The only reason I ask is that the IPPM registry draft for output > > categories has been unchanged since January. So are we constraining > > (simplifying) what was agreed to previously? > > > > Remember a schedule can contain a List of Actions thus a List of > > Outputs. > > > > If the IPPM team is fine with the simplification; I am OK as well. The > > easier the better in my view. > > > > Juergen - So where is the "link" between the Scheduled Action's output > > and the downstream Schedule? I didn't see this relationship. > > > > BR, > > Tim > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Wednesday, September 23, 2015 9:14 AM > > To: Carey, Timothy (Timothy) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: draft-ietf- > > lmap-information-model-06 > > > > Tim, > > > > we have removed the notion of multiple outputs and we have simplified > > the model such that outputs can only be fed into another schedule (but > > not into an action of a schedule). The new model is that measurement > > tasks will tag results and if certain tags are not needed, you filter > > the output based on the tags. > > > > /js > > > > On Mon, Jul 27, 2015 at 08:23:01PM +0000, Carey, Timothy (Timothy) > > wrote: > > > Juergen, > > > > > > I was looking at the definition of ma-action-destinations. I don't > > understand what we did here. > > > > > > It used to be the case that a registry entry can define outputs that > > were pipelined to a scheduled action. Now I it looks like it is a > > schedule. > > > > > > However previously we said: > > > An empty list means that all outputs defined by the Action's task > > registry are invoked. - this is missing from you draft - what do we do > > with an empty list? > > > > > > Likewise we actually defined the output number to a list of > > > Schedules > > - I didn't see that modeled in the simple list of schedules. > > > > > > BR, > > > Tim > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap From nobody Sun Sep 27 00:59:55 2015 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 C7A151A0025 for ; Sun, 27 Sep 2015 00:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHXXWmUwmCqV for ; Sun, 27 Sep 2015 00:59:52 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5378F1A0021 for ; Sun, 27 Sep 2015 00:59:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BSBQBBP8ZV/xUHmMZbGQEBgjMhLFRpBoMeplAGkz+HfQIcgQo6EgEBAQEBAQGBCoQjAQEBAQMSEQpMEAIBCA0EBAEBCx0DAgICMBQJCAIEAQ0FCBqIDAGseIpWlWgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXhh+FMoQwAScxBgGCaS+BFAWMVYUwgwYBlVuRBBcPg31vgQUBHyOBBAEBAQ X-IPAS-Result: A2BSBQBBP8ZV/xUHmMZbGQEBgjMhLFRpBoMeplAGkz+HfQIcgQo6EgEBAQEBAQGBCoQjAQEBAQMSEQpMEAIBCA0EBAEBCx0DAgICMBQJCAIEAQ0FCBqIDAGseIpWlWgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXhh+FMoQwAScxBgGCaS+BFAWMVYUwgwYBlVuRBBcPg31vgQUBHyOBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208,217";a="121764465" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Sep 2015 03:59:48 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 27 Sep 2015 03:59:48 -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, 27 Sep 2015 09:59:46 +0200 From: "Romascanu, Dan (Dan)" To: Holger Wiehen , "lmap@ietf.org" Thread-Topic: [lmap] Consider constraints for MA capabilities (lmap-information-model) Thread-Index: AQHQ9uwoEFEbdkH29E+CSf3vMyRxdJ5QBriQ Date: Sun, 27 Sep 2015 07:59:44 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB30E0F@AZ-FFEXMB04.global.avaya.com> References: <82660D27-0B52-443E-83CF-5A02E9E791BC@nic.br> In-Reply-To: <82660D27-0B52-443E-83CF-5A02E9E791BC@nic.br> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CB30E0FAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: Juergen Schoenwaelder Subject: Re: [lmap] Consider constraints for MA capabilities (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, 27 Sep 2015 07:59:54 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CB30E0FAZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSG9sZ2VyLA0KDQpXZSBjYW4gZGlzY3VzcyB0aGlzIGluZGVlZCBhdCB0aGUgdmlydHVhbCBp bnRlcmltIChwYXJ0IG9mIHRoZSBJTSBkaXNjdXNzaW9ucykNCg0KUmVnYXJkcywNCg0KRGFuDQoN Cg0KRnJvbTogbG1hcCBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEhvbGdlciBXaWVoZW4NClNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTUgNzo1MiBQ TQ0KVG86IGxtYXBAaWV0Zi5vcmcNCkNjOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXINClN1YmplY3Q6 IFtsbWFwXSBDb25zaWRlciBjb25zdHJhaW50cyBmb3IgTUEgY2FwYWJpbGl0aWVzIChsbWFwLWlu Zm9ybWF0aW9uLW1vZGVsKQ0KDQpIaS4NCg0KRm9sbG93aW5nIGlzIGEgc3VnZ2VzdGlvbiB0byBl eHRlbmQgdGhlIGNvbmNlcHQgb2YgTUEgY2FwYWJpbGl0aWVzLiBNYXliZSBpdCBpcyBvbiB0aW1l IGZvciB0aGUgaW50ZXJpbT8NCg0KVGhlIGNhcGFiaWxpdGllcyBvZiBhIE1BIG1pZ2h0IGluY2x1 ZGUgY29uc3RyYWludHMsIGZvciB0aGUgbWVhc3VyZW1lbnQgdGFza3MgaXQgc3VwcG9ydHMuIFRo ZSBDb250cm9sbGVyIHNob3VsZCBjb25zaWRlciB0aG9zZSBjb25zdHJhaW50cyB3aGVuIGl0IGlu c3RydWN0cyB0aGUgTUEuIENvbnN0cmFpbnRzIG1pZ2h0IGxpbWl0IHRoZSBDb250cm9sbGVy4oCZ cyBjaG9pY2UgZm9yIHRhc2stb3B0aW9ucyBvciBmb3IgdGFzayBzY2hlZHVsaW5nLg0KDQpUaHJl ZSBleGFtcGxlczoNCi0gQSBtZWFzdXJlbWVudCBhZ2VudCBkb2VzIHN1cHBvcnQgYSBnaXZlbiBt ZWFzdXJlbWVudCB0YXNrLCBidXQgZHVlIHRvIGxpbWl0ZWQgZGV2aWNlIHJlc291cmNlcywgdGhl IHRhc2sgY29uZmlndXJhdGlvbiBzaG91bGQgcmVzcGVjdCBhIG1heGltdW0gZHVyYXRpb24uDQot IEEgbWVhc3VyZW1lbnQgYWdlbnQgaXMgZGVwbG95ZWQgYXQgYW4gb2ZmaWNlIGxvY2F0aW9uLiBN ZWFzdXJlbWVudHMgc2hvdWxkIG9jY3VyIGFmdGVyIG9mZmljZSBob3Vycywgb25seS4NCi0gQSBs YXJnZSBzY2FsZSBtZWFzdXJlbWVudCBuZXR3b3JrIGlzIGRlcGxveWVkIGFjcm9zcyBtdWx0aXBs ZSBhdXRvbm9tb3VzIHN5c3RlbXMuIFRoZSBwYXJ0aWNpcGF0aW5nIG9yZ2FuaXNhdGlvbnMgY2Fu IGRlY2lkZSBpZiB0aGV5IGFsbG93IHRlc3RzICBjcm9zc2luZyBBUyBib3VuZGVyaWVzLg0KDQoN CkluIHRoZSBsaXN0IGFyY2hpdmUsIGl0IHdhcyBtZW50aW9uZWQgdGhhdCB0aGUgbWEtdGFzay1j YXBhYmlsaXR5LW9iaiB3aWxsIGJlIHJlaW50cm9kdWNlZC4gQ29uc3RyYWludHMgY291bGQgYmUg YW4gb3B0aW9uYWwgYXRyaWJ1dGUgb2YgdGhpcyBvYmplY3Q6DQoNCiBvYmplY3Qgew0KICAgICAg ICAgIHN0cmluZyBtYS10YXNrLW5hbWU7DQogICAgICAgICAgdXJpIG1hLXRhc2stcmVnaXN0cnk7 DQogICAgICAgICAgc3RyaW5nIG1hLXRhc2stcm9sZTsNCiAgICAgICAgICBbIG1hLWNhcGFiaWxp dHktdGFzay1jb25zdHJhaW50LW9iaiBtYS1jYXBhYmlsaXR5LXRhc2stY29uc3RyYWludHM8MC4u Kj4gXQ0KICAgICAgICAgIFsgbWEtY2FwYWJpbGl0eS1zY2hlZHVsZS1jb25zdHJhaW50LW9iaiBt YS1jYXBhYmlsaXR5LXNjaGVkdWxlLWNvbnN0cmFpbnRzPDAuLio+IF0NCiB9IG1hLXRhc2stY2Fw YWJpbGl0eS1vYmo7DQoNCm9iamVjdCB7DQogICAgICAgICAgc3RyaW5nIG1hLW9wdGlvbi1uYW1l Ow0KICAgICAgICAgIFsgb2JqZWN0IG1hLW9wdGlvbi12YWx1ZS1zZXQ8MC4uKj47IF0NCiAgICAg ICAgICBbIG9iamVjdCBtYS1vcHRpb24tdmFsdWUtcmFuZ2Utc3RhcnQ7IF0NCiAgICAgICAgICBb IG9iamVjdCBtYS1vcHRpb24tdmFsdWUtcmFuZ2UtZW5kOyBdDQp9IG1hLWNhcGFiaWxpdHktdGFz ay1jb25zdHJhaW50LW9iag0KDQpJbiB0aGlzIGNhc2UgdGhlIGNvbnN0cmFpbnQgYXBwbGllcyB0 byBhIHRhc2vigJlzIGNvbmZpZ3VyYXRpb24uIFRoZSBjb25zdHJhaW50IGV4cGxpY2l0bHkgZW51 bWVyYXRlcyB0aGUgYWxsb3dlZCB0YXNrLW9wdGlvbiB2YWx1ZXMsIG9yIHNwZWNpZmllcyBhIHJh bmdlIG9mIGFsbG93ZWQgdGFzay1vcHRpb24gdmFsdWVzLCBnaXZlbiBhIGxvd2VyIGFuZC9vciB1 cHBlciBib3VuZC4NCg0KQSBjb25zdHJhaW50IG9uIHRhc2sgc2NoZWR1bGluZyB3aWxsIGJlIG1v cmUgY29tcGxleCB0byBtb2RlbC4NCg0KV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgdGhlIG5vdGlv biBvZiBjb25zdHJhaW50cywgd2hlbiBhbm5vdW5jaW5nIGNhcGFiaWxpdGllcyBvZiBhIE1BPw0K DQoNClJlZ2FyZHMsDQoNCkhvbGdlciBXaWVoZW4uDQoNCg0K --_000_9904FB1B0159DA42B0B887B7FA8119CA5CB30E0FAZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCgl0ZXh0LWRlY29yYXRp b246bm9uZSBub25lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCgl0ZXh0LWRlY29yYXRp b246bm9uZSBub25lO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBw bGUtdGFiLXNwYW47fQ0KcC5ib2xkLCBsaS5ib2xkLCBkaXYuYm9sZA0KCXttc28tc3R5bGUtbmFt ZTpib2xkOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglmb250 LXdlaWdodDpib2xkO30NCnAuaXRhbGljLCBsaS5pdGFsaWMsIGRpdi5pdGFsaWMNCgl7bXNvLXN0 eWxlLW5hbWU6aXRhbGljOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm IjsNCglmb250LXN0eWxlOml0YWxpYzt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibGFjayIgdmxpbms9ImJsYWNrIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgSG9sZ2VyLA0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBjYW4gZGlz Y3VzcyB0aGlzIGluZGVlZCBhdCB0aGUgdmlydHVhbCBpbnRlcmltIChwYXJ0IG9mIHRoZSBJTSBk aXNjdXNzaW9ucyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPkhvbGdlciBXaWVoZW48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIFNl cHRlbWJlciAyNCwgMjAxNSA3OjUyIFBNPGJyPg0KPGI+VG86PC9iPiBsbWFwQGlldGYub3JnPGJy Pg0KPGI+Q2M6PC9iPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXI8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g W2xtYXBdIENvbnNpZGVyIGNvbnN0cmFpbnRzIGZvciBNQSBjYXBhYmlsaXRpZXMgKGxtYXAtaW5m b3JtYXRpb24tbW9kZWwpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Gb2xsb3dpbmcgaXMgYSBzdWdnZXN0aW9uIHRvIGV4dGVuZCB0aGUgY29u Y2VwdCBvZiBNQSBjYXBhYmlsaXRpZXMuIE1heWJlIGl0IGlzIG9uIHRpbWUgZm9yIHRoZSBpbnRl cmltPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgY2FwYWJpbGl0aWVzIG9mIGEgTUEgbWlnaHQgaW5jbHVkZSBjb25zdHJhaW50cywgZm9y IHRoZSBtZWFzdXJlbWVudCB0YXNrcyBpdCBzdXBwb3J0cy4gVGhlIENvbnRyb2xsZXIgc2hvdWxk IGNvbnNpZGVyIHRob3NlIGNvbnN0cmFpbnRzIHdoZW4gaXQgaW5zdHJ1Y3RzIHRoZSBNQS4gQ29u c3RyYWludHMgbWlnaHQgbGltaXQgdGhlIENvbnRyb2xsZXLigJlzIGNob2ljZSBmb3IgdGFzay1v cHRpb25zIG9yIGZvcg0KIHRhc2sgc2NoZWR1bGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhyZWUgZXhhbXBsZXM6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEEgbWVhc3VyZW1lbnQg YWdlbnQgZG9lcyBzdXBwb3J0IGEgZ2l2ZW4gbWVhc3VyZW1lbnQgdGFzaywgYnV0IGR1ZSB0byBs aW1pdGVkIGRldmljZSByZXNvdXJjZXMsIHRoZSB0YXNrIGNvbmZpZ3VyYXRpb24gc2hvdWxkIHJl c3BlY3QgYSBtYXhpbXVtIGR1cmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBBIG1lYXN1cmVtZW50IGFnZW50IGlzIGRlcGxveWVkIGF0 IGFuIG9mZmljZSBsb2NhdGlvbi4gTWVhc3VyZW1lbnRzIHNob3VsZCBvY2N1ciBhZnRlciBvZmZp Y2UgaG91cnMsIG9ubHkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tIEEgbGFyZ2Ugc2NhbGUgbWVhc3VyZW1lbnQgbmV0d29yayBpcyBk ZXBsb3llZCBhY3Jvc3MgbXVsdGlwbGUgYXV0b25vbW91cyBzeXN0ZW1zLiBUaGUgcGFydGljaXBh dGluZyBvcmdhbmlzYXRpb25zIGNhbiBkZWNpZGUgaWYgdGhleSBhbGxvdyB0ZXN0cyAmbmJzcDtj cm9zc2luZyBBUyBib3VuZGVyaWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSBsaXN0IGFyY2hpdmUsIGl0IHdhcyBtZW50aW9u ZWQgdGhhdCB0aGUgbWEtdGFzay1jYXBhYmlsaXR5LW9iaiB3aWxsIGJlIHJlaW50cm9kdWNlZC4g Q29uc3RyYWludHMgY291bGQgYmUgYW4gb3B0aW9uYWwgYXRyaWJ1dGUgb2YgdGhpcyBvYmplY3Q6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDtvYmplY3QgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPnN0cmluZyBt YS10YXNrLW5hbWU7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+dXJpIG1hLXRhc2stcmVn aXN0cnk7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+c3RyaW5nIG1hLXRhc2stcm9sZTs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5bJm5ic3A7bWEtY2FwYWJpbGl0eS10YXNrLWNv bnN0cmFpbnQtb2JqIG1hLWNhcGFiaWxpdHktdGFzay1jb25zdHJhaW50cyZsdDswLi4qJmd0OyBd PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5bJm5ic3A7bWEtY2Fw YWJpbGl0eS1zY2hlZHVsZS1jb25zdHJhaW50LW9iaiBtYS1jYXBhYmlsaXR5LXNjaGVkdWxlLWNv bnN0cmFpbnRzJmx0OzAuLiomZ3Q7IF08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDt9IG1hLXRhc2stY2FwYWJpbGl0eS1vYmo7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+b2JqZWN0IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5zdHJpbmcgbWEtb3B0 aW9uLW5hbWU7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+WyZuYnNwO29iamVjdCBtYS1v cHRpb24tdmFsdWUtc2V0Jmx0OzAuLiomZ3Q7OyBdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+WyZuYnNwO29iamVjdCBtYS1vcHRpb24tdmFsdWUtcmFuZ2Utc3RhcnQ7IF08bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJh cHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5bJm5ic3A7b2JqZWN0IG1hLW9wdGlvbi12YWx1ZS1yYW5nZS1l bmQ7IF08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pn0gbWEtY2FwYWJpbGl0eS10YXNrLWNvbnN0cmFpbnQtb2JqJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoaXMgY2FzZSB0aGUg Y29uc3RyYWludCBhcHBsaWVzIHRvIGEgdGFza+KAmXMgY29uZmlndXJhdGlvbi4gVGhlIGNvbnN0 cmFpbnQgZXhwbGljaXRseSZuYnNwO2VudW1lcmF0ZXMgdGhlIGFsbG93ZWQgdGFzay1vcHRpb24g dmFsdWVzLCBvciBzcGVjaWZpZXMgYSByYW5nZSBvZiBhbGxvd2VkIHRhc2stb3B0aW9uIHZhbHVl cywgZ2l2ZW4gYSBsb3dlciBhbmQvb3IgdXBwZXIgYm91bmQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgY29uc3RyYWludCBvbiB0 YXNrIHNjaGVkdWxpbmcgd2lsbCBiZSBtb3JlIGNvbXBsZXggdG8gbW9kZWwuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgZG8geW91IHRo aW5rIGFib3V0IHRoZSBub3Rpb24gb2YgY29uc3RyYWludHMsIHdoZW4gYW5ub3VuY2luZyBjYXBh YmlsaXRpZXMgb2YgYSBNQT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib2xnZXIgV2llaGVuLiAmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9904FB1B0159DA42B0B887B7FA8119CA5CB30E0FAZFFEXMB04globa_-- From nobody Sun Sep 27 06:11:03 2015 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 EE46C1AD082 for ; Sun, 27 Sep 2015 06:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMTLjk0SkcEs for ; Sun, 27 Sep 2015 06:10:58 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 EACFA1ACF6C for ; Sun, 27 Sep 2015 06:10:57 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id CF6B855CD2F55; Sun, 27 Sep 2015 13:10:51 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t8RD97Zw017617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Sep 2015 13:10:52 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Sun, 27 Sep 2015 09:09:21 -0400 From: "Carey, Timothy (Timothy)" To: "MORTON, ALFRED C (AL)" , Juergen Schoenwaelder Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the information model Thread-Index: AQHQ9g97/2M+BXlhaEigCJzBc+neRp5NNIDQgAGluWCAACTaUIAABEXAgAAo96CAADXToIAA95ng Date: Sun, 27 Sep 2015 13:09:20 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC25B3EF@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC227456@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923145229.GG1945@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC258EC3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427CF@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77DC25A906@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427D7@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77DC25AAC4@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427D9@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB48427D9@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the 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, 27 Sep 2015 13:11:01 -0000 Al, Hmmm - I think there might be the gap in this thinking. If the metrics are defined in the Registry where would the "Tests" be defin= ed such that they can be ultimately translated into an IM Task or Action - = These tests have to have knowledge the parameters and results of the "conta= ining metrics" along with their own elements. For example where/how would the ICMP Ping test be defined that validates a = latency metric? There are RFCs (e.g., 792, 4443) that describe the ICMP Pin= g message but not the Ping test. Also the ICMP RFC doesn't talk about eleme= nts of the test of the message (e.g., repetitions) as well as how the eleme= nts relate to the metric's parameters and how both the metric's parameters = and test elements are mapped to the LMAP IM task/action structure. What was the conclusion to where these tests are defined if not the Registr= y? BR, Tim -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Saturday, September 26, 2015 5:13 PM To: Carey, Timothy (Timothy); Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Cap= abilities and ma conditions back into the information model Hi Tim, The Measurement Protocol and Protocol Roles can't come from the IPPM metri= cs registry - just like setting a single method of measurement role would c= ause entirely duplicate entries in the registry just to change the role, ad= ding each possible protocol (TWAMP, OWAMP, ICMP, IPSLA,...) adds even more = multiplication of a single entry. So, that's why we agreed not to add protocol in the registry at the worksho= p with BBF last year. If an MA has TWAMP capability, it certainly knows and can say so in a capab= ilities message. My guess is that the MAs will have one of the above measur= ement protocols, so it's really just a matter of revealing the single choic= e of the developers and any limitations (e.g., this MA can only perform as = a TWAMP Server&Reflector). hope this helps, Al > -----Original Message----- > From: Carey, Timothy (Timothy)=20 > [mailto:timothy.carey@alcatel-lucent.com] > Sent: Saturday, September 26, 2015 3:29 PM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert=20 > Task Capabilities and ma conditions back into the information model >=20 > Al, >=20 > I am not sure where the Measurement Capability and Protocol Roles=20 > would come from given a set of registry entries. > I do think the correlation of the IM to the Registry around Tasks and=20 > Actions is what is causing (at least my) confusion. >=20 > Summary > ------------------------------- > ID | Name | URI | Description | > Metric Definition > ----------------------------------------- > Reference Definition | Fixed Parameters | Method of Measurement > --------------------------------------------------------------- > Reference | Packet | Traffic | Sampling | Run-time | Role | Method |=20 > Generation | Filter | dist. | Param | | > | Stream | > Output > ----------------------------- > | Type | Reference | Units | > | | Definition | | >=20 >=20 > I > BR, > Tim >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Saturday, September 26, 2015 11:52 AM > To: Carey, Timothy (Timothy); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert=20 > Task Capabilities and ma conditions back into the information model >=20 > Hi Tim, > good question (we're having Tuesday's meeting on Saturday :-( ) >=20 > I think we need some approximate hierarchy like this: >=20 > Measurement Capability [ > Measurement Protocol [ > Protocol Roles [ ] > ] > Registry URI [ > Method Roles [ ] > ] > ] > so, an example would be >=20 > Measurement Capability [ > TWAMP [ > Control-Client; Session-Sender; Server; Session-Reflector; > ] > Prefix:Act_IP_UDP_Round-trip_Delay_95th-percentile_Poisson [ > Src; Dst; > ... more URIs and Roles... > ] > ] > for a fully capable MA. >=20 > I think you can easily conjure-up how to indicate a system with less=20 > than full capabilities, or how a different Meas. Protocols could be=20 > substituted in a different meas. capability that measures the *same*=20 > registered metric. >=20 > Al >=20 >=20 > > -----Original Message----- > > From: Carey, Timothy (Timothy) > > [mailto:timothy.carey@alcatel-lucent.com] > > Sent: Saturday, September 26, 2015 12:16 PM > > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert=20 > > Task Capabilities and ma conditions back into the information model > > > > Al, > > > > Indeed we do need that to be a list as you suggest but what is=20 > > relationship with the role to the list of registry entries? > > > > BR, > > Tim > > > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Saturday, September 26, 2015 9:12 AM > > To: Carey, Timothy (Timothy); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert=20 > > Task Capabilities and ma conditions back into the information model > > > > Hi Tim and Juergen, > > > > Here's a small addition to what Tim proposed: > > > > * ma-task-capability-obj ma-supported-tasks<0..*>; > > > > It's necessary for all non-measurement tasks to have a registry=20 > > providing the details of each task (and someone needs to start that=20 > > development). > > > > But for measurement Tasks, there can be multiple Performance Metric=20 > > Registry entries involved now, and each task will be some=20 > > combination of registered metrics. > > > > So we also need ma-supported-registry-entries<0..*>; > > and the text below (from 3.9) needs some revisions to keep-up with=20 > > the latest agreements (if I've got this right): > > > > A Measurement Task Configuration is the same in information terms > to > > any other Task Configuration. Both measurement and non-measurement > > Tasks have registry entries to enable the MA to uniquely identify > the > > Task it should execute and retrieve the schema for any parameters > > that may be passed to the Task. Registry entries are specified=20 > > as > a > > URI and can therefore be used to identify the Task within a > namespace > > or point to a web or local file location for the Task information. > > As mentioned previously, these URIs may be used to identify the > > Measurement Task in a public namespace > > [I-D.ietf-ippm-metric-registry]. > > > > Al > > > > > -----Original Message----- > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey,=20 > > > Timothy > > > (Timothy) > > > Sent: Friday, September 25, 2015 8:51 AM > > > To: Juergen Schoenwaelder > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert=20 > > > Task Capabilities and ma conditions back into the information=20 > > > model > > > > > > Juergen, > > > > > > But the ma-status-object doesn't provide all the conditions of the=20 > > > MA might be experiencing (which might be implementation specific). > > > > > > BR, > > > Tim > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-=20 > > > university.de] > > > Sent: Wednesday, September 23, 2015 9:52 AM > > > To: Carey, Timothy (Timothy) > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert=20 > > > Task Capabilities and ma conditions back into the information=20 > > > model > > > > > > On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) > > > wrote: > > > > Juergen, > > > > > > > > In draft 05 we removed the ability for a measurement agent to=20 > > > > report > > > its metrics that it supports. > > > > We need to add > > > > > > > > * ma-task-capability-obj ma-supported-tasks<0..*>; > > > > > > > > * [ma-condition-obj ma-conditions<0..*>;] > > > > > > > > They were in the ma-status-obj. > > > > > > You are correct. There currently is no 'list' of tasks that are=20 > > > supported by a device anymore and we may have to put this back in. > > > > > > We changed the reporting of runtime failures to make them more > useful. > > > See the ma-task-status-obj. > > > > > > /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 Sun Sep 27 12:07:12 2015 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 7E92C1B2CE8 for ; Sun, 27 Sep 2015 12:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 K2uBhD7dpDEH for ; Sun, 27 Sep 2015 12:07:08 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2435A1B2CE6 for ; Sun, 27 Sep 2015 12:07:08 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id A924E123F02; Sun, 27 Sep 2015 15:33:41 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 57306E0118; Sun, 27 Sep 2015 15:05:22 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Sun, 27 Sep 2015 15:07:04 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Timothy)" , Juergen Schoenwaelder Date: Sun, 27 Sep 2015 15:07:02 -0400 Thread-Topic: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the information model Thread-Index: AQHQ9g97/2M+BXlhaEigCJzBc+neRp5NNIDQgAGluWCAACTaUIAABEXAgAAo96CAADXToIAA95nggABVDKA= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB48427EB@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC227456@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923145229.GG1945@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC258EC3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427CF@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77DC25A906@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427D7@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77DC25AAC4@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427D9@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77DC25B3EF@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC25B3EF@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the 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, 27 Sep 2015 19:07:11 -0000 Hi Tim, This is a very useful discussion, because it makes clear to me=20 some possible gaps in understanding between the LMAP and IPPM communities (since we are discussing IPPM-specific examples in this thread, and again during the Interim meeting on Tuesday). We need to close these gaps, and examples provide the catalyst for more discussion and learning for all of us. please replies see below, Al > -----Original Message----- > From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] > Sent: Sunday, September 27, 2015 9:09 AM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task > Capabilities and ma conditions back into the information model >=20 > Al, >=20 > Hmmm - I think there might be the gap in this thinking. > If the metrics are defined in the Registry where would the "Tests" be > defined such that they can be ultimately translated into an IM Task or > Action - These tests have to have knowledge the parameters and results > of the "containing metrics" along with their own elements. [ACM]=20 The largest category of columns in the Performance Metrics Registry contain= s the details on "How to Perform Tests" - what we call Methods of Measurement= . For Active Metrics, the critical columns are: Method of Measurement ---------------------------------------------- Reference | Packet |.| Run-time | Role | Method | Generation |.| Parameters | | | Stream |.| So, the RFCs that define Active Metrics in IPPM literature also define the Methods of Measurement, or "Tests". Further, where the authors of a Registry Entry for a Metric want to augment the Reference Method with more detail,=20 they are able to do so in the Reference Method column. Thus, it's very important to get feedback from folks who may be implementing the registered metrics: is the level of detail in the Reference Method sufficient that independent implementations will produce equivalent results? Or, are there questions that=20 we still need to answer to avoid ambiguity? >=20 > For example where/how would the ICMP Ping test be defined that validates > a latency metric? There are RFCs (e.g., 792, 4443) that describe the > ICMP Ping message but not the Ping test. Also the ICMP RFC doesn't talk > about elements of the test of the message (e.g., repetitions) as well as > how the elements relate to the metric's parameters and how both the > metric's parameters and test elements are mapped to the LMAP IM > task/action structure. [ACM]=20 Great question. This reminds me of a conversation between Marcelo, Phil and me almost three years ago, when we were discussing the apparent lack=20 of a DNS response time metric. I suggested that we could rely on the RFC 2681 Round-trip Delay Metric, and specify that the packet sent would have a "Type-P" of a UDP DNS Message (Standard Query). The current version of this DNS example is included in the draft proposing initial cont= ents: https://tools.ietf.org/html/draft-morton-ippm-initial-registry-00#section-6 This entry contains a Reference Method of Measurement based on RFC 2681 and= RFC 6673: https://tools.ietf.org/html/draft-morton-ippm-initial-registry-00#section-6= .3.1 Clearly, we could do the same thing with ICMP Echo Request/Reply packets, and specify a test equivalent to the connectivity assessment performed by p= ing apps. >=20 > What was the conclusion to where these tests are defined if not the > Registry? [ACM]=20 I think another area of knowledge transfer between LMAP and IPPM is the=20 role of IPPM's test protocols (and the limits on their scope of operation). For example, TWAMP is a protocol to coordinate, generate, and control Activ= e Measurement Streams in the context of Test Sessions between two hosts on th= e Internet. TWAMP does its job independent from the metrics that the system intends to = measure. TWAMP entities have to get some testing details from the information model= =20 (Run-time Parameters) and the Registered Metrics. A single TWAMP Test Sess= ion would correspond to an LMAP measurement Task.=20 The TWAMP protocol does not define how to make measurements, or discuss the= =20 process to generate specific streams of packets,=20 provide accurate timestamps where/when needed, or other details of the Method of Measurement. That's where another proces= s implementing the Registered Metric and its Method of Measurement comes-in.= =20 A TWAMP entity could be configured by the info model/data model. In https://tools.ietf.org/html/draft-cmzrjp-ippm-twamp-yang-01 another author team has created a YANG model for TWAMP. hope this helps! >=20 > BR, > Tim >=20 >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Saturday, September 26, 2015 5:13 PM > To: Carey, Timothy (Timothy); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task > Capabilities and ma conditions back into the information model >=20 > Hi Tim, >=20 > The Measurement Protocol and Protocol Roles can't come from the IPPM > metrics registry - just like setting a single method of measurement role > would cause entirely duplicate entries in the registry just to change > the role, adding each possible protocol (TWAMP, OWAMP, ICMP, IPSLA,...) > adds even more multiplication of a single entry. >=20 > So, that's why we agreed not to add protocol in the registry at the > workshop with BBF last year. >=20 > If an MA has TWAMP capability, it certainly knows and can say so in a > capabilities message. My guess is that the MAs will have one of the > above measurement protocols, so it's really just a matter of revealing > the single choice of the developers and any limitations (e.g., this MA > can only perform as a TWAMP Server&Reflector). >=20 > hope this helps, > Al >=20 > > -----Original Message----- > > From: Carey, Timothy (Timothy) > > [mailto:timothy.carey@alcatel-lucent.com] > > Sent: Saturday, September 26, 2015 3:29 PM > > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert > > Task Capabilities and ma conditions back into the information model > > > > Al, > > > > I am not sure where the Measurement Capability and Protocol Roles > > would come from given a set of registry entries. > > I do think the correlation of the IM to the Registry around Tasks and > > Actions is what is causing (at least my) confusion. > > > > Summary > > ------------------------------- > > ID | Name | URI | Description | > > Metric Definition > > ----------------------------------------- > > Reference Definition | Fixed Parameters | Method of Measurement > > --------------------------------------------------------------- > > Reference | Packet | Traffic | Sampling | Run-time | Role | Method | > > Generation | Filter | dist. | Param | | > > | Stream | > > Output > > ----------------------------- > > | Type | Reference | Units | > > | | Definition | | > > > > > > I > > BR, > > Tim > > > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Saturday, September 26, 2015 11:52 AM > > To: Carey, Timothy (Timothy); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert > > Task Capabilities and ma conditions back into the information model > > > > Hi Tim, > > good question (we're having Tuesday's meeting on Saturday :-( ) > > > > I think we need some approximate hierarchy like this: > > > > Measurement Capability [ > > Measurement Protocol [ > > Protocol Roles [ ] > > ] > > Registry URI [ > > Method Roles [ ] > > ] > > ] > > so, an example would be > > > > Measurement Capability [ > > TWAMP [ > > Control-Client; Session-Sender; Server; Session-Reflector; > > ] > > Prefix:Act_IP_UDP_Round-trip_Delay_95th-percentile_Poisson [ > > Src; Dst; > > ... more URIs and Roles... > > ] > > ] > > for a fully capable MA. > > > > I think you can easily conjure-up how to indicate a system with less > > than full capabilities, or how a different Meas. Protocols could be > > substituted in a different meas. capability that measures the *same* > > registered metric. > > > > Al > > > > > > > -----Original Message----- > > > From: Carey, Timothy (Timothy) > > > [mailto:timothy.carey@alcatel-lucent.com] > > > Sent: Saturday, September 26, 2015 12:16 PM > > > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > > > Cc: lmap@ietf.org > > > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert > > > Task Capabilities and ma conditions back into the information model > > > > > > Al, > > > > > > Indeed we do need that to be a list as you suggest but what is > > > relationship with the role to the list of registry entries? > > > > > > BR, > > > Tim > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Saturday, September 26, 2015 9:12 AM > > > To: Carey, Timothy (Timothy); Juergen Schoenwaelder > > > Cc: lmap@ietf.org > > > Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert > > > Task Capabilities and ma conditions back into the information model > > > > > > Hi Tim and Juergen, > > > > > > Here's a small addition to what Tim proposed: > > > > > * ma-task-capability-obj ma-supported-tasks<0..*>; > > > > > > It's necessary for all non-measurement tasks to have a registry > > > providing the details of each task (and someone needs to start that > > > development). > > > > > > But for measurement Tasks, there can be multiple Performance Metric > > > Registry entries involved now, and each task will be some > > > combination of registered metrics. > > > > > > So we also need ma-supported-registry-entries<0..*>; > > > and the text below (from 3.9) needs some revisions to keep-up with > > > the latest agreements (if I've got this right): > > > > > > A Measurement Task Configuration is the same in information terms > > to > > > any other Task Configuration. Both measurement and non- > measurement > > > Tasks have registry entries to enable the MA to uniquely identify > > the > > > Task it should execute and retrieve the schema for any parameters > > > that may be passed to the Task. Registry entries are specified > > > as > > a > > > URI and can therefore be used to identify the Task within a > > namespace > > > or point to a web or local file location for the Task > information. > > > As mentioned previously, these URIs may be used to identify the > > > Measurement Task in a public namespace > > > [I-D.ietf-ippm-metric-registry]. > > > > > > Al > > > > > > > -----Original Message----- > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, > > > > Timothy > > > > (Timothy) > > > > Sent: Friday, September 25, 2015 8:51 AM > > > > To: Juergen Schoenwaelder > > > > Cc: lmap@ietf.org > > > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert > > > > Task Capabilities and ma conditions back into the information > > > > model > > > > > > > > Juergen, > > > > > > > > But the ma-status-object doesn't provide all the conditions of the > > > > MA might be experiencing (which might be implementation specific). > > > > > > > > BR, > > > > Tim > > > > > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > > university.de] > > > > Sent: Wednesday, September 23, 2015 9:52 AM > > > > To: Carey, Timothy (Timothy) > > > > Cc: lmap@ietf.org > > > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert > > > > Task Capabilities and ma conditions back into the information > > > > model > > > > > > > > On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) > > > > wrote: > > > > > Juergen, > > > > > > > > > > In draft 05 we removed the ability for a measurement agent to > > > > > report > > > > its metrics that it supports. > > > > > We need to add > > > > > > > > > > * ma-task-capability-obj ma-supported-tasks<0..*>; > > > > > > > > > > * [ma-condition-obj ma-conditions<0..*>;] > > > > > > > > > > They were in the ma-status-obj. > > > > > > > > You are correct. There currently is no 'list' of tasks that are > > > > supported by a device anymore and we may have to put this back in. > > > > > > > > We changed the reporting of runtime failures to make them more > > useful. > > > > See the ma-task-status-obj. > > > > > > > > /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 Mon Sep 28 00:19:12 2015 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 C4C271B319C for ; Mon, 28 Sep 2015 00:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeLCbC75pU1v for ; Mon, 28 Sep 2015 00:19: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 2758B1B31A6 for ; Mon, 28 Sep 2015 00:19:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E194A8FA; Mon, 28 Sep 2015 09:19: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 yGY5NUuLxjmE; Mon, 28 Sep 2015 09:19:07 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 28 Sep 2015 09:19:07 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 75DED20053; Mon, 28 Sep 2015 09:19:07 +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 0JjGODGOhP6i; Mon, 28 Sep 2015 09:19:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E4B12004E; Mon, 28 Sep 2015 09:19:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 84B703768832; Mon, 28 Sep 2015 09:19:04 +0200 (CEST) Date: Mon, 28 Sep 2015 09:19:04 +0200 From: Juergen Schoenwaelder To: Holger Wiehen Message-ID: <20150928071902.GA95432@elstar.local> Mail-Followup-To: Holger Wiehen , lmap@ietf.org References: <82660D27-0B52-443E-83CF-5A02E9E791BC@nic.br> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <82660D27-0B52-443E-83CF-5A02E9E791BC@nic.br> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] Consider constraints for MA capabilities (lmap-information-model) 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, 28 Sep 2015 07:19:12 -0000 Holger, I believe the WGs goal should be deliver a base model and to leave additional features to future extension. I think we should avoid feature creep. So the questions to ask are: - Is this something that can be found on a significant number of probes deployed today? - Can this be defined as an extension of the information model or does it have to be in the core LMAP information model? /js On Thu, Sep 24, 2015 at 01:51:46PM -0300, Holger Wiehen wrote: > Hi. > > Following is a suggestion to extend the concept of MA capabilities. Maybe it is on time for the interim? > > The capabilities of a MA might include constraints, for the measurement tasks it supports. The Controller should consider those constraints when it instructs the MA. Constraints might limit the Controller’s choice for task-options or for task scheduling. > > Three examples: > - A measurement agent does support a given measurement task, but due to limited device resources, the task configuration should respect a maximum duration. > - A measurement agent is deployed at an office location. Measurements should occur after office hours, only. > - A large scale measurement network is deployed across multiple autonomous systems. The participating organisations can decide if they allow tests crossing AS bounderies. > > > In the list archive, it was mentioned that the ma-task-capability-obj will be reintroduced. Constraints could be an optional atribute of this object: > > object { > string ma-task-name; > uri ma-task-registry; > string ma-task-role; > [ ma-capability-task-constraint-obj ma-capability-task-constraints<0..*> ] > [ ma-capability-schedule-constraint-obj ma-capability-schedule-constraints<0..*> ] > } ma-task-capability-obj; > > object { > string ma-option-name; > [ object ma-option-value-set<0..*>; ] > [ object ma-option-value-range-start; ] > [ object ma-option-value-range-end; ] > } ma-capability-task-constraint-obj > > In this case the constraint applies to a task’s configuration. The constraint explicitly enumerates the allowed task-option values, or specifies a range of allowed task-option values, given a lower and/or upper bound. > > A constraint on task scheduling will be more complex to model. > > What do you think about the notion of constraints, when announcing capabilities of a MA? > > > Regards, > > Holger Wiehen. > > -- 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 28 05:12:49 2015 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 73AC41A8AB6 for ; Mon, 28 Sep 2015 05:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw9es4AsD5Rf for ; Mon, 28 Sep 2015 05:12:46 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [200.160.4.5]) (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 BC8851A8AA5 for ; Mon, 28 Sep 2015 05:12:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id D7E4E14794D; Mon, 28 Sep 2015 09:12:38 -0300 (BRT) X-Virus-Scanned: Debian amavisd-new at mail.nic.br Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mPj5jfSBDhB; Mon, 28 Sep 2015 09:12:36 -0300 (BRT) Received: from 5.140.net.registro.br (unknown [IPv6:2001:12ff:0:5::140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id B1D1314794F; Mon, 28 Sep 2015 09:12:36 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1443442356; bh=DYkscdfkD8TI4y4p0g3YGZBSGr7EEtLZzOfEkJTCXU4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=OuLrWLVpAqf7Bb+0PnROK826bxFx8D/NdGz7cEaOOg03VZQLjHs5Rvt7Csa2LSfje nGtySvPuPzRjZIbH96V0jvDw292j72/fMCnujnncWSY4jySdq1x1X63NfxqDGHurCZ fDJTKVU17P2lBGuUDNW3TjYn0f0IpctIlIREYMjk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Holger Wiehen In-Reply-To: <20150928071902.GA95432@elstar.local> Date: Mon, 28 Sep 2015 09:12:36 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5357123E-7319-4437-8D48-3B9BE63ED9AD@nic.br> References: <82660D27-0B52-443E-83CF-5A02E9E791BC@nic.br> <20150928071902.GA95432@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2104) DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br B1D1314794F Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] Consider constraints for MA capabilities (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, 28 Sep 2015 12:12:48 -0000 J=C3=BCrgen, > On Sep 28, 2015, at 4:19 AM, Juergen Schoenwaelder = wrote: >=20 > Holger, >=20 > I believe the WGs goal should be deliver a base model and to leave > additional features to future extension. I think we should avoid > feature creep. I agree it will be beneficial to leave =E2=80=9Ccapability = constraints=E2=80=9D to an extension if the typical use case does not = depend on it. >=20 > So the questions to ask are: >=20 > - Is this something that can be found on a significant number of > probes deployed today? Maybe the WG could comment on that.=20 > - Can this be defined as an extension of the information model or > does it have to be in the core LMAP information model? My impression is that the notion of constraints is inherent to the = concept of capabilities. So it seemed to me like a conceptual hole. I understand a capability as the ability to perform a given measurement = task within a range of supported configurations.=20 RFC7594 states in section 5.2.2 that LMAP does not consider task = negotiation between MA e Controller. The announcement of =E2=80=9Ccapabili= ty constraints=E2=80=9D would be coherent with this restriction. It = would be a one way information, just like the proper capability.=20 Thank=E2=80=99s Holger Wiehen. > /js >=20 > On Thu, Sep 24, 2015 at 01:51:46PM -0300, Holger Wiehen wrote: >> Hi. >>=20 >> Following is a suggestion to extend the concept of MA capabilities. = Maybe it is on time for the interim? >>=20 >> The capabilities of a MA might include constraints, for the = measurement tasks it supports. The Controller should consider those = constraints when it instructs the MA. Constraints might limit the = Controller=E2=80=99s choice for task-options or for task scheduling. >>=20 >> Three examples: >> - A measurement agent does support a given measurement task, but due = to limited device resources, the task configuration should respect a = maximum duration. >> - A measurement agent is deployed at an office location. Measurements = should occur after office hours, only.=20 >> - A large scale measurement network is deployed across multiple = autonomous systems. The participating organisations can decide if they = allow tests crossing AS bounderies. >>=20 >>=20 >> In the list archive, it was mentioned that the ma-task-capability-obj = will be reintroduced. Constraints could be an optional atribute of this = object: >>=20 >> object { >> string ma-task-name; >> uri ma-task-registry; >> string ma-task-role; >> [ ma-capability-task-constraint-obj = ma-capability-task-constraints<0..*> ] >> [ ma-capability-schedule-constraint-obj = ma-capability-schedule-constraints<0..*> ] >> } ma-task-capability-obj; >>=20 >> object { >> string ma-option-name; >> [ object ma-option-value-set<0..*>; ] >> [ object ma-option-value-range-start; ] >> [ object ma-option-value-range-end; ] >> } ma-capability-task-constraint-obj=20 >>=20 >> In this case the constraint applies to a task=E2=80=99s = configuration. The constraint explicitly enumerates the allowed = task-option values, or specifies a range of allowed task-option values, = given a lower and/or upper bound. >>=20 >> A constraint on task scheduling will be more complex to model. >>=20 >> What do you think about the notion of constraints, when announcing = capabilities of a MA? >>=20 >>=20 >> Regards, >>=20 >> Holger Wiehen. =20 >>=20 >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Tue Sep 29 04:11:34 2015 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 BE27D1A0140 for ; Tue, 29 Sep 2015 04:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKpyiyTdRBkW for ; Tue, 29 Sep 2015 04:11:32 -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 ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B0D1A6F1E for ; Tue, 29 Sep 2015 04:11:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AfAwA3Q8ZV/yYyC4dbGQSCMSEsVG+pbgaTNgmCBoV3AoEmOBQBAQEBAQEBfwuEJQEBAxIbXgEMCRVWHwcBBBsaiAwBDAOnW4ULoDoBCgEBARoEhh+KCi2DI4EUBZULAYUBiSqEJYMLkQQXD4N9gjeBBAEBAQ X-IPAS-Result: A2AfAwA3Q8ZV/yYyC4dbGQSCMSEsVG+pbgaTNgmCBoV3AoEmOBQBAQEBAQEBfwuEJQEBAxIbXgEMCRVWHwcBBBsaiAwBDAOnW4ULoDoBCgEBARoEhh+KCi2DI4EUBZULAYUBiSqEJYMLkQQXD4N9gjeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208,217";a="144208289" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 Sep 2015 07:11:31 -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; 29 Sep 2015 07:11:30 -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; Tue, 29 Sep 2015 13:11:28 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: virtual interim meeting today Thread-Index: AdD6p5YBZKPyEdqZS8Wzg1dPxw8nWg== Date: Tue, 29 Sep 2015 11:11:28 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB32A61@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.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CB32A61AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] virtual interim meeting today 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, 29 Sep 2015 11:11:33 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CB32A61AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The virtual interim meeting is scheduled for today at 10AM EDT. The agenda and reading list is available at https://www.ietf.org/proceeding= s/interim/2015/09/29/lmap/agenda/agenda-interim-2015-lmap-3. The updated Webex information is available at https://mailarchive.ietf.org/= arch/msg/lmap/XznFjylSO8W6mrJ6BSSO29T3C7M. We need two volunteers for taking summary notes (consensus calls and decisi= ons if any, action items). Please consider volunteering. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5CB32A61AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The virtual interim meeting is scheduled for today a= t 10AM EDT.

 

The agenda and reading list is available at https://www.ietf.org/proceedings/interim/2015/09/29/lmap/agenda/agenda-inte= rim-2015-lmap-3.

 

The updated Webex information is available at https://mailarchive.ietf.org/arch/msg/lmap/XznFjylSO8W6mrJ6BSSO29T3C7M.=

 

We need two volunteers for taking summary notes (con= sensus calls and decisions if any, action items). Please consider volunteer= ing.

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CB32A61AZFFEXMB04globa_-- From nobody Tue Sep 29 06:19:34 2015 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 DBB5B1B3D41 for ; Tue, 29 Sep 2015 06:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73qjmETWSHyn for ; Tue, 29 Sep 2015 06:19:30 -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 607181B3D38 for ; Tue, 29 Sep 2015 06:19:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1D467FEF; Tue, 29 Sep 2015 15:19:29 +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 q-2xUXabUHuD; Tue, 29 Sep 2015 15:19:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 29 Sep 2015 15:19:27 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C63FC20053; Tue, 29 Sep 2015 15:19:27 +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 86tnSgANlq-e; Tue, 29 Sep 2015 15:19:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A5392004E; Tue, 29 Sep 2015 15:19:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 404FC37699D7; Tue, 29 Sep 2015 15:19:25 +0200 (CEST) Date: Tue, 29 Sep 2015 15:19:24 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150929131924.GA99139@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77DC2266C0@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923140659.GD1945@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC258E35@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC258E35@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Actions 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, 29 Sep 2015 13:19:33 -0000 Tim, your suggested changes look good to me. /js On Fri, Sep 25, 2015 at 12:13:09PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > Ok thanks - that was my hope as well. > The current IM draft has some verbiage that could be interpreted otherwise. > > "It should be clear that the top-level behavior 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 Event object referenced > by the Schedule in which they appear. Note, however, that Actions > can have Action specific parameters." > > Perhaps we should say "Every Action contained by a Schedule". > > Also: > 3.7 Common Objects: Schedules > Multiple Actions in the list of a single Measurement Schedule will be > executed according to the execution mode of the Schedule. > > Perhaps we should say " Multiple Actions contained as an ordered list within a single Measurement Schedule ". > > Finally: > Actions in different Schedules execute in > parallel with such conflicts being reported in the Reporting > Information where necessary. > > Perhaps we should say "Actions contained in different Schedules ". > > > P.S. Also the draft as lowercase action instead of uppercase Action is some instances. > > BR, > Tim > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, September 23, 2015 9:07 AM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Actions > > On Mon, Jul 27, 2015 at 07:41:10PM +0000, Carey, Timothy (Timothy) wrote: > > Juergen, > > > > If Actions are now considered stand-alone entities outside the schedule. Shouldn't the MA have a list of Actions available like Tasks and CommunicationChannels? > > > > I do not think that actions are considered stand-alone entities. Actions exist as part of a schedule. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- 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 29 06:29:44 2015 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 867D91B3DD5 for ; Tue, 29 Sep 2015 06:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceihNPoUY8Pq for ; Tue, 29 Sep 2015 06:29:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA311B3DD3 for ; Tue, 29 Sep 2015 06:29:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F0A78787; Tue, 29 Sep 2015 15:29:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id X2XK9unASJnA; Tue, 29 Sep 2015 15:29: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; Tue, 29 Sep 2015 15:29:39 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B16D2004E; Tue, 29 Sep 2015 15:29:39 +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 dKeFuSnDpY3Y; Tue, 29 Sep 2015 15:29:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1757A20054; Tue, 29 Sep 2015 15:29:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 058E63769A2A; Tue, 29 Sep 2015 15:29:37 +0200 (CEST) Date: Tue, 29 Sep 2015 15:29:37 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150929132937.GB99139@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77DC226710@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923141342.GE1945@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC258E6A@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC258E6A@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Simplification of multiple outputs resulting from an Action or List of Actions) 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, 29 Sep 2015 13:29:44 -0000 Here is my understanding: I think a task has one output but that one output can carry multiple metrics. The metrics are properly tagged so that they can be filtered. If task M produce metrics m1 andf m2, then the result records should include the tags m1 and m2. If the output of M is forwarded to another task, the task can either consume both m1 and m2 or it might simply filter out one of them. It would be nice if the registry would not just define the metrics but also the tags for the metrics (as well as the option names used to set the parameters of the metric). /js On Fri, Sep 25, 2015 at 12:39:08PM +0000, Carey, Timothy (Timothy) wrote: > > > Juergen, > > "We have removed the notion of multiple outputs and we have simplified the model such that outputs can only be fed into another schedule (but not into an action of a schedule)." > > Is Al Morton and the IPPM team ok with this modification? > The only reason I ask is that the IPPM registry draft for output categories has been unchanged since January. So are we constraining (simplifying) what was agreed to previously? > > Remember a schedule can contain a List of Actions thus a List of Outputs. > > If the IPPM team is fine with the simplification; I am OK as well. The easier the better in my view. > > Juergen - So where is the "link" between the Scheduled Action's output and the downstream Schedule? I didn't see this relationship. > > BR, > Tim > > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, September 23, 2015 9:14 AM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: draft-ietf-lmap-information-model-06 > > Tim, > > we have removed the notion of multiple outputs and we have simplified the model such that outputs can only be fed into another schedule (but not into an action of a schedule). The new model is that measurement tasks will tag results and if certain tags are not needed, you filter the output based on the tags. > > /js > > On Mon, Jul 27, 2015 at 08:23:01PM +0000, Carey, Timothy (Timothy) wrote: > > Juergen, > > > > I was looking at the definition of ma-action-destinations. I don't understand what we did here. > > > > It used to be the case that a registry entry can define outputs that were pipelined to a scheduled action. Now I it looks like it is a schedule. > > > > However previously we said: > > An empty list means that all outputs defined by the Action's task registry are invoked. - this is missing from you draft - what do we do with an empty list? > > > > Likewise we actually defined the output number to a list of Schedules - I didn't see that modeled in the simple list of schedules. > > > > BR, > > Tim > > > _______________________________________________ > > 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 -- 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 29 06:35:44 2015 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 7ADDD1B3E5F for ; Tue, 29 Sep 2015 06:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkwL_Wrad0dC for ; Tue, 29 Sep 2015 06:35:35 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9BB1B3E61 for ; Tue, 29 Sep 2015 06:35:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7750910E6; Tue, 29 Sep 2015 15:35:22 +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 sbXFYEBsB0nK; Tue, 29 Sep 2015 15:35: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; Tue, 29 Sep 2015 15:35:21 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D05DC20053; Tue, 29 Sep 2015 15:35:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kCyQWvqHigz7; Tue, 29 Sep 2015 15:35:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7538F2004E; Tue, 29 Sep 2015 15:35:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 62AA33769A67; Tue, 29 Sep 2015 15:35:19 +0200 (CEST) Date: Tue, 29 Sep 2015 15:35:19 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150929133519.GC99139@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" , "MORTON, ALFRED C (AL)" References: <9966516C6EB5FC4381E05BF80AA55F77DC22D001@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923154438.GC2358@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC259120@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC259120@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action Destinations and tie with the Regisrry output 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, 29 Sep 2015 13:35:43 -0000 Tim, I think I do not understand your question. An action can choose to send its output to other schedules. In other words, we have forward pointers indicating the data flow. You seem to ask for a backwards pointer which in my view does not make much sense. But as I said, I am not sure I understand your question. /js On Fri, Sep 25, 2015 at 02:23:21PM +0000, Carey, Timothy (Timothy) wrote: > Al, > > So what do you think about how to link the ActionDestination of another Schedule with the results of this Schedules Action? > > BR, > Tim > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, September 23, 2015 10:45 AM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action Destinations and tie with the Regisrry output > > Tim, > > the information model currently assumes that results are tagged. A task producing multiple 'outputs' would tag them to distinguish them. > > How all this links to the registry is, honestly speaking, somewhat unclear to me since I do not really understand how the registry itself works. It would help me a lot if draft-ietf-ippm-metric-registry-04 > would contain a collection of example registry entries. > > /js > > On Wed, Aug 05, 2015 at 02:06:24PM +0000, Carey, Timothy (Timothy) wrote: > > Juergen, > > > > In previous information models we linked the Registry's outputs with the downstream tasks. > > > > In LMAP IM-06 draft we now have a concept of an ActionDestination which describes which schedules are invoked based on the task's output selection. However we do not link back the task output to the ActionDestination via parameter in the ActionDestination object (maybe called Output?). Did I miss understand the intent of the ActionDestination and its linkage? > > > > BR, > > Tim > > > _______________________________________________ > > 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 -- 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 29 06:42:58 2015 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 3A7B21B3EE4 for ; Tue, 29 Sep 2015 06:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyEIt1mQXaLs for ; Tue, 29 Sep 2015 06:42: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 01D6A1B3EE2 for ; Tue, 29 Sep 2015 06:42:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C064A948; Tue, 29 Sep 2015 15:42: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 o0fZWoleWHb7; Tue, 29 Sep 2015 15:42:51 +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, 29 Sep 2015 15:42:51 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A389E20054; Tue, 29 Sep 2015 15:42:51 +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 dzazWUMCos1m; Tue, 29 Sep 2015 15:42:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A7EB2004E; Tue, 29 Sep 2015 15:42:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EC8443769AB3; Tue, 29 Sep 2015 15:42:49 +0200 (CEST) Date: Tue, 29 Sep 2015 15:42:49 +0200 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20150929134249.GD99139@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77DC227456@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923145229.GG1945@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC258EC3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D0BB48427CF@NJFPSRVEXG0.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0BB48427CF@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "Carey, Timothy \(Timothy\)" , "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the information model 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, 29 Sep 2015 13:42:57 -0000 On Sat, Sep 26, 2015 at 10:12:22AM -0400, MORTON, ALFRED C (AL) wrote: > Hi Tim and Juergen, > > Here's a small addition to what Tim proposed: > > > * ma-task-capability-obj ma-supported-tasks<0..*>; > > It's necessary for all non-measurement tasks to have a registry > providing the details of each task (and someone needs to start that > development). Why is this needed? Our code can run tasks that are not registered. In fact, it does not know how to work with the registry at the moment. Why would I have to have a registry for a housekeeping task? > But for measurement Tasks, there can be multiple Performance Metric > Registry entries involved now, and each task will be some combination > of registered metrics. > > So we also need ma-supported-registry-entries<0..*>; > and the text below (from 3.9) needs some revisions to keep-up with > the latest agreements (if I've got this right): How would that be different from ma-task-registry-entries<1..*> in ma-task-status-obj (except that you allow an empty list, which seems reasonable)? /js > A Measurement Task Configuration is the same in information terms to > any other Task Configuration. Both measurement and non-measurement > Tasks have registry entries to enable the MA to uniquely identify the > Task it should execute and retrieve the schema for any parameters > that may be passed to the Task. Registry entries are specified as a > URI and can therefore be used to identify the Task within a namespace > or point to a web or local file location for the Task information. > As mentioned previously, these URIs may be used to identify the > Measurement Task in a public namespace > [I-D.ietf-ippm-metric-registry]. > > Al > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy > > (Timothy) > > Sent: Friday, September 25, 2015 8:51 AM > > To: Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task > > Capabilities and ma conditions back into the information model > > > > Juergen, > > > > But the ma-status-object doesn't provide all the conditions of the MA > > might be experiencing (which might be implementation specific). > > > > BR, > > Tim > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Wednesday, September 23, 2015 9:52 AM > > To: Carey, Timothy (Timothy) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task > > Capabilities and ma conditions back into the information model > > > > On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) > > wrote: > > > Juergen, > > > > > > In draft 05 we removed the ability for a measurement agent to report > > its metrics that it supports. > > > We need to add > > > > > > * ma-task-capability-obj ma-supported-tasks<0..*>; > > > > > > * [ma-condition-obj ma-conditions<0..*>;] > > > > > > They were in the ma-status-obj. > > > > You are correct. There currently is no 'list' of tasks that are > > supported by a device anymore and we may have to put this back in. > > > > We changed the reporting of runtime failures to make them more useful. > > See the ma-task-status-obj. > > > > /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 -- 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 30 03:40:16 2015 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 D76D81B2E29 for ; Wed, 30 Sep 2015 03:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sl4Afxfj06Pr for ; Wed, 30 Sep 2015 03:40:13 -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 F1F371B2E1E for ; Wed, 30 Sep 2015 03:40:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BE938FEF for ; Wed, 30 Sep 2015 12:40:11 +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 eR3RWBsyTsE0 for ; Wed, 30 Sep 2015 12:40:09 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 30 Sep 2015 12:40:09 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 775F420053 for ; Wed, 30 Sep 2015 12:40:09 +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 POiUF_lX1q5X; Wed, 30 Sep 2015 12: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 6056E2004E; Wed, 30 Sep 2015 12:40:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4E1A9376A8CE; Wed, 30 Sep 2015 12:40:07 +0200 (CEST) Date: Wed, 30 Sep 2015 12:40:07 +0200 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20150930104007.GD1699@elstar.local> Mail-Followup-To: lmap@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [lmap] info model issues list 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, 30 Sep 2015 10:40:15 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, here is a snapshot of my information model issues list after yesterday's meeting. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="issues.txt" # -*- org -*- # #+TITLE: LMAP Information Model Issues List #+OPTIONS: num:nil #+OPTIONS: toc:1 #+TODO: NEW(n) OPEN(o) VRFY(v) EDIT(e) REVIEW(r) DONE(d) #+TODO: DEAD(x) # #+HTML_HEAD_EXTRA: * OPEN :LI01: Disabling schedules on controller timeout Add a boolean flag to the ma-task-obj that indicates whether the task will be disabled if communication to the controller has stopped. The default will be true. ma-task-auto-disable: A boolean flag indicating whether the task will be disabled if the communication with the controller has timed out. The default value of the flag is true. The description of ma-controller-timeout will then be updated to say that all actions refering to tasks where ma-task-auto-disable is true will not be executed anymore. Add details to an ma-action-status-obj to report whether an action is currently disabled. - Timothy Carey indicated support for this solution. * OPEN :LI02: Action Execution Mode questions Go through the whole document replacing 'list' with either 'ordered list' or ''unordered set' to make the distinction clear. Note that we sometimes also use the word 'collection'. - Timothy Carey indicated support for this solution. He likes to see a better definition of pipelining. * OPEN :LI03: Action clarification Actions are not 'standalone' objects, they are part of a schedule definition. Timothy Carey suggests rewordings: s/Every Action referenced by a Schedule/Every Action contained in a Schedule/ s/Multiple Actions in the list/Multiple Actions contained as an ordered list/ s/Actions in different Schedules/Actions contained in different Schedules/ Check for lowercase action vs uppercase Action. - Juergen Schoenwaelder indicated support for these changes. * OPEN :LI04: Instruction tasks and friends Change 2.B on page 8 to read: B. Control Tasks implement the Control Protocol and communicate with the Controller. Search for occurances of Configuration Task; Instruction Task; Suppression Task; Capabilities Task; Logging Task and try to eliminate these terms. - Timothy Carey indicated support for this proposal. * OPEN :LI05: List of tasks available on a device There currently is no 'list' of tasks that are supported by a device anymore and we may have to put this back in so that a controller can learn about the capabilities of a measurement agent. We may need to better separate status information from capability information. * OPEN :LI06: Remove ma-task-role It seems ma-task-role does not serve any purpose since the role is hard wired in the registry already. It turns out that this is a misunderstanding. The metrics registry defines the set of possible roles, we still need to be able to (i) configure the role taken by a task/action and we need to be able to report which roles are supported (as part of the capability information). * OPEN :LI07: Add an ma-schedule-status-obj Define an ma-schedule-status-obj and hook it into the ma-status-obj. It should capture details, e.g., whether schedules are suppressed. - Timothy Carey indicated support for this proposal. We need to work out the details. * OPEN :LI08: Add status objects for elements that have a state. We should add more status objects that report the state of things that can have a state. In the current model, schedules can be suppressed so that should be reported. This issue seems to be a generalization of the previous issue. * OPEN :LI09: Unify the handling of suppression and disablement See the proposal posted to the mailing list. * OPEN :LI10: Reporting of the measurement point Section 5.4 of the framework (RFC 7594) has a bullet saying that the report includes the measurement point (RFC 7398) where the MA is located. The question is how it is configured whether the measurement point is included in the report. * OPEN :LI11: Handling of data send to parallel mode schedules If an action directions out to another schedule and the target schedule is using 'parallel' mode, does the output go to all actions listed in the schedule or only to the first one listed? --uAKRQypu60I7Lcqm-- From nobody Wed Sep 30 04:44:03 2015 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 03DB51B5D8D for ; Wed, 30 Sep 2015 04:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKJ117_d3Vm0 for ; Wed, 30 Sep 2015 04:43:59 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 218581B5D8A for ; Wed, 30 Sep 2015 04:43:58 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 71494D6A4AA2F; Wed, 30 Sep 2015 11:43:53 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t8UBhqHZ021655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Sep 2015 11:43:54 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 30 Sep 2015 07:43:52 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Review of draft-ietf-lmap-information-model-06: Action Destinations and tie with the Regisrry output Thread-Index: AQHQ9hbV28K6B38uwk+20lrSx4yoSJ5NTtcAgAZ/ZoCAASv44A== Date: Wed, 30 Sep 2015 11:43:51 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC25DF10@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC22D001@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923154438.GC2358@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC259120@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150929133519.GC99139@elstar.local> In-Reply-To: <20150929133519.GC99139@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action Destinations and tie with the Regisrry output 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, 30 Sep 2015 11:44:01 -0000 Juergen and Al, So given the results of the virtual meeting. Again thanks Al for the for ex= amples. I think we can resolve this activity with the following understandi= ng. A Metric in a registry entry will have at most 1 output. A task can have mu= ltiple registry entries so a scheduled action can have multiple outputs whi= ch, as Juergen noted in yesterday's meeting, will proceed to be inputs in t= he initial action(s) of the destination schedule. Is this a correct understanding? BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, September 29, 2015 8:35 AM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org; MORTON, ALFRED C (AL) Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action = Destinations and tie with the Regisrry output Tim, I think I do not understand your question. An action can choose to send its= output to other schedules. In other words, we have forward pointers indica= ting the data flow. You seem to ask for a backwards pointer which in my vie= w does not make much sense. But as I said, I am not sure I understand your = question. /js On Fri, Sep 25, 2015 at 02:23:21PM +0000, Carey, Timothy (Timothy) wrote: > Al, >=20 > So what do you think about how to link the ActionDestination of another S= chedule with the results of this Schedules Action? >=20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, September 23, 2015 10:45 AM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06:=20 > Action Destinations and tie with the Regisrry output >=20 > Tim, >=20 > the information model currently assumes that results are tagged. A task p= roducing multiple 'outputs' would tag them to distinguish them. >=20 > How all this links to the registry is, honestly speaking, somewhat=20 > unclear to me since I do not really understand how the registry itself=20 > works. It would help me a lot if draft-ietf-ippm-metric-registry-04 > would contain a collection of example registry entries. >=20 > /js >=20 > On Wed, Aug 05, 2015 at 02:06:24PM +0000, Carey, Timothy (Timothy) wrote: > > Juergen, > >=20 > > In previous information models we linked the Registry's outputs with th= e downstream tasks. > >=20 > > In LMAP IM-06 draft we now have a concept of an ActionDestination which= describes which schedules are invoked based on the task's output selection= . However we do not link back the task output to the ActionDestination via = parameter in the ActionDestination object (maybe called Output?). Did I mis= s understand the intent of the ActionDestination and its linkage? > >=20 > > BR, > > Tim >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 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 30 06:58:03 2015 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 1DE471A8741 for ; Wed, 30 Sep 2015 06:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTDxaT7Wan2U for ; Wed, 30 Sep 2015 06:57:59 -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 984301A874B for ; Wed, 30 Sep 2015 06:57:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 63F05EA3; Wed, 30 Sep 2015 15:57:58 +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 yfXC5qnO3EcK; Wed, 30 Sep 2015 15:57:57 +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, 30 Sep 2015 15:57:57 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B26D20053; Wed, 30 Sep 2015 15:57:57 +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 jDqCaS2IL5vh; Wed, 30 Sep 2015 15:57:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 228722004E; Wed, 30 Sep 2015 15:57:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E39023779357; Wed, 30 Sep 2015 15:57:55 +0200 (CEST) Date: Wed, 30 Sep 2015 15:57:55 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150930135755.GB25888@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" , "MORTON, ALFRED C (AL)" References: <9966516C6EB5FC4381E05BF80AA55F77DC22D001@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150923154438.GC2358@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC259120@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150929133519.GC99139@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC25DF10@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC25DF10@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Action Destinations and tie with the Regisrry output 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, 30 Sep 2015 13:58:01 -0000 On Wed, Sep 30, 2015 at 11:43:51AM +0000, Carey, Timothy (Timothy) wrote: > Juergen and Al, > > So given the results of the virtual meeting. Again thanks Al for the for examples. I think we can resolve this activity with the following understanding. > > A Metric in a registry entry will have at most 1 output. A task can have multiple registry entries so a scheduled action can have multiple outputs which, as Juergen noted in yesterday's meeting, will proceed to be inputs in the initial action(s) of the destination schedule. > > Is this a correct understanding? > I think so. And going a bit further, my understanding is that a single metric output can consist of a varying number of primitive values. /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 30 14:40:02 2015 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 CFAAF1A9109 for ; Wed, 30 Sep 2015 14:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IGSzfqjhxqs for ; Wed, 30 Sep 2015 14:40:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 56FC01A90E0 for ; Wed, 30 Sep 2015 14:39:59 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 85DF2A68397B5; Wed, 30 Sep 2015 21:39:53 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t8ULdtIH010684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Sep 2015 21:39:55 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 30 Sep 2015 17:39:50 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder , "lmap@ietf.org" Thread-Topic: [lmap] info model issues list Thread-Index: AQHQ+7JZ+zVJ5yg/MkKGWReJFzQzUJ5Vlx9A Date: Wed, 30 Sep 2015 21:39:52 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC25EC9C@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20150930104007.GD1699@elstar.local> In-Reply-To: <20150930104007.GD1699@elstar.local> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] info model issues 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: Wed, 30 Sep 2015 21:40:02 -0000 Juergen, I check this list against my list and have the following comments: Missing: We need to put back the [ma-condition-obj ma-conditions<..*> to al= low for conditions or status not specified by the IM. Missing: Could we add the issue for the IM to describe its interaction with= the registry - parameters, outputs, roles... LI05: When we talk about MA reporting its task capabilities - Could we note= that we have to report the Registry entry capabilities associated with the= task. I would suspect that for each supported task the capabilities (param= eters, outputs, roles) might change by MA. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, September 30, 2015 5:40 AM To: lmap@ietf.org Subject: [lmap] info model issues list Hi, here is a snapshot of my information model issues list after yesterday's me= eting. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103