From nobody Fri Jul 1 01:11:26 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DA912D50C; Fri, 1 Jul 2016 01:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 N9d6WNs4OK0k; Fri, 1 Jul 2016 01:11:16 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0094.outbound.protection.outlook.com [104.47.33.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59F512D1EA; Fri, 1 Jul 2016 01:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AluKMec2pchLJJ1M51kfG8H9UJ5O0DM7kgCdLMqm4rM=; b=O/1zfeZ2IfJnrB5XzGQgd20F2CptMZsC0zB/PuxbGiPmeZEwQs52VlmUkFk+wQ+lnXJCUmp+bb0F+jvSPQVKaFPARnDMHqe3SCSDXB6Lm3H3MQI56lNCbKh2+fVb1Ls4cIaK+sEeV6DI+E9rdgeqT/LMAPgcdwpwh/1oRBkcKh0= Received: from BY2PR0501MB2133.namprd05.prod.outlook.com (10.163.198.19) by BL2PR05MB930.namprd05.prod.outlook.com (10.242.198.140) with Microsoft SMTP Server (TLS) id 15.1.511.8; Fri, 1 Jul 2016 08:11:13 +0000 Received: from BY2PR0501MB2133.namprd05.prod.outlook.com ([10.163.198.19]) by BY2PR0501MB2133.namprd05.prod.outlook.com ([10.163.198.19]) with mapi id 15.01.0528.020; Fri, 1 Jul 2016 08:11:12 +0000 From: Srivathsa Sarangapani To: Gregory Mirsky , Brian Trammell , IETF IPPM WG Thread-Topic: [ippm] Draft Meeting Agenda for IPPM at IETF 96 Thread-Index: AQHR0rAunPzWWF42ekqrV8liuvwcJ6ACkuCAgAEEbAA= Date: Fri, 1 Jul 2016 08:11:12 +0000 Message-ID: <0A798FC9-3F45-4110-83D9-80CFB0B626BA@juniper.net> References: <7347100B5761DC41A166AC17F22DF11221ABE058@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221ABE058@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 authentication-results: spf=none (sender IP is ) smtp.mailfrom=srivathsas@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.10] x-ms-office365-filtering-correlation-id: 45fa0fe5-3745-4039-55a6-08d3a1874414 x-microsoft-exchange-diagnostics: 1; BL2PR05MB930; 5:B5gOfGFHvfkID8L4qWwtsZLinXRB5nZeFJGKWeq4xSfKSlbVtJRjpm9WIs18rnQD5d7EYNbyGMOPItX3rSgnLp4Ch6WcSgURPb3unWwZi6InzWRYmXZvdz6jkT04iOLryU6Ab1egx59XfNJodV0dwA==; 24:URWHay55IMs4vwStm+MixF8ZcuBr9Uc4DAH/dxkjLywwLWmTivz2Q09YfK16GtrdN2+iBfV9QgEP/k+faFFWn871AuoQfQAN/6xkmBOWExw=; 7:IgQI3MmrEV/UMGaLyps0upOetz6KGKipgzXmXfmCflapPmeyfiCtUVZyylNgK6yedlVEW/qbb2svtSD0MIht6n6/84xHh0thubgiKJLwMLH1xECmzuCWIaFhMCDCfpLKwbM9whKx7bVnQLyL4HrKorEBizzwEHfzu6soToujJIuvK/iVlWIPsNLi/uCP/AXWQBBvyBWg7fh3P68R6yRh5q1+qWgAqShUu/qKP8bEmN+5aRciMoNKkgfv+QYU0GGJ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR05MB930; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959)(138986009662008)(788757137089)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BL2PR05MB930; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB930; x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(497574002)(13464003)(22804003)(189002)(51914003)(16236675004)(19580395003)(50986999)(3846002)(82746002)(54356999)(3280700002)(19580405001)(87936001)(66066001)(19300405004)(122556002)(7906003)(10400500002)(83716003)(2950100001)(81156014)(5002640100001)(76176999)(15975445007)(101416001)(8676002)(83506001)(2900100001)(33656002)(36756003)(86362001)(586003)(5001770100001)(102836003)(4326007)(4001350100001)(189998001)(19617315012)(68736007)(345774005)(19625215002)(6116002)(8936002)(105586002)(106116001)(99286002)(106356001)(92566002)(81166006)(2906002)(7736002)(3660700001)(7846002)(77096005)(9326002)(97736004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB930; H:BY2PR0501MB2133.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_0A798FC93F45411083D980CFB0B626BAjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2016 08:11:12.3761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB930 Archived-At: Cc: Peyush Gupta , "rtg-ooam-dt@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] [ippm] Draft Meeting Agenda for IPPM at IETF 96 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 08:11:19 -0000 --_000_0A798FC93F45411083D980CFB0B626BAjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KVGhhbmtzIGZvciB0aGUgcmVwbHkuDQoNCkN1cnJlbnRseSBUV0FNUCBpcyB3 aWRlbHkgZGVwbG95ZWQgYnkgbG90IG9mIG9wZXJhdG9ycyB0byBtZWFzdXJlIFJUVC4gV2Ugd2Fu dCB0byBFRkZFQ1RJVkVMWSBleHRlbmQgdGhlIHVzZSBvZiBUV0FNUCB0byBhY2hpZXZlIGxvdCBt b3JlIGZ1bmN0aW9uYWxpdHkoYnkgdXNpbmcgdGhlIHBheWxvYWQgd2hpY2ggaXMgY3VycmVudGx5 IE5PVCB1c2VkKS4NCldlIGFyZSBjb25jZW50cmF0aW5nIG9uIHR3byBNZXRyaWNzOiBLZWVwYWxp dmVsZXNzIG9mIGEgZnVuY3Rpb25hbGl0eS9zZXJ2aWNlIGFuZCBTZXJ2aWNlIExhdGVuY3kgaW50 cm9kdWNlZCBieSBhIHNlcnZpY2UuDQoNCldoZW4gd2Ugc2F5IHNlcnZpY2UgaXQgbWVhbnMgYSBm dW5jdGlvbmFsaXR5LiBJdCBpcyBubyB3YXkgcmVsYXRlZCB0byBTRkMgT05MWS4gSSBjb3VsZCBz YXkgdGhhdCBib3RoIFNlY3Rpb24gMSAmIDIgb2YgZHJhZnQtc3B2LWlwcG0tbW9uaXRvci1pbXBs ZW1lbnRhdGlvbi1zZXJ2aWNlcy1rcGkgY291bGQgYmUgdXNlZCBpbiBTRkMgYWxzbyBidXQgdGhp cyBOT1QgRk9SIFNGQyBvbmx5Lg0KV2UgYXJlIHJlZmVycmluZyB0byBhIOKAnHNwZWNpZmljIGZ1 bmN0aW9uYWwgbW9kdWxl4oCdIGFzIGEgc2VydmljZS4gU28gZm9yIGV4YW1wbGUgd2hlbiB3ZSBz cGVhayBvZiBrZWVwYWxpdmVuZXNzIG9mIGEgc2VydmljZSwgRE5TIG9yIEhUVFAgQ09VTEQgYmUg cmVmZXJyZWQgYXMgYSBzZXJ2aWNlIGhlcmUuDQpTYXkgaWYgVFdBTVAgaXMgY3VycmVudGx5IGJl aW5nIHVzZWQgdG8gY2FsY3VsYXRlIHRoZSBydHQgYmV0d2VlbiBhIEhUVFAgc2VydmVyIGFuZCBz b21lIE5ldHdvcmsgRWxlbWVudCwgd2Ugd2FudCB0byBvdmVybG9hZC9waWdneWJhY2svZXh0ZW5k IFRXQU1QIHRvIGNoZWNrIGV2ZW4gdGhlIGxpdmVsaW5lc3Mgb2YgdGhlIEhUVFAgU2VydmljZS9G dW5jdGlvbmFsaXR5IG9uIHRoYXQgc2VydmVyLg0KSWYgdGhlIG5hbWUgc2VydmljZSBpcyBjb25m dXNpbmcsIHRoZW4gcG9zc2libHkgd2UgY291bGQgcmVwbGFjZSB0aGUgbmFtZSBzZXJ2aWNlIHdp dGggc29tZSBvdGhlciBuYW1lIGxpa2Ug4oCcQXBwbGljYXRpb24gRnVuY3Rpb25hbGl0eeKAnSBv ciBzb21ldGhpbmcgbGlrZSB0aGF0LiBQbGVhc2UgbGV0IHVzIGtub3cuDQoNCkkgY291bGQgc2Vl IHRoZSBldmVuIE9BTSB0b29sIFJGQyA3Mjc2IHJlZmVycyB0byBUV0FNUCB0byBjYWxjdWxhdGUg UlRULiBTaW1pbGFybHksIE9BTSBjYW4gcmVmZXIgdG8gdGhlc2UgZXh0ZW5zaW9uIGRyYWZ0cyBm b3IgY2FsY3VsYXRpbmcga2VlcGFsaXZlIGFuZCBzZXJ2aWNlIGxhdGVuY3kgZm9yIGEgcGFydGlj dWxhciBzZXJ2aWNlLg0KDQpSZWdhcmRpbmcgUkZDIDc1NTUsIEkgY291bGQgc2VlIHRoYXQgdGhp cyBpcyBtb3N0bHkgZGVhbGluZyB3aXRoIE1QTFMgbmV0d29ya3MgYW5kIGl0cyBvcGVyYXRpb25z LiBJIGNvdWxkIG5vdCBzZWUgdGhhdCB0aGlzIGlzIHVzZWQgdG8gY2FsY3VsYXRlIGxpdmVsaW5l c3Mgb3IgbGF0ZW5jeSBvZiBhbnkgb3RoZXIgc3BlY2lmaWMgZnVuY3Rpb25hbGl0eS4NCg0K4oCU DQpSZWdhcmRzLA0KVmF0aHNhDQoNCg0KRnJvbTogR3JlZ29yeSBNaXJza3kgPGdyZWdvcnkubWly c2t5QGVyaWNzc29uLmNvbT4NCkRhdGU6IEZyaWRheSwgSnVseSAxLCAyMDE2IGF0IDM6MzkgQU0N ClRvOiBTcml2YXRoc2EgU2FyYW5nYXBhbmkgPHNyaXZhdGhzYXNAanVuaXBlci5uZXQ+LCBCcmlh biBUcmFtbWVsbCA8aWV0ZkB0cmFtbWVsbC5jaD4sIElFVEYgSVBQTSBXRyA8aXBwbUBpZXRmLm9y Zz4NCkNjOiBQZXl1c2ggR3VwdGEgPHBleXVzaGdAanVuaXBlci5uZXQ+LCAibG1hcEBpZXRmLm9y ZyIgPGxtYXBAaWV0Zi5vcmc+LCAicnRnLW9vYW0tZHRAaWV0Zi5vcmciIDxydGctb29hbS1kdEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbaXBwbV0gRHJhZnQgTWVldGluZyBBZ2VuZGEgZm9yIElQ UE0gYXQgSUVURiA5Ng0KDQoNCkhpIFNyaXZhdGhzYSwNCg0KbXkgdW5kZXJzdGFuZGluZyBvZiB5 b3VyIHByb3Bvc2FscyBpcyB0aGF0IHlvdSB1c2UgVFdBTVAtVGVzdCBub3QgdG8gcGVyZm9ybSBh bnkgbWVhc3VyZW1lbnQgYnV0IHJhdGhlciB0byBjYXJyeSBvcGFxdWUsIGZvciBUV0FNUC1TZW5k ZXIgYW5kIFRXQU1QLVJlZmxlY3RvciwgZGF0YSB0byBiZSB1c2VkIGJ5IFNlcnZpY2UgRnVuY3Rp b24gKFNGKSBPQU0uIEFuZCBUV0FNUC1Db250cm9sIGlzIGV4dGVuZGVkIHRvIG5lZ290aWF0ZSB0 aGUgc2l6ZSBhbmQgdGhlICBpbnRlcnByZXRhdGlvbiBvZiB0aGF0IG9wYXF1ZSBwYXlsb2FkIG9u IGJlaGFsZiBvZiBTRiBPQU0uIFdoYXQgeW91J3ZlIHByb3Bvc2VkIGluIFNlY3Rpb24gMiBvZiBk cmFmdC1zcHYtaXBwbS1tb25pdG9yLWltcGxlbWVudGF0aW9uLXNlcnZpY2VzLWtwaSBpcyB2ZXJ5 IHNpbWlsYXIgdG8gaWRlYSBpbiBSRkMgNzU1NSBQcm94eSBNUExTIEVjaG8gUmVxdWVzdCBhbmQg YmVlbiBpbmNsdWRlZCBpbiBPdmVybGF5IE9BTSBSZXF1aXJlbWVudHM8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LW9vYW1kdC1ydGd3Zy1vb2FtLXJlcXVpcmVtZW50LTAwPiBhczoN Cg0KICAgUkVRIzE1OiBPdmVybGF5IE9BTSBNVVNUIGJlIGFibGUgdG8gdHJpZ2dlciBvbi1kZW1h bmQgRk0gd2l0aA0KDQogICAgICAgICAgICByZXNwb25zZXMgYmVpbmcgZGlyZWN0ZWQgdG93YXJk cyBpbml0aWF0b3Igb2Ygc3VjaCBwcm94eQ0KDQogICAgICAgICAgICByZXF1ZXN0Lg0KDQoNCg0K ICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgR3JlZw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwcG0gW21h aWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcml2YXRoc2EgU2FyYW5n YXBhbmkNClNlbnQ6IFRodXJzZGF5LCBKdW5lIDMwLCAyMDE2IDI6MTcgQU0NClRvOiBCcmlhbiBU cmFtbWVsbDsgSUVURiBJUFBNIFdHDQpDYzogUGV5dXNoIEd1cHRhOyBsbWFwQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW2lwcG1dIERyYWZ0IE1lZXRpbmcgQWdlbmRhIGZvciBJUFBNIGF0IElFVEYg OTYNCg0KDQoNCkhpIEJyYWluIGFuZCBCaWxsLA0KDQoNCg0KVGhhbmsgeW91IGZvciBzaGFyaW5n IHRoZSBhZ2VuZGEgZm9yIHRoZSB1cGNvbWluZyBJRVRGIGV2ZW50IGluIEJlcmxpbi4NCg0KV2Ug YXJlIGludGVyZXN0ZWQgaW4gcHJlc2VudGluZyBvdXIgZHJhZnQgb24gVFdBTVAgZXh0ZW5zaW9u IGZvciBtb25pdG9yaW5nIHNlcnZpY2VzIEtQSSA6DQoNCltkcmFmdC1zcHYtaXBwbS1tb25pdG9y LW1ldGhvZG9sb2d5LXNlcnZpY2VzLWtwaSAmIGRyYWZ0LXNwdi1pcHBtLW1vbml0b3ItaW1wbGVt ZW50YXRpb24tc2VydmljZXMta3BpXQ0KDQoNCg0KV2UgaGF2ZSBnb3QgbG90IG9mIGNvbW1lbnRz IGluIHRoZSBsYXN0IGlldGYgbWVldGluZyBmcm9tIHRoZSBtZW1iZXJzIGluIG9yZGVyIHRvIG1h a2UgdGhlc2UgZHJhZnQgbW9yZSBmb2N1c2VkIGFuZCBkZXRhaWxlZC4NCg0KV2UgaGF2ZSBoYWQg bXVsdGlwbGUgZGlzY3Vzc2lvbiB3aXRoIG1vc3Qgb2YgdGhlIG1lbWJlcnMvY3VzdG9tZXJzIG9m ZmxpbmUgYW5kIGFmdGVyIHRoYXQgd2UgaGF2ZSBtb2RpZmllZCB0aGUgZHJhZnQgYW5kIGFkZHJl c3NlcyBtb3N0IG9mIHRoZSBjb25jZXJucyBmcm9tIHRoZW0uDQoNCg0KDQpQbGVhc2UgcHJvdmlk ZSB1cyBhIHNsb3QgaW4gdGhlIG1pZGRsZSBvZiB0aGUgaXBwbSBXRyB0aGlzIHRpbWUsIHNvIHRo YXQgd2UgY2FuIGRpc2N1c3MgdGhlIHJldmlzZWQgZHJhZnQgd2l0aCBhbGwgdGhlIGF0dGVuZGVl cyBhbmQgYWRkcmVzcyB0aGVpciBjb25jZXJucyBpZiBhbnkuDQoNCg0KDQpUaGlzIHdpbGwgaGVs cCB1cyBpbiB0YWtpbmcgb3VyIGRyYWZ0cyBmb3J3YXJkLg0KDQoNCg0KVGhhbmsgeW91IGZvciB5 b3VyIGF0dGVudGlvbi4NCg0KDQoNCuKAlA0KDQpCZXN0IFJlZ2FyZHMsDQoNClNyaXZhdGhzYSBT YXJhbmdhcGFuaQ0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206 IEJyaWFuIFRyYW1tZWxsIDxpZXRmQHRyYW1tZWxsLmNoPG1haWx0bzppZXRmQHRyYW1tZWxsLmNo Pj4NCg0KRGF0ZTogTW9uZGF5LCBKdW5lIDI3LCAyMDE2IGF0IDI6NTggUE0NCg0KVG86IElFVEYg SVBQTSBXRyA8aXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4+DQoNCkNjOiA8bG1h cEBpZXRmLm9yZzxtYWlsdG86bG1hcEBpZXRmLm9yZz4+DQoNClN1YmplY3Q6IFtpcHBtXSBEcmFm dCBNZWV0aW5nIEFnZW5kYSBmb3IgSVBQTSBhdCBJRVRGIDk2DQoNCg0KDQpHcmVldGluZ3MsIGFs bCwNCg0KDQoNCldlJ3ZlIHBvc3RlZCBhIGRyYWZ0IG1lZXRpbmcgYWdlbmRhIGF0IGh0dHBzOi8v d3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2L2FnZW5kYS9hZ2VuZGEtOTYtaXBwbSAoY29waWVk IGlubGluZSBiZWxvdykgd2l0aCBwcmVzZW50YXRpb25zIGZvciB3b3JraW5nIGdyb3VwIGl0ZW1z IChmaXZlLCBpbmNsdWRpbmcgdGhyZWUgbmV3bHkgYWRvcHRlZCkgYW5kIGluZGl2aWR1YWwgZHJh ZnRzIGRpc2N1c3NlZCBvbiBsaXN0IHNpbmNlIEJ1ZW5vcyBBaXJlcyAobm9uZSB0aGlzIHRpbWUg YXJvdW5kKS4NCg0KDQoNCldlJ2QgbGlrZSB0byBmb2N1cyBkaXNjdXNzaW9uIG9uIHRoZSBpbml0 aWFsIHJlZ2lzdHJ5IGRyYWZ0IHRoaXMgdGltZSBhcm91bmQsIHNpbmNlIHdlIHJlYWxseSBzaG91 bGQgY29tcGxldGUgdGhpcyBkb2N1bWVudCBpbiBvcmRlciB0byBmaW5pc2ggb3VyIGNoYXJ0ZXJl ZCB3b3JrIG9uIHByb3ZpZGluZyBhIGJhc2lzIGZvciB1c2luZyBJUFBNIG1ldHJpY3MgaW4gd2lk ZXIgbWVhc3VyZW1lbnQgZWZmb3J0cy4gVG8gdGhhdCBlbmQsIHdlJ2xsIGFsc28gaGF2ZSBhbiBp bnZpdGVkIHNwZWFrZXIsIEFobWVkIEFsZGFiYmFnaCBvZiBPRkNPTSwgc3BlYWtpbmcgb24gUW9T IG1vbml0b3JpbmcgYWN0aXZpdHkgYXQgQkVSRUMgKHRoZSBFdXJvcGVhbiB0ZWxlY29tcyByZWd1 bGF0aW9uIGNvb3JkaW5hdGlvbiBib2R5KTsgdGhpcyByZXByZXNlbnRzIGEga2V5IGF1ZGllbmNl IGFuZCB1c2VyIGNvbW11bml0eSBmb3IgdGhpcyByZWdpc3RyeS4gV2UnbGwgYWxzbyByZXNlcnZl IDI1IG1pbnV0ZXMgZm9yIGluaXRpYWwgcmVnaXN0cnkgZGlzY3Vzc2lvbi4NCg0KDQoNCkxNQVAg cGVvcGxlIChpbiBDQykgd2hvIGhhdmVuJ3QgcGFpZCBtdWNoIGF0dGVudGlvbiBvZiBJUFBNIG9m IGxhdGU6IGlmIHlvdSBoYXZlIG9waW5pb25zIGFib3V0IHdoYXQgc2hvdWxkIHNob3cgdXAgaW4g dGhlIGluaXRpYWwgcmVnaXN0cnksIHBsZWFzZSB0cnkgdG8gZHJvcCBieSB0aGUgSVBQTSBtZWV0 aW5nIGluIEJlcmxpbi4gVGhlIGludml0ZWQgdGFsayBtYXkgYWxzbyBiZSBvZiBpbnRlcmVzdCB0 byB5b3UuDQoNCg0KDQpZb3UnbGwgbm90ZSB0d28gKCopIG9uIHRoZSBhZ2VuZGE6IHRoZXNlIGFy ZSBwcm92aXNpb25hbCBzbG90cyBwZW5kaW5nIHN1Ym1pc3Npb24gb2YgdGhlIGRyYWZ0cyBiZWZv cmUgdGhlIGRlYWRsaW5lLiBPdGhlcndpc2UsIHdlJ2xsIHJlbW92ZSB0aGVzZSBzbG90cyBmcm9t IHRoZSBzY2hlZHVsZS4NCg0KDQoNCkRyYWZ0IGF1dGhvcnM6IHBsZWFzZSBsZXQgdXMga25vdyBp ZiB3ZSd2ZSBnb3QgdGhlIHJpZ2h0IHNwZWFrZXIgbmFtZSBuZXh0IHRvIGVhY2ggaXRlbS4NCg0K DQoNClRoYW5rcywgY2hlZXJzLA0KDQoNCg0KQnJpYW4gYW5kIEJpbGwgKGNoYWlyIGhhdHMpDQoN Cg0KDQoNCg0KDQoNCklQUE0gQWdlbmRhIC0gSUVURiA5NiAtIEJlcmxpbiwgR2VybWFueQ0KDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNClR1ZSAxOSBKdWx5 IDIwMTYgLSAxNDowMCBDZW50cmFsIEV1cm9wZWFuIFN1bW1lciBUaW1lIChVVEMrMikNCg0KDQoN Ck1haW4gQWdlbmRhDQoNCi0tLS0tLS0tLS0tDQoNCg0KDQpUaW1lICB8IFNwZWFrZXIgICAgICB8 IEl0ZW0NCg0KLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KMTQ6MDAgfCBDaGFpcnMgICAgICAgfCBO b3RlIHdlbGwsIGludHJvLCBzdGF0dXMsIGFnZW5kYSBiYXNoDQoNCjE0OjEwIHwgQS4gQWxkYWJi YWdoIHwgSW52aXRlZCBUYWxrOiBRb1MgTW9uaXRvcmluZyBBY3Rpdml0eSBhdCBCRVJFQw0KDQox NDoyNSB8IEEuIE1vcnRvbiAgICB8IGRyYWZ0LWlldGYtaXBwbS1pbml0aWFsLXJlZ2lzdHJ5DQoN CjE0OjUwIHwgSi4gRmFiaW5pICAgIHwgZHJhZnQtaWV0Zi1pcHBtLTIzMzAtaXB2NiAoKikNCg0K MTU6MDUgfCBHLiBNaXJza3kgICAgfCBkcmFmdC1pZXRmLWlwcG0tdHdhbXAtdGltZS1mb3JtYXQN Cg0KMTU6MTUgfCBHLiBGb2NjaW9sYSAgfCBkcmFmdC1pZXRmLWlwcG0tYWx0LW1hcmsNCg0KMTU6 MzAgfCBBLiBNb3J0b24gICAgfCBkcmFmdC1pZWZ0LWlwcG0tbW9kZWwtYmFzZWQtbWV0cmljcyAo KikNCg0KDQoNCkxpZ2h0bmluZyBUYWxrcw0KDQotLS0tLS0tLS0tLS0tLS0NCg0KDQoNCkZpdmUg bWludXRlcyBwZXIgdG9waWMgKHN0cmljdCksIHdpdGggYXZhaWxhYmxlIHRpbWUgYXQgdGhlIGVu ZCBvZiB0aGUNCg0KbWFpbiBhZ2VuZGEuDQoNCg0KDQpTcGVha2VyICAgICAgfCBJdGVtDQoNCi0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNClIuIEdlaWIgICAgICB8IGRyYWZ0LWxlaXBuaXR6LXNwcmlu Zy1wbXMtaW1wbGVtZW50YXRpb24tcmVwb3J0LTAwDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KaXBwbSBtYWlsaW5nIGxpc3QNCg0K aXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQo= --_000_0A798FC93F45411083D980CFB0B626BAjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseTpUYWhvbWE7fQ0Kc3Bhbi5QbGFp blRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1p bHk6Q2FsaWJyaTt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseTpUYWhvbWE7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSBHcmVnLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSByZXBseS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q3VycmVudGx5IFRXQU1QIGlzIHdpZGVseSBkZXBsb3llZCBi eSBsb3Qgb2Ygb3BlcmF0b3JzIHRvIG1lYXN1cmUgUlRULiBXZSB3YW50IHRvIEVGRkVDVElWRUxZ IGV4dGVuZCB0aGUgdXNlIG9mIFRXQU1QIHRvIGFjaGlldmUgbG90IG1vcmUgZnVuY3Rpb25hbGl0 eShieSB1c2luZyB0aGUgcGF5bG9hZCB3aGljaCBpcyBjdXJyZW50bHkgTk9UIHVzZWQpLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgYXJlIGNvbmNlbnRyYXRpbmcgb24g dHdvIE1ldHJpY3M6IEtlZXBhbGl2ZWxlc3Mgb2YgYSBmdW5jdGlvbmFsaXR5L3NlcnZpY2UgYW5k IFNlcnZpY2UgTGF0ZW5jeSBpbnRyb2R1Y2VkIGJ5IGEgc2VydmljZS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2hlbiB3ZSBzYXkgc2VydmljZSBpdCBtZWFucyBhIGZ1bmN0aW9uYWxpdHkuIEl0 IGlzIG5vIHdheSByZWxhdGVkIHRvIFNGQyBPTkxZLiBJIGNvdWxkIHNheSB0aGF0IGJvdGggU2Vj dGlvbiAxICZhbXA7IDIgb2YgZHJhZnQtc3B2LWlwcG0tbW9uaXRvci1pbXBsZW1lbnRhdGlvbi1z ZXJ2aWNlcy1rcGkgY291bGQgYmUgdXNlZCBpbiBTRkMgYWxzbyBidXQgdGhpcyBOT1QgRk9SIFNG QyBvbmx5LjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFyZSByZWZlcnJpbmcgdG8gYSDi gJxzcGVjaWZpYyBmdW5jdGlvbmFsIG1vZHVsZeKAnSBhcyBhIHNlcnZpY2UuIFNvIGZvciBleGFt cGxlIHdoZW4gd2Ugc3BlYWsgb2Yga2VlcGFsaXZlbmVzcyBvZiBhIHNlcnZpY2UsIEROUyBvciBI VFRQIENPVUxEIGJlIHJlZmVycmVkIGFzIGEgc2VydmljZSBoZXJlLg0KPC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2F5IGlmIFRXQU1QIGlzIGN1cnJlbnRseSBiZWluZyB1c2VkIHRvIGNhbGN1 bGF0ZSB0aGUgcnR0IGJldHdlZW4gYSBIVFRQIHNlcnZlciBhbmQgc29tZSBOZXR3b3JrIEVsZW1l bnQsIHdlIHdhbnQgdG8gb3ZlcmxvYWQvcGlnZ3liYWNrL2V4dGVuZCBUV0FNUCB0byBjaGVjayBl dmVuIHRoZSBsaXZlbGluZXNzIG9mIHRoZSBIVFRQIFNlcnZpY2UvRnVuY3Rpb25hbGl0eSBvbiB0 aGF0IHNlcnZlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBu YW1lIHNlcnZpY2UgaXMgY29uZnVzaW5nLCB0aGVuIHBvc3NpYmx5IHdlIGNvdWxkIHJlcGxhY2Ug dGhlIG5hbWUgc2VydmljZSB3aXRoIHNvbWUgb3RoZXIgbmFtZSBsaWtlIOKAnEFwcGxpY2F0aW9u IEZ1bmN0aW9uYWxpdHnigJ0gb3Igc29tZXRoaW5nIGxpa2UgdGhhdC4gUGxlYXNlIGxldCB1cyBr bm93LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGNvdWxkIHNlZSB0aGUgZXZlbiBPQU0gdG9v bCBSRkMgNzI3NiByZWZlcnMgdG8gVFdBTVAgdG8gY2FsY3VsYXRlIFJUVC4gU2ltaWxhcmx5LCBP QU0gY2FuIHJlZmVyIHRvIHRoZXNlIGV4dGVuc2lvbiBkcmFmdHMgZm9yIGNhbGN1bGF0aW5nIGtl ZXBhbGl2ZSBhbmQgc2VydmljZSBsYXRlbmN5IGZvciBhIHBhcnRpY3VsYXIgc2VydmljZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkaW5nIFJGQyA3NTU1LCBJIGNvdWxkIHNlZSB0aGF0 IHRoaXMgaXMgbW9zdGx5IGRlYWxpbmcgd2l0aCBNUExTIG5ldHdvcmtzIGFuZCBpdHMgb3BlcmF0 aW9ucy4gSSBjb3VsZCBub3Qgc2VlIHRoYXQgdGhpcyBpcyB1c2VkIHRvIGNhbGN1bGF0ZSBsaXZl bGluZXNzIG9yIGxhdGVuY3kgb2YgYW55IG90aGVyIHNwZWNpZmljIGZ1bmN0aW9uYWxpdHkuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPuKAlCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5WYXRoc2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+R3JlZ29yeSBNaXJza3kgJmx0O2dyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBKdWx5IDEsIDIwMTYgYXQgMzozOSBBTTxicj4NCjxiPlRv OiA8L2I+U3JpdmF0aHNhIFNhcmFuZ2FwYW5pICZsdDtzcml2YXRoc2FzQGp1bmlwZXIubmV0Jmd0 OywgQnJpYW4gVHJhbW1lbGwgJmx0O2lldGZAdHJhbW1lbGwuY2gmZ3Q7LCBJRVRGIElQUE0gV0cg Jmx0O2lwcG1AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5QZXl1c2ggR3VwdGEgJmx0O3Bl eXVzaGdAanVuaXBlci5uZXQmZ3Q7LCAmcXVvdDtsbWFwQGlldGYub3JnJnF1b3Q7ICZsdDtsbWFw QGlldGYub3JnJmd0OywgJnF1b3Q7cnRnLW9vYW0tZHRAaWV0Zi5vcmcmcXVvdDsgJmx0O3J0Zy1v b2FtLWR0QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogW2lwcG1dIERyYWZ0 IE1lZXRpbmcgQWdlbmRhIGZvciBJUFBNIGF0IElFVEYgOTY8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IaSBTcml2YXRo c2EsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5teSB1bmRlcnN0YW5k aW5nIG9mIHlvdXIgcHJvcG9zYWxzIGlzIHRoYXQgeW91IHVzZSBUV0FNUC1UZXN0IG5vdCB0byBw ZXJmb3JtIGFueSBtZWFzdXJlbWVudCBidXQgcmF0aGVyIHRvIGNhcnJ5IG9wYXF1ZSwgZm9yIFRX QU1QLVNlbmRlciBhbmQgVFdBTVAtUmVmbGVjdG9yLCBkYXRhIHRvIGJlIHVzZWQgYnkgU2Vydmlj ZSBGdW5jdGlvbiAoU0YpIE9BTS4gQW5kIFRXQU1QLUNvbnRyb2wgaXMgZXh0ZW5kZWQNCiB0byBu ZWdvdGlhdGUgdGhlIHNpemUgYW5kIHRoZSAmbmJzcDtpbnRlcnByZXRhdGlvbiBvZiB0aGF0IG9w YXF1ZSBwYXlsb2FkIG9uIGJlaGFsZiBvZiBTRiBPQU0uIFdoYXQgeW91J3ZlIHByb3Bvc2VkIGlu IFNlY3Rpb24gMiBvZiBkcmFmdC1zcHYtaXBwbS1tb25pdG9yLWltcGxlbWVudGF0aW9uLXNlcnZp Y2VzLWtwaSBpcyB2ZXJ5IHNpbWlsYXIgdG8gaWRlYSBpbiBSRkMgNzU1NSBQcm94eSBNUExTIEVj aG8gUmVxdWVzdCBhbmQgYmVlbiBpbmNsdWRlZA0KIGluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1vb2FtZHQtcnRnd2ctb29hbS1yZXF1aXJlbWVudC0wMCI+DQpP dmVybGF5IE9BTSBSZXF1aXJlbWVudHM8L2E+IGFzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFJFUSMxNTogT3ZlcmxheSBPQU0gTVVTVCBiZSBh YmxlIHRvIHRyaWdnZXIgb24tZGVtYW5kIEZNIHdpdGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNwb25zZXMgYmVpbmcgZGlyZWN0ZWQgdG93YXJk cyBpbml0aWF0b3Igb2Ygc3VjaCBwcm94eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlcXVlc3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9t OiBpcHBtIFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3JpdmF0 aHNhIFNhcmFuZ2FwYW5pPGJyPg0KU2VudDogVGh1cnNkYXksIEp1bmUgMzAsIDIwMTYgMjoxNyBB TTxicj4NClRvOiBCcmlhbiBUcmFtbWVsbDsgSUVURiBJUFBNIFdHPGJyPg0KQ2M6IFBleXVzaCBH dXB0YTsgbG1hcEBpZXRmLm9yZzxicj4NClN1YmplY3Q6IFJlOiBbaXBwbV0gRHJhZnQgTWVldGlu ZyBBZ2VuZGEgZm9yIElQUE0gYXQgSUVURiA5NjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5IaSBCcmFpbiBhbmQgQmlsbCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmsg eW91IGZvciBzaGFyaW5nIHRoZSBhZ2VuZGEgZm9yIHRoZSB1cGNvbWluZyBJRVRGIGV2ZW50IGlu IEJlcmxpbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldlIGFyZSBp bnRlcmVzdGVkIGluIHByZXNlbnRpbmcgb3VyIGRyYWZ0IG9uIFRXQU1QIGV4dGVuc2lvbiBmb3Ig bW9uaXRvcmluZyBzZXJ2aWNlcyBLUEkgOg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5bZHJhZnQtc3B2LWlwcG0tbW9uaXRvci1tZXRob2RvbG9neS1zZXJ2aWNlcy1r cGkgJmFtcDsgZHJhZnQtc3B2LWlwcG0tbW9uaXRvci1pbXBsZW1lbnRhdGlvbi1zZXJ2aWNlcy1r cGldPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldlIGhhdmUgZ290IGxvdCBvZiBjb21t ZW50cyBpbiB0aGUgbGFzdCBpZXRmIG1lZXRpbmcgZnJvbSB0aGUgbWVtYmVycyBpbiBvcmRlciB0 byBtYWtlIHRoZXNlIGRyYWZ0IG1vcmUgZm9jdXNlZCBhbmQgZGV0YWlsZWQuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XZSBoYXZlIGhhZCBtdWx0aXBsZSBkaXNjdXNz aW9uIHdpdGggbW9zdCBvZiB0aGUgbWVtYmVycy9jdXN0b21lcnMgb2ZmbGluZSBhbmQgYWZ0ZXIg dGhhdCB3ZSBoYXZlIG1vZGlmaWVkIHRoZSBkcmFmdCBhbmQgYWRkcmVzc2VzIG1vc3Qgb2YgdGhl IGNvbmNlcm5zIGZyb20gdGhlbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGxlYXNl IHByb3ZpZGUgdXMgYSBzbG90IGluIHRoZSBtaWRkbGUgb2YgdGhlIGlwcG0gV0cgdGhpcyB0aW1l LCBzbyB0aGF0IHdlIGNhbiBkaXNjdXNzIHRoZSByZXZpc2VkIGRyYWZ0IHdpdGggYWxsIHRoZSBh dHRlbmRlZXMgYW5kIGFkZHJlc3MgdGhlaXIgY29uY2VybnMgaWYgYW55LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5UaGlzIHdpbGwgaGVscCB1cyBpbiB0YWtpbmcgb3VyIGRyYWZ0cyBm b3J3YXJkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFuayB5b3UgZm9yIHlvdXIg YXR0ZW50aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij7igJQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlNyaXZhdGhzYSBTYXJhbmdhcGFuaTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5Gcm9tOiBCcmlhbiBUcmFtbWVsbCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmlldGZAdHJhbW1lbGwuY2giPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lIj5pZXRmQHRyYW1tZWxsLmNoPC9zcGFuPjwvYT4mZ3Q7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5EYXRlOiBNb25kYXksIEp1bmUgMjcsIDIw MTYgYXQgMjo1OCBQTTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VG86 IElFVEYgSVBQTSBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5pcHBtQGlldGYub3Jn PC9zcGFuPjwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5D YzogJmx0OzxhIGhyZWY9Im1haWx0bzpsbWFwQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bG1hcEBpZXRmLm9yZzwvc3Bhbj48L2E+ Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3ViamVjdDogW2lw cG1dIERyYWZ0IE1lZXRpbmcgQWdlbmRhIGZvciBJUFBNIGF0IElFVEYgOTY8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+R3JlZXRpbmdzLCBhbGwsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPldlJ3ZlIHBvc3RlZCBhIGRyYWZ0IG1lZXRpbmcgYWdlbmRhIGF0IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2L2FnZW5kYS9hZ2VuZGEtOTYtaXBwbSI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvYWdlbmRhL2FnZW5kYS05Ni1pcHBtPC9z cGFuPjwvYT4gKGNvcGllZCBpbmxpbmUgYmVsb3cpIHdpdGggcHJlc2VudGF0aW9ucyBmb3Igd29y a2luZyBncm91cCBpdGVtcyAoZml2ZSwgaW5jbHVkaW5nIHRocmVlIG5ld2x5IGFkb3B0ZWQpIGFu ZCBpbmRpdmlkdWFsIGRyYWZ0cyBkaXNjdXNzZWQgb24NCiBsaXN0IHNpbmNlIEJ1ZW5vcyBBaXJl cyAobm9uZSB0aGlzIHRpbWUgYXJvdW5kKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ V2UnZCBsaWtlIHRvIGZvY3VzIGRpc2N1c3Npb24gb24gdGhlIGluaXRpYWwgcmVnaXN0cnkgZHJh ZnQgdGhpcyB0aW1lIGFyb3VuZCwgc2luY2Ugd2UgcmVhbGx5IHNob3VsZCBjb21wbGV0ZSB0aGlz IGRvY3VtZW50IGluIG9yZGVyIHRvIGZpbmlzaCBvdXIgY2hhcnRlcmVkIHdvcmsgb24gcHJvdmlk aW5nIGEgYmFzaXMgZm9yIHVzaW5nIElQUE0gbWV0cmljcyBpbiB3aWRlciBtZWFzdXJlbWVudCBl ZmZvcnRzLg0KIFRvIHRoYXQgZW5kLCB3ZSdsbCBhbHNvIGhhdmUgYW4gaW52aXRlZCBzcGVha2Vy LCBBaG1lZCBBbGRhYmJhZ2ggb2YgT0ZDT00sIHNwZWFraW5nIG9uIFFvUyBtb25pdG9yaW5nIGFj dGl2aXR5IGF0IEJFUkVDICh0aGUgRXVyb3BlYW4gdGVsZWNvbXMgcmVndWxhdGlvbiBjb29yZGlu YXRpb24gYm9keSk7IHRoaXMgcmVwcmVzZW50cyBhIGtleSBhdWRpZW5jZSBhbmQgdXNlciBjb21t dW5pdHkgZm9yIHRoaXMgcmVnaXN0cnkuIFdlJ2xsIGFsc28gcmVzZXJ2ZQ0KIDI1IG1pbnV0ZXMg Zm9yIGluaXRpYWwgcmVnaXN0cnkgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+TE1BUCBwZW9wbGUgKGluIENDKSB3aG8gaGF2ZW4ndCBwYWlkIG11Y2ggYXR0ZW50aW9u IG9mIElQUE0gb2YgbGF0ZTogaWYgeW91IGhhdmUgb3BpbmlvbnMgYWJvdXQgd2hhdCBzaG91bGQg c2hvdyB1cCBpbiB0aGUgaW5pdGlhbCByZWdpc3RyeSwgcGxlYXNlIHRyeSB0byBkcm9wIGJ5IHRo ZSBJUFBNIG1lZXRpbmcgaW4gQmVybGluLiBUaGUgaW52aXRlZCB0YWxrIG1heSBhbHNvIGJlIG9m IGludGVyZXN0IHRvDQogeW91LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Zb3UnbGwg bm90ZSB0d28gKCopIG9uIHRoZSBhZ2VuZGE6IHRoZXNlIGFyZSBwcm92aXNpb25hbCBzbG90cyBw ZW5kaW5nIHN1Ym1pc3Npb24gb2YgdGhlIGRyYWZ0cyBiZWZvcmUgdGhlIGRlYWRsaW5lLiBPdGhl cndpc2UsIHdlJ2xsIHJlbW92ZSB0aGVzZSBzbG90cyBmcm9tIHRoZSBzY2hlZHVsZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RHJhZnQgYXV0aG9yczogcGxlYXNlIGxldCB1cyBrbm93 IGlmIHdlJ3ZlIGdvdCB0aGUgcmlnaHQgc3BlYWtlciBuYW1lIG5leHQgdG8gZWFjaCBpdGVtLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3MsIGNoZWVycyw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+QnJpYW4gYW5kIEJpbGwgKGNoYWlyIGhhdHMpPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5J UFBNIEFnZW5kYSAtIElFVEYgOTYgLSBCZXJsaW4sIEdlcm1hbnk8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UdWUgMTkgSnVseSAyMDE2IC0gMTQ6 MDAgQ2VudHJhbCBFdXJvcGVhbiBTdW1tZXIgVGltZSAoVVRDJiM0MzsyKTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5NYWluIEFnZW5kYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+LS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGlt ZSZuYnNwOyB8IFNwZWFrZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBJdGVtPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLS0mIzQzOy0tLS0tLS0t LS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4xNDowMCB8 IENoYWlycyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IE5vdGUgd2VsbCwg aW50cm8sIHN0YXR1cywgYWdlbmRhIGJhc2g8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjE0OjEwIHwgQS4gQWxkYWJiYWdoIHwgSW52aXRlZCBUYWxrOiBRb1MgTW9uaXRv cmluZyBBY3Rpdml0eSBhdCBCRVJFQzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+MTQ6MjUgfCBBLiBNb3J0b24mbmJzcDsmbmJzcDsmbmJzcDsgfCBkcmFmdC1pZXRmLWlw cG0taW5pdGlhbC1yZWdpc3RyeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+MTQ6NTAgfCBKLiBGYWJpbmkmbmJzcDsmbmJzcDsmbmJzcDsgfCBkcmFmdC1pZXRmLWlwcG0t MjMzMC1pcHY2ICgqKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MTU6 MDUgfCBHLiBNaXJza3kmbmJzcDsmbmJzcDsmbmJzcDsgfCBkcmFmdC1pZXRmLWlwcG0tdHdhbXAt dGltZS1mb3JtYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjE1OjE1 IHwgRy4gRm9jY2lvbGEmbmJzcDsgfCBkcmFmdC1pZXRmLWlwcG0tYWx0LW1hcms8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjE1OjMwIHwgQS4gTW9ydG9uJm5ic3A7Jm5i c3A7Jm5ic3A7IHwgZHJhZnQtaWVmdC1pcHBtLW1vZGVsLWJhc2VkLW1ldHJpY3MgKCopPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkxpZ2h0bmluZyBUYWxrczxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkZpdmUgbWludXRlcyBwZXIgdG9waWMgKHN0cmljdCksIHdpdGggYXZhaWxh YmxlIHRpbWUgYXQgdGhlIGVuZCBvZiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPm1haW4gYWdlbmRhLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TcGVh a2VyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgSXRlbTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SLiBHZWliJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwO3wgZHJhZnQtbGVpcG5pdHotc3ByaW5nLXBtcy1pbXBsZW1lbnRhdGlvbi1y ZXBvcnQtMDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+aXBwbSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aXBwbUBpZXRmLm9yZzwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwcG08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0A798FC93F45411083D980CFB0B626BAjunipernet_-- From nobody Tue Jul 5 05:02:53 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6976812D1E3 for ; Tue, 5 Jul 2016 05:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.345 X-Spam-Level: X-Spam-Status: No, score=-8.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 yvcjd67-izfR for ; Tue, 5 Jul 2016 05:02:50 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 8C58A12D1E6 for ; Tue, 5 Jul 2016 05:02:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2F3AgBKoXtX/yYyC4ddHoJSIS1WgQK3L?= =?us-ascii?q?IIPgXcihXYCgTg4FAEBAQEBAQEDYhwLgkEiFxABAQEBAQFPAj4xAxIbXgEMCRV?= =?us-ascii?q?WJgEEGxqIDgENmlqFEpl7AQoBAQEeBYYoiQ6DKoIvBZkTAZAwhFaDIoVIkAoeN?= =?us-ascii?q?oNwiGgBfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2F3AgBKoXtX/yYyC4ddHoJSIS1WgQK3LIIPgXcihXYCgTg?= =?us-ascii?q?4FAEBAQEBAQEDYhwLgkEiFxABAQEBAQFPAj4xAxIbXgEMCRVWJgEEGxqIDgENm?= =?us-ascii?q?lqFEpl7AQoBAQEeBYYoiQ6DKoIvBZkTAZAwhFaDIoVIkAoeNoNwiGgBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,579,1459828800"; d="scan'208,217";a="160972730" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Jul 2016 08:02:41 -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/AES256-SHA; 05 Jul 2016 08:02:41 -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, 5 Jul 2016 14:02:40 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP WG at IETF 96 - preliminary agenda Thread-Index: AdHWtSAKzTrK9SmIQwep/GQSYxIubQ== Date: Tue, 5 Jul 2016 12:02:38 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7522CD62@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_9904FB1B0159DA42B0B887B7FA8119CA7522CD62AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP WG at IETF 96 - preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 12:02:51 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA7522CD62AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have uploaded a preliminary agenda for the LMAP WG meeting at IETF 96 at: https://www.ietf.org/proceedings/96/agenda/agenda-96-lmap Please let us know if you need any changes, or if there are other topics yo= u would like to discuss. Thanks and Regards, Jason and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA7522CD62AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have uploaded a preliminary agenda for the LMAP WG= meeting at IETF 96 at:

 

https://www.ietf.org/proceedings/96/agenda/agenda-96-lmap=

 

Please let us know if you need any changes, or if th= ere are other topics you would like to discuss.

 

Thanks and Regards,

 

Jason and Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA7522CD62AZFFEXMB04globa_-- From nobody Tue Jul 5 05:04:44 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538A812D1E3 for ; Tue, 5 Jul 2016 05:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.325 X-Spam-Level: X-Spam-Status: No, score=-8.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 MkIBmFkCz-73 for ; Tue, 5 Jul 2016 05:04:41 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (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 2CD3812D0A8 for ; Tue, 5 Jul 2016 05:04:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HxAQDkoXtX/xUHmMZdHQGCUiEtVoECj?= =?us-ascii?q?SSqCIIPgXeGGAKBODgUAQEBAQEBAQNiHAuEUAMSG14BDAkVViYBBBsaiA4Bmma?= =?us-ascii?q?FEpl7DAEkhiiJDoMqgi8FmRMBmCiFSJAKHjaCCByBTIhoAX4BAQE?= X-IPAS-Result: =?us-ascii?q?A2HxAQDkoXtX/xUHmMZdHQGCUiEtVoECjSSqCIIPgXeGGAK?= =?us-ascii?q?BODgUAQEBAQEBAQNiHAuEUAMSG14BDAkVViYBBBsaiA4BmmaFEpl7DAEkhiiJD?= =?us-ascii?q?oMqgi8FmRMBmCiFSJAKHjaCCByBTIhoAX4BAQE?= X-IronPort-AV: E=Sophos;i="5.26,579,1459828800"; d="scan'208,217";a="194572115" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 05 Jul 2016 08:04:39 -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/AES256-SHA; 05 Jul 2016 08:04:39 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Tue, 5 Jul 2016 14:04:38 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP WG at IETF 96 - do we need remote participation? Thread-Index: AdHWtWZUNMORMGMQSI2zambgVQ+Vkw== Date: Tue, 5 Jul 2016 12:04:36 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7522CD74@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_9904FB1B0159DA42B0B887B7FA8119CA7522CD74AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP WG at IETF 96 - do we need remote participation? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 12:04:43 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA7522CD74AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Do we need active remote participation for the LMAP WG meeting at IETF 96? = If we do we need to know in advance. By now we did not receive any such req= uest. Let us know. Thanks and Regards, Jason and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA7522CD74AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Do we need active remote participation for the LMAP = WG meeting at IETF 96? If we do we need to know in advance. By now we did n= ot receive any such request. Let us know.

 

Thanks and Regards,

 

Jason and Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA7522CD74AZFFEXMB04globa_-- From nobody Tue Jul 5 05:10:38 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B2912D511 for ; Tue, 5 Jul 2016 05:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.325 X-Spam-Level: X-Spam-Status: No, score=-8.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 erucoR5uRIrf for ; Tue, 5 Jul 2016 05:10:34 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (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 99E3F12D50D for ; Tue, 5 Jul 2016 05:10:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2H1AQAOo3tX/xUHmMZdHoJSIS1WgQK3L?= =?us-ascii?q?YIPgXeGGAKBODgUAQEBAQEBAQNiHAuEUAMSG14BFRULSyYBBBsaiA4BmmuFEpl?= =?us-ascii?q?8DAEkhiiJDj2CbYIvBZkTAZAwhFaDIoVIkAoeNoNwiGgBfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2H1AQAOo3tX/xUHmMZdHoJSIS1WgQK3LYIPgXeGGAKBODg?= =?us-ascii?q?UAQEBAQEBAQNiHAuEUAMSG14BFRULSyYBBBsaiA4BmmuFEpl8DAEkhiiJDj2Cb?= =?us-ascii?q?YIvBZkTAZAwhFaDIoVIkAoeNoNwiGgBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,579,1459828800"; d="scan'208,217";a="194572992" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 05 Jul 2016 08:10:33 -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/AES256-SHA; 05 Jul 2016 08:10:33 -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, 5 Jul 2016 14:10:32 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP WG at IETF 96 - updated I-Ds for WGLC Thread-Index: AdHWtjlkcr03qOd4QmCllKUBlooqUA== Date: Tue, 5 Jul 2016 12:10:30 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7522CD94@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_9904FB1B0159DA42B0B887B7FA8119CA7522CD94AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP WG at IETF 96 - updated I-Ds for WGLC X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 12:10:36 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA7522CD94AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As discussed at the virtual interim we should send the updated Internet-Dra= fts to WGLC and focus on comments and open issues at IETF 96. Document edit= ors - please take into account that the Internet Draft submission cut-off i= s Friday 7/8! Thanks and Regards, Jason and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA7522CD94AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As discussed at the virtual interim we should send t= he updated Internet-Drafts to WGLC and focus on comments and open issues at= IETF 96. Document editors – please take into account that the Internet Draft submission cut-off&nbs= p;is Friday 7/8!

 

Thanks and Regards,

 

Jason and Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA7522CD94AZFFEXMB04globa_-- From nobody Tue Jul 5 05:25:50 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B721012D1E6 for ; Tue, 5 Jul 2016 05:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 GSH3aLZj8K9p for ; Tue, 5 Jul 2016 05:25:46 -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 B47E112B069 for ; Tue, 5 Jul 2016 05:25:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 34BD2F9D; Tue, 5 Jul 2016 14:25:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fRdj_7v6pUz6; Tue, 5 Jul 2016 14:25:31 +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, 5 Jul 2016 14:25:31 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 902A820152; Tue, 5 Jul 2016 14:21:42 +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 9ZsbPAfBjgEx; Tue, 5 Jul 2016 14:21: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 9DD592014F; Tue, 5 Jul 2016 14:21:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EBC523BB9839; Tue, 5 Jul 2016 14:21:39 +0200 (CEST) Date: Tue, 5 Jul 2016 14:21:39 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20160705122136.GA13405@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA7522CD62@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA7522CD62@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP WG at IETF 96 - preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jul 2016 12:25:49 -0000 On Tue, Jul 05, 2016 at 12:02:38PM +0000, Romascanu, Dan (Dan) wrote: > I have uploaded a preliminary agenda for the LMAP WG meeting at IETF 96 at: > > https://www.ietf.org/proceedings/96/agenda/agenda-96-lmap > > Please let us know if you need any changes, or if there are other topics you would like to discuss. > I suggest to change the order of items 5. and 6. since the YANG data model follows the information model and the RESTCONF I-D follows the YANG data model. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jul 5 06:00:21 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C8612D53B for ; Tue, 5 Jul 2016 06:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 WaOhHCEtvOJa for ; Tue, 5 Jul 2016 06:00: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 7CAE612D0CB for ; Tue, 5 Jul 2016 06:00:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4052130; Tue, 5 Jul 2016 15:00:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id o_fyX5SHxyT9; Tue, 5 Jul 2016 15:00:12 +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, 5 Jul 2016 15:00:12 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 731BC20074; Tue, 5 Jul 2016 15:00:12 +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 JzVZy84pzDSD; Tue, 5 Jul 2016 15:00:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20FB220069; Tue, 5 Jul 2016 15:00:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C1F6F3BBAB86; Tue, 5 Jul 2016 15:00:09 +0200 (CEST) Date: Tue, 5 Jul 2016 15:00:09 +0200 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20160705130009.GA13508@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <4AF73AA205019A4C8A1DDD32C034631D4593BBF235@NJFPSRVEXG0.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D4593BBF235@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Calculation of Cycle-Number X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jul 2016 13:00:19 -0000 On Mon, Jun 27, 2016 at 09:19:50PM -0400, MORTON, ALFRED C (AL) wrote: > LMAP, > > At the latest Interim meeting, I agreed to prepare text that > calculates the variable part of a Cycle-ID. This is planned > to be the numeric index to a specific *recurring* event, > or cycle among many cycles in the results. > We are referring to the numeric part as Cycle-Number. > (The other part of Cycle-ID is the Cycle-Context-ID, which > can be alphanumeric and is not intended to be modified at the MA > or elsewhere.) > > See the meeting notes for further background: > https://www.ietf.org/proceedings/interim/2016/06/13/lmap/minutes/minutes-interim-2016-lmap-3 > > I propose to calculate the Cycle-Number based on the time and > date of each recurring schedule event, which is a component of > the Measurement Schedule. The MA has to calculate the time and > date of each recurring schedule event, and may use its own format. > See below for generation of a Cycle-Number. > Measurement Actions may be aligned with event time or have > some random time offset. > > Since the LMAP Collector does not possess the Measurement Schedule > as described in Section 5.4 of RFC 7594, > it has no knowledge of recurring event time and dates, and > cannot perform the same calculation. Section 8.4.2 of RFC 7594 > identifies the Measurement Schedule as sensitive information, > so this should remain as described by the LMAP Framework. > > For a Collector to infer the Cycle-Number > from the time and date of Measurement Results, the Collector > needs to know the times of recurring schedule events, > or at least: one of the event times, > the duration of the recurring event, and > confirmation that the event timing has not been changed > (changes may be needed to avoid an attacker who intends to > bias the measurements). According to the LMAP Framework, > the Collector has none of this information. > > Even if the Collector has information necessary to infer the > Cycle-Number, its calculations can be subject to errors from > the following sources: > > * There may be overlapping measurements from concurrent > recurring schedules (which would likely use different cycle > durations, referenced to different recurring events). > * There may be a 'wait for X' step in a measurement task that > causes an Action/Measurement to be delayed such that the > actual measurement time occurs in a subsequent cycle. > > with inference of the wrong Cycle-number as the result. > Overlapping Measurements are described in Section 5.3.2 of RFC 7594. > > Measurement Time alone does not lead to the correct > recurring schedule event for calculation of the Cycle-Number. > > > -=-=-=-=-=- Note: there are many date, time and datetime formats > in various languages, this is a simple approximation -=-=-=-=-=-=-= > > The MA calculates that the next recurring event will occur on > Date = YYYY-MM-DD, at Time = HHMMSS, according to information > from the Controller. > > A simple Cycle-Number can be formed by converting the date and > time to strings, and concatenating the strings: > > Cycle-Number = print( str(Date) + "-" + str(Time) ) #possibly truncate time to HHMM > > All MAs have synchronized clocks, so they all produce the same > Cycle-Number and report it with the measurement results for that > recurring event when they are operating on the same recurring schedule. > Hm. How is this different from sending the date-and-time of the event that triggered the execution of a schedule? YANG uses the RFC 3339 profile of the ISO 8601 format, that is, YYYY-MM-DDTHH:MM:SS+00:00 (if you are operating in UTC). This is what I suggested before but somehow I thought during the interim that you wanted something that (a) is purely numeric and (b) has a sufficiently course grained resolution and (c) hides all randomization effects and hence for this one would have to configure a resolution and then round down the actual event time-stamp according to the configured resolution and then report the result as a number, e.g. YYYYMMDDHHMMSS (where some portions at then end may always be zero depending on the configured resolution, e.g., if I set the resolution to 5 minutes than of course SS will always be 00). I guess (since you are not explicitely writing it) that you assume the next recurring event is precise to calculate and not impacted by any variation due to randomization or simply exceution delays and hence multiple systems will come up with the same cycle number. Frankly, this is not the case even with your proposal. Consider simple periodic schedules; they will have a defined interval but not necessarily a defined and thus synchronized start time. So multiple systems executing the same periodic schedules will not give you the predictable cycle numbers you are looking for. If we were to go with an approach where you configure a cycle-number-resolution in seconds and then you calculate a numeric cycle-number as outlined above, then the questions are whether this is a global configuration knob or whether different ma-schedule-obj's can have different cycle-number-resolutions or whether such a cycle-number-resolution is even seen as a property of an event source (which may make sense since the event configuration really determins what a suitable cycle-number-resolution value is). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jul 5 06:07:21 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D24612D578 for ; Tue, 5 Jul 2016 06:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.346 X-Spam-Level: X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 NIprwkq78hu6 for ; Tue, 5 Jul 2016 06:07:07 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 52F5F12D552 for ; Tue, 5 Jul 2016 06:07:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2F0AwCNsHtX/yYyC4dcGwEBAYJzLVZ8B?= =?us-ascii?q?o0kmjoBj1CCD4F3GoF0hAoCgTE4FAEBAQEBAQEDYieDNVs8AQEBAQMSKD8MBAI?= =?us-ascii?q?BCA0BAgUNFAkHMhQRAQEEDg0aiA4BoCOZfwEBAQEBBQEBAQEBAQEBAR6GKIRMh?= =?us-ascii?q?EKDKoIvBZkTAYYIgnqHGAFjhyqFSJAKHjaDcG6HegF+AQEB?= X-IPAS-Result: =?us-ascii?q?A2F0AwCNsHtX/yYyC4dcGwEBAYJzLVZ8Bo0kmjoBj1CCD4F?= =?us-ascii?q?3GoF0hAoCgTE4FAEBAQEBAQEDYieDNVs8AQEBAQMSKD8MBAIBCA0BAgUNFAkHM?= =?us-ascii?q?hQRAQEEDg0aiA4BoCOZfwEBAQEBBQEBAQEBAQEBAR6GKIRMhEKDKoIvBZkTAYY?= =?us-ascii?q?IgnqHGAFjhyqFSJAKHjaDcG6HegF+AQEB?= X-IronPort-AV: E=Sophos;i="5.26,579,1459828800"; d="scan'208";a="160982432" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Jul 2016 09:02:44 -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/AES256-SHA; 05 Jul 2016 09:02:43 -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, 5 Jul 2016 15:02:42 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [lmap] LMAP WG at IETF 96 - preliminary agenda Thread-Index: AdHWtSAKzTrK9SmIQwep/GQSYxIubQAJC7WAAAb3YrA= Date: Tue, 5 Jul 2016 13:02:41 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7522CE79@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA7522CD62@AZ-FFEXMB04.global.avaya.com> <20160705122136.GA13405@elstar.local> In-Reply-To: <20160705122136.GA13405@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] LMAP WG at IETF 96 - preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 13:07:11 -0000 Done.=20 Thanks and Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] >=20 > I suggest to change the order of items 5. and 6. since the YANG data mode= l > follows the information model and the RESTCONF I-D follows the YANG data > model. >=20 > /js >=20 From nobody Tue Jul 5 06:34:23 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6236512D552 for ; Tue, 5 Jul 2016 06:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 RJUmRTVvgvcG for ; Tue, 5 Jul 2016 06:34:20 -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 E06A112B050 for ; Tue, 5 Jul 2016 06:34:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AE1BE745; Tue, 5 Jul 2016 15:34:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id crqG4IzktWqP; Tue, 5 Jul 2016 15:34:16 +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, 5 Jul 2016 15:34:15 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E510A2006D; Tue, 5 Jul 2016 15:34:15 +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 cAHo4E0EJptJ; Tue, 5 Jul 2016 15:34:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98DD920069; Tue, 5 Jul 2016 15:34:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7A30E3BBADDD; Tue, 5 Jul 2016 15:34:13 +0200 (CEST) Date: Tue, 5 Jul 2016 15:34:12 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160705133412.GA13649@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A6BD31C@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A6BD31C@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or Tag? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jul 2016 13:34:22 -0000 On Tue, Jun 14, 2016 at 07:20:19PM +0000, Carey, Timothy (Nokia - US) wrote: > At the June 13, 2016 LMAP interim meeting we discussed whether the > Cycle-Context-ID should be passed as a tag or option from the controller to the MA. The group asked if we could attempt to come to consensus on this over the email list. > > The following background information should be considered when deciding if something should be a tag or option. > > > 1) Tags were meant to be used within the MA and were not intended to be "passed" to measurement functions. > > 2) Tags are simply a list of free formatted strings > > 3) Tags can be assigned to tasks, schedules and actions > > 4) Tags were intended to be echoed by the results for the scheduled action. > > 5) Options are be assigned by the controller and either used within the MA (e.g., Channel) or passed to the measurement function by the MA. > > 6) Options are list of name value pairs where the name has meaning. Some option names are reserved (i.e., Role, Channel) I think we effectively eliminated the Role option since we now list the set of roles as part of the ma-metric-registry-obj itself. > 7) Options can be assigned to tasks, schedules and actions > > 8) Options are reported by the results for the scheduled action > > With this background in mind - there are 2 ways for a controller to pass the Cycle Context Identifier - as a tag or an option. > > > If the identifier is used as a tag - the string value of the tag probably needs to have some format for the name (e.g., CycleContextId:). As pointed out the value of the name portion of the tag could be an organizational construct. > > If the identifier is used as an option - we could reserve a name for the Option (e.g., CycleContextId). However it also could be an organizational construct as well. > > So the choice is Tag or Option. If we use an option should we also reserve a name. > > My opinion is to use an Option with a reserved name. This way every controller, agent, collector would understand the meaning. > I think the right tool here is a tag since there is no point to pass the CycleContextId to the measurement functions. Tags are there for, well, tagging (and this is what the CycleContextId is). The other meta questions are whether the CycleContextId must be recognizable at all and what you dof if for example a specific measurement serves multiple purposes. I would prefer to not standardize how the tags are exactly used. This does not preclude that other organizations establish guidelines or conventions and who knows perhaps some of them will become universally used. But at this point, me preference would be to say 'if you need to tag your measurements, simply tag them'. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jul 5 10:58:49 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E2812B060 for ; Tue, 5 Jul 2016 10:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 sTmM0Fj7Naob for ; Tue, 5 Jul 2016 10:58:46 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59AE12D533 for ; Tue, 5 Jul 2016 10:58:45 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 6AB0A6C603C80; Tue, 5 Jul 2016 17:58:41 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u65HwiI2032422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jul 2016 17:58:44 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 u65HwiQ7001310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Jul 2016 17:58:44 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.10]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 5 Jul 2016 13:58:44 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Model: Cycle Context Identifier Option or Tag? Thread-Index: AQHR1sHwUje9UMKRSk+iGSlPXY4exqAKH6kg Date: Tue, 5 Jul 2016 17:58:44 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6D5FFC@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A6BD31C@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160705133412.GA13649@elstar.local> In-Reply-To: <20160705133412.GA13649@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] Information Model: Cycle Context Identifier Option or Tag? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 17:58:48 -0000 Juergen, Yes you are correct about role as an option. So the only well known option = is Channel; which still holds the argument for an option to be used within = the MA > 5) Options are be assigned by the controller and either used within = the MA (e.g., Channel) or passed to the measurement function by the MA. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, July 05, 2016 8:34 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or T= ag? On Tue, Jun 14, 2016 at 07:20:19PM +0000, Carey, Timothy (Nokia - US) wrote= : > At the June 13, 2016 LMAP interim meeting we discussed whether the=20 > Cycle-Context-ID should be passed as a tag or option from the controller = to the MA. The group asked if we could attempt to come to consensus on thi= s over the email list. >=20 > The following background information should be considered when deciding i= f something should be a tag or option. >=20 >=20 > 1) Tags were meant to be used within the MA and were not intended to= be "passed" to measurement functions. >=20 > 2) Tags are simply a list of free formatted strings >=20 > 3) Tags can be assigned to tasks, schedules and actions >=20 > 4) Tags were intended to be echoed by the results for the scheduled = action. >=20 > 5) Options are be assigned by the controller and either used within = the MA (e.g., Channel) or passed to the measurement function by the MA. >=20 > 6) Options are list of name value pairs where the name has meaning. = Some option names are reserved (i.e., Role, Channel) I think we effectively eliminated the Role option since we now list the set= of roles as part of the ma-metric-registry-obj itself. =20 > 7) Options can be assigned to tasks, schedules and actions >=20 > 8) Options are reported by the results for the scheduled action >=20 > With this background in mind - there are 2 ways for a controller to pass = the Cycle Context Identifier - as a tag or an option. >=20 >=20 > If the identifier is used as a tag - the string value of the tag probably= needs to have some format for the name (e.g., CycleContextId:). As = pointed out the value of the name portion of the tag could be an organizati= onal construct. >=20 > If the identifier is used as an option - we could reserve a name for the= Option (e.g., CycleContextId). However it also could be an organizational = construct as well. >=20 > So the choice is Tag or Option. If we use an option should we also reserv= e a name. >=20 > My opinion is to use an Option with a reserved name. This way every contr= oller, agent, collector would understand the meaning. > I think the right tool here is a tag since there is no point to pass the Cy= cleContextId to the measurement functions. Tags are there for, well, taggin= g (and this is what the CycleContextId is). The other meta questions are wh= ether the CycleContextId must be recognizable at all and what you dof if fo= r example a specific measurement serves multiple purposes. I would prefer t= o not standardize how the tags are exactly used. This does not preclude tha= t other organizations establish guidelines or conventions and who knows per= haps some of them will become universally used. But at this point, me prefe= rence would be to say 'if you need to tag your measurements, simply tag the= m'. /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 Tue Jul 5 11:02:53 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A36712D12B for ; Tue, 5 Jul 2016 11:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 krX7Uv3dGKRO for ; Tue, 5 Jul 2016 11:02:49 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 368B912B060 for ; Tue, 5 Jul 2016 11:02:49 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 31969D90FE1AD; Tue, 5 Jul 2016 18:02:46 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u65I2lb1028619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jul 2016 18:02:48 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 u65I2lMn002233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Jul 2016 18:02:47 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.10]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 5 Jul 2016 14:02:47 -0400 From: "Carey, Timothy (Nokia - US)" To: "Carey, Timothy (Nokia - US)" , "Juergen Schoenwaelder" Thread-Topic: [lmap] Information Model: Cycle Context Identifier Option or Tag? Thread-Index: AQHR1sHwUje9UMKRSk+iGSlPXY4exqAKH6kggAAA6sA= Date: Tue, 5 Jul 2016 18:02:47 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6D6016@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A6BD31C@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160705133412.GA13649@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] Information Model: Cycle Context Identifier Option or Tag? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 18:02:51 -0000 Sorry I hit send accidentally Yes you are correct about role as an option. So the only well known option = is Channel; which still holds the argument for an option to be used within = the MA but not the passed to a tag' > 5) Options are be assigned by the controller and either used within = the MA (e.g., Channel) or passed to the measurement function by the MA. So it would be=20 > 5) Options are be assigned by the controller and either used within = the MA (i.e., Channel). BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Tuesday, July 05, 2016 8:34 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or T= ag? On Tue, Jun 14, 2016 at 07:20:19PM +0000, Carey, Timothy (Nokia - US) wrote= : > At the June 13, 2016 LMAP interim meeting we discussed whether the=20 > Cycle-Context-ID should be passed as a tag or option from the controller = to the MA. The group asked if we could attempt to come to consensus on thi= s over the email list. >=20 > The following background information should be considered when deciding i= f something should be a tag or option. >=20 >=20 > 1) Tags were meant to be used within the MA and were not intended to= be "passed" to measurement functions. >=20 > 2) Tags are simply a list of free formatted strings >=20 > 3) Tags can be assigned to tasks, schedules and actions >=20 > 4) Tags were intended to be echoed by the results for the scheduled = action. >=20 > 5) Options are be assigned by the controller and either used within = the MA (e.g., Channel) or passed to the measurement function by the MA. >=20 > 6) Options are list of name value pairs where the name has meaning. = Some option names are reserved (i.e., Role, Channel) I think we effectively eliminated the Role option since we now list the set= of roles as part of the ma-metric-registry-obj itself. =20 > 7) Options can be assigned to tasks, schedules and actions >=20 > 8) Options are reported by the results for the scheduled action >=20 > With this background in mind - there are 2 ways for a controller to pass = the Cycle Context Identifier - as a tag or an option. >=20 >=20 > If the identifier is used as a tag - the string value of the tag probably= needs to have some format for the name (e.g., CycleContextId:). As = pointed out the value of the name portion of the tag could be an organizati= onal construct. >=20 > If the identifier is used as an option - we could reserve a name for the= Option (e.g., CycleContextId). However it also could be an organizational = construct as well. >=20 > So the choice is Tag or Option. If we use an option should we also reserv= e a name. >=20 > My opinion is to use an Option with a reserved name. This way every contr= oller, agent, collector would understand the meaning. > I think the right tool here is a tag since there is no point to pass the Cy= cleContextId to the measurement functions. Tags are there for, well, taggin= g (and this is what the CycleContextId is). The other meta questions are wh= ether the CycleContextId must be recognizable at all and what you dof if fo= r example a specific measurement serves multiple purposes. I would prefer t= o not standardize how the tags are exactly used. This does not preclude tha= t other organizations establish guidelines or conventions and who knows per= haps some of them will become universally used. But at this point, me prefe= rence would be to say 'if you need to tag your measurements, simply tag the= m'. /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 Thu Jul 7 06:07:15 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9254712D76D for ; Thu, 7 Jul 2016 06:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 bIcqGwvYsb7S for ; Thu, 7 Jul 2016 06:07:12 -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 6428312D7B3 for ; Thu, 7 Jul 2016 06:07:11 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9B9A672C; Thu, 7 Jul 2016 15:07:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id iomhkdFtoHKA; Thu, 7 Jul 2016 15:07: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; Thu, 7 Jul 2016 15:07:07 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6776620075; Thu, 7 Jul 2016 15:07:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3HZo30pmgonJ; Thu, 7 Jul 2016 15:07:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53F7620069; Thu, 7 Jul 2016 15:07:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C80AF3BBE518; Thu, 7 Jul 2016 15:07:03 +0200 (CEST) Date: Thu, 7 Jul 2016 15:07:02 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160707130700.GA18614@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A6BD31C@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160705133412.GA13649@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6D6016@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A6D6016@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or Tag? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 13:07:14 -0000 On Tue, Jul 05, 2016 at 06:02:47PM +0000, Carey, Timothy (Nokia - US) wrote: > Sorry I hit send accidentally > > Yes you are correct about role as an option. So the only well known option is Channel; which still holds the argument for an option to be used within the MA but not the passed to a tag' > > > 5) Options are be assigned by the controller and either used within the MA (e.g., Channel) or passed to the measurement function by the MA. This depends how you implement things. In my implementation, the reporting will be done by just another task. So the channel information is passed to the task. > So it would be > > 5) Options are be assigned by the controller and either used within the MA (i.e., Channel). This sound wrong since most options will be providing information to the measurement tasks. I think the better wording is: 5) Options are be assigned by the controller and passed to tasks by the MA. /js > BR, > Tim > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, July 05, 2016 8:34 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or Tag? > > On Tue, Jun 14, 2016 at 07:20:19PM +0000, Carey, Timothy (Nokia - US) wrote: > > At the June 13, 2016 LMAP interim meeting we discussed whether the > > Cycle-Context-ID should be passed as a tag or option from the controller to the MA. The group asked if we could attempt to come to consensus on this over the email list. > > > > The following background information should be considered when deciding if something should be a tag or option. > > > > > > 1) Tags were meant to be used within the MA and were not intended to be "passed" to measurement functions. > > > > 2) Tags are simply a list of free formatted strings > > > > 3) Tags can be assigned to tasks, schedules and actions > > > > 4) Tags were intended to be echoed by the results for the scheduled action. > > > > 5) Options are be assigned by the controller and either used within the MA (e.g., Channel) or passed to the measurement function by the MA. > > > > 6) Options are list of name value pairs where the name has meaning. Some option names are reserved (i.e., Role, Channel) > > I think we effectively eliminated the Role option since we now list the set of roles as part of the ma-metric-registry-obj itself. > > > 7) Options can be assigned to tasks, schedules and actions > > > > 8) Options are reported by the results for the scheduled action > > > > With this background in mind - there are 2 ways for a controller to pass the Cycle Context Identifier - as a tag or an option. > > > > > > If the identifier is used as a tag - the string value of the tag probably needs to have some format for the name (e.g., CycleContextId:). As pointed out the value of the name portion of the tag could be an organizational construct. > > > > If the identifier is used as an option - we could reserve a name for the Option (e.g., CycleContextId). However it also could be an organizational construct as well. > > > > So the choice is Tag or Option. If we use an option should we also reserve a name. > > > > My opinion is to use an Option with a reserved name. This way every controller, agent, collector would understand the meaning. > > > > I think the right tool here is a tag since there is no point to pass the CycleContextId to the measurement functions. Tags are there for, well, tagging (and this is what the CycleContextId is). The other meta questions are whether the CycleContextId must be recognizable at all and what you dof if for example a specific measurement serves multiple purposes. I would prefer to not standardize how the tags are exactly used. This does not preclude that other organizations establish guidelines or conventions and who knows perhaps some of them will become universally used. But at this point, me preference would be to say 'if you need to tag your measurements, simply tag them'. > > /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 Thu Jul 7 06:11:12 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EDB12D752 for ; Thu, 7 Jul 2016 06:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RNUEPCOwMPp2 for ; Thu, 7 Jul 2016 06:11:07 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 9FA5C12D76D for ; Thu, 7 Jul 2016 06:11:07 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 57DE2C13268F7; Thu, 7 Jul 2016 13:11:04 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u67DB5Ci008931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Jul 2016 13:11:05 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 u67DB48P011613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Jul 2016 13:11:05 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.10]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 7 Jul 2016 09:11:04 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Model: Cycle Context Identifier Option or Tag? Thread-Index: AQHR1sHwUje9UMKRSk+iGSlPXY4exqAKH6kggAAA6sCAAxXeAP//vYlg Date: Thu, 7 Jul 2016 13:11:03 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6D8C4C@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A6BD31C@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160705133412.GA13649@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6D6016@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160707130700.GA18614@elstar.local> In-Reply-To: <20160707130700.GA18614@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] Information Model: Cycle Context Identifier Option or Tag? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 13:11:10 -0000 Juergen, But how do we handle Channel?- There are channels used for the MA itself, r= ight? BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, July 07, 2016 8:07 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or T= ag? On Tue, Jul 05, 2016 at 06:02:47PM +0000, Carey, Timothy (Nokia - US) wrote= : > Sorry I hit send accidentally >=20 > Yes you are correct about role as an option. So the only well known optio= n is Channel; which still holds the argument for an option to be used withi= n the MA but not the passed to a tag' >=20 > > 5) Options are be assigned by the controller and either used withi= n the MA (e.g., Channel) or passed to the measurement function by the MA. This depends how you implement things. In my implementation, the reporting = will be done by just another task. So the channel information is passed to = the task. =20 > So it would be > > 5) Options are be assigned by the controller and either used withi= n the MA (i.e., Channel). This sound wrong since most options will be providing information to the me= asurement tasks. I think the better wording is: 5) Options are be assigned by the controller and passed to tasks by th= e MA. /js =20 > BR, > Tim > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, July 05, 2016 8:34 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or= Tag? >=20 > On Tue, Jun 14, 2016 at 07:20:19PM +0000, Carey, Timothy (Nokia - US) wro= te: > > At the June 13, 2016 LMAP interim meeting we discussed whether the=20 > > Cycle-Context-ID should be passed as a tag or option from the controlle= r to the MA. The group asked if we could attempt to come to consensus on t= his over the email list. > >=20 > > The following background information should be considered when deciding= if something should be a tag or option. > >=20 > >=20 > > 1) Tags were meant to be used within the MA and were not intended = to be "passed" to measurement functions. > >=20 > > 2) Tags are simply a list of free formatted strings > >=20 > > 3) Tags can be assigned to tasks, schedules and actions > >=20 > > 4) Tags were intended to be echoed by the results for the schedule= d action. > >=20 > > 5) Options are be assigned by the controller and either used withi= n the MA (e.g., Channel) or passed to the measurement function by the MA. > >=20 > > 6) Options are list of name value pairs where the name has meaning= . Some option names are reserved (i.e., Role, Channel) >=20 > I think we effectively eliminated the Role option since we now list the s= et of roles as part of the ma-metric-registry-obj itself. > =20 > > 7) Options can be assigned to tasks, schedules and actions > >=20 > > 8) Options are reported by the results for the scheduled action > >=20 > > With this background in mind - there are 2 ways for a controller to pas= s the Cycle Context Identifier - as a tag or an option. > >=20 > >=20 > > If the identifier is used as a tag - the string value of the tag probab= ly needs to have some format for the name (e.g., CycleContextId:). A= s pointed out the value of the name portion of the tag could be an organiza= tional construct. > >=20 > > If the identifier is used as an option - we could reserve a name for t= he Option (e.g., CycleContextId). However it also could be an organizationa= l construct as well. > >=20 > > So the choice is Tag or Option. If we use an option should we also rese= rve a name. > >=20 > > My opinion is to use an Option with a reserved name. This way every con= troller, agent, collector would understand the meaning. > > >=20 > I think the right tool here is a tag since there is no point to pass the = CycleContextId to the measurement functions. Tags are there for, well, tagg= ing (and this is what the CycleContextId is). The other meta questions are = whether the CycleContextId must be recognizable at all and what you dof if = for example a specific measurement serves multiple purposes. I would prefer= to not standardize how the tags are exactly used. This does not preclude t= hat other organizations establish guidelines or conventions and who knows p= erhaps some of them will become universally used. But at this point, me pre= ference would be to say 'if you need to tag your measurements, simply tag t= hem'. >=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 --=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 Thu Jul 7 06:24:04 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194F012D7BF for ; Thu, 7 Jul 2016 06:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 ZrliqPSdrxhC for ; Thu, 7 Jul 2016 06:24:01 -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 EDB6012D1DE for ; Thu, 7 Jul 2016 06:24: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 B3329AD6; Thu, 7 Jul 2016 15:23:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id XwSqExtFkTwa; Thu, 7 Jul 2016 15:23:55 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 7 Jul 2016 15:23:55 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 892E22006D; Thu, 7 Jul 2016 15:23:55 +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 utBsLL0YwVEK; Thu, 7 Jul 2016 15:23:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47E0F20069; Thu, 7 Jul 2016 15:23:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3D9423BBE608; Thu, 7 Jul 2016 15:23:52 +0200 (CEST) Date: Thu, 7 Jul 2016 15:23:51 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160707132351.GB18614@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A6BD31C@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160705133412.GA13649@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6D6016@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160707130700.GA18614@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6D8C4C@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A6D8C4C@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or Tag? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 13:24:03 -0000 I think the information model also allows the communication with the controller to be a separate task: Tasks can implement a variety of different types of Actions. While in terms of the Information Model, all Tasks have the same structure, it can help conceptually to think of different Task categories: 1. Measurement Tasks measure some aspect of network performance or traffic. They may also capture contextual information from the MA device or network interfaces such as the device type or interface speed. 2. Data Transfer Tasks A. Reporting Tasks report the results of Measurement Tasks to Collectors B. Control Task(s) implement the Control Protocol and communicate with the Controller. 3. Data Analysis Tasks can exist to analyse data from other Measurement Tasks locally on the MA 4. Data Management Tasks may exist to clean-up, filter or compress data on the MA such as Measurement Task results That said, I would not mind to get read of the well-known Channel option as well. One thing I have to do is to work through a concrete example how things will work with YANG/RESTCONF and in particular the NETCONF/RESTCONF configuration data models worked on in the NETCONF working group. Another option is that the IPPM metrics registry, which currently is designed for Measurement Tasks, also hosts entries for other tasks so that their options are defined outside the information model and data models. I thinking loud, not sure any of this is really a workable idea. /js On Thu, Jul 07, 2016 at 01:11:03PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > But how do we handle Channel?- There are channels used for the MA itself, right? > > BR, > Tim > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, July 07, 2016 8:07 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or Tag? > > On Tue, Jul 05, 2016 at 06:02:47PM +0000, Carey, Timothy (Nokia - US) wrote: > > Sorry I hit send accidentally > > > > Yes you are correct about role as an option. So the only well known option is Channel; which still holds the argument for an option to be used within the MA but not the passed to a tag' > > > > > 5) Options are be assigned by the controller and either used within the MA (e.g., Channel) or passed to the measurement function by the MA. > > This depends how you implement things. In my implementation, the reporting will be done by just another task. So the channel information is passed to the task. > > > So it would be > > > 5) Options are be assigned by the controller and either used within the MA (i.e., Channel). > > This sound wrong since most options will be providing information to the measurement tasks. I think the better wording is: > > 5) Options are be assigned by the controller and passed to tasks by the MA. > > /js > > > BR, > > Tim > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, July 05, 2016 8:34 AM > > To: Carey, Timothy (Nokia - US) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or Tag? > > > > On Tue, Jun 14, 2016 at 07:20:19PM +0000, Carey, Timothy (Nokia - US) wrote: > > > At the June 13, 2016 LMAP interim meeting we discussed whether the > > > Cycle-Context-ID should be passed as a tag or option from the controller to the MA. The group asked if we could attempt to come to consensus on this over the email list. > > > > > > The following background information should be considered when deciding if something should be a tag or option. > > > > > > > > > 1) Tags were meant to be used within the MA and were not intended to be "passed" to measurement functions. > > > > > > 2) Tags are simply a list of free formatted strings > > > > > > 3) Tags can be assigned to tasks, schedules and actions > > > > > > 4) Tags were intended to be echoed by the results for the scheduled action. > > > > > > 5) Options are be assigned by the controller and either used within the MA (e.g., Channel) or passed to the measurement function by the MA. > > > > > > 6) Options are list of name value pairs where the name has meaning. Some option names are reserved (i.e., Role, Channel) > > > > I think we effectively eliminated the Role option since we now list the set of roles as part of the ma-metric-registry-obj itself. > > > > > 7) Options can be assigned to tasks, schedules and actions > > > > > > 8) Options are reported by the results for the scheduled action > > > > > > With this background in mind - there are 2 ways for a controller to pass the Cycle Context Identifier - as a tag or an option. > > > > > > > > > If the identifier is used as a tag - the string value of the tag probably needs to have some format for the name (e.g., CycleContextId:). As pointed out the value of the name portion of the tag could be an organizational construct. > > > > > > If the identifier is used as an option - we could reserve a name for the Option (e.g., CycleContextId). However it also could be an organizational construct as well. > > > > > > So the choice is Tag or Option. If we use an option should we also reserve a name. > > > > > > My opinion is to use an Option with a reserved name. This way every controller, agent, collector would understand the meaning. > > > > > > > I think the right tool here is a tag since there is no point to pass the CycleContextId to the measurement functions. Tags are there for, well, tagging (and this is what the CycleContextId is). The other meta questions are whether the CycleContextId must be recognizable at all and what you dof if for example a specific measurement serves multiple purposes. I would prefer to not standardize how the tags are exactly used. This does not preclude that other organizations establish guidelines or conventions and who knows perhaps some of them will become universally used. But at this point, me preference would be to say 'if you need to tag your measurements, simply tag them'. > > > > /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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 7 06:32:18 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F6512B005 for ; Thu, 7 Jul 2016 06:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8iEasaw1tchi for ; Thu, 7 Jul 2016 06:32:14 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 BD5AF12D098 for ; Thu, 7 Jul 2016 06:32:14 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 3DBB960FFAF07; Thu, 7 Jul 2016 13:32:11 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u67DWDnQ030048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Jul 2016 13:32:13 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 u67DWDP0008587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Jul 2016 13:32:13 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.10]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 7 Jul 2016 09:32:13 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Model: Cycle Context Identifier Option or Tag? Thread-Index: AQHR1sHwUje9UMKRSk+iGSlPXY4exqAKH6kggAAA6sCAAxXeAP//vYlggABHKoD//73RIA== Date: Thu, 7 Jul 2016 13:32:11 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6D8D24@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A6BD31C@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160705133412.GA13649@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6D6016@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160707130700.GA18614@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6D8C4C@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160707132351.GB18614@elstar.local> In-Reply-To: <20160707132351.GB18614@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] Information Model: Cycle Context Identifier Option or Tag? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 13:32:17 -0000 Juergen, I am fine with your explaination (albeit the term tasks implies and impleme= ntation). Given this explaination the cycle context identifier can be used = as an option its just given to a MA "task". Anyway - the question is if we use a tag - do we need to have a specific fo= rmat so that Controllers and Collectors will know this the Cycle-context-id= entifier. For options this is handled via a well known name. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, July 07, 2016 8:24 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or T= ag? I think the information model also allows the communication with the contro= ller to be a separate task: Tasks can implement a variety of different types of Actions. While in terms of the Information Model, all Tasks have the same structure, it can help conceptually to think of different Task categories: 1. Measurement Tasks measure some aspect of network performance or traffic. They may also capture contextual information from the MA device or network interfaces such as the device type or interface speed. 2. Data Transfer Tasks A. Reporting Tasks report the results of Measurement Tasks to Collectors B. Control Task(s) implement the Control Protocol and communicate with the Controller. 3. Data Analysis Tasks can exist to analyse data from other Measurement Tasks locally on the MA 4. Data Management Tasks may exist to clean-up, filter or compress data on the MA such as Measurement Task results That said, I would not mind to get read of the well-known Channel option as= well. One thing I have to do is to work through a concrete example how thi= ngs will work with YANG/RESTCONF and in particular the NETCONF/RESTCONF con= figuration data models worked on in the NETCONF working group. Another opti= on is that the IPPM metrics registry, which currently is designed for Measu= rement Tasks, also hosts entries for other tasks so that their options are = defined outside the information model and data models. I thinking loud, not= sure any of this is really a workable idea. /js On Thu, Jul 07, 2016 at 01:11:03PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > But how do we handle Channel?- There are channels used for the MA itself,= right? >=20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, July 07, 2016 8:07 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or= Tag? >=20 > On Tue, Jul 05, 2016 at 06:02:47PM +0000, Carey, Timothy (Nokia - US) wro= te: > > Sorry I hit send accidentally > >=20 > > Yes you are correct about role as an option. So the only well known opt= ion is Channel; which still holds the argument for an option to be used wit= hin the MA but not the passed to a tag' > >=20 > > > 5) Options are be assigned by the controller and either used wit= hin the MA (e.g., Channel) or passed to the measurement function by the MA. >=20 > This depends how you implement things. In my implementation, the reportin= g will be done by just another task. So the channel information is passed t= o the task. > =20 > > So it would be > > > 5) Options are be assigned by the controller and either used wit= hin the MA (i.e., Channel). >=20 > This sound wrong since most options will be providing information to the = measurement tasks. I think the better wording is: >=20 > 5) Options are be assigned by the controller and passed to tasks by = the MA. >=20 > /js > =20 > > BR, > > Tim > > -----Original Message----- > > From: Juergen Schoenwaelder=20 > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, July 05, 2016 8:34 AM > > To: Carey, Timothy (Nokia - US) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] Information Model: Cycle Context Identifier Option = or Tag? > >=20 > > On Tue, Jun 14, 2016 at 07:20:19PM +0000, Carey, Timothy (Nokia - US) w= rote: > > > At the June 13, 2016 LMAP interim meeting we discussed whether the=20 > > > Cycle-Context-ID should be passed as a tag or option from the control= ler to the MA. The group asked if we could attempt to come to consensus on= this over the email list. > > >=20 > > > The following background information should be considered when decidi= ng if something should be a tag or option. > > >=20 > > >=20 > > > 1) Tags were meant to be used within the MA and were not intende= d to be "passed" to measurement functions. > > >=20 > > > 2) Tags are simply a list of free formatted strings > > >=20 > > > 3) Tags can be assigned to tasks, schedules and actions > > >=20 > > > 4) Tags were intended to be echoed by the results for the schedu= led action. > > >=20 > > > 5) Options are be assigned by the controller and either used wit= hin the MA (e.g., Channel) or passed to the measurement function by the MA. > > >=20 > > > 6) Options are list of name value pairs where the name has meani= ng. Some option names are reserved (i.e., Role, Channel) > >=20 > > I think we effectively eliminated the Role option since we now list the= set of roles as part of the ma-metric-registry-obj itself. > > =20 > > > 7) Options can be assigned to tasks, schedules and actions > > >=20 > > > 8) Options are reported by the results for the scheduled action > > >=20 > > > With this background in mind - there are 2 ways for a controller to p= ass the Cycle Context Identifier - as a tag or an option. > > >=20 > > >=20 > > > If the identifier is used as a tag - the string value of the tag prob= ably needs to have some format for the name (e.g., CycleContextId:).= As pointed out the value of the name portion of the tag could be an organi= zational construct. > > >=20 > > > If the identifier is used as an option - we could reserve a name for= the Option (e.g., CycleContextId). However it also could be an organizatio= nal construct as well. > > >=20 > > > So the choice is Tag or Option. If we use an option should we also re= serve a name. > > >=20 > > > My opinion is to use an Option with a reserved name. This way every c= ontroller, agent, collector would understand the meaning. > > > > >=20 > > I think the right tool here is a tag since there is no point to pass th= e CycleContextId to the measurement functions. Tags are there for, well, ta= gging (and this is what the CycleContextId is). The other meta questions ar= e whether the CycleContextId must be recognizable at all and what you dof i= f for example a specific measurement serves multiple purposes. I would pref= er to not standardize how the tags are exactly used. This does not preclude= that other organizations establish guidelines or conventions and who knows= perhaps some of them will become universally used. But at this point, me p= reference would be to say 'if you need to tag your measurements, simply tag= them'. > >=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 >=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 Fri Jul 8 07:08:35 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A9512D73F for ; Fri, 8 Jul 2016 07:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 jIVjdKGbXcDu for ; Fri, 8 Jul 2016 07:08:32 -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 6A93E12B05A for ; Fri, 8 Jul 2016 07:08:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EC688779; Fri, 8 Jul 2016 16:08:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 0Gbkd9mkfjdE; Fri, 8 Jul 2016 16:08:28 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 8 Jul 2016 16:08:29 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E2CE20074; Fri, 8 Jul 2016 16:08:29 +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 lbVXZBqEsZ02; Fri, 8 Jul 2016 16:08: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 605222006D; Fri, 8 Jul 2016 16:08:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 50AD23BC325E; Fri, 8 Jul 2016 16:08:26 +0200 (CEST) Date: Fri, 8 Jul 2016 16:08:26 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160708140824.GA24055@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A6BD31C@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160705133412.GA13649@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6D6016@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160707130700.GA18614@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6D8C4C@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160707132351.GB18614@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6D8D24@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A6D8D24@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or Tag? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:08:35 -0000 On Thu, Jul 07, 2016 at 01:32:11PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > I am fine with your explaination (albeit the term tasks implies and implementation). Given this explaination the cycle context identifier can be used as an option its just given to a MA "task". > I think the model is really simple: - The MA is executing tasks. - Options are name/value pairs and passed from the MA to tasks. - Tags are simple strings and maintained by the MA but they are not passed to tasks. Obviously, the MA is not executing itself as a task. > Anyway - the question is if we use a tag - do we need to have a specific format so that Controllers and Collectors will know this the Cycle-context-identifier. For options this is handled via a well known name. - The tag used to identify a measurement cycle is only relevant for the code/human configuring the controller and doing the data analysis, i.e. consuming the data collected by the collector. Hence, all we have to do is to provide a means to carry the tags around (which we have accomplished). - We define an information model that governs the design of data models / protocols that are used in concrete implementations. I do not think the information model should not define concrete option names or tag formats. - If there is a need to define common or well-known option names or tag formats, I think we should do this separately so that these can evolve and change over time without requiring updates to the information model. Given this, I propose to (a) not detail how tags are used to carry a cycle ID and (b) to remove the text suggesting that there is a special Channel option name. This kind of information should either fall out of a registry or a separate applicability specification. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jul 8 07:25:57 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E7912D5C3 for ; Fri, 8 Jul 2016 07:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 6u5df3f3x6D9 for ; Fri, 8 Jul 2016 07:25:54 -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 A12E712D501 for ; Fri, 8 Jul 2016 07:25:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 486FAAEB; Fri, 8 Jul 2016 16:25:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yilqyQSOZOpl; Fri, 8 Jul 2016 16:25: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; Fri, 8 Jul 2016 16:25:52 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42A9B20074; Fri, 8 Jul 2016 16:25:52 +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 Wl8H5uVubqw2; Fri, 8 Jul 2016 16:25:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A94E82006D; Fri, 8 Jul 2016 16:25:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5B18E3BC34EA; Fri, 8 Jul 2016 16:25:51 +0200 (CEST) Date: Fri, 8 Jul 2016 16:25:51 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160708142551.GB24055@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A6BCB1A@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A6BCB1A@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model: Schedule end and duration; tags X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:25:56 -0000 Yes, I will try to get this documented. /js On Tue, Jun 14, 2016 at 12:56:57PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > Just an FYI - The text for the Schedule object (section 3.7) doesn't have a description for the schedule end and duration - for example why/when you would want to do this as we discussed yesterday. > The text also mentions options for the Schedule - I think you meant the actions associated with the schedule. > > Finally there isn't in this section a discussion on the use of the tags although section 3.9 does talk about tags for the task. I would suspect that tags for task/schedule/action would have similar text in section 3.7 as options in the sense of what they are intended to do. Since tags are only values - what is reported in the results is the union of the Task's, Schedule's and Action's tag. > > 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 Fri Jul 8 07:40:43 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB2F12D736 for ; Fri, 8 Jul 2016 07:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 o5zfcQT28piX for ; Fri, 8 Jul 2016 07:40:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DCA212D5C3 for ; Fri, 8 Jul 2016 07:40:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 28DADAD6; Fri, 8 Jul 2016 16:40:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id CU24MtcoVPNs; Fri, 8 Jul 2016 16:40:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 8 Jul 2016 16:40:38 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D41B20074; Fri, 8 Jul 2016 16:40:38 +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 QdZirkpD-S-n; Fri, 8 Jul 2016 16:40:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D2542006D; Fri, 8 Jul 2016 16:40:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9AD833BC37EB; Fri, 8 Jul 2016 16:40:36 +0200 (CEST) Date: Fri, 8 Jul 2016 16:40:36 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160708144036.GC24055@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A6BD110@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A6BD110@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model: Measurement Suppression Start and End X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:40:42 -0000 On Tue, Jun 14, 2016 at 04:31:21PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > Based on what we discussed in yesterday's meeting I am fine with the naming and definition of the events in the IM draft 09. > > However when I reviewed the Measurement Suppression object for events I found: > > ma-suppression-start: The optional event indicating when > suppression starts. The default value > is 'immediate'. > ma-suppression-end: The optional event indicating when > suppression ends. The default value is > 'indefinite'. > > I think you meant that when these nodes are not present the meaning for start is that an immediate event happens and for stop the suppression remains for an indefinite period of time? > Yes, I will try to describe this more clearly. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jul 8 07:55:44 2016 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B326512D4FB; Fri, 8 Jul 2016 07:55:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708145538.32176.30295.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 07:55:38 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-10.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:55:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : Information Model for Large-Scale Measurement Platforms (LMAP) Authors : Trevor Burbridge Philip Eardley Marcelo Bagnulo Juergen Schoenwaelder Filename : draft-ietf-lmap-information-model-10.txt Pages : 49 Date : 2016-07-08 Abstract: This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the Measurement Agent that can be implemented via one or more Control and Report protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-information-model-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 08:02:17 2016 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A3B12D612; Fri, 8 Jul 2016 08:02:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708150204.32176.47763.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 08:02:04 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-yang-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 15:02:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : A YANG Data Model for LMAP Measurement Agents Authors : Juergen Schoenwaelder Vaibhav Bajpai Filename : draft-ietf-lmap-yang-05.txt Pages : 73 Date : 2016-07-08 Abstract: This document defines a data model for Large-Scale Measurement Platforms (LMAP). The data model is defined using the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-yang-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-yang-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 08:06:36 2016 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE04A12D7D7; Fri, 8 Jul 2016 08:06:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708150617.32168.92967.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 08:06:17 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-restconf-03.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 15:06:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : Using RESTCONF with LMAP Measurement Agents Authors : Juergen Schoenwaelder Vaibhav Bajpai Filename : draft-ietf-lmap-restconf-03.txt Pages : 9 Date : 2016-07-08 Abstract: This document describes how RESTCONF can be used with a YANG data model for Large-Scale Measurement Platforms (LMAP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-restconf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-restconf-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-restconf-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 10 01:20:37 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD33412B009 for ; Sun, 10 Jul 2016 01:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.206 X-Spam-Level: X-Spam-Status: No, score=-8.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 L1qObfj4rtSp for ; Sun, 10 Jul 2016 01:20:34 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 41683127078 for ; Sun, 10 Jul 2016 01:20:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EBAgCWBIJX/xUHmMZdHoJSIS1WfAa3A?= =?us-ascii?q?oIPgXoihXYCgR84FAEBAQEBAQEDYhwLglE5PAEBAQEBASMCPjEDEgsQXgEMCRU?= =?us-ascii?q?dORQSAQQTCBqIDgENn1OFEpksAQsBHwWGKIhwAQEdgkcLWIIvBZkYAYYMii+EW?= =?us-ascii?q?IMihUiQDx42g3FuiEU2AX4BAQE?= X-IPAS-Result: =?us-ascii?q?A2EBAgCWBIJX/xUHmMZdHoJSIS1WfAa3AoIPgXoihXYCgR8?= =?us-ascii?q?4FAEBAQEBAQEDYhwLglE5PAEBAQEBASMCPjEDEgsQXgEMCRUdORQSAQQTCBqID?= =?us-ascii?q?gENn1OFEpksAQsBHwWGKIhwAQEdgkcLWIIvBZkYAYYMii+EWIMihUiQDx42g3F?= =?us-ascii?q?uiEU2AX4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,340,1464667200"; d="scan'208,217";a="182829785" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Jul 2016 04:20:31 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 10 Jul 2016 04:20:32 -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; Sun, 10 Jul 2016 10:20:29 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: WGLC for draft-ietf-lmap-information-model-10 Thread-Index: AdHag+qKiZkUncDUTdC+/Q8kz8WA3w== Date: Sun, 10 Jul 2016 08:20:28 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA752355BF@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA752355BFAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] WGLC for draft-ietf-lmap-information-model-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jul 2016 08:20:36 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA752355BFAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This message starts an LMAP Working Group Last Call for the I-D 'Informatio= n Model for Large Scale Measurement Platforms (LMAP)' which can be found at= https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/. Pleas= e send your comments, questions and concerns to the WG mail list lmap@ietf.= org. The WGLC extends for three weeks until Sunday 7/= 31, but it would be very useful to send comments before the IETF 96 meeting= of the WG which will take place on Friday 7/22. If you believe that the document is ready for submission to the IESG as it = stands - please say it as well. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA752355BFAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This message starts an LMAP Working Group Last Call = for the I-D ‘Information Model for Large Scale Measurement Platforms = (LMAP)’ which can be found at https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/. Please send your comments, questions and concerns to the WG mail list lmap@ietf.org. The WGLC extends for th= ree weeks until Sunday 7/31, but it would be very useful to send comments b= efore the IETF 96 meeting of the WG which will take place on Friday 7/22.

 

If you believe that the document is ready for submis= sion to the IESG as it stands – please say it as well.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA752355BFAZFFEXMB04globa_-- From nobody Sun Jul 10 01:23:19 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CEE12B009 for ; Sun, 10 Jul 2016 01:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.206 X-Spam-Level: X-Spam-Status: No, score=-8.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 2AYZJCa8dLul for ; Sun, 10 Jul 2016 01:23:15 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 9BBC4127078 for ; Sun, 10 Jul 2016 01:23:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EBAgCWBIJX/yYyC4ddHoJSIS1WfAa3A?= =?us-ascii?q?oIPgXoihXYCgR84FAEBAQEBAQEDYhwLglE5PAEBAQEBASMCPjEDEgsQXgEMCRU?= =?us-ascii?q?dORQSAQQTCBqIDgENn1OFEpksAQsBHwWGKIhwAQEdgkcLWIIvBZkYAYYMii+EW?= =?us-ascii?q?IMihUiQDx42g3FuiEU2AX4BAQE?= X-IPAS-Result: =?us-ascii?q?A2EBAgCWBIJX/yYyC4ddHoJSIS1WfAa3AoIPgXoihXYCgR8?= =?us-ascii?q?4FAEBAQEBAQEDYhwLglE5PAEBAQEBASMCPjEDEgsQXgEMCRUdORQSAQQTCBqID?= =?us-ascii?q?gENn1OFEpksAQsBHwWGKIhwAQEdgkcLWIIvBZkYAYYMii+EWIMihUiQDx42g3F?= =?us-ascii?q?uiEU2AX4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,340,1464667200"; d="scan'208,217";a="182829888" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Jul 2016 04:23:14 -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/AES256-SHA; 10 Jul 2016 04:23:14 -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; Sun, 10 Jul 2016 10:23:12 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: WGLC for draft-ietf-lmap-yang-05.txt Thread-Index: AdHahEuYn6BF94ZHRZ+eXAc/Cpaf8Q== Date: Sun, 10 Jul 2016 08:23:11 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA752355D3@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA752355D3AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] WGLC for draft-ietf-lmap-yang-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jul 2016 08:23:17 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA752355D3AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This message starts an LMAP Working Group Last Call for the I-D 'A YANG Dat= a Model for LMAP Measurement Agents' which can be found at https://datatrac= ker.ietf.org/doc/draft-ietf-lmap-yang/. Please send your comments, question= s and concerns to the WG mail list lmap@ietf.org. The= WGLC extends for three weeks until Sunday 7/31, but it would be very usefu= l to send comments before the IETF 96 meeting of the WG which will take pla= ce on Friday 7/22. If you believe that the document is ready for submission to the IESG as it = stands - please say it as well. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA752355D3AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This message starts an LMAP Working Group Last Call = for the I-D ‘A YANG Data Model for LMAP Measurement Agents’ whi= ch can be found at https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/. = Please send your comments, questions and concerns to the WG mail list lmap@ietf.org. Th= e WGLC extends for three weeks until Sunday 7/31, but it would be very usef= ul to send comments before the IETF 96 meeting of the WG which will take pl= ace on Friday 7/22.

 

If you believe that the document is ready for submis= sion to the IESG as it stands – please say it as well.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA752355D3AZFFEXMB04globa_-- From nobody Sun Jul 10 01:25:25 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7EF128E19 for ; Sun, 10 Jul 2016 01:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.206 X-Spam-Level: X-Spam-Status: No, score=-8.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 FwI1Ain5bMSf for ; Sun, 10 Jul 2016 01:25:23 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 93D2A127078 for ; Sun, 10 Jul 2016 01:25:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EBAgA7BYJX/xUHmMZdHoJSIS1WfAa3A?= =?us-ascii?q?oIPgXoihXYCgR84FAEBAQEBAQEDYhwLglE5PAEBAQEBASMCPjEDEgsQXgEMCRU?= =?us-ascii?q?dORQSAQQTCBqIDgENn1SFEpksAQsBHwWGKIhwAQEdgkcLWIIvBZkYAYYMii+EW?= =?us-ascii?q?IMihUiQDx42g3FuiEU2AX4BAQE?= X-IPAS-Result: =?us-ascii?q?A2EBAgA7BYJX/xUHmMZdHoJSIS1WfAa3AoIPgXoihXYCgR8?= =?us-ascii?q?4FAEBAQEBAQEDYhwLglE5PAEBAQEBASMCPjEDEgsQXgEMCRUdORQSAQQTCBqID?= =?us-ascii?q?gENn1SFEpksAQsBHwWGKIhwAQEdgkcLWIIvBZkYAYYMii+EWIMihUiQDx42g3F?= =?us-ascii?q?uiEU2AX4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,340,1464667200"; d="scan'208,217";a="161534481" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Jul 2016 04:25:19 -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/AES256-SHA; 10 Jul 2016 04:25:20 -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, 10 Jul 2016 10:25:18 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: WGLC for draft-ietf-lmap-restconf-03.txt Thread-Index: AdHahJaL7o/XQdRbTRywMlnlpG6nCw== Date: Sun, 10 Jul 2016 08:25:17 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA752355E4@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA752355E4AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] WGLC for draft-ietf-lmap-restconf-03.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jul 2016 08:25:24 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA752355E4AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This message starts an LMAP Working Group Last Call for the I-D 'Using REST= CONF with LMAP Measurement Agents' which can be found at https://datatracke= r.ietf.org/doc/draft-ietf-lmap-restconf/. Please send your comments, questi= ons and concerns to the WG mail list lmap@ietf.org. T= he WGLC extends for three weeks until Sunday 7/31, but it would be very use= ful to send comments before the IETF 96 meeting of the WG which will take p= lace on Friday 7/22. If you believe that the document is ready for submission to the IESG as it = stands - please say it as well. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA752355E4AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This message starts an LMAP Working Group Last Call = for the I-D ‘Using RESTCONF with LMAP Measurement Agents’ which= can be found at https://datatracker.ietf.org/doc/draft-ietf-lmap-restconf/= . Please send your comments, questions and concerns to the WG mail list lmap@ietf.org. Th= e WGLC extends for three weeks until Sunday 7/31, but it would be very usef= ul to send comments before the IETF 96 meeting of the WG which will take pl= ace on Friday 7/22.

 

If you believe that the document is ready for submis= sion to the IESG as it stands – please say it as well.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA752355E4AZFFEXMB04globa_-- From nobody Sun Jul 10 01:28:02 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B6112B009 for ; Sun, 10 Jul 2016 01:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 9Rvtyxg5Fe5M for ; Sun, 10 Jul 2016 01:27:58 -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 54EDA127078 for ; Sun, 10 Jul 2016 01:27:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 58E2AF9D; Sun, 10 Jul 2016 10:27:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4Gy9rkWqytmB; Sun, 10 Jul 2016 10:27:52 +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; Sun, 10 Jul 2016 10:27:55 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD76D2006D; Sun, 10 Jul 2016 10:27:54 +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 oNbT_pGF3o7i; Sun, 10 Jul 2016 10:27:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 920A520063; Sun, 10 Jul 2016 10:27:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4BC293BC7F52; Sun, 10 Jul 2016 10:27:52 +0200 (CEST) Date: Sun, 10 Jul 2016 10:27:51 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20160710082751.GA30888@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA752355BF@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA752355BF@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 10 Jul 2016 08:28:00 -0000 On Sun, Jul 10, 2016 at 08:20:28AM +0000, Romascanu, Dan (Dan) wrote: > This message starts an LMAP Working Group Last Call for the I-D 'Information Model for Large Scale Measurement Platforms (LMAP)' which can be found at https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/. Please send your comments, questions and concerns to the WG mail list lmap@ietf.org. The WGLC extends for three weeks until Sunday 7/31, but it would be very useful to send comments before the IETF 96 meeting of the WG which will take place on Friday 7/22. > > If you believe that the document is ready for submission to the IESG as it stands - please say it as well. > I believe the document is ready to go once we have resolved the issues listed below (which I hope is an achievable goal for the Berlin meeting). Appendix A. Open Issues o There is a proposal to add a cycle number to the result reports but it is still unclear how exactly the cycle number is calculated and how parameters needed to calculate the cycle interval are conveyed to the MA. o There is a proposal to remove the well-known Channel option name from the information model. o There is a potentially unresolved discussion around the ma- schedule-end and ma-schedule-duration. o It may be useful to add ma-capability-tags so that MAs could be tagged with additional information (e.g., dsl, cable, home, office, nat, ipv4, ipv6, ...). /js PS: In preparation of -10, I have gone through the whole document in order to spot any remaining inconsistencies (and I fixed a few ones I found). It is probably a good time for others as well to read the whole document now. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Jul 10 01:35:12 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAD2128E19 for ; Sun, 10 Jul 2016 01:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 2Jbra1OtGYlp for ; Sun, 10 Jul 2016 01:35:08 -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 5B63A127078 for ; Sun, 10 Jul 2016 01:35:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1C097F9D; Sun, 10 Jul 2016 10:35:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yrzwgXDapBRs; Sun, 10 Jul 2016 10:35:03 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 10 Jul 2016 10:35:05 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F74420069; Sun, 10 Jul 2016 10:35:05 +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 djoXk4X_TDBq; Sun, 10 Jul 2016 10:35:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B040220063; Sun, 10 Jul 2016 10:35:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A0B343BC7FED; Sun, 10 Jul 2016 10:35:04 +0200 (CEST) Date: Sun, 10 Jul 2016 10:35:04 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20160710083504.GB30888@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA752355D3@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA752355D3@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] WGLC for draft-ietf-lmap-yang-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 10 Jul 2016 08:35:10 -0000 On Sun, Jul 10, 2016 at 08:23:11AM +0000, Romascanu, Dan (Dan) wrote: > This message starts an LMAP Working Group Last Call for the I-D 'A YANG Data Model for LMAP Measurement Agents' which can be found at https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/. Please send your comments, questions and concerns to the WG mail list lmap@ietf.org. The WGLC extends for three weeks until Sunday 7/31, but it would be very useful to send comments before the IETF 96 meeting of the WG which will take place on Friday 7/22. > > If you believe that the document is ready for submission to the IESG as it stands - please say it as well. > I believe the document is almost ready to go once we have resolved the issues listed below (which I hope is an achievable goal for the Berlin meeting) and we aligned it with any pending issues on the information model document. Appendix A. Open Issues A.1. The information model makes a distinction between control tasks and schedules and instruction tasks and schedules. The YANG model kind of ignores this distinction. Should we have special subtrees to separate control from instruction tasks and schedules? Or should we somehow flag control tasks and schedules? It may be conceivable that people want to apply different access control policies for control schedules and for instruction schedules (which would favour a solution that separates things into different subtrees). A.2. Examples Do we want to keep the examples? If yes, they should be better aligned. If we keep the examples, do we need to keep both versions (XML and JSON)? I would love to get a YANG doctors review at this point (e.g. Martin, Lada) since it is always good to have someone's opinion who has not been involved in the writing process. /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 Sun Jul 10 01:36:26 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26497128E19 for ; Sun, 10 Jul 2016 01:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.207 X-Spam-Level: X-Spam-Status: No, score=-8.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 73AhOTGITBXD for ; Sun, 10 Jul 2016 01:36:23 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 B7F0C127078 for ; Sun, 10 Jul 2016 01:36:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FoAwBQCIJX/yYyC4ddGgEBAQGCcy1Wf?= =?us-ascii?q?AaNJJoFAY9Ygg+BehqBdIQKAoEfOBQBAQEBAQEBA2Ing0VbPAEBAQECARILHT8?= =?us-ascii?q?FBwQCAQgNAQIBBAEBAQoUCQcyFAkIAQEEDgUIGogGCAGke5krAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHIYohEyEQ4Mqgi8FjgaLEgGGDIJ6hzVOhywMhTyQDx42g3F?= =?us-ascii?q?uiHsBfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2FoAwBQCIJX/yYyC4ddGgEBAQGCcy1WfAaNJJoFAY9Ygg+?= =?us-ascii?q?BehqBdIQKAoEfOBQBAQEBAQEBA2Ing0VbPAEBAQECARILHT8FBwQCAQgNAQIBB?= =?us-ascii?q?AEBAQoUCQcyFAkIAQEEDgUIGogGCAGke5krAQEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BHIYohEyEQ4Mqgi8FjgaLEgGGDIJ6hzVOhywMhTyQDx42g3FuiHsBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,340,1464667200"; d="scan'208";a="182830632" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Jul 2016 04:36:22 -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/AES256-SHA; 10 Jul 2016 04:36:22 -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; Sun, 10 Jul 2016 10:36:20 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [lmap] WGLC for draft-ietf-lmap-information-model-10 Thread-Index: AdHag+qKiZkUncDUTdC+/Q8kz8WA3///4IiA///eUgA= Date: Sun, 10 Jul 2016 08:36:19 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA75235606@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA752355BF@AZ-FFEXMB04.global.avaya.com> <20160710082751.GA30888@elstar.local> In-Reply-To: <20160710082751.GA30888@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jul 2016 08:36:25 -0000 Right. The scope of this WGLC is to have as many people involved in the rev= iew of the document which includes open issues and any other comments about= the documents.=20 Thanks for driving this editing work.=20 Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Sunday, July 10, 2016 11:28 AM > To: Romascanu, Dan (Dan) > Cc: lmap@ietf.org > Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-10 >=20 > On Sun, Jul 10, 2016 at 08:20:28AM +0000, Romascanu, Dan (Dan) wrote: > > This message starts an LMAP Working Group Last Call for the I-D > 'Information Model for Large Scale Measurement Platforms (LMAP)' which .... > I believe the document is ready to go once we have resolved the issues li= sted > below (which I hope is an achievable goal for the Berlin meeting). >=20 > Appendix A. Open Issues >=20 > o There is a proposal to add a cycle number to the result reports > but it is still unclear how exactly the cycle number is calculated > and how parameters needed to calculate the cycle interval are > conveyed to the MA. >=20 > o There is a proposal to remove the well-known Channel option name > from the information model. >=20 > o There is a potentially unresolved discussion around the ma- > schedule-end and ma-schedule-duration. >=20 > o It may be useful to add ma-capability-tags so that MAs could be > tagged with additional information (e.g., dsl, cable, home, > office, nat, ipv4, ipv6, ...). >=20 > /js >=20 > PS: In preparation of -10, I have gone through the whole document in > order to spot any remaining inconsistencies (and I fixed a few > ones I found). It is probably a good time for others as well to > read the whole document now. >=20 > -- From nobody Sun Jul 10 01:37:36 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B936127078 for ; Sun, 10 Jul 2016 01:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.207 X-Spam-Level: X-Spam-Status: No, score=-8.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 unf_CIeDaokz for ; Sun, 10 Jul 2016 01:37:33 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 3B26D128E19 for ; Sun, 10 Jul 2016 01:37:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2H9AwBQCIJX/yYyC4ddGwEBAYJzLVZ8B?= =?us-ascii?q?o0kmgUBj1iCD4F6GoF0hAoCgR84FAEBAQEBAQEDYieDRVs8AQEBAQMSKD8MBAI?= =?us-ascii?q?BCA0BAgEEAQELFAkHMhQJCAEBBA4FCBqIDgGke5krAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHIYohEyEQ4Mqgi8FmRgBhgyKGWSHLIVIkA8eNoNxboh7AX4BAQE?= X-IPAS-Result: =?us-ascii?q?A2H9AwBQCIJX/yYyC4ddGwEBAYJzLVZ8Bo0kmgUBj1iCD4F?= =?us-ascii?q?6GoF0hAoCgR84FAEBAQEBAQEDYieDRVs8AQEBAQMSKD8MBAIBCA0BAgEEAQELF?= =?us-ascii?q?AkHMhQJCAEBBA4FCBqIDgGke5krAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYohEy?= =?us-ascii?q?EQ4Mqgi8FmRgBhgyKGWSHLIVIkA8eNoNxboh7AX4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,340,1464667200"; d="scan'208";a="182830674" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Jul 2016 04:37:32 -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/AES256-SHA; 10 Jul 2016 04:37:31 -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, 10 Jul 2016 04:37:30 -0400 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [lmap] WGLC for draft-ietf-lmap-yang-05.txt Thread-Index: AdHahEuYn6BF94ZHRZ+eXAc/Cpaf8f//4coA///eDcA= Date: Sun, 10 Jul 2016 08:37:29 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA75235618@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA752355D3@AZ-FFEXMB04.global.avaya.com> <20160710083504.GB30888@elstar.local> In-Reply-To: <20160710083504.GB30888@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] WGLC for draft-ietf-lmap-yang-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jul 2016 08:37:34 -0000 This should be easy as soon as I can talk with the secretary of the YANG Do= ctors team :-)=20 Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Sunday, July 10, 2016 11:35 AM > To: Romascanu, Dan (Dan) > Cc: lmap@ietf.org > Subject: Re: [lmap] WGLC for draft-ietf-lmap-yang-05.txt >=20 >=20 > I would love to get a YANG doctors review at this point (e.g. Martin, > Lada) since it is always good to have someone's opinion who has not been > involved in the writing process. >=20 > /js >=20 From nobody Sun Jul 10 01:43:32 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63D012B01A for ; Sun, 10 Jul 2016 01:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 vM_cDfDynfbS for ; Sun, 10 Jul 2016 01:43:29 -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 ABC2D12B009 for ; Sun, 10 Jul 2016 01:43:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 79633F7D; Sun, 10 Jul 2016 10:43:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id R3O9bth5ycpL; Sun, 10 Jul 2016 10:43:25 +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; Sun, 10 Jul 2016 10:43:27 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6370820069; Sun, 10 Jul 2016 10:43: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 SlBkK7ICaE_u; Sun, 10 Jul 2016 10:43: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 4A18220063; Sun, 10 Jul 2016 10:43:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 22C273BC80B2; Sun, 10 Jul 2016 10:43:26 +0200 (CEST) Date: Sun, 10 Jul 2016 10:43:26 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20160710084326.GA30984@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA752355E4@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA752355E4@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] WGLC for draft-ietf-lmap-restconf-03.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 10 Jul 2016 08:43:31 -0000 On Sun, Jul 10, 2016 at 08:25:17AM +0000, Romascanu, Dan (Dan) wrote: > This message starts an LMAP Working Group Last Call for the I-D 'Using RESTCONF with LMAP Measurement Agents' which can be found at https://datatracker.ietf.org/doc/draft-ietf-lmap-restconf/. Please send your comments, questions and concerns to the WG mail list lmap@ietf.org. The WGLC extends for three weeks until Sunday 7/31, but it would be very useful to send comments before the IETF 96 meeting of the WG which will take place on Friday 7/22. > > If you believe that the document is ready for submission to the IESG as it stands - please say it as well. > I believe this document is not yet ready. I have come to the conclusion that this document should explain how the LMAP data models works together with RESTCONF(/NETCONF) configuration data models. Many MAs will require call-home in order to communicate through firewalls and I think this document should explain how the pieces worked on in the NETCONF WG complement the work done in the LMAP WG. If people share this view, then (a) we need to spend some time to work out the details how things work together and (b) this document can't be finalized until the corresponding work in the NETCONF WG is stable. It might also help to have some running code, lets see whether the hackathon gets us closer to this (looking of course for volunteers). /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 Jul 11 09:26:36 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8681E12D5A1 for ; Mon, 11 Jul 2016 09:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 p_Q3g2K7QVRk for ; Mon, 11 Jul 2016 09:26:33 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 A9D4812D5A8 for ; Mon, 11 Jul 2016 09:26:33 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 0D528F0CB4717 for ; Mon, 11 Jul 2016 16:26:30 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u6BGQW10012206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 11 Jul 2016 16:26:32 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 u6BGQVH3006955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 11 Jul 2016 16:26:32 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.10]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 11 Jul 2016 12:26:12 -0400 From: "Carey, Timothy (Nokia - US)" To: "lmap@ietf.org" Thread-Topic: Information Model - draft 10: Definition of an active schedule Thread-Index: AdHbkO9rjWOQE9lVT8m8iKb7+R60DQ== Date: Mon, 11 Jul 2016 16:26:11 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6DC709@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_9966516C6EB5FC4381E05BF80AA55F77012A6DC709US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Information Model - draft 10: Definition of an active schedule X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 16:26:35 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A6DC709US70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, In IM draft 10 we have documented a constraint that only 1 instance of a sc= hedule is "active" at a time. I assume an "active" schedule can be a schedule with a state whose value is= either Suppressed or Running? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A6DC709US70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

In IM draft 10 we have documented a constraint that = only 1 instance of a schedule is “active” at a time.=

 

I assume an “active” schedule can be a s= chedule with a state whose value is either Suppressed or Running?

 

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77012A6DC709US70UWXCHMBA0_-- From nobody Mon Jul 11 10:05:19 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F9F12D58C for ; Mon, 11 Jul 2016 10:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iUgz_6gv3Zkt for ; Mon, 11 Jul 2016 10:05:17 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 AF46412D096 for ; Mon, 11 Jul 2016 10:05:17 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id CA7CD58FD0D8 for ; Mon, 11 Jul 2016 17:05:14 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u6BH5G3Y003402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 11 Jul 2016 17:05:16 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 u6BH5Fwq023396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 11 Jul 2016 17:05:15 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.10]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Mon, 11 Jul 2016 13:05:15 -0400 From: "Carey, Timothy (Nokia - US)" To: "lmap@ietf.org" Thread-Topic: Information Model draft 10: Storage status parameter Thread-Index: AdHblmQtLcfO3MYwQYGkte0J9p6pVw== Date: Mon, 11 Jul 2016 17:05:14 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6DC858@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_9966516C6EB5FC4381E05BF80AA55F77012A6DC858US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Information Model draft 10: Storage status parameter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 17:05:19 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A6DC858US70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, I see we added a parameter in the status for schedules and actions that rep= orts the "storage" - not sure if this is memory or disk but at any rate - t= hese parameters might be difficult to obtain for some MAs. Could we please = make these parameters optional. Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A6DC858US70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

I see we added a parameter in the status for schedul= es and actions that reports the “storage” - not sure if this is= memory or disk but at any rate – these parameters might be difficult= to obtain for some MAs. Could we please make these parameters optional.

 

Thanks,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77012A6DC858US70UWXCHMBA0_-- From nobody Mon Jul 11 10:50:28 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340D512D5F8 for ; Mon, 11 Jul 2016 10:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 9gu5ILfq14kZ for ; Mon, 11 Jul 2016 10:50: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 755C512D60E for ; Mon, 11 Jul 2016 10:50: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 4B1A7765; Mon, 11 Jul 2016 19:50:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1UL96Jt-3coe; Mon, 11 Jul 2016 19:50: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; Mon, 11 Jul 2016 19:50:24 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8CC1F20069; Mon, 11 Jul 2016 19:50:24 +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 d79Or6GShfRI; Mon, 11 Jul 2016 19:50:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF06820063; Mon, 11 Jul 2016 19:50:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8886D3BCB08B; Mon, 11 Jul 2016 19:50:23 +0200 (CEST) Date: Mon, 11 Jul 2016 19:50:23 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160711175023.GB33652@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A6DC709@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A6DC709@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model - draft 10: Definition of an active schedule X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 17:50:28 -0000 On Mon, Jul 11, 2016 at 04:26:11PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > In IM draft 10 we have documented a constraint that only 1 instance of a schedule is "active" at a time. > > I assume an "active" schedule can be a schedule with a state whose value is either Suppressed or Running? > For me, an active schedule is one that is running. I suggest the following new wording: communicate with the Controller. A specific Schedule can only be active once. Attempts to start a Schedule while the same Schedule is still running will fail. /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 Jul 11 10:59:37 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3938C12D5C9 for ; Mon, 11 Jul 2016 10:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 6Rdopco4fGJG for ; Mon, 11 Jul 2016 10:59: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 07A1712D0CD for ; Mon, 11 Jul 2016 10:59:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C90BDFAA; Mon, 11 Jul 2016 19:59:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UTDij-xlkA0b; Mon, 11 Jul 2016 19:59: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, 11 Jul 2016 19:59:33 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1807320069; Mon, 11 Jul 2016 19:59:33 +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 IQf-JVFUgB9O; Mon, 11 Jul 2016 19:59:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DBFD20063; Mon, 11 Jul 2016 19:59:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 428133BCB201; Mon, 11 Jul 2016 19:59:32 +0200 (CEST) Date: Mon, 11 Jul 2016 19:59:32 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160711175932.GD33652@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A6DC858@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A6DC858@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model draft 10: Storage status parameter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 17:59:36 -0000 On Mon, Jul 11, 2016 at 05:05:14PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > I see we added a parameter in the status for schedules and actions that reports the "storage" - not sure if this is memory or disk but at any rate - these parameters might be difficult to obtain for some MAs. Could we please make these parameters optional. > I do not really know what 'mandatory' and 'optional' means for an information model. I am not sure I really want to investigate this question. /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 Jul 11 11:18:14 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EF712D624 for ; Mon, 11 Jul 2016 11:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 rMfqlZU6Y1yq for ; Mon, 11 Jul 2016 11:18:10 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 8983712B038 for ; Mon, 11 Jul 2016 11:18:10 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id A4F36B5E0BC88; Mon, 11 Jul 2016 18:18:07 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u6BII8dS003520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2016 18:18:09 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u6BIH8Hq030265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Jul 2016 18:18:08 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.10]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 11 Jul 2016 14:17:40 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Model - draft 10: Definition of an active schedule Thread-Index: AdHbkO9rjWOQE9lVT8m8iKb7+R60DQALUpaAAAdvCmA= Date: Mon, 11 Jul 2016 18:17:39 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6DC992@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A6DC709@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160711175023.GB33652@elstar.local> In-Reply-To: <20160711175023.GB33652@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: "lmap@ietf.org" Subject: Re: [lmap] Information Model - draft 10: Definition of an active schedule X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 18:18:12 -0000 Ok works for me -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, July 11, 2016 12:50 PM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information Model - draft 10: Definition of an active s= chedule On Mon, Jul 11, 2016 at 04:26:11PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > In IM draft 10 we have documented a constraint that only 1 instance of a = schedule is "active" at a time. >=20 > I assume an "active" schedule can be a schedule with a state whose value = is either Suppressed or Running? > For me, an active schedule is one that is running. I suggest the following = new wording: communicate with the Controller. A specific Schedule can only be active once. Attempts to start a Schedule while the same Schedule is still running will fail. /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 Mon Jul 11 11:19:42 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E31312D63A for ; Mon, 11 Jul 2016 11:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1b8sLFWnjld5 for ; Mon, 11 Jul 2016 11:19:39 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 80C7C12B038 for ; Mon, 11 Jul 2016 11:19:39 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 58B4664651F97; Mon, 11 Jul 2016 18:19:36 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u6BIJc72009926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2016 18:19:38 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 u6BIJacb032392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Jul 2016 18:19:38 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.10]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 11 Jul 2016 14:19:25 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Model draft 10: Storage status parameter Thread-Index: AdHblmQtLcfO3MYwQYGkte0J9p6pVwAKRzQAAAe2u/A= Date: Mon, 11 Jul 2016 18:19:24 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6DC9A1@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A6DC858@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160711175932.GD33652@elstar.local> In-Reply-To: <20160711175932.GD33652@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: "lmap@ietf.org" Subject: Re: [lmap] Information Model draft 10: Storage status parameter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 18:19:41 -0000 Optional elements has the "[]" construct -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, July 11, 2016 1:00 PM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information Model draft 10: Storage status parameter On Mon, Jul 11, 2016 at 05:05:14PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > I see we added a parameter in the status for schedules and actions that r= eports the "storage" - not sure if this is memory or disk but at any rate -= these parameters might be difficult to obtain for some MAs. Could we pleas= e make these parameters optional. >=20 I do not really know what 'mandatory' and 'optional' means for an informati= on model. I am not sure I really want to investigate this question. /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 Tue Jul 12 06:53:30 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FE612DC45 for ; Tue, 12 Jul 2016 06:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 JYqVYb70F6G3 for ; Tue, 12 Jul 2016 06:53:24 -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 7D34912D9BE for ; Tue, 12 Jul 2016 06:19: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 B25FD740; Tue, 12 Jul 2016 15:19:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zPdMjCivu_iZ; Tue, 12 Jul 2016 15:19:08 +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, 12 Jul 2016 15:19:09 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A0FD020069; Tue, 12 Jul 2016 15:19:09 +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 FNOmriI1VXnh; Tue, 12 Jul 2016 15:19:08 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 845E020063; Tue, 12 Jul 2016 15:19:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B9CC93BCD098; Tue, 12 Jul 2016 15:19:06 +0200 (CEST) Date: Tue, 12 Jul 2016 15:19:06 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160712131906.GA35507@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A6DC858@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160711175932.GD33652@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DC9A1@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A6DC9A1@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model draft 10: Storage status parameter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 13:53:28 -0000 Oh, this gets interesting. The text says: An optional property is enclosed by square brackets, [ ], Now does this mean that [foo] is essentially a shortcut of foo<0..1> or foo<0..*> (like it is in ABNF) or is [foo] indicating that this is a portion of the information model that can be ignored by a data model. So far I have interpreted it in the ABNF sense but I now see that other interpretations are possible. Back to the -storage definitions: What makes them difficult to implement? Is it the fact that it says "amount of allocated physical storage and not the storage used by logical data records" or are there any other reasons why this is difficult to implement? /js On Mon, Jul 11, 2016 at 06:19:24PM +0000, Carey, Timothy (Nokia - US) wrote: > Optional elements has the "[]" construct > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, July 11, 2016 1:00 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] Information Model draft 10: Storage status parameter > > On Mon, Jul 11, 2016 at 05:05:14PM +0000, Carey, Timothy (Nokia - US) wrote: > > Juergen, > > > > I see we added a parameter in the status for schedules and actions that reports the "storage" - not sure if this is memory or disk but at any rate - these parameters might be difficult to obtain for some MAs. Could we please make these parameters optional. > > > > I do not really know what 'mandatory' and 'optional' means for an information model. I am not sure I really want to investigate this question. > > /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 Jul 12 07:07:05 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFF012D8CF for ; Tue, 12 Jul 2016 07:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0h52YrgC6s4E for ; Tue, 12 Jul 2016 07:06:59 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 0E28312D88A for ; Tue, 12 Jul 2016 06:25:31 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id A25C424A50781; Tue, 12 Jul 2016 13:25:28 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u6CDPTIP008183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Jul 2016 13:25:30 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 u6CDPTlx008152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Jul 2016 13:25:29 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.10]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 12 Jul 2016 09:25:29 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Model draft 10: Storage status parameter Thread-Index: AdHblmQtLcfO3MYwQYGkte0J9p6pVwAKRzQAAAe2u/AAIMibAAAIWbyQ Date: Tue, 12 Jul 2016 13:25:30 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6DD6BA@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A6DC858@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160711175932.GD33652@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DC9A1@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160712131906.GA35507@elstar.local> In-Reply-To: <20160712131906.GA35507@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] Information Model draft 10: Storage status parameter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 14:07:03 -0000 Well I didn't know if you were talking about memory allocated to a process/= thread or some other storage. We need to clear that up first. If it is memory allocation that would be I would have to know the memory us= ed by a task (diagnostic) which might be just a feature of an existing task= . For example - some diagnostics use DNS resolution and ping to determine con= nectivity. The MA may not know or be able to know the current memory usage = of the IP stack process or the DNS client. Not all CPEs use a Linux framewo= rk some use proprietary Operating systems which might not have these capabi= lities. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, July 12, 2016 8:19 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information Model draft 10: Storage status parameter Oh, this gets interesting. The text says: An optional property is enclosed by square brackets, [ ], Now does this mean that [foo] is essentially a shortcut of foo<0..1> or foo= <0..*> (like it is in ABNF) or is [foo] indicating that this is a portion o= f the information model that can be ignored by a data model. So far I have = interpreted it in the ABNF sense but I now see that other interpretations a= re possible. Back to the -storage definitions: What makes them difficult to implement? = Is it the fact that it says "amount of allocated physical storage and not t= he storage used by logical data records" or are there any other reasons why= this is difficult to implement? /js On Mon, Jul 11, 2016 at 06:19:24PM +0000, Carey, Timothy (Nokia - US) wrote= : > Optional elements has the "[]" construct >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, July 11, 2016 1:00 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] Information Model draft 10: Storage status=20 > parameter >=20 > On Mon, Jul 11, 2016 at 05:05:14PM +0000, Carey, Timothy (Nokia - US) wro= te: > > Juergen, > >=20 > > I see we added a parameter in the status for schedules and actions that= reports the "storage" - not sure if this is memory or disk but at any rate= - these parameters might be difficult to obtain for some MAs. Could we ple= ase make these parameters optional. > >=20 >=20 > I do not really know what 'mandatory' and 'optional' means for an informa= tion model. I am not sure I really want to investigate this question. >=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 --=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 Jul 12 07:43:26 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC2312DF0F for ; Tue, 12 Jul 2016 07:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 iry28mlxV6Ok for ; Tue, 12 Jul 2016 07:43:24 -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 29EA212DFB6 for ; Tue, 12 Jul 2016 06:56: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 EB48E14E5; Tue, 12 Jul 2016 15:56:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id OhQeRDaTSVIU; Tue, 12 Jul 2016 15:56:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 12 Jul 2016 15:56:06 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7ACD20069; Tue, 12 Jul 2016 15:56:06 +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 yEkQdzRPusnJ; Tue, 12 Jul 2016 15:56:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C6F020063; Tue, 12 Jul 2016 15:56:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 422A43BCD1CD; Tue, 12 Jul 2016 15:56:05 +0200 (CEST) Date: Tue, 12 Jul 2016 15:56:05 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160712135605.GA35555@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A6DC858@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160711175932.GD33652@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DC9A1@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160712131906.GA35507@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DD6BA@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A6DD6BA@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model draft 10: Storage status parameter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 14:43:26 -0000 The descriptions say: The amount of storage allocated to the [schedule|action] in bytes. This object reports the amount of allocated physical storage and not the storage used by logical data records. Data models should use a 64-bit integer type. Is 'storage' ambiguous? For me, storage does _not_ include main memory. In my implementation, this is the amount of filesystem storage allocated to the schedules and actions. And physical storage means I count the number of data blocks occupied and not the amount data used on the data blocks. (If you have potentially many small files, the difference can be significant and allocation typically fails if you run out of physical storage.) /js On Tue, Jul 12, 2016 at 01:25:30PM +0000, Carey, Timothy (Nokia - US) wrote: > Well I didn't know if you were talking about memory allocated to a process/thread or some other storage. We need to clear that up first. > > If it is memory allocation that would be I would have to know the memory used by a task (diagnostic) which might be just a feature of an existing task. > > For example - some diagnostics use DNS resolution and ping to determine connectivity. The MA may not know or be able to know the current memory usage of the IP stack process or the DNS client. Not all CPEs use a Linux framework some use proprietary Operating systems which might not have these capabilities. > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, July 12, 2016 8:19 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] Information Model draft 10: Storage status parameter > > Oh, this gets interesting. The text says: > > An optional property is enclosed by square brackets, [ ], > > Now does this mean that [foo] is essentially a shortcut of foo<0..1> or foo<0..*> (like it is in ABNF) or is [foo] indicating that this is a portion of the information model that can be ignored by a data model. So far I have interpreted it in the ABNF sense but I now see that other interpretations are possible. > > Back to the -storage definitions: What makes them difficult to implement? Is it the fact that it says "amount of allocated physical storage and not the storage used by logical data records" or are there any other reasons why this is difficult to implement? > > /js > > On Mon, Jul 11, 2016 at 06:19:24PM +0000, Carey, Timothy (Nokia - US) wrote: > > Optional elements has the "[]" construct > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, July 11, 2016 1:00 PM > > To: Carey, Timothy (Nokia - US) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] Information Model draft 10: Storage status > > parameter > > > > On Mon, Jul 11, 2016 at 05:05:14PM +0000, Carey, Timothy (Nokia - US) wrote: > > > Juergen, > > > > > > I see we added a parameter in the status for schedules and actions that reports the "storage" - not sure if this is memory or disk but at any rate - these parameters might be difficult to obtain for some MAs. Could we please make these parameters optional. > > > > > > > I do not really know what 'mandatory' and 'optional' means for an information model. I am not sure I really want to investigate this question. > > > > /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 -- 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 Jul 12 07:48:21 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C5B12DD04 for ; Tue, 12 Jul 2016 07:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 mQ0HxkT-kY-Q for ; Tue, 12 Jul 2016 07:48:19 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 7029212E039 for ; Tue, 12 Jul 2016 07:04:34 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 4587B18181BB4; Tue, 12 Jul 2016 14:04:31 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u6CE4Wvd017408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Jul 2016 14:04:33 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 u6CE4VWi016424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Jul 2016 14:04:32 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.10]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Tue, 12 Jul 2016 10:04:20 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Model draft 10: Storage status parameter Thread-Index: AdHblmQtLcfO3MYwQYGkte0J9p6pVwAKRzQAAAe2u/AAIMibAAAIWbyQ///Hh4CAAEHAEA== Date: Tue, 12 Jul 2016 14:04:21 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6DD807@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A6DC858@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160711175932.GD33652@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DC9A1@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160712131906.GA35507@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DD6BA@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160712135605.GA35555@elstar.local> In-Reply-To: <20160712135605.GA35555@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] Information Model draft 10: Storage status parameter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 14:48:21 -0000 You want the actual size, in octets, of a schedule or action that resides i= n a device's non-volatile memory, correct? -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, July 12, 2016 8:56 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information Model draft 10: Storage status parameter The descriptions say: The amount of storage allocated to the [schedule|action] in bytes. This object reports the amount of allocated physical storage and not the storage used by logical data records. Data models should use a 64-bit integer type. Is 'storage' ambiguous? For me, storage does _not_ include main memory. In = my implementation, this is the amount of filesystem storage allocated to th= e schedules and actions. And physical storage means I count the number of d= ata blocks occupied and not the amount data used on the data blocks. (If yo= u have potentially many small files, the difference can be significant and = allocation typically fails if you run out of physical storage.) /js On Tue, Jul 12, 2016 at 01:25:30PM +0000, Carey, Timothy (Nokia - US) wrote= : > Well I didn't know if you were talking about memory allocated to a proces= s/thread or some other storage. We need to clear that up first. >=20 > If it is memory allocation that would be I would have to know the memory = used by a task (diagnostic) which might be just a feature of an existing ta= sk. >=20 > For example - some diagnostics use DNS resolution and ping to determine c= onnectivity. The MA may not know or be able to know the current memory usag= e of the IP stack process or the DNS client. Not all CPEs use a Linux frame= work some use proprietary Operating systems which might not have these capa= bilities. >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, July 12, 2016 8:19 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] Information Model draft 10: Storage status=20 > parameter >=20 > Oh, this gets interesting. The text says: >=20 > An optional property is enclosed by square brackets, [ ], >=20 > Now does this mean that [foo] is essentially a shortcut of foo<0..1> or f= oo<0..*> (like it is in ABNF) or is [foo] indicating that this is a portion= of the information model that can be ignored by a data model. So far I hav= e interpreted it in the ABNF sense but I now see that other interpretations= are possible. >=20 > Back to the -storage definitions: What makes them difficult to implement?= Is it the fact that it says "amount of allocated physical storage and not= the storage used by logical data records" or are there any other reasons w= hy this is difficult to implement? >=20 > /js >=20 > On Mon, Jul 11, 2016 at 06:19:24PM +0000, Carey, Timothy (Nokia - US) wro= te: > > Optional elements has the "[]" construct > >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, July 11, 2016 1:00 PM > > To: Carey, Timothy (Nokia - US) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] Information Model draft 10: Storage status=20 > > parameter > >=20 > > On Mon, Jul 11, 2016 at 05:05:14PM +0000, Carey, Timothy (Nokia - US) w= rote: > > > Juergen, > > >=20 > > > I see we added a parameter in the status for schedules and actions th= at reports the "storage" - not sure if this is memory or disk but at any ra= te - these parameters might be difficult to obtain for some MAs. Could we p= lease make these parameters optional. > > >=20 > >=20 > > I do not really know what 'mandatory' and 'optional' means for an infor= mation model. I am not sure I really want to investigate this question. > >=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 >=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 Tue Jul 12 07:54:06 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD7812DA77 for ; Tue, 12 Jul 2016 07:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 Fh58XoRV04nS for ; Tue, 12 Jul 2016 07:54: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 2C35F12DA22 for ; Tue, 12 Jul 2016 07:14: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 F32066DA; Tue, 12 Jul 2016 16:14:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nxzkUKpr4y0e; Tue, 12 Jul 2016 16:14:50 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 12 Jul 2016 16:14:52 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 334C420069; Tue, 12 Jul 2016 16:14:52 +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 uf5Jjt0b0xJ9; Tue, 12 Jul 2016 16:14: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 D6D4120063; Tue, 12 Jul 2016 16:14:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C8B103BCD3A2; Tue, 12 Jul 2016 16:14:48 +0200 (CEST) Date: Tue, 12 Jul 2016 16:14:48 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160712141448.GD35555@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A6DC858@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160711175932.GD33652@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DC9A1@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160712131906.GA35507@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DD6BA@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160712135605.GA35555@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DD807@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A6DD807@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model draft 10: Storage status parameter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 14:54:05 -0000 No. I do not care about the static size of the executable. I want to report the amount of storage used to temporary buffer data. I had MAs running out of storage due to a reporting task failing (in one case it was an expired certificate) and measurement tasks filling storage until there were GBs of data buffered and the device was running into trouble. The last time we discussed this I think the agreement was not to go into controls that may deal with such situations but instead to make counters available that allow controllers to detect MA showing unusal leakage of storage. /js On Tue, Jul 12, 2016 at 02:04:21PM +0000, Carey, Timothy (Nokia - US) wrote: > You want the actual size, in octets, of a schedule or action that resides in a device's non-volatile memory, correct? > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, July 12, 2016 8:56 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] Information Model draft 10: Storage status parameter > > The descriptions say: > > The amount of storage allocated to the [schedule|action] in bytes. > This object reports the amount of allocated physical storage and not > the storage used by logical data records. Data models should use a > 64-bit integer type. > > Is 'storage' ambiguous? For me, storage does _not_ include main memory. In my implementation, this is the amount of filesystem storage allocated to the schedules and actions. And physical storage means I count the number of data blocks occupied and not the amount data used on the data blocks. (If you have potentially many small files, the difference can be significant and allocation typically fails if you run out of physical storage.) > > /js > > On Tue, Jul 12, 2016 at 01:25:30PM +0000, Carey, Timothy (Nokia - US) wrote: > > Well I didn't know if you were talking about memory allocated to a process/thread or some other storage. We need to clear that up first. > > > > If it is memory allocation that would be I would have to know the memory used by a task (diagnostic) which might be just a feature of an existing task. > > > > For example - some diagnostics use DNS resolution and ping to determine connectivity. The MA may not know or be able to know the current memory usage of the IP stack process or the DNS client. Not all CPEs use a Linux framework some use proprietary Operating systems which might not have these capabilities. > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, July 12, 2016 8:19 AM > > To: Carey, Timothy (Nokia - US) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] Information Model draft 10: Storage status > > parameter > > > > Oh, this gets interesting. The text says: > > > > An optional property is enclosed by square brackets, [ ], > > > > Now does this mean that [foo] is essentially a shortcut of foo<0..1> or foo<0..*> (like it is in ABNF) or is [foo] indicating that this is a portion of the information model that can be ignored by a data model. So far I have interpreted it in the ABNF sense but I now see that other interpretations are possible. > > > > Back to the -storage definitions: What makes them difficult to implement? Is it the fact that it says "amount of allocated physical storage and not the storage used by logical data records" or are there any other reasons why this is difficult to implement? > > > > /js > > > > On Mon, Jul 11, 2016 at 06:19:24PM +0000, Carey, Timothy (Nokia - US) wrote: > > > Optional elements has the "[]" construct > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Monday, July 11, 2016 1:00 PM > > > To: Carey, Timothy (Nokia - US) > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] Information Model draft 10: Storage status > > > parameter > > > > > > On Mon, Jul 11, 2016 at 05:05:14PM +0000, Carey, Timothy (Nokia - US) wrote: > > > > Juergen, > > > > > > > > I see we added a parameter in the status for schedules and actions that reports the "storage" - not sure if this is memory or disk but at any rate - these parameters might be difficult to obtain for some MAs. Could we please make these parameters optional. > > > > > > > > > > I do not really know what 'mandatory' and 'optional' means for an information model. I am not sure I really want to investigate this question. > > > > > > /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 > > -- > 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 Jul 12 07:59:31 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DD412D919 for ; Tue, 12 Jul 2016 07:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bUH3bujV1yur for ; Tue, 12 Jul 2016 07:59:27 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 E16E312DAE3 for ; Tue, 12 Jul 2016 07:27:26 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id CC016A94304F4; Tue, 12 Jul 2016 14:27:23 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u6CERPtr000811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Jul 2016 14:27:25 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u6CERP68025361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Jul 2016 14:27:25 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.10]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 12 Jul 2016 10:27:03 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Model draft 10: Storage status parameter Thread-Index: AdHblmQtLcfO3MYwQYGkte0J9p6pVwAKRzQAAAe2u/AAIMibAAAIWbyQ///Hh4CAAEHAEP//w3sAgABCnyA= Date: Tue, 12 Jul 2016 14:27:04 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6DD8F8@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A6DC858@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160711175932.GD33652@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DC9A1@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160712131906.GA35507@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DD6BA@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160712135605.GA35555@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DD807@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160712141448.GD35555@elstar.local> In-Reply-To: <20160712141448.GD35555@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] Information Model draft 10: Storage status parameter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 14:59:29 -0000 Ok - I wasn't thinking of the executable size either but the non-volatile m= emory used by the task or action in the process of executing the task and r= epresenting the report associated with the scheduled action? -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, July 12, 2016 9:15 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information Model draft 10: Storage status parameter No. I do not care about the static size of the executable. I want to report= the amount of storage used to temporary buffer data. I had MAs running out= of storage due to a reporting task failing (in one case it was an expired = certificate) and measurement tasks filling storage until there were GBs of = data buffered and the device was running into trouble. The last time we discussed this I think the agreement was not to go into co= ntrols that may deal with such situations but instead to make counters avai= lable that allow controllers to detect MA showing unusal leakage of storage= . /js On Tue, Jul 12, 2016 at 02:04:21PM +0000, Carey, Timothy (Nokia - US) wrote= : > You want the actual size, in octets, of a schedule or action that resides= in a device's non-volatile memory, correct? >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, July 12, 2016 8:56 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] Information Model draft 10: Storage status=20 > parameter >=20 > The descriptions say: >=20 > The amount of storage allocated to the [schedule|action] in bytes. > This object reports the amount of allocated physical storage and not > the storage used by logical data records. Data models should use a > 64-bit integer type. >=20 > Is 'storage' ambiguous? For me, storage does _not_ include main=20 > memory. In my implementation, this is the amount of filesystem storage=20 > allocated to the schedules and actions. And physical storage means I=20 > count the number of data blocks occupied and not the amount data used=20 > on the data blocks. (If you have potentially many small files, the=20 > difference can be significant and allocation typically fails if you=20 > run out of physical storage.) >=20 > /js >=20 > On Tue, Jul 12, 2016 at 01:25:30PM +0000, Carey, Timothy (Nokia - US) wro= te: > > Well I didn't know if you were talking about memory allocated to a proc= ess/thread or some other storage. We need to clear that up first. > >=20 > > If it is memory allocation that would be I would have to know the memor= y used by a task (diagnostic) which might be just a feature of an existing = task. > >=20 > > For example - some diagnostics use DNS resolution and ping to determine= connectivity. The MA may not know or be able to know the current memory us= age of the IP stack process or the DNS client. Not all CPEs use a Linux fra= mework some use proprietary Operating systems which might not have these ca= pabilities. > >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, July 12, 2016 8:19 AM > > To: Carey, Timothy (Nokia - US) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] Information Model draft 10: Storage status=20 > > parameter > >=20 > > Oh, this gets interesting. The text says: > >=20 > > An optional property is enclosed by square brackets, [ ], > >=20 > > Now does this mean that [foo] is essentially a shortcut of foo<0..1> or= foo<0..*> (like it is in ABNF) or is [foo] indicating that this is a porti= on of the information model that can be ignored by a data model. So far I h= ave interpreted it in the ABNF sense but I now see that other interpretatio= ns are possible. > >=20 > > Back to the -storage definitions: What makes them difficult to implemen= t? Is it the fact that it says "amount of allocated physical storage and n= ot the storage used by logical data records" or are there any other reasons= why this is difficult to implement? > >=20 > > /js > >=20 > > On Mon, Jul 11, 2016 at 06:19:24PM +0000, Carey, Timothy (Nokia - US) w= rote: > > > Optional elements has the "[]" construct > > >=20 > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Monday, July 11, 2016 1:00 PM > > > To: Carey, Timothy (Nokia - US) > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] Information Model draft 10: Storage status=20 > > > parameter > > >=20 > > > On Mon, Jul 11, 2016 at 05:05:14PM +0000, Carey, Timothy (Nokia - US)= wrote: > > > > Juergen, > > > >=20 > > > > I see we added a parameter in the status for schedules and actions = that reports the "storage" - not sure if this is memory or disk but at any = rate - these parameters might be difficult to obtain for some MAs. Could we= please make these parameters optional. > > > >=20 > > >=20 > > > I do not really know what 'mandatory' and 'optional' means for an inf= ormation model. I am not sure I really want to investigate this question. > > >=20 > > > /js > > >=20 > > > --=20 > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > >=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 > --=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 Tue Jul 12 09:57:18 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC3A12D17B for ; Tue, 12 Jul 2016 09:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 zYpRhxR57H8U for ; Tue, 12 Jul 2016 09:57: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 C15F912D1E6 for ; Tue, 12 Jul 2016 09:57:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8F5E5A8C; Tue, 12 Jul 2016 18:57:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oMLf2PcAF9qY; Tue, 12 Jul 2016 18:57:12 +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, 12 Jul 2016 18:57:13 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9714620069; Tue, 12 Jul 2016 18:57:13 +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 6SBGUvDPiuBG; Tue, 12 Jul 2016 18:57:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B3B320063; Tue, 12 Jul 2016 18:57:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7A6BB3BCDC07; Tue, 12 Jul 2016 18:57:11 +0200 (CEST) Date: Tue, 12 Jul 2016 18:57:11 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160712165710.GA36168@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A6DC858@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160711175932.GD33652@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DC9A1@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160712131906.GA35507@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DD6BA@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160712135605.GA35555@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DD807@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160712141448.GD35555@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A6DD8F8@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A6DD8F8@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model draft 10: Storage status parameter X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 16:57:18 -0000 On Tue, Jul 12, 2016 at 02:27:04PM +0000, Carey, Timothy (Nokia - US) wrote: > Ok - I wasn't thinking of the executable size either but the > non-volatile memory used by the task or action in the process of > executing the task and representing the report associated with the > scheduled action? In my implementation, every schedule and every action has a 'workspace' somewhere in the filesystem. This is where I keep some meta-data and this is also where results may be temporarily stored. If results move to another schedule, the results essentially just move in the filesystem from one workspace to another. If you run on an ordinary computer, this workspace may reside on a filesystem running on a non-volatile storage device. If you are on an embedded router, the filesystem hosting the 'workspaces' may actually be volatile, running on an in-memory filesystem (to avoid permanent writes to flash memory). So I decided to use the term 'storage' and I specifically avoided using the term non-volatile memory since the storage may actually be volatile, depending on the OS and device specifics you are operating in. /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 Jul 13 11:31:06 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615BC12D1D1 for ; Wed, 13 Jul 2016 11:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 l64PQCTyoguE for ; Wed, 13 Jul 2016 11:31:02 -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 34FC012D1C7 for ; Wed, 13 Jul 2016 11:31:02 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 65295120868; Wed, 13 Jul 2016 14:41:56 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg11.research.att.com [135.207.255.123]) by mail-azure.research.att.com (Postfix) with ESMTP id BBB6AE1084; Wed, 13 Jul 2016 14:30:58 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG11.research.att.com ([fe80::516e:6eec:2697:ec78%17]) with mapi; Wed, 13 Jul 2016 14:30:58 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder Date: Wed, 13 Jul 2016 14:30:57 -0400 Thread-Topic: [lmap] Calculation of Cycle-Number Thread-Index: AdHWvTKVVUWQB8gkSQaQnu/+1QiacwGcN8BA Message-ID: <4AF73AA205019A4C8A1DDD32C034631D4593E6C231@NJFPSRVEXG0.research.att.com> References: <4AF73AA205019A4C8A1DDD32C034631D4593BBF235@NJFPSRVEXG0.research.att.com> <20160705130009.GA13508@elstar.local> In-Reply-To: <20160705130009.GA13508@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] Calculation of Cycle-Number X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 18:31:04 -0000 Hi Juergen, I think we can agree on some simple format for this (mostly) numeric part of the Cycle-ID. In the community definition-writing, the Cycle-ID was split in two parts and here we are focusing on what we called the numeric part.=20 I have no objection to a minimal number of alpha characters, and "." is needed in both alpha and numeric,=20 so converting an internal date and time to YYYYMMDD.HHMM=20 would satisfy the use case I've described previously. We could define one exact format for the cycle number, and call it "type 1" in case folks want to extend to=20 different format later. Or define the resolution as you=20 suggested, perhaps as a property of an event where resolution could be aligned with the repeating interval. You've raised the issue of synchronizing the repeating events among all the MAs using the same schedule, these produce measurement results we wish to easily associate later with the Cycle-ID.=20 The periodic events need to have a defined interval (duration) and a defined, synchronized start time. Schedule events=20 seem to have both available: +--rw events +--rw event* [name] +--rw name lmap:identifier +--rw (event-type)? | +--:(periodic) | | +--rw periodic | | +--rw interval uint32 | | +--rw start? yang:date-and-time | | +--rw end? yang:date-and-time The recurring Actions performed for each event can be affected=20 variation due to randomization or execution delays. Hence, each Action should have the Cycle-ID assigned as soon as it is calculated & formatted, at the start of the event, or an Action unexpectedly delayed could be assigned the subsequent Cycle-ID. hope this helps, Al PS: I'd prefer not to use the RFC 3339 profile of the ISO 8601 format directly,=20 YYYY-MM-DDTHH:MM:SS+00:00 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Tuesday, July 05, 2016 9:00 AM > To: MORTON, ALFRED C (AL) > Cc: lmap@ietf.org > Subject: Re: [lmap] Calculation of Cycle-Number >=20 > On Mon, Jun 27, 2016 at 09:19:50PM -0400, MORTON, ALFRED C (AL) wrote: > > LMAP, > > > > At the latest Interim meeting, I agreed to prepare text that > > calculates the variable part of a Cycle-ID. This is planned > > to be the numeric index to a specific *recurring* event, > > or cycle among many cycles in the results. > > We are referring to the numeric part as Cycle-Number. > > (The other part of Cycle-ID is the Cycle-Context-ID, which > > can be alphanumeric and is not intended to be modified at the MA > > or elsewhere.) > > > > See the meeting notes for further background: > > > https://www.ietf.org/proceedings/interim/2016/06/13/lmap/minutes/minutes > -interim-2016-lmap-3 > > > > I propose to calculate the Cycle-Number based on the time and > > date of each recurring schedule event, which is a component of > > the Measurement Schedule. The MA has to calculate the time and > > date of each recurring schedule event, and may use its own format. > > See below for generation of a Cycle-Number. > > Measurement Actions may be aligned with event time or have > > some random time offset. > > > > Since the LMAP Collector does not possess the Measurement Schedule > > as described in Section 5.4 of RFC 7594, > > it has no knowledge of recurring event time and dates, and > > cannot perform the same calculation. Section 8.4.2 of RFC 7594 > > identifies the Measurement Schedule as sensitive information, > > so this should remain as described by the LMAP Framework. > > > > For a Collector to infer the Cycle-Number > > from the time and date of Measurement Results, the Collector > > needs to know the times of recurring schedule events, > > or at least: one of the event times, > > the duration of the recurring event, and > > confirmation that the event timing has not been changed > > (changes may be needed to avoid an attacker who intends to > > bias the measurements). According to the LMAP Framework, > > the Collector has none of this information. > > > > Even if the Collector has information necessary to infer the > > Cycle-Number, its calculations can be subject to errors from > > the following sources: > > > > * There may be overlapping measurements from concurrent > > recurring schedules (which would likely use different cycle > > durations, referenced to different recurring events). > > * There may be a 'wait for X' step in a measurement task that > > causes an Action/Measurement to be delayed such that the > > actual measurement time occurs in a subsequent cycle. > > > > with inference of the wrong Cycle-number as the result. > > Overlapping Measurements are described in Section 5.3.2 of RFC 7594. > > > > Measurement Time alone does not lead to the correct > > recurring schedule event for calculation of the Cycle-Number. > > > > > > -=3D-=3D-=3D-=3D-=3D- Note: there are many date, time and datetime form= ats > > in various languages, this is a simple approximation -=3D-=3D-=3D-=3D-= =3D-=3D-=3D > > > > The MA calculates that the next recurring event will occur on > > Date =3D YYYY-MM-DD, at Time =3D HHMMSS, according to information > > from the Controller. > > > > A simple Cycle-Number can be formed by converting the date and > > time to strings, and concatenating the strings: > > > > Cycle-Number =3D print( str(Date) + "-" + str(Time) ) #possibly truncat= e > time to HHMM > > > > All MAs have synchronized clocks, so they all produce the same > > Cycle-Number and report it with the measurement results for that > > recurring event when they are operating on the same recurring > schedule. > > >=20 > Hm. How is this different from sending the date-and-time of the event > that triggered the execution of a schedule? YANG uses the RFC 3339 > profile of the ISO 8601 format, that is, YYYY-MM-DDTHH:MM:SS+00:00 (if > you are operating in UTC). This is what I suggested before but somehow > I thought during the interim that you wanted something that >=20 > (a) is purely numeric and > (b) has a sufficiently course grained resolution and > (c) hides all randomization effects >=20 > and hence for this one would have to configure a resolution and then > round down the actual event time-stamp according to the configured > resolution and then report the result as a number, e.g. YYYYMMDDHHMMSS > (where some portions at then end may always be zero depending on the > configured resolution, e.g., if I set the resolution to 5 minutes > than of course SS will always be 00). >=20 > I guess (since you are not explicitely writing it) that you assume the > next recurring event is precise to calculate and not impacted by any > variation due to randomization or simply exceution delays and hence > multiple systems will come up with the same cycle number. Frankly, > this is not the case even with your proposal. Consider simple periodic > schedules; they will have a defined interval but not necessarily a > defined and thus synchronized start time. So multiple systems > executing the same periodic schedules will not give you the > predictable cycle numbers you are looking for. >=20 > If we were to go with an approach where you configure a > cycle-number-resolution in seconds and then you calculate a numeric > cycle-number as outlined above, then the questions are whether this is > a global configuration knob or whether different ma-schedule-obj's can > have different cycle-number-resolutions or whether such a > cycle-number-resolution is even seen as a property of an event source > (which may make sense since the event configuration really determins > what a suitable cycle-number-resolution value is). >=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 From nobody Mon Jul 18 21:17:40 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDBB12D14B for ; Mon, 18 Jul 2016 21:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=viavisolutions.onmicrosoft.com 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 ZfeXDZOIXxOh for ; Mon, 18 Jul 2016 21:17:36 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0129.outbound.protection.outlook.com [104.47.40.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B71C12D0C7 for ; Mon, 18 Jul 2016 21:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viavisolutions.onmicrosoft.com; s=selector1-viavisolutions-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DZ8mAtIeCU0sj8BXfQlyt99CL5W7D4GtqEAyDW5/LNg=; b=t1nNseM3Kw6eiNkAkJ1UCvE6R4RFb1Mol9vP3HAgtASkBpEzkRKwpkU8hJy0ybMvEeH8X4TbRiTsUlJIxVQ9Cpdg2LAInJE34OuRfte9Xnau3BJbcsElVNJMEchDvKAFqe2NQCrswF/d5cxdSqKlCLkrokCt4Bcj7U58NUPYamM= Received: from BY2PR18MB0278.namprd18.prod.outlook.com (10.163.72.156) by BY2PR18MB0279.namprd18.prod.outlook.com (10.163.72.157) with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 19 Jul 2016 04:17:33 +0000 Received: from BY2PR18MB0278.namprd18.prod.outlook.com ([10.163.72.156]) by BY2PR18MB0278.namprd18.prod.outlook.com ([10.163.72.156]) with mapi id 15.01.0544.014; Tue, 19 Jul 2016 04:17:34 +0000 From: Ron Stana To: "lmap@ietf.org" Thread-Topic: MAs that require a common proxy Thread-Index: AdHhdDenFSAxb1naSEWTvA208cugJQ== Date: Tue, 19 Jul 2016 04:17:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ron.Stana@viavisolutions.com; x-originating-ip: [104.129.204.64] x-ms-office365-filtering-correlation-id: 921fad89-87d4-4093-3b75-08d3af8b9bf0 x-microsoft-exchange-diagnostics: 1; BY2PR18MB0279; 6:qBMfgEZP9d0poZGvaq1rrL219eMroH5arz6D4ee09gAgVp7iO+QMfrZ8LAu+j9UyWwpImtTtO1MlWwUJtUvs5TfejShvrv4L9ykEHdI34F4hFccRzfD7PpyRG3yT24yrCaAAmGhnWHMZMzA7OLCUtG+O87/XITZEMUf1EJbmYMwu3hmpAOzgwUj8OD3H9BYgI+iTpStZECFeh2A0jhwZOq+7VnDforz0vREgpQZtCFQ3P7LCPOTjb7VAiE8lUMXx+wkT/3rb6idJ5jZ7+fK3YAJq+H501dzYAzUHnDs1twK1gYRSJ/FC+FMVhkUvntZJ; 5:V14kKDa1NL0rYacmMOpzsvkcDWWa5mQsdFkU8KrMqejs5KiBnyh4bBNBIVKdNoUcrqBbHaYTkLAlRZJwG9AdMY7fu7VCBiFGhDCRuXpI6UW7G0ZABn30VjIJOYcFGz3lTJUIVHlP7hOaA409JU6bow==; 24:NVcGTd6VPqJdCkwY4usQFrG9FEfCOwTyfVUEqGqmdCeblmcKaOxFkqnHq1saks0hnBvWcQUqBFrZ+sEk5zHwjTnAHo7N6vtXbcaD+LSTP8c=; 7:UqSXJKOecl0VTudMHx1F+Mt6NSASAJwKLzQ1St3ZLYKEw3yDD/qMZ/wF0R11gdbZcc3scZdjA02Nu6Uc8J1Acv73Z9NcsRlK2Mu14hdhxtAxKtFmaGVz/a7l5dhwqGiUr+SNudBfBExhmezCFsksclWpXYEk7fvz0kR7xYiQXOpUm8KaCkbKtNQeHyqwqnQGZ6ZuqURhew1uj40Bxr0oMoI7YaRQnVbPTyzXQ+jXZKXmONIMBCo5vCORMcPxDiO8 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR18MB0279; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046)(6042046); SRVR:BY2PR18MB0279; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0279; x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(2351001)(33656002)(77096005)(106356001)(74316002)(229853001)(15975445007)(50986999)(54356999)(122556002)(19609705001)(6116002)(790700001)(2501003)(2906002)(76576001)(5630700001)(110136002)(97736004)(5640700001)(9686002)(105586002)(5002640100001)(87936001)(16236675004)(5003600100003)(7736002)(19300405004)(7696003)(3280700002)(2900100001)(107886002)(3660700001)(189998001)(7846002)(99286002)(450100001)(68736007)(66066001)(86362001)(8936002)(19625215002)(19580395003)(92566002)(586003)(102836003)(81166006)(3846002)(101416001)(1730700003)(10400500002)(81156014)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR18MB0279; H:BY2PR18MB0278.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: viavisolutions.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR18MB02780C19F14DF3D7A82110C98A370BY2PR18MB0278namp_" MIME-Version: 1.0 X-OriginatorOrg: viavisolutions.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2016 04:17:33.8256 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c44ec86f-d007-4b6c-8795-8ea75e4a6f9b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0279 Archived-At: Subject: [lmap] MAs that require a common proxy X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 04:17:39 -0000 --_000_BY2PR18MB02780C19F14DF3D7A82110C98A370BY2PR18MB0278namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable LMAP Team, We have an MA that cannot be communicated with directly and so requires com= munication through a proxy server. One proxy server can be used for many M= As, thus there is a 1-to-many relationship. The LMAP APIs seem to assume direct communication from the Controller to th= e MA. Our initial thought is to add the MA-ID as a URL parameter to requests from= the Controller to the proxy. This would allow the proxy to know which MA = the request is for. While this would not necessarily make the requests LMA= P compliant it would allow the content to remain LMAP compliant. Thoughts from the LMAP Team on how to handle this situation would be apprec= iated, Ron --_000_BY2PR18MB02780C19F14DF3D7A82110C98A370BY2PR18MB0278namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

LMAP Team,

 

We have an MA that cannot be communicated with direc= tly and so requires communication through a proxy server.  One proxy s= erver can be used for many MAs, thus there is a 1-to-many relationship.

 

The LMAP APIs seem to assume direct communication fr= om the Controller to the MA. 

 

Our initial thought is to add the MA-ID as a URL par= ameter to requests from the Controller to the proxy.  This would allow= the proxy to know which MA the request is for.  While this would not = necessarily make the requests LMAP compliant it would allow the content to remain LMAP compliant. 

 

Thoughts from the LMAP Team on how to handle this si= tuation would be appreciated,

 

Ron

--_000_BY2PR18MB02780C19F14DF3D7A82110C98A370BY2PR18MB0278namp_-- From nobody Mon Jul 18 23:22:06 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E6712DC96 for ; Mon, 18 Jul 2016 23:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 U1m3kZHPZGxI for ; Mon, 18 Jul 2016 23:22: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 DD58412D6A7 for ; Mon, 18 Jul 2016 23:22: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 2DCB1747; Tue, 19 Jul 2016 08:22:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id aE52n5hxq0iM; Tue, 19 Jul 2016 08:21: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; Tue, 19 Jul 2016 08:22:00 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0FD1120074; Tue, 19 Jul 2016 08:22:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id G83Tr0btE4Bt; Tue, 19 Jul 2016 08:21:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 369EA20069; Tue, 19 Jul 2016 08:21:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 40EFB3BD90E9; Tue, 19 Jul 2016 08:21:57 +0200 (CEST) Date: Tue, 19 Jul 2016 08:21:57 +0200 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20160719062157.GA49074@elstar.local> Mail-Followup-To: Ron Stana , "lmap@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] MAs that require a common proxy X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 06:22:05 -0000 Ron, I think this is a rather general problem that deserves to be solved generically, that is without assuming anything specific about the data models being proxied. The NETMOD/NETCONF WGs are doing work related to mount-points, which may be something to look into. But perhaps even generic HTTP proxies could help if your MAs have addresses that are resolvable by the proxy. /js On Tue, Jul 19, 2016 at 04:17:33AM +0000, Ron Stana wrote: > LMAP Team, > > We have an MA that cannot be communicated with directly and so requires communication through a proxy server. One proxy server can be used for many MAs, thus there is a 1-to-many relationship. > > The LMAP APIs seem to assume direct communication from the Controller to the MA. > > Our initial thought is to add the MA-ID as a URL parameter to requests from the Controller to the proxy. This would allow the proxy to know which MA the request is for. While this would not necessarily make the requests LMAP compliant it would allow the content to remain LMAP compliant. > > Thoughts from the LMAP Team on how to handle this situation would be appreciated, > > Ron -- 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 Jul 19 01:23:08 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA5412DC02 for ; Tue, 19 Jul 2016 01:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 VmaTPYxuG5rZ for ; Tue, 19 Jul 2016 01:23:04 -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 5C97112D0DD for ; Tue, 19 Jul 2016 01:23:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 27B47767; Tue, 19 Jul 2016 10:23:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id VgmQg0Z1FG9l; Tue, 19 Jul 2016 10:22:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 19 Jul 2016 10:23:00 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7043620074; Tue, 19 Jul 2016 10:23: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 skD2RDGYnGFK; Tue, 19 Jul 2016 10:22:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9DEDD20077; Tue, 19 Jul 2016 10:22:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A7DC53BD92FF; Tue, 19 Jul 2016 10:22:56 +0200 (CEST) Date: Tue, 19 Jul 2016 10:22:56 +0200 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20160719082256.GA49271@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <4AF73AA205019A4C8A1DDD32C034631D4593BBF235@NJFPSRVEXG0.research.att.com> <20160705130009.GA13508@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D4593E6C231@NJFPSRVEXG0.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D4593E6C231@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Calculation of Cycle-Number X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 08:23:08 -0000 Al, I think we either encode the cycle number as an RFC 3339 date and time value or as a number, perhaps even seconds since 1st Jan 1970. I do not see which problem we solve by introducing yet another encoding _at the data exchange between an MA and a Collector_. How the collector stores data in its database is a Collector's implementation detail. I guess my preference really is the RFC 3339 date and time format since almost all programming languages have functions to deal with this format. Many databases also understand this format. While the format is one sub-issue, the other sub-issue is how exactly the cycle number is calculated. I asked question in a prior post about details [1] (e.g., where the resolution should be configured) but got no response. I think we should leave Berlin with a concrete solution on the table that people agree on or we drop the cycle number altogether (and leave it to the Collector to calculate a cycle number from the timestamps included in the reports). /js [1] https://mailarchive.ietf.org/arch/search/?email_list=lmap On Wed, Jul 13, 2016 at 02:30:57PM -0400, MORTON, ALFRED C (AL) wrote: > Hi Juergen, > > I think we can agree on some simple format for this > (mostly) numeric part of the Cycle-ID. In the community > definition-writing, the Cycle-ID was split in two parts > and here we are focusing on what we called the numeric part. > I have no objection to a minimal number of alpha characters, > and "." is needed in both alpha and numeric, > so converting an internal date and time to YYYYMMDD.HHMM > would satisfy the use case I've described previously. > > We could define one exact format for the cycle number, > and call it "type 1" in case folks want to extend to > different format later. Or define the resolution as you > suggested, perhaps as a property of an event where resolution > could be aligned with the repeating interval. > > You've raised the issue of synchronizing the repeating events > among all the MAs using the same schedule, these produce measurement > results we wish to easily associate later with the Cycle-ID. > The periodic events need to have a defined interval (duration) > and a defined, synchronized start time. Schedule events > seem to have both available: > > +--rw events > +--rw event* [name] > +--rw name lmap:identifier > +--rw (event-type)? > | +--:(periodic) > | | +--rw periodic > | | +--rw interval uint32 > | | +--rw start? yang:date-and-time > | | +--rw end? yang:date-and-time > > The recurring Actions performed for each event can be affected > variation due to randomization or execution delays. > Hence, each Action should have the Cycle-ID assigned > as soon as it is calculated & formatted, at the start > of the event, or an Action unexpectedly delayed could be > assigned the subsequent Cycle-ID. > > hope this helps, > Al > > PS: I'd prefer not to use the RFC 3339 > profile of the ISO 8601 format directly, > YYYY-MM-DDTHH:MM:SS+00:00 > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Tuesday, July 05, 2016 9:00 AM > > To: MORTON, ALFRED C (AL) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] Calculation of Cycle-Number > > > > On Mon, Jun 27, 2016 at 09:19:50PM -0400, MORTON, ALFRED C (AL) wrote: > > > LMAP, > > > > > > At the latest Interim meeting, I agreed to prepare text that > > > calculates the variable part of a Cycle-ID. This is planned > > > to be the numeric index to a specific *recurring* event, > > > or cycle among many cycles in the results. > > > We are referring to the numeric part as Cycle-Number. > > > (The other part of Cycle-ID is the Cycle-Context-ID, which > > > can be alphanumeric and is not intended to be modified at the MA > > > or elsewhere.) > > > > > > See the meeting notes for further background: > > > > > https://www.ietf.org/proceedings/interim/2016/06/13/lmap/minutes/minutes > > -interim-2016-lmap-3 > > > > > > I propose to calculate the Cycle-Number based on the time and > > > date of each recurring schedule event, which is a component of > > > the Measurement Schedule. The MA has to calculate the time and > > > date of each recurring schedule event, and may use its own format. > > > See below for generation of a Cycle-Number. > > > Measurement Actions may be aligned with event time or have > > > some random time offset. > > > > > > Since the LMAP Collector does not possess the Measurement Schedule > > > as described in Section 5.4 of RFC 7594, > > > it has no knowledge of recurring event time and dates, and > > > cannot perform the same calculation. Section 8.4.2 of RFC 7594 > > > identifies the Measurement Schedule as sensitive information, > > > so this should remain as described by the LMAP Framework. > > > > > > For a Collector to infer the Cycle-Number > > > from the time and date of Measurement Results, the Collector > > > needs to know the times of recurring schedule events, > > > or at least: one of the event times, > > > the duration of the recurring event, and > > > confirmation that the event timing has not been changed > > > (changes may be needed to avoid an attacker who intends to > > > bias the measurements). According to the LMAP Framework, > > > the Collector has none of this information. > > > > > > Even if the Collector has information necessary to infer the > > > Cycle-Number, its calculations can be subject to errors from > > > the following sources: > > > > > > * There may be overlapping measurements from concurrent > > > recurring schedules (which would likely use different cycle > > > durations, referenced to different recurring events). > > > * There may be a 'wait for X' step in a measurement task that > > > causes an Action/Measurement to be delayed such that the > > > actual measurement time occurs in a subsequent cycle. > > > > > > with inference of the wrong Cycle-number as the result. > > > Overlapping Measurements are described in Section 5.3.2 of RFC 7594. > > > > > > Measurement Time alone does not lead to the correct > > > recurring schedule event for calculation of the Cycle-Number. > > > > > > > > > -=-=-=-=-=- Note: there are many date, time and datetime formats > > > in various languages, this is a simple approximation -=-=-=-=-=-=-= > > > > > > The MA calculates that the next recurring event will occur on > > > Date = YYYY-MM-DD, at Time = HHMMSS, according to information > > > from the Controller. > > > > > > A simple Cycle-Number can be formed by converting the date and > > > time to strings, and concatenating the strings: > > > > > > Cycle-Number = print( str(Date) + "-" + str(Time) ) #possibly truncate > > time to HHMM > > > > > > All MAs have synchronized clocks, so they all produce the same > > > Cycle-Number and report it with the measurement results for that > > > recurring event when they are operating on the same recurring > > schedule. > > > > > > > Hm. How is this different from sending the date-and-time of the event > > that triggered the execution of a schedule? YANG uses the RFC 3339 > > profile of the ISO 8601 format, that is, YYYY-MM-DDTHH:MM:SS+00:00 (if > > you are operating in UTC). This is what I suggested before but somehow > > I thought during the interim that you wanted something that > > > > (a) is purely numeric and > > (b) has a sufficiently course grained resolution and > > (c) hides all randomization effects > > > > and hence for this one would have to configure a resolution and then > > round down the actual event time-stamp according to the configured > > resolution and then report the result as a number, e.g. YYYYMMDDHHMMSS > > (where some portions at then end may always be zero depending on the > > configured resolution, e.g., if I set the resolution to 5 minutes > > than of course SS will always be 00). > > > > I guess (since you are not explicitely writing it) that you assume the > > next recurring event is precise to calculate and not impacted by any > > variation due to randomization or simply exceution delays and hence > > multiple systems will come up with the same cycle number. Frankly, > > this is not the case even with your proposal. Consider simple periodic > > schedules; they will have a defined interval but not necessarily a > > defined and thus synchronized start time. So multiple systems > > executing the same periodic schedules will not give you the > > predictable cycle numbers you are looking for. > > > > If we were to go with an approach where you configure a > > cycle-number-resolution in seconds and then you calculate a numeric > > cycle-number as outlined above, then the questions are whether this is > > a global configuration knob or whether different ma-schedule-obj's can > > have different cycle-number-resolutions or whether such a > > cycle-number-resolution is even seen as a property of an event source > > (which may make sense since the event configuration really determins > > what a suitable cycle-number-resolution value is). > > > > /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 Tue Jul 19 03:04:23 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4B212D58D for ; Tue, 19 Jul 2016 03:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.206 X-Spam-Level: X-Spam-Status: No, score=-8.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 OpPPYGlxVR88 for ; Tue, 19 Jul 2016 03:04:20 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 3681C12D5C3 for ; Tue, 19 Jul 2016 03:00:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2E2AgDY+Y1X/yYyC4dcHoJTIS1WgQK2U?= =?us-ascii?q?IIPgXqGGgKBMjgUAQEBAQEBAQNiHAuEYAMSG14BFRVWJgEEGxqIDgGfBYUTmF8?= =?us-ascii?q?MASSGK4kOgyqCLwWZJAGQTIRZgyOFUJAeHjaDc4d/AX4BAQE?= X-IPAS-Result: =?us-ascii?q?A2E2AgDY+Y1X/yYyC4dcHoJTIS1WgQK2UIIPgXqGGgKBMjg?= =?us-ascii?q?UAQEBAQEBAQNiHAuEYAMSG14BFRVWJgEEGxqIDgGfBYUTmF8MASSGK4kOgyqCL?= =?us-ascii?q?wWZJAGQTIRZgyOFUJAeHjaDc4d/AX4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,389,1464667200"; d="scan'208,217";a="184014726" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Jul 2016 06:00:15 -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/AES256-SHA; 19 Jul 2016 06:00:15 -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; Tue, 19 Jul 2016 06:00:14 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP meeting - note takers, jabber scrives, presentations Thread-Index: AdHhpFerDO0SNnpoSgSS9Glp6vJRgA== Date: Tue, 19 Jul 2016 10:00:13 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA75240CB5@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_9904FB1B0159DA42B0B887B7FA8119CA75240CB5AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP meeting - note takers, jabber scrives, presentations X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 10:04:22 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA75240CB5AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A few logistics issues in preparation for our Friday LMAP WG meeting: - We need to volunteers to take notes. Please volunteer. - We need one scribe for the jabber. Please volunteer - Folks who own slots on the agenda - if you plan to use slides pl= ease send them in advance - meaning until Thursday Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA75240CB5AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

A few logistics issues in preparation for our Friday= LMAP WG meeting:

 

-     &= nbsp;    We need to volunteers to t= ake notes. Please volunteer.

-     &= nbsp;    We need one scribe for the= jabber. Please volunteer

-     &= nbsp;    Folks who own slots on the= agenda – if you plan to use slides please send them in advance ̵= 1; meaning until Thursday

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA75240CB5AZFFEXMB04globa_-- From nobody Tue Jul 19 06:30:46 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6422D12D9CF for ; Tue, 19 Jul 2016 06:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 SCCPUqHs7qS1 for ; Tue, 19 Jul 2016 06:30:40 -0700 (PDT) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (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 3C6D412DC11 for ; Tue, 19 Jul 2016 06:10:40 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id u6JDAdx4025957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2016 07:10:39 -0600 Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 6789A1E0049; Tue, 19 Jul 2016 08:10:34 -0500 (CDT) Received: from lxdnp32k.corp.intranet (unknown [151.117.18.14]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 421721E0032; Tue, 19 Jul 2016 08:10:34 -0500 (CDT) Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id u6JDAXs0007374; Tue, 19 Jul 2016 07:10:33 -0600 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id u6JDAXRg007370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Jul 2016 07:10:33 -0600 Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0195.001; Tue, 19 Jul 2016 08:10:33 -0500 From: "Bugenhagen, Michael K" To: "'Ron Stana'" , "lmap@ietf.org" Thread-Topic: MAs that require a common proxy Thread-Index: AdHhdDenFSAxb1naSEWTvA208cugJQASmAHg Date: Tue, 19 Jul 2016 13:10:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: multipart/alternative; boundary="_000_A68F3CAC468B2E48BB775ACE2DD99B5E0556108Bpodcwmbxex505ct_" MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [lmap] MAs that require a common proxy X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 13:30:44 -0000 --_000_A68F3CAC468B2E48BB775ACE2DD99B5E0556108Bpodcwmbxex505ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would recommend using an approach like we used with VoIP where agents tha= t go through proxy's and firewalls have a different behavior and make sure = a channel is open in both directions by being a bit more chatty (at least f= rom a IOT perspective)... The MA pokes the Controller, and the control can then directly get back = to the agent... Regards, Mike om: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Ron Stana Sent: Monday, July 18, 2016 11:18 PM To: lmap@ietf.org Subject: [lmap] MAs that require a common proxy LMAP Team, We have an MA that cannot be communicated with directly and so requires com= munication through a proxy server. One proxy server can be used for many M= As, thus there is a 1-to-many relationship. The LMAP APIs seem to assume direct communication from the Controller to th= e MA. Our initial thought is to add the MA-ID as a URL parameter to requests from= the Controller to the proxy. This would allow the proxy to know which MA = the request is for. While this would not necessarily make the requests LMA= P compliant it would allow the content to remain LMAP compliant. Thoughts from the LMAP Team on how to handle this situation would be apprec= iated, Ron This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. --_000_A68F3CAC468B2E48BB775ACE2DD99B5E0556108Bpodcwmbxex505ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would recommend usin= g an approach like we used with VoIP where agents that go through proxyR= 17;s and firewalls have a different behavior and make sure a channel is ope= n in both directions by being a bit more chatty (at least from a IOT perspective)…    

 

   The MA po= kes the Controller, and the control can then directly get back to the agent= …

 

Regards,

Mike=

 

 

 

 

 

 

 

 

om: lmap [mail= to:lmap-bounces@ietf.org] On Behalf Of Ron Stana
Sent: Monday, July 18, 2016 11:18 PM
To: lmap@ietf.org
Subject: [lmap] MAs that require a common proxy

 

LMAP Team,

 

We have an MA that cannot be communicated with direc= tly and so requires communication through a proxy server.  One proxy s= erver can be used for many MAs, thus there is a 1-to-many relationship.

 

The LMAP APIs seem to assume direct communication fr= om the Controller to the MA. 

 

Our initial thought is to add the MA-ID as a URL par= ameter to requests from the Controller to the proxy.  This would allow= the proxy to know which MA the request is for.  While this would not = necessarily make the requests LMAP compliant it would allow the content to remain LMAP compliant. 

 

Thoughts from the LMAP Team on how to handle this si= tuation would be appreciated,

 

Ron

This communication is the property of CenturyLink and may contain c= onfidential or privileged information. Unauthorized use of this communicati= on is strictly prohibited and may be unlawful. If you have received this co= mmunication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communicat= ion and any attachments.
--_000_A68F3CAC468B2E48BB775ACE2DD99B5E0556108Bpodcwmbxex505ct_-- From nobody Tue Jul 19 07:23:32 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0A712DAAB for ; Tue, 19 Jul 2016 07:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 H4VsPGvCwetq for ; Tue, 19 Jul 2016 07:23:28 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BAB12DAB1 for ; Tue, 19 Jul 2016 06:43:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AF52774D; Tue, 19 Jul 2016 15:43:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id o4XSCwX0DynA; Tue, 19 Jul 2016 15:43:17 +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, 19 Jul 2016 15:43:18 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7DB1C20078; Tue, 19 Jul 2016 15:43:18 +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 wXCP3Qey6o73; Tue, 19 Jul 2016 15:43:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9EAC020077; Tue, 19 Jul 2016 15:43:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 692103BDA329; Tue, 19 Jul 2016 15:43:15 +0200 (CEST) Date: Tue, 19 Jul 2016 15:43:14 +0200 From: Juergen Schoenwaelder To: "Bugenhagen, Michael K" Message-ID: <20160719134314.GA50107@elstar.local> Mail-Followup-To: "Bugenhagen, Michael K" , 'Ron Stana' , "lmap@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: 'Ron Stana' , "lmap@ietf.org" Subject: Re: [lmap] MAs that require a common proxy X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 14:23:31 -0000 Michael, you seem to be talking about what is known as 'call home' in the NETCONF WG () while the original question was an N:1 proxy situation. If the reason for this N:1 proxy situation is indeed a NAT function, then yes 'call home' is the recommended way to go. See the 3rd paragraph in section 2 of . /js On Tue, Jul 19, 2016 at 01:10:32PM +0000, Bugenhagen, Michael K wrote: > I would recommend using an approach like we used with VoIP where agents that go through proxy's and firewalls have a different behavior and make sure a channel is open in both directions by being a bit more chatty (at least from a IOT perspective)... > > The MA pokes the Controller, and the control can then directly get back to the agent... > > Regards, > Mike > > > > > > > > > om: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Ron Stana > Sent: Monday, July 18, 2016 11:18 PM > To: lmap@ietf.org > Subject: [lmap] MAs that require a common proxy > > LMAP Team, > > We have an MA that cannot be communicated with directly and so requires communication through a proxy server. One proxy server can be used for many MAs, thus there is a 1-to-many relationship. > > The LMAP APIs seem to assume direct communication from the Controller to the MA. > > Our initial thought is to add the MA-ID as a URL parameter to requests from the Controller to the proxy. This would allow the proxy to know which MA the request is for. While this would not necessarily make the requests LMAP compliant it would allow the content to remain LMAP compliant. > > Thoughts from the LMAP Team on how to handle this situation would be appreciated, > > Ron > This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. > _______________________________________________ > 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 Tue Jul 19 07:34:41 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6966712DD16 for ; Tue, 19 Jul 2016 07:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 DAa8fXZwFZ-Y for ; Tue, 19 Jul 2016 07:34:38 -0700 (PDT) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 EB48112D964 for ; Tue, 19 Jul 2016 07:02:42 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id u6JE2fRI064075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2016 09:02:41 -0500 Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 907541E0065; Tue, 19 Jul 2016 09:02:36 -0500 (CDT) Received: from lxdnp31k.corp.intranet (unknown [151.117.18.14]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 649FE1E0050; Tue, 19 Jul 2016 09:02:36 -0500 (CDT) Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id u6JE2aej027906; Tue, 19 Jul 2016 08:02:36 -0600 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id u6JE2Z78027887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Jul 2016 08:02:36 -0600 Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0195.001; Tue, 19 Jul 2016 09:02:35 -0500 From: "Bugenhagen, Michael K" To: "'Juergen Schoenwaelder'" Thread-Topic: [lmap] MAs that require a common proxy Thread-Index: AdHhdDenFSAxb1naSEWTvA208cugJQASmAHgAAu0GQAACdGwMA== Date: Tue, 19 Jul 2016 14:02:34 +0000 Message-ID: References: <20160719134314.GA50107@elstar.local> In-Reply-To: <20160719134314.GA50107@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: 'Ron Stana' , "lmap@ietf.org" Subject: Re: [lmap] MAs that require a common proxy X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 14:34:40 -0000 Correct, it wasn't named when I was doing that type of work ... early VoIP = days.. Thanks! Mike -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Tuesday, July 19, 2016 8:43 AM To: Bugenhagen, Michael K Cc: 'Ron Stana'; lmap@ietf.org Subject: Re: [lmap] MAs that require a common proxy Michael, you seem to be talking about what is known as 'call home' in the NETCONF WG= () while the original question was an N:1 proxy situation. If the reason for t= his N:1 proxy situation is indeed a NAT function, then yes 'call home' is t= he recommended way to go. See the 3rd paragraph in section 2 of . /js On Tue, Jul 19, 2016 at 01:10:32PM +0000, Bugenhagen, Michael K wrote: > I would recommend using an approach like we used with VoIP where agents t= hat go through proxy's and firewalls have a different behavior and make sur= e a channel is open in both directions by being a bit more chatty (at least= from a IOT perspective)... > > The MA pokes the Controller, and the control can then directly get bac= k to the agent... > > Regards, > Mike > > > > > > > > > om: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Ron Stana > Sent: Monday, July 18, 2016 11:18 PM > To: lmap@ietf.org > Subject: [lmap] MAs that require a common proxy > > LMAP Team, > > We have an MA that cannot be communicated with directly and so requires c= ommunication through a proxy server. One proxy server can be used for many= MAs, thus there is a 1-to-many relationship. > > The LMAP APIs seem to assume direct communication from the Controller to = the MA. > > Our initial thought is to add the MA-ID as a URL parameter to requests fr= om the Controller to the proxy. This would allow the proxy to know which M= A the request is for. While this would not necessarily make the requests L= MAP compliant it would allow the content to remain LMAP compliant. > > Thoughts from the LMAP Team on how to handle this situation would be > appreciated, > > Ron > This communication is the property of CenturyLink and may contain confide= ntial or privileged information. Unauthorized use of this communication is = strictly prohibited and may be unlawful. If you have received this communic= ation in error, please immediately notify the sender by reply e-mail and de= stroy all copies of the communication and any attachments. > _______________________________________________ > 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 This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Wed Jul 20 02:33:11 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7708C12D0A5 for ; Wed, 20 Jul 2016 02:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 zHVUmY94D7vG for ; Wed, 20 Jul 2016 02:33:07 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (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 B63EE12D13E for ; Wed, 20 Jul 2016 02:33:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FSAgDhRI9X/xUHmMZdHoJTIS1WfAa2W?= =?us-ascii?q?4IPgXoihXgCgS44FAEBAQEBAQEDYhwLglEiFxABAQEBAQFPAj4xAQISG14BFRV?= =?us-ascii?q?WJgEEGxqIDgENn3WFE5hCAQoBAQEeBYYriBRbAQEdgkcLWIIvBZkmAZBNh32FU?= =?us-ascii?q?IZfiUEeNoNzbgGGOjYBfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2FSAgDhRI9X/xUHmMZdHoJTIS1WfAa2W4IPgXoihXgCgS4?= =?us-ascii?q?4FAEBAQEBAQEDYhwLglEiFxABAQEBAQFPAj4xAQISG14BFRVWJgEEGxqIDgENn?= =?us-ascii?q?3WFE5hCAQoBAQEeBYYriBRbAQEdgkcLWIIvBZkmAZBNh32FUIZfiUEeNoNzbgG?= =?us-ascii?q?GOjYBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,393,1464667200"; d="scan'208,217";a="196942770" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 20 Jul 2016 05:32:27 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 20 Jul 2016 05:32:27 -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; Wed, 20 Jul 2016 11:32:26 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: way forward (after IETF 96) Thread-Index: AdHiaZ/a/sJ9ytL0TOyROH/S6B+TOQ== Date: Wed, 20 Jul 2016 09:32:25 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA75242378@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_9904FB1B0159DA42B0B887B7FA8119CA75242378AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] way forward (after IETF 96) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 09:33:09 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA75242378AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have uploaded the chairs slides for the LMAP WG meeting at https://www.ie= tf.org/proceedings/96/slides/slides-96-lmap-0.pdf. The last slide includes a 'Way Forward' straw-man proposal that includes wh= at needs to be done before IETF 96 and 97. It reads right now like this: * Complete WGLC - 7/31 * Update documents - 8/31 * 2 weeks WGLC - 9/15 * Virtual Interim meeting (if needed) - 9/15 - 9/30 * Submit updated documents to the IESG - 10/15 * Discuss re-chartering or concluding - start now * Meet at IETF 97 - only if not finished, or new work proposals get t= raction on the WG mail list As you can see we are approaching the conclusion of the current charter. Ou= r AD asked us to think about what next. We basically have two options. Conc= lude the WG and let the implementations and deployment bring feedback on wh= at is good, what is bad and what is missing. Or, revisit the different prop= osals for future work that have been made in the last 2-3 years. I suggest = that we start discussing this at the end of the meeting on Friday, and cont= inue the discussion on the mail list. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA75242378AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have uploaded the chairs slides for the LMAP WG me= eting at https://www.ietf.org/proceedings/96/slides/slides-96-lmap-0.pdf.

 

The last slide includes a ‘Way Forward’ = straw-man proposal that includes what needs to be done before IETF 96 and 9= 7. It reads right now like this:

 

•       Complete WGLC ̵= 1; 7/31

•       Update documents &#= 8211; 8/31

•       2 weeks WGLC –= ; 9/15

•       Virtual Interim mee= ting (if needed) – 9/15 – 9/30

•       Submit updated docu= ments to the IESG – 10/15

•       Discuss re-charteri= ng or concluding – start now

•       Meet at IETF 97 = 211; only if not finished, or new work proposals get traction on the WG mai= l list

 

 

As you can see we are approaching the conclusion of = the current charter. Our AD asked us to think about what next. We basically= have two options. Conclude the WG and let the implementations and deployme= nt bring feedback on what is good, what is bad and what is missing. Or, revisit the different proposals for f= uture work that have been made in the last 2-3 years. I suggest that we sta= rt discussing this at the end of the meeting on Friday, and continue the di= scussion on the mail list.

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA75242378AZFFEXMB04globa_-- From nobody Wed Jul 20 02:36:11 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E258E12D0A5 for ; Wed, 20 Jul 2016 02:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.206 X-Spam-Level: X-Spam-Status: No, score=-8.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 2hme40UN1h2n for ; Wed, 20 Jul 2016 02:35:23 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 0F55012D134 for ; Wed, 20 Jul 2016 02:35:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FSAgDGRI9X/yYyC4ddHoJTIS1WfAa4a?= =?us-ascii?q?oF6IoV4AoEuOBQBAQEBAQEBA2IcC4JRIhcQAQEBAQEBTwI+MQECEhteAQwJFVY?= =?us-ascii?q?fBwEEGxqIDgENn3OFE5hCAQsBHwWGK4gUeoMqgi8FmSYBkE2EWYMkhVCGX4lBH?= =?us-ascii?q?jaDc24BhnABfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2FSAgDGRI9X/yYyC4ddHoJTIS1WfAa4aoF6IoV4AoEuOBQ?= =?us-ascii?q?BAQEBAQEBA2IcC4JRIhcQAQEBAQEBTwI+MQECEhteAQwJFVYfBwEEGxqIDgENn?= =?us-ascii?q?3OFE5hCAQsBHwWGK4gUeoMqgi8FmSYBkE2EWYMkhVCGX4lBHjaDc24BhnABfgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.28,393,1464667200"; d="scan'208,217";a="184247235" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Jul 2016 05:35:13 -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/AES256-SHA; 20 Jul 2016 05:35:13 -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, 20 Jul 2016 05:35:12 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: pointers to implementations Thread-Index: AdHiagLfBH7UQQ1uQ2CXyKyYRik2nQ== Date: Wed, 20 Jul 2016 09:35:11 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA752423AE@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_9904FB1B0159DA42B0B887B7FA8119CA752423AEAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] pointers to implementations X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 09:35:42 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA752423AEAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have uploaded the chairs slides for the LMAP WG meeting at https://www.ie= tf.org/proceedings/96/slides/slides-96-lmap-0.pdf. As you can see in slide 4 I included a bullet about implementations. If you= have implemented LMAP or part of it, please send me the relevant links, an= d I will update the presentation. If you are at the meeting I would be glad= to let you talk about it 1-2 minutes in the meeting. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA752423AEAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have uploaded the chairs slides for the LMAP WG me= eting at https://www.ietf.org/proceedings/96/slides/slides-96-lmap-0.pdf.

 

As you can see in slide 4 I included a bullet about = implementations. If you have implemented LMAP or part of it, please send me= the relevant links, and I will update the presentation. If you are at the = meeting I would be glad to let you talk about it 1-2 minutes in the meeting.

 

Thanks and Regards,

 

Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA752423AEAZFFEXMB04globa_-- From nobody Wed Jul 20 03:07:58 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D7312D110 for ; Wed, 20 Jul 2016 03:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 rgoXykEgOKG6 for ; Wed, 20 Jul 2016 03:07:54 -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 2D16312D095 for ; Wed, 20 Jul 2016 03:07:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F3EC96BA; Wed, 20 Jul 2016 12:07:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id U-Nhpv6qWtRw; Wed, 20 Jul 2016 12:07: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, 20 Jul 2016 12:07:52 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24ED320075; Wed, 20 Jul 2016 12:07:52 +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 CZuk5jwqtaXo; Wed, 20 Jul 2016 12:07: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 B723520077; Wed, 20 Jul 2016 12:07:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 547C23BDBC8A; Wed, 20 Jul 2016 12:07:49 +0200 (CEST) Date: Wed, 20 Jul 2016 12:07:48 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20160720100748.GA52066@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA752423AE@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA752423AE@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] pointers to implementations X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 10:07:56 -0000 On Wed, Jul 20, 2016 at 09:35:11AM +0000, Romascanu, Dan (Dan) wrote: > Hi, > > I have uploaded the chairs slides for the LMAP WG meeting at https://www.ietf.org/proceedings/96/slides/slides-96-lmap-0.pdf. > > As you can see in slide 4 I included a bullet about implementations. If you have implemented LMAP or part of it, please send me the relevant links, and I will update the presentation. If you are at the meeting I would be glad to let you talk about it 1-2 minutes in the meeting. > We (Jacobs University) have an implementation of the information model / yang data model called lmapd. The code is not yet on github (since I am lazy). I am happy to briefly explain what our code does and what I did to it during the hackathon. I am not sure whether I will have slides - I rather try to prepare a short demo if there is time left and there is interest. /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 Jul 20 03:11:50 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D45912DB2A for ; Wed, 20 Jul 2016 03:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 Ovsai2iV8SXW for ; Wed, 20 Jul 2016 03:11:45 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (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 0074512DB33 for ; Wed, 20 Jul 2016 03:11:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EqAQAdTY9X/xUHmMZdGQEBAQEBgnQtg?= =?us-ascii?q?VIGjSSrR4F6hhoCgS84FAEBAQEBAQEDYieEXAEBAQEDEig/DAQCAQgNAQIBBAE?= =?us-ascii?q?BAQoUCQcyFAkIAQEEDgUIGogOAaUDmEQBAQEBAQEBAwEBAQEBAQEBAQEBHIYrh?= =?us-ascii?q?EyEQoMqgi8FmSYBkE2EWYMkhVCGX4lBHjaCCxyBTG6GcQF+AQEB?= X-IPAS-Result: =?us-ascii?q?A2EqAQAdTY9X/xUHmMZdGQEBAQEBgnQtgVIGjSSrR4F6hho?= =?us-ascii?q?CgS84FAEBAQEBAQEDYieEXAEBAQEDEig/DAQCAQgNAQIBBAEBAQoUCQcyFAkIA?= =?us-ascii?q?QEEDgUIGogOAaUDmEQBAQEBAQEBAwEBAQEBAQEBAQEBHIYrhEyEQoMqgi8FmSY?= =?us-ascii?q?BkE2EWYMkhVCGX4lBHjaCCxyBTG6GcQF+AQEB?= X-IronPort-AV: E=Sophos;i="5.28,393,1464667200"; d="scan'208";a="196949291" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 20 Jul 2016 06:11:23 -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/AES256-SHA; 20 Jul 2016 06:11:20 -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, 20 Jul 2016 12:11:16 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [lmap] pointers to implementations Thread-Index: AdHiagLfBH7UQQ1uQ2CXyKyYRik2nf//55UA///d6YA= Date: Wed, 20 Jul 2016 10:11:15 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA752424FF@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA752423AE@AZ-FFEXMB04.global.avaya.com> <20160720100748.GA52066@elstar.local> In-Reply-To: <20160720100748.GA52066@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] pointers to implementations X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 10:11:47 -0000 No slides needed. A short demo would be great.=20 Thanks and Regards, Dan > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, July 20, 2016 1:08 PM > To: Romascanu, Dan (Dan) > Cc: lmap@ietf.org > Subject: Re: [lmap] pointers to implementations >=20 > On Wed, Jul 20, 2016 at 09:35:11AM +0000, Romascanu, Dan (Dan) wrote: > > Hi, > > > > I have uploaded the chairs slides for the LMAP WG meeting at ... > > As you can see in slide 4 I included a bullet about implementations. If= you > have implemented LMAP or part of it, please send me the relevant links, a= nd > I will update the presentation. If you are at the meeting I would be glad= to let > you talk about it 1-2 minutes in the meeting. > > >=20 > We (Jacobs University) have an implementation of the information model / > yang data model called lmapd. The code is not yet on github (since I am l= azy). > I am happy to briefly explain what our code does and what I did to it dur= ing > the hackathon. I am not sure whether I will have slides - I rather try to > prepare a short demo if there is time left and there is interest. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH From nobody Thu Jul 21 05:15:39 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E88C12D890 for ; Thu, 21 Jul 2016 05:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 0pedc9jUUOvr for ; Thu, 21 Jul 2016 05:15:36 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (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 97C4B12D811 for ; Thu, 21 Jul 2016 05:15:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FVAgC1u5BX/yYyC4ddHQGCUyEtVoECj?= =?us-ascii?q?SWpKoIPgXuGGgKBLTgUAQEBAQEBAQNiHAuEYAMSG14BDAkVViYBBBsaiA4BnzO?= =?us-ascii?q?FE5g4DAEkhiuJDoMqgi8Fk2SFQgGJEIdGhFmDJIVRkCEeNoNzhz0BfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2FVAgC1u5BX/yYyC4ddHQGCUyEtVoECjSWpKoIPgXuGGgK?= =?us-ascii?q?BLTgUAQEBAQEBAQNiHAuEYAMSG14BDAkVViYBBBsaiA4BnzOFE5g4DAEkhiuJD?= =?us-ascii?q?oMqgi8Fk2SFQgGJEIdGhFmDJIVRkCEeNoNzhz0BfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,399,1464667200"; d="scan'208,217";a="197209465" 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; 21 Jul 2016 08:15:33 -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/AES256-SHA; 21 Jul 2016 08:15:33 -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, 21 Jul 2016 14:15:32 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP WG meeting - note takers and jabber scribe needed! Thread-Index: AdHjSZMkN3BrA+nfTtem0nIOY1RyHQ== Date: Thu, 21 Jul 2016 12:15:31 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA75244493@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_9904FB1B0159DA42B0B887B7FA8119CA75244493AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP WG meeting - note takers and jabber scribe needed! X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 12:15:37 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA75244493AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In order to start in time the meeting tomorrow we need two note takers and = one jabber scribe assigned in advance. Please help! Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA75244493AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In order to start in time the meeting tomorrow we ne= ed two note takers and one jabber scribe assigned in advance.

 

Please help!

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA75244493AZFFEXMB04globa_-- From nobody Thu Jul 21 06:00:04 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A9F12DA0F for ; Thu, 21 Jul 2016 05:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 rP7W9IoaTw4i for ; Thu, 21 Jul 2016 05:59: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 42E9312D8C4 for ; Thu, 21 Jul 2016 05:59:52 -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 6AD2A120905; Thu, 21 Jul 2016 09:11:10 -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 A4DE0E0444; Thu, 21 Jul 2016 08:58:04 -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; Thu, 21 Jul 2016 08:59:51 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder Date: Thu, 21 Jul 2016 08:59:48 -0400 Thread-Topic: [lmap] Calculation of Cycle-Number Thread-Index: AdHhls0LeIPf+Da9SN6ar4XwnaKMQwBrihBg Message-ID: <4AF73AA205019A4C8A1DDD32C034631D45963B262B@NJFPSRVEXG0.research.att.com> References: <4AF73AA205019A4C8A1DDD32C034631D4593BBF235@NJFPSRVEXG0.research.att.com> <20160705130009.GA13508@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D4593E6C231@NJFPSRVEXG0.research.att.com> <20160719082256.GA49271@elstar.local> In-Reply-To: <20160719082256.GA49271@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] Calculation of Cycle-Number X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 12:59:58 -0000 Hi Juergen, It seems that each recurring event has a time associated with it, and that all event times can be calculated based on the=20 start time of the first event and the period, so that the MA knows=20 when to begin each set of Actions that are part of the recurring event. (IOW, I can schedule recurring events to start at HH:00, HH:15, HH:30, HH:4= 5 on all Mas where I want to use Cycle-ID.) Since the MA knows each recurring event time, it can calculate=20 the numeric part of the Cycle-ID. Each event time would be present=20 in some OS-dependent format, and available for reduction to=20 the desired resolution. My colleagues want the numeric part pf Cycle-ID to be easy to type as part of a query, so that's why the numeric format(s) I keep using are short, numeric, and avoid a lot of separation characters.=20 The calculation and format they want is as simple as $ date "+%Y%m%d.%H%M" 20160711.1800 (this is fully numeric) for the recurring event beginning at 6pm on July 11, 2016. Other MA OS may need to apply additional formatting to=20 produce the YYYYMMDD.HHMM result. I don't find seconds since 1st Jan 1970 to be meaningful to=20 someone typing a query, and RFC 3339 YYYY-MM-DDTHH:MM:SS+00:00 is certainly more than needed. I'm willing to live with a single format and resolution, so I don't need the resolution to be variable based on the repeating=20 period of the recurring events. The Collector should simply indicate that Cycle-ID is to be included with the results of each Action in the recurring event schedule. In previous versions of the Information Model, we had cycle-id in ma-task-obj and ma-report-task-object, for example: object { string ma-task-name; ma-metric-registry-obj ma-task-metrics<0..*>; [ma-option-obj ma-task-options<0..*>;] [boolean ma-task-suppress-by-default;] [string ma-task-cycle-id;] } ma-task-obj; I'm not sure if this is still the best way for the Controller to indicate that the option to use cycle-id is wanted, but it is=20 a starting point. I've covered the desired calculation, format, and how the Controller=20 indicates the need for cycle-id calculation and inclusion with the results, subject to further discussion. I'm willing to meet and discuss the topic further today, face to face, with anyone still here at IETF. Suggest a time. regards, Al > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Tuesday, July 19, 2016 4:23 AM > To: MORTON, ALFRED C (AL) > Cc: lmap@ietf.org > Subject: Re: [lmap] Calculation of Cycle-Number >=20 > Al, >=20 > I think we either encode the cycle number as an RFC 3339 date and time > value or as a number, perhaps even seconds since 1st Jan 1970. I do > not see which problem we solve by introducing yet another encoding _at > the data exchange between an MA and a Collector_. How the collector > stores data in its database is a Collector's implementation detail. I > guess my preference really is the RFC 3339 date and time format since > almost all programming languages have functions to deal with this > format. Many databases also understand this format. >=20 > While the format is one sub-issue, the other sub-issue is how exactly > the cycle number is calculated. I asked question in a prior post about > details [1] (e.g., where the resolution should be configured) but got > no response. >=20 > I think we should leave Berlin with a concrete solution on the table > that people agree on or we drop the cycle number altogether (and leave > it to the Collector to calculate a cycle number from the timestamps > included in the reports). >=20 > /js >=20 > [1] https://mailarchive.ietf.org/arch/search/?email_list=3Dlmap >=20 > On Wed, Jul 13, 2016 at 02:30:57PM -0400, MORTON, ALFRED C (AL) wrote: > > Hi Juergen, > > > > I think we can agree on some simple format for this > > (mostly) numeric part of the Cycle-ID. In the community > > definition-writing, the Cycle-ID was split in two parts > > and here we are focusing on what we called the numeric part. > > I have no objection to a minimal number of alpha characters, > > and "." is needed in both alpha and numeric, > > so converting an internal date and time to YYYYMMDD.HHMM > > would satisfy the use case I've described previously. > > > > We could define one exact format for the cycle number, > > and call it "type 1" in case folks want to extend to > > different format later. Or define the resolution as you > > suggested, perhaps as a property of an event where resolution > > could be aligned with the repeating interval. > > > > You've raised the issue of synchronizing the repeating events > > among all the MAs using the same schedule, these produce measurement > > results we wish to easily associate later with the Cycle-ID. > > The periodic events need to have a defined interval (duration) > > and a defined, synchronized start time. Schedule events > > seem to have both available: > > > > +--rw events > > +--rw event* [name] > > +--rw name lmap:identifier > > +--rw (event-type)? > > | +--:(periodic) > > | | +--rw periodic > > | | +--rw interval uint32 > > | | +--rw start? yang:date-and-time > > | | +--rw end? yang:date-and-time > > > > The recurring Actions performed for each event can be affected > > variation due to randomization or execution delays. > > Hence, each Action should have the Cycle-ID assigned > > as soon as it is calculated & formatted, at the start > > of the event, or an Action unexpectedly delayed could be > > assigned the subsequent Cycle-ID. > > > > hope this helps, > > Al > > > > PS: I'd prefer not to use the RFC 3339 > > profile of the ISO 8601 format directly, > > YYYY-MM-DDTHH:MM:SS+00:00 > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > university.de] > > > Sent: Tuesday, July 05, 2016 9:00 AM > > > To: MORTON, ALFRED C (AL) > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] Calculation of Cycle-Number > > > > > > On Mon, Jun 27, 2016 at 09:19:50PM -0400, MORTON, ALFRED C (AL) > wrote: > > > > LMAP, > > > > > > > > At the latest Interim meeting, I agreed to prepare text that > > > > calculates the variable part of a Cycle-ID. This is planned > > > > to be the numeric index to a specific *recurring* event, > > > > or cycle among many cycles in the results. > > > > We are referring to the numeric part as Cycle-Number. > > > > (The other part of Cycle-ID is the Cycle-Context-ID, which > > > > can be alphanumeric and is not intended to be modified at the MA > > > > or elsewhere.) > > > > > > > > See the meeting notes for further background: > > > > > > > > https://www.ietf.org/proceedings/interim/2016/06/13/lmap/minutes/minutes > > > -interim-2016-lmap-3 > > > > > > > > I propose to calculate the Cycle-Number based on the time and > > > > date of each recurring schedule event, which is a component of > > > > the Measurement Schedule. The MA has to calculate the time and > > > > date of each recurring schedule event, and may use its own format. > > > > See below for generation of a Cycle-Number. > > > > Measurement Actions may be aligned with event time or have > > > > some random time offset. > > > > > > > > Since the LMAP Collector does not possess the Measurement Schedule > > > > as described in Section 5.4 of RFC 7594, > > > > it has no knowledge of recurring event time and dates, and > > > > cannot perform the same calculation. Section 8.4.2 of RFC 7594 > > > > identifies the Measurement Schedule as sensitive information, > > > > so this should remain as described by the LMAP Framework. > > > > > > > > For a Collector to infer the Cycle-Number > > > > from the time and date of Measurement Results, the Collector > > > > needs to know the times of recurring schedule events, > > > > or at least: one of the event times, > > > > the duration of the recurring event, and > > > > confirmation that the event timing has not been changed > > > > (changes may be needed to avoid an attacker who intends to > > > > bias the measurements). According to the LMAP Framework, > > > > the Collector has none of this information. > > > > > > > > Even if the Collector has information necessary to infer the > > > > Cycle-Number, its calculations can be subject to errors from > > > > the following sources: > > > > > > > > * There may be overlapping measurements from concurrent > > > > recurring schedules (which would likely use different cycle > > > > durations, referenced to different recurring events). > > > > * There may be a 'wait for X' step in a measurement task that > > > > causes an Action/Measurement to be delayed such that the > > > > actual measurement time occurs in a subsequent cycle. > > > > > > > > with inference of the wrong Cycle-number as the result. > > > > Overlapping Measurements are described in Section 5.3.2 of RFC > 7594. > > > > > > > > Measurement Time alone does not lead to the correct > > > > recurring schedule event for calculation of the Cycle-Number. > > > > > > > > > > > > -=3D-=3D-=3D-=3D-=3D- Note: there are many date, time and datetime = formats > > > > in various languages, this is a simple approximation -=3D-=3D-=3D-= =3D-=3D-=3D- > =3D > > > > > > > > The MA calculates that the next recurring event will occur on > > > > Date =3D YYYY-MM-DD, at Time =3D HHMMSS, according to information > > > > from the Controller. > > > > > > > > A simple Cycle-Number can be formed by converting the date and > > > > time to strings, and concatenating the strings: > > > > > > > > Cycle-Number =3D print( str(Date) + "-" + str(Time) ) #possibly > truncate > > > time to HHMM > > > > > > > > All MAs have synchronized clocks, so they all produce the same > > > > Cycle-Number and report it with the measurement results for that > > > > recurring event when they are operating on the same recurring > > > schedule. > > > > > > > > > > Hm. How is this different from sending the date-and-time of the > event > > > that triggered the execution of a schedule? YANG uses the RFC 3339 > > > profile of the ISO 8601 format, that is, YYYY-MM-DDTHH:MM:SS+00:00 > (if > > > you are operating in UTC). This is what I suggested before but > somehow > > > I thought during the interim that you wanted something that > > > > > > (a) is purely numeric and > > > (b) has a sufficiently course grained resolution and > > > (c) hides all randomization effects > > > > > > and hence for this one would have to configure a resolution and then > > > round down the actual event time-stamp according to the configured > > > resolution and then report the result as a number, e.g. > YYYYMMDDHHMMSS > > > (where some portions at then end may always be zero depending on the > > > configured resolution, e.g., if I set the resolution to 5 minutes > > > than of course SS will always be 00). > > > > > > I guess (since you are not explicitely writing it) that you assume > the > > > next recurring event is precise to calculate and not impacted by any > > > variation due to randomization or simply exceution delays and hence > > > multiple systems will come up with the same cycle number. Frankly, > > > this is not the case even with your proposal. Consider simple > periodic > > > schedules; they will have a defined interval but not necessarily a > > > defined and thus synchronized start time. So multiple systems > > > executing the same periodic schedules will not give you the > > > predictable cycle numbers you are looking for. > > > > > > If we were to go with an approach where you configure a > > > cycle-number-resolution in seconds and then you calculate a numeric > > > cycle-number as outlined above, then the questions are whether this > is > > > a global configuration knob or whether different ma-schedule-obj's > can > > > have different cycle-number-resolutions or whether such a > > > cycle-number-resolution is even seen as a property of an event > source > > > (which may make sense since the event configuration really determins > > > what a suitable cycle-number-resolution value is). > > > > > > /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 >=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 Thu Jul 21 06:36:33 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C95812D556 for ; Thu, 21 Jul 2016 06:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 gfl3XTnnYndS for ; Thu, 21 Jul 2016 06:36:23 -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 1020C12D501 for ; Thu, 21 Jul 2016 06:36:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D8E671563; Thu, 21 Jul 2016 15:36:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id I7Oaf-7germy; Thu, 21 Jul 2016 15:36:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 21 Jul 2016 15:36:18 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A61520077; Thu, 21 Jul 2016 15:36:18 +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 6rSLdUce-VYJ; Thu, 21 Jul 2016 15:36:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6354820075; Thu, 21 Jul 2016 15:36:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 386843BDE60E; Thu, 21 Jul 2016 15:36:14 +0200 (CEST) Date: Thu, 21 Jul 2016 15:36:14 +0200 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20160721133614.GA54297@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <4AF73AA205019A4C8A1DDD32C034631D4593BBF235@NJFPSRVEXG0.research.att.com> <20160705130009.GA13508@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D4593E6C231@NJFPSRVEXG0.research.att.com> <20160719082256.GA49271@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D45963B262B@NJFPSRVEXG0.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D45963B262B@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Calculation of Cycle-Number X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:36:28 -0000 On Thu, Jul 21, 2016 at 08:59:48AM -0400, MORTON, ALFRED C (AL) wrote: > Hi Juergen, > > It seems that each recurring event has a time associated with it, > and that all event times can be calculated based on the > start time of the first event and the period, so that the MA knows > when to begin each set of Actions that are part of the recurring event. > (IOW, I can schedule recurring events to start at HH:00, HH:15, HH:30, HH:45 > on all Mas where I want to use Cycle-ID.) > > Since the MA knows each recurring event time, it can calculate > the numeric part of the Cycle-ID. Each event time would be present > in some OS-dependent format, and available for reduction to > the desired resolution. This is not as simple as in the example since you can create way more complex recurring schedules. There is not necessarily a natural 'cycle-number interval' for the schedules we allow - or they may be tough to calculate. For example, you can schedule to run something on every Friday 13th. What is the 'cycle-number interval' for such a recurring schedule and how do I calculate it? > My colleagues want the numeric part pf Cycle-ID to be easy to type > as part of a query, so that's why the numeric format(s) I keep using > are short, numeric, and avoid a lot of separation characters. > The calculation and format they want is as simple as > > $ date "+%Y%m%d.%H%M" > 20160711.1800 (this is fully numeric) > > for the recurring event beginning at 6pm on July 11, 2016. > Other MA OS may need to apply additional formatting to > produce the YYYYMMDD.HHMM result. I think our focus is which data is exchanged over the network and how it is encoded while traveling over the network. We are not designing a user interface. If a Collector receives data from an MA, then it needs to stick the data somewhere (e.g. some form of a database). Since I do not think we assume human Collectors, the data formats should make it easy to process the data and to stick it in databases. > I don't find seconds since 1st Jan 1970 to be meaningful to > someone typing a query, and RFC 3339 YYYY-MM-DDTHH:MM:SS+00:00 > is certainly more than needed. > > I'm willing to live with a single format and resolution, so > I don't need the resolution to be variable based on the repeating > period of the recurring events. The Collector should simply indicate > that Cycle-ID is to be included with the results of each Action > in the recurring event schedule. I think our disconnect is how a user accesses data stored in a Collector's database and how we encode data shipped from an MA to a Collector. > In previous versions of the Information Model, we had cycle-id > in ma-task-obj and ma-report-task-object, for example: > > object { > string ma-task-name; > ma-metric-registry-obj ma-task-metrics<0..*>; > [ma-option-obj ma-task-options<0..*>;] > [boolean ma-task-suppress-by-default;] > [string ma-task-cycle-id;] > } ma-task-obj; > > I'm not sure if this is still the best way for the Controller to > indicate that the option to use cycle-id is wanted, but it is > a starting point. This was the cycle-id as described in section 3 of RFC 7594, namely a tag value. This has been replaced by a general tagging mechanism. The cycle-number is an idea that was proposed later and right now I am not sure how an MA would know when to generate one and how to infer the cycle-number > I've covered the desired calculation, format, and how the Controller > indicates the need for cycle-id calculation and inclusion with the > results, subject to further discussion. > > I'm willing to meet and discuss the topic further today, face to face, > with anyone still here at IETF. Suggest a time. What about 6pm at one of the tables in the Wintergarten? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 21 07:44:33 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4581912D667 for ; Thu, 21 Jul 2016 07:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 cpNl4V2NK2mS for ; Thu, 21 Jul 2016 07:44:30 -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 3C30312D0C7 for ; Thu, 21 Jul 2016 07:44:30 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 9B731120AE0; Thu, 21 Jul 2016 10:55:48 -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 DE71FE1051; Thu, 21 Jul 2016 10:44:29 -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; Thu, 21 Jul 2016 10:44:29 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder Date: Thu, 21 Jul 2016 10:44:27 -0400 Thread-Topic: [lmap] Calculation of Cycle-Number Thread-Index: AdHjVOQUL+v4dbVsTvOEmN+5bOWSAgAAiJQA Message-ID: <4AF73AA205019A4C8A1DDD32C034631D45963B265D@NJFPSRVEXG0.research.att.com> References: <4AF73AA205019A4C8A1DDD32C034631D4593BBF235@NJFPSRVEXG0.research.att.com> <20160705130009.GA13508@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D4593E6C231@NJFPSRVEXG0.research.att.com> <20160719082256.GA49271@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D45963B262B@NJFPSRVEXG0.research.att.com> <20160721133614.GA54297@elstar.local> In-Reply-To: <20160721133614.GA54297@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] Calculation of Cycle-Number X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 14:44:32 -0000 Hi Juergen, I'm clearly talking about periodic events (cyclic), and if we need to restrict the scope to periodic only, that's fine with me. We could calculate the numeric part of a cycle-id for an event on "Friday the 13th", and it would have a 13 in it, but this doesn't help anyone, AFAICT. I also want the Collector to receive the results and stick it=20 in databases. Database searches/queries benefit from indexes,=20 and cycle-id is the index that we've already found useful in a=20 large-scale measurement system. I want to add that index with the results, so that ingestion can be efficient. It's almost never mentioned in discussion that we are designing a=20 system for large scale deployment. The MA has autonomy and probably some=20 spare cycles before measurements start, so it can calculate a=20 cycle-id. The Collector is an aggregation point serving many MAs and we need to conserve its processing, IMO. Sending results in a form ready for ingestion seems most efficient there. I realize this definition of cycle-id has expanded functionality from the original, but when I had to write and present the topic to get the concept restored in the information model, I tried to=20 write a more direct replacement for the database index our=20 measurement systems use now. > What about 6pm at one of the tables in the Wintergarten? Ok, That's where we'll meet, see you then, anyone else on the list with opinions is welcome too. Al > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, July 21, 2016 9:36 AM > To: MORTON, ALFRED C (AL) > Cc: lmap@ietf.org > Subject: Re: [lmap] Calculation of Cycle-Number >=20 > On Thu, Jul 21, 2016 at 08:59:48AM -0400, MORTON, ALFRED C (AL) wrote: > > Hi Juergen, > > > > It seems that each recurring event has a time associated with it, > > and that all event times can be calculated based on the > > start time of the first event and the period, so that the MA knows > > when to begin each set of Actions that are part of the recurring > event. > > (IOW, I can schedule recurring events to start at HH:00, HH:15, HH:30, > HH:45 > > on all Mas where I want to use Cycle-ID.) > > > > Since the MA knows each recurring event time, it can calculate > > the numeric part of the Cycle-ID. Each event time would be present > > in some OS-dependent format, and available for reduction to > > the desired resolution. >=20 > This is not as simple as in the example since you can create way more > complex recurring schedules. There is not necessarily a natural > 'cycle-number interval' for the schedules we allow - or they may be > tough to calculate. For example, you can schedule to run something on > every Friday 13th. What is the 'cycle-number interval' for such a > recurring schedule and how do I calculate it? >=20 > > My colleagues want the numeric part pf Cycle-ID to be easy to type > > as part of a query, so that's why the numeric format(s) I keep using > > are short, numeric, and avoid a lot of separation characters. > > The calculation and format they want is as simple as > > > > $ date "+%Y%m%d.%H%M" > > 20160711.1800 (this is fully numeric) > > > > for the recurring event beginning at 6pm on July 11, 2016. > > Other MA OS may need to apply additional formatting to > > produce the YYYYMMDD.HHMM result. >=20 > I think our focus is which data is exchanged over the network and how > it is encoded while traveling over the network. We are not designing a > user interface. If a Collector receives data from an MA, then it needs > to stick the data somewhere (e.g. some form of a database). Since I do > not think we assume human Collectors, the data formats should make it > easy to process the data and to stick it in databases. >=20 > > I don't find seconds since 1st Jan 1970 to be meaningful to > > someone typing a query, and RFC 3339 YYYY-MM-DDTHH:MM:SS+00:00 > > is certainly more than needed. > > > > I'm willing to live with a single format and resolution, so > > I don't need the resolution to be variable based on the repeating > > period of the recurring events. The Collector should simply indicate > > that Cycle-ID is to be included with the results of each Action > > in the recurring event schedule. >=20 > I think our disconnect is how a user accesses data stored in a > Collector's database and how we encode data shipped from an MA to a > Collector. >=20 > > In previous versions of the Information Model, we had cycle-id > > in ma-task-obj and ma-report-task-object, for example: > > > > object { > > string ma-task-name; > > ma-metric-registry-obj ma-task-metrics<0..*>; > > [ma-option-obj ma-task-options<0..*>;] > > [boolean ma-task-suppress-by-default;] > > [string ma-task-cycle-id;] > > } ma-task-obj; > > > > I'm not sure if this is still the best way for the Controller to > > indicate that the option to use cycle-id is wanted, but it is > > a starting point. >=20 > This was the cycle-id as described in section 3 of RFC 7594, namely a > tag value. This has been replaced by a general tagging mechanism. > The cycle-number is an idea that was proposed later and right now > I am not sure how an MA would know when to generate one and how to > infer the cycle-number >=20 > > I've covered the desired calculation, format, and how the Controller > > indicates the need for cycle-id calculation and inclusion with the > > results, subject to further discussion. > > > > I'm willing to meet and discuss the topic further today, face to face, > > with anyone still here at IETF. Suggest a time. >=20 > What about 6pm at one of the tables in the Wintergarten? >=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 From nobody Thu Jul 21 08:03:35 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D0312B058 for ; Thu, 21 Jul 2016 08:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 JxCNEzrHwseM for ; Thu, 21 Jul 2016 08:03: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 C53B412B050 for ; Thu, 21 Jul 2016 08:03:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9ABB11567; Thu, 21 Jul 2016 17:03:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qyVQI1mQnDY4; Thu, 21 Jul 2016 17:03:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 21 Jul 2016 17:03:27 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9BB0720079; Thu, 21 Jul 2016 17:03: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 tx5I3KVOaX7i; Thu, 21 Jul 2016 17:03: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 3547420077; Thu, 21 Jul 2016 17:03:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 312E93BDE96C; Thu, 21 Jul 2016 17:03:24 +0200 (CEST) Date: Thu, 21 Jul 2016 17:03:24 +0200 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20160721150324.GA54411@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <4AF73AA205019A4C8A1DDD32C034631D4593BBF235@NJFPSRVEXG0.research.att.com> <20160705130009.GA13508@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D4593E6C231@NJFPSRVEXG0.research.att.com> <20160719082256.GA49271@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D45963B262B@NJFPSRVEXG0.research.att.com> <20160721133614.GA54297@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D45963B265D@NJFPSRVEXG0.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D45963B265D@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Calculation of Cycle-Number X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:03:34 -0000 On Thu, Jul 21, 2016 at 10:44:27AM -0400, MORTON, ALFRED C (AL) wrote: > Hi Juergen, > > I'm clearly talking about periodic events (cyclic), and if we > need to restrict the scope to periodic only, that's fine with me. > We could calculate the numeric part of a cycle-id for an event on > "Friday the 13th", and it would have a 13 in it, but this doesn't > help anyone, AFAICT. > > I also want the Collector to receive the results and stick it > in databases. Database searches/queries benefit from indexes, > and cycle-id is the index that we've already found useful in a > large-scale measurement system. I want to add that index with > the results, so that ingestion can be efficient. > > It's almost never mentioned in discussion that we are designing a > system for large scale deployment. The MA has autonomy and probably some > spare cycles before measurements start, so it can calculate a > cycle-id. The Collector is an aggregation point serving many MAs > and we need to conserve its processing, IMO. Sending results in > a form ready for ingestion seems most efficient there. The calculation itself is hardly keeping any CPU busy (compared to everything else coing on). I think we are effectively talking about this (in Python syntax) cyclno = secs - (secs % itv) where secs is the event time in seconds since epoch and itv is the cycle-interval in seconds. This should be trivial to do for any collector. If we distribute this calculation (I remain personally unconvinced that this is necessary but I will not object to this if people feel strongly that the above calculation is too hard to scale on a collector) then it needs to be clear to all MAs how to obtain the itv value. BTW, what I find more seriously missing in the report is the (recurring) event time without the optionally added randomization. This would be a useful addition to the report since there is currently no way to obtain the randomization that was added. (And if you want to calculate a cycle-number, you likely want the event time without any randomization added. Am I correct here Al? > I realize this definition of cycle-id has expanded functionality > from the original, but when I had to write and present the topic > to get the concept restored in the information model, I tried to > write a more direct replacement for the database index our > measurement systems use now. And this is appreciated, Al. But things are a bit more complex then they may appear to you and thus I kept pushing for more details. > > What about 6pm at one of the tables in the Wintergarten? > > Ok, That's where we'll meet, see you then, anyone else on the > list with opinions is welcome too. Cool, see you in about an hour. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 21 08:49:18 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A255712D0B4 for ; Thu, 21 Jul 2016 08:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 eHSKAacGc9qo for ; Thu, 21 Jul 2016 08:49:15 -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 022DE12B031 for ; Thu, 21 Jul 2016 08:49:15 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 7C668120B83; Thu, 21 Jul 2016 12:00:33 -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 A8177E1051; Thu, 21 Jul 2016 11:49:11 -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; Thu, 21 Jul 2016 11:49:11 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder Date: Thu, 21 Jul 2016 11:49:08 -0400 Thread-Topic: [lmap] Calculation of Cycle-Number Thread-Index: AdHjYRAxnxik02wZTPWbNFXbtMsbFQABJEGw Message-ID: <4AF73AA205019A4C8A1DDD32C034631D45963B2677@NJFPSRVEXG0.research.att.com> References: <4AF73AA205019A4C8A1DDD32C034631D4593BBF235@NJFPSRVEXG0.research.att.com> <20160705130009.GA13508@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D4593E6C231@NJFPSRVEXG0.research.att.com> <20160719082256.GA49271@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D45963B262B@NJFPSRVEXG0.research.att.com> <20160721133614.GA54297@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D45963B265D@NJFPSRVEXG0.research.att.com> <20160721150324.GA54411@elstar.local> In-Reply-To: <20160721150324.GA54411@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] Calculation of Cycle-Number X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:49:16 -0000 Hi Juergen, As you just said, > ... BTW, what I find more seriously missing in the report is the > (recurring) event time without the optionally added randomization. This is one of the reasons the MA should do the calculation, the details of the schedule including events are not sent to the Collector. This was part of my rationale in the message that started the thread: Al> Since the LMAP Collector does not possess the Measurement Schedule Al> as described in Section 5.4 of RFC 7594, Al > it has no knowledge of recurring event time and dates, and Al > cannot perform the same calculation. Section 8.4.2 of RFC 7594 Al > identifies the Measurement Schedule as sensitive information, Al > so this should remain as described by the LMAP Framework. Juergen wrote: > This would be a useful addition to the report since there is currently > no way to obtain the randomization that was added. (And if you want to > calculate a cycle-number, you likely want the event time without any > randomization added. Am I correct here Al? Yes, I want to calculate the cycle-number based on each recurring event tim= e without any randomization added. But the MA has to do the calculation, for all the reasons I gave in my first message to this thread (which seems to be missing from the archive= , but Juergen's first reply is there...) Al > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, July 21, 2016 11:03 AM > To: MORTON, ALFRED C (AL) > Cc: lmap@ietf.org > Subject: Re: [lmap] Calculation of Cycle-Number >=20 > On Thu, Jul 21, 2016 at 10:44:27AM -0400, MORTON, ALFRED C (AL) wrote: > > Hi Juergen, > > > > I'm clearly talking about periodic events (cyclic), and if we > > need to restrict the scope to periodic only, that's fine with me. > > We could calculate the numeric part of a cycle-id for an event on > > "Friday the 13th", and it would have a 13 in it, but this doesn't > > help anyone, AFAICT. > > > > I also want the Collector to receive the results and stick it > > in databases. Database searches/queries benefit from indexes, > > and cycle-id is the index that we've already found useful in a > > large-scale measurement system. I want to add that index with > > the results, so that ingestion can be efficient. > > > > It's almost never mentioned in discussion that we are designing a > > system for large scale deployment. The MA has autonomy and probably > some > > spare cycles before measurements start, so it can calculate a > > cycle-id. The Collector is an aggregation point serving many MAs > > and we need to conserve its processing, IMO. Sending results in > > a form ready for ingestion seems most efficient there. >=20 > The calculation itself is hardly keeping any CPU busy (compared to > everything else coing on). I think we are effectively talking about > this (in Python syntax) >=20 > cyclno =3D secs - (secs % itv) >=20 > where secs is the event time in seconds since epoch and itv is the > cycle-interval in seconds. This should be trivial to do for any > collector. >=20 > If we distribute this calculation (I remain personally unconvinced > that this is necessary but I will not object to this if people feel > strongly that the above calculation is too hard to scale on a > collector) then it needs to be clear to all MAs how to obtain the itv > value. BTW, what I find more seriously missing in the report is the > (recurring) event time without the optionally added randomization. > This would be a useful addition to the report since there is currently > no way to obtain the randomization that was added. (And if you want to > calculate a cycle-number, you likely want the event time without any > randomization added. Am I correct here Al? >=20 > > I realize this definition of cycle-id has expanded functionality > > from the original, but when I had to write and present the topic > > to get the concept restored in the information model, I tried to > > write a more direct replacement for the database index our > > measurement systems use now. >=20 > And this is appreciated, Al. But things are a bit more complex then > they may appear to you and thus I kept pushing for more details. >=20 > > > What about 6pm at one of the tables in the Wintergarten? > > > > Ok, That's where we'll meet, see you then, anyone else on the > > list with opinions is welcome too. >=20 > Cool, see you in about an hour. >=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 From nobody Thu Jul 21 10:25:25 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7D612D7F8 for ; Thu, 21 Jul 2016 10:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 Ji90Soo8KjUa for ; Thu, 21 Jul 2016 10:25:22 -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 8780112D7F3 for ; Thu, 21 Jul 2016 10:25:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 49553AF3 for ; Thu, 21 Jul 2016 19:25:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id mUO0iVhZnI_Y for ; Thu, 21 Jul 2016 19:25:15 +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 ; Thu, 21 Jul 2016 19:25:19 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 269D920077 for ; Thu, 21 Jul 2016 19:25:19 +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 HEfgTDfCZZtE; Thu, 21 Jul 2016 19:25:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAFA020075; Thu, 21 Jul 2016 19:25:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E1AEE3BDEEBA; Thu, 21 Jul 2016 19:25:16 +0200 (CEST) Date: Thu, 21 Jul 2016 19:25:16 +0200 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20160721172516.GA54646@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.6.0 (2016-04-01) Archived-At: Subject: [lmap] lmap example execution diagram X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 17:25:24 -0000 Hi, while talking with Al I created a diagram illustrating the execution of some schedules on paper in order to make it easier for us to understand the various interesting points in time we have. We found this drawing very helpful and so I started to draw it up in ASCII art so that it fits the RFC format constraints and I added some (very minimal) explanatory text to it. Our proposal is to add such a diagram to the information model and in addition I like to propose to align the examples contained in the YANG and RESTCONF documents with this diagram since it might be helpful to have examples that together tell a consistent story. Feedback welcome. ------8<------8<------8<------8<------8<------8<------ In the example, we have two event sources E1 and E2 and three schedules S1, S2, and S3. The schedule S3 is started by events of event source E2 while the schedules S1 and S2 are both started by events of the event source E1. The schedules S1 and S2 have two actions each and schedule S3 has a single action. The event source E2 has no randomization while the event source has the randomization r. The diagram below shows a possible timeline of an execution. The time T is progressing downwards. The dotted vertial line indicates progress of time while a dotted horizontal line indicates which schedule are triggered by an event. Tilded lines indicate data flowing from an action to another schedule. Actions within a schedule are named A1, A2, etc. E2 E1 T S1 S2 S3 sequential parallel sequential : e0 + : : e0+r + .......... + .......... ++ : | A1 A1 || A2 : + |+ ~~~~~~~> : | A2 | : | + ~~~~~~~~> : + ~~~~~~~~~~~~~~~~~~~~~> : : e1 + : e1+r + .......... + .......... ++ : | A1 A1 || : | +|~~~~~~~> : | | A2 : + +~~~~~~~> : | A2 : + ~~~~~~~~~~~~~~~~~~~~> e0 + ................................... + : | A1 e3 + | e3+r + .......... + .......... ++ | : | A1 A1 || A2 | : + ++ ~~~~~~> | : | A2 + : + ~~~~~~~~~~~~~~~~~~~~> V Note that implementations must handle possible concurrency issues. In the example execution, action A1 of schedule S3 is consuming that has been forwarded to schedule S3 while additional data is arriving from action A2 of schedule S2. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 21 11:15:36 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF0112D669 for ; Thu, 21 Jul 2016 11:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 2vuw2kULTJRn for ; Thu, 21 Jul 2016 11:15: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 1289312B02E for ; Thu, 21 Jul 2016 11:15: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 6104710A7; Thu, 21 Jul 2016 20:15:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id s1NPyPl4A-cg; Thu, 21 Jul 2016 20:15:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 21 Jul 2016 20:15:28 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 101A020077; Thu, 21 Jul 2016 20:15:28 +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 SbD-V8i1SR_Q; Thu, 21 Jul 2016 20:15:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F98220075; Thu, 21 Jul 2016 20:15:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4E2793BDF1AA; Thu, 21 Jul 2016 20:15:26 +0200 (CEST) Date: Thu, 21 Jul 2016 20:15:25 +0200 From: Juergen Schoenwaelder To: "lmap@ietf.org" Message-ID: <20160721181525.GA55267@elstar.local> Mail-Followup-To: "lmap@ietf.org" , "MORTON, ALFRED C (AL)" References: <4AF73AA205019A4C8A1DDD32C034631D4593BBF235@NJFPSRVEXG0.research.att.com> <20160705130009.GA13508@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D4593E6C231@NJFPSRVEXG0.research.att.com> <20160719082256.GA49271@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D45963B262B@NJFPSRVEXG0.research.att.com> <20160721133614.GA54297@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D45963B265D@NJFPSRVEXG0.research.att.com> <20160721150324.GA54411@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D45963B2677@NJFPSRVEXG0.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D45963B2677@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "MORTON, ALFRED C \(AL\)" Subject: Re: [lmap] Calculation of Cycle-Number X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 18:15:35 -0000 I met Al today and the outcome is that we have a concrete proposal for the cycle-number. a) We add ma-event-cycle-interval as an optional element to ma-event-obj. ma-event-cycle-interval: The optional ma-event-cycle-interval defines the duration of the time interval in seconds that is used to calculate cycle numbers. No cycle number is calculated if ma-event- cycle-interval does not exist. b) We add ma-report-result-event-time as a non-optional element to ma-report-result-obj. ma-report-result-event-time: The date and time of the event that triggerent the schedule of the action that produced the reported result values. The date and time does not include any added randomization. c) We add ma-report-result-cycle-number as an optional element to ma-report-result-obj. ma-report-result-cycle-number: An optional cycle number derived from ma-report-result-event-time. It is the time closest to ma-report-result- event-time that is a multiple of the ma-event-cycle-interval of the event that triggered the execution of the schedule. The value is only present in an ma-report-result-obj if the event that triggered the execution of the schedule has a defined ma-event- cycle-interval. The cycle number is represented in the format YYYYMMDD.HHMMSS where YYYY represents the year, MM the month (1..12), DD the day of the months (01..31), HH the hour (00..23), MM the minute (00..59), and SS the second (00..59). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 21 12:04:30 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C005712D85B for ; Thu, 21 Jul 2016 12:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 drmQ3cpfUMU3 for ; Thu, 21 Jul 2016 12:04:26 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C98212D77D for ; Thu, 21 Jul 2016 12:04:26 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id C0F04C7541B8D; Thu, 21 Jul 2016 19:04:21 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u6LJ4OTf017282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Jul 2016 19:04:24 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 u6LJ4Jq7020823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Jul 2016 19:04:24 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.10]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 21 Jul 2016 15:04:18 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder , "lmap@ietf.org" Thread-Topic: [lmap] lmap example execution diagram Thread-Index: AQHR44I+aVlkvEEvzkaRrVv0nhorN6AjPePQ Date: Thu, 21 Jul 2016 19:04:19 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6F1C17@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20160721172516.GA54646@elstar.local> In-Reply-To: <20160721172516.GA54646@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] lmap example execution diagram X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 19:04:29 -0000 Juergen, The example is accurate. The change would be that event source "E1" has the randomization r In the example, we have two event sources E1 and E2 and three schedules S1,= S2, and S3. The schedule S3 is started by events of event source E2 while = the schedules S1 and S2 are both started by events of the event source E1. = The schedules S1 and S2 have two actions each and schedule S3 has a single = action. The event source E2 has no randomization while the event source E1 = has the randomization r. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, July 21, 2016 7:25 PM To: lmap@ietf.org Subject: [lmap] lmap example execution diagram Hi, while talking with Al I created a diagram illustrating the execution of som= e schedules on paper in order to make it easier for us to understand the va= rious interesting points in time we have. We found this drawing very helpfu= l and so I started to draw it up in ASCII art so that it fits the RFC forma= t constraints and I added some (very minimal) explanatory text to it. Our proposal is to add such a diagram to t= he information model and in addition I like to propose to align the example= s contained in the YANG and RESTCONF documents with this diagram since it m= ight be helpful to have examples that together tell a consistent story. Feedback welcome. ------8<------8<------8<------8<------8<------8<------ In the example, we have two event sources E1 and E2 and three schedules S1,= S2, and S3. The schedule S3 is started by events of event source E2 while = the schedules S1 and S2 are both started by events of the event source E1. = The schedules S1 and S2 have two actions each and schedule S3 has a single = action. The event source E2 has no randomization while the event source has= the randomization r. The diagram below shows a possible timeline of an execution. The time T is = progressing downwards. The dotted vertial line indicates progress of time w= hile a dotted horizontal line indicates which schedule are triggered by an = event. Tilded lines indicate data flowing from an action to another schedul= e. Actions within a schedule are named A1, A2, etc. E2 E1 T S1 S2 S3 sequential parallel sequential : e0 + : : e0+r + .......... + .......... ++ : | A1 A1 || A2 : + |+ ~~~~~~~> : | A2 | : | + ~~~~~~~~> : + ~~~~~~~~~~~~~~~~~~~~~> : : e1 + : e1+r + .......... + .......... ++ : | A1 A1 || : | +|~~~~~~~> : | | A2 : + +~~~~~~~> : | A2 : + ~~~~~~~~~~~~~~~~~~~~> e0 + ................................... + : | A1 e3 + | e3+r + .......... + .......... ++ | : | A1 A1 || A2 | : + ++ ~~~~~~> | : | A2 + : + ~~~~~~~~~~~~~~~~~~~~> V Note that implementations must handle possible concurrency issues. In the = example execution, action A1 of schedule S3 is consuming that has been forw= arded to schedule S3 while additional data is arriving from action A2 of sc= hedule S2. /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 Thu Jul 28 02:24:30 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10E812D849 for ; Thu, 28 Jul 2016 02:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.206 X-Spam-Level: X-Spam-Status: No, score=-8.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 LpkG8w_zSaOK for ; Thu, 28 Jul 2016 02:24:27 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 4B97012D8A1 for ; Thu, 28 Jul 2016 02:24:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FXAgAQzplX/yYyC4ddHAEBglkhLVaBA?= =?us-ascii?q?o0lqTiCD4F9JIV5AoE3OBQBAQEBAQEBA1ocC4JROTwBAQEBAQEjAj4xAxIbXgE?= =?us-ascii?q?VFVYmAQQbGogPAQ2eSIUTmCABCgEBAR4FhiuETIRCgkcLWIISHQWZMgGGF4pQh?= =?us-ascii?q?FqDJYVVkCYeNoN6iGYBfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2FXAgAQzplX/yYyC4ddHAEBglkhLVaBAo0lqTiCD4F9JIV?= =?us-ascii?q?5AoE3OBQBAQEBAQEBA1ocC4JROTwBAQEBAQEjAj4xAxIbXgEVFVYmAQQbGogPA?= =?us-ascii?q?Q2eSIUTmCABCgEBAR4FhiuETIRCgkcLWIISHQWZMgGGF4pQhFqDJYVVkCYeNoN?= =?us-ascii?q?6iGYBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,433,1464667200"; d="scan'208,217";a="185460488" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Jul 2016 05:24:25 -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/AES256-SHA; 28 Jul 2016 05:24:25 -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.0294.000; Thu, 28 Jul 2016 11:24:22 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: Reminder - 3 LMAP documents in WGLC Thread-Index: AdHosdKbvDXs999ER/+q3AjFztvEFw== Date: Thu, 28 Jul 2016 09:24:21 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA752541E9@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA752541E9AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Reminder - 3 LMAP documents in WGLC X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 09:24:29 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA752541E9AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is a kind reminder that there are three LMAP I-Ds in WGLC: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ https://datatracker.ietf.org/doc/draft-ietf-lmap-restconf The WGLC ends on Sunday 7/31. Your reviews and comments are needed and high= ly appreciated. If you believe that any or all the document are ready for s= ubmission to the IESG as they stand - please say it as well. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA752541E9AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 =

This is a kind reminder = that there are three LMAP I-Ds in WGLC:

 =

https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model= /

http= s://datatracker.ietf.org/doc/draft-ietf-lmap-yang/

h= ttps://datatracker.ietf.org/doc/draft-ietf-lmap-restconf

&n= bsp;

The WGLC ends on Sunday 7/31. Your reviews and comme= nts are needed and highly appreciated. If you believe that any or all the document are= ready for submission to the IESG as they stand – please say it as we= ll.

 =

Thanks and Regards,=

 =

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA752541E9AZFFEXMB04globa_-- From nobody Thu Jul 28 07:12:57 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241ED12D772 for ; Thu, 28 Jul 2016 07:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 NYnlWITP0J90 for ; Thu, 28 Jul 2016 07:12:54 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (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 976DE12D771 for ; Thu, 28 Jul 2016 07:12:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2F9AwBdEppX/yYyC4ddHQGCWSEtVoECj?= =?us-ascii?q?SWpOIIPgX0khXkCgTQ4FAEBAQEBAQEDWhwLglEiFxABAQEBAQFPAj4xAxIbXgE?= =?us-ascii?q?MCRVWJgEEGxqIDwENnhaFE5geAQoBAQEeBYYriQ6DKoIvBZkyAZBnhFqDJYVVk?= =?us-ascii?q?CYeNoN6iGYBfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2F9AwBdEppX/yYyC4ddHQGCWSEtVoECjSWpOIIPgX0khXk?= =?us-ascii?q?CgTQ4FAEBAQEBAQEDWhwLglEiFxABAQEBAQFPAj4xAxIbXgEMCRVWJgEEGxqID?= =?us-ascii?q?wENnhaFE5geAQoBAQEeBYYriQ6DKoIvBZkyAZBnhFqDJYVVkCYeNoN6iGYBfgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.28,434,1464667200"; d="scan'208,217";a="198371292" 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; 28 Jul 2016 10:12:34 -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/AES256-SHA; 28 Jul 2016 10:12:34 -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.0294.000; Thu, 28 Jul 2016 10:12:33 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP WG meeting at IETF 96 - draft minutes posted Thread-Index: AdHo2hTHo/Kz8gQWRH272nU0qXcN0Q== Date: Thu, 28 Jul 2016 14:12:32 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7525481B@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA7525481BAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP WG meeting at IETF 96 - draft minutes posted X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 14:12:56 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA7525481BAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have posted the draft of the minutes of the LMAP WG meeting at IETF 96 at= https://www.ietf.org/proceedings/96/minutes/minutes-96-lmap. Thanks to Bar= bara Stark and the other note takers - you made my task very easy. If there= are any additions, corrections, questions, comments, or concerns please le= t me know. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA7525481BAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have posted the draft of the minutes of the LMAP W= G meeting at IETF 96 at htt= ps://www.ietf.org/proceedings/96/minutes/minutes-96-lmap. Thanks to Bar= bara Stark and the other note takers – you made my task very easy. If= there are any additions, corrections, questions, comments, or concerns please let me know.

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA7525481BAZFFEXMB04globa_-- From nobody Thu Jul 28 09:29:53 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA27912B025 for ; Thu, 28 Jul 2016 09:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.206 X-Spam-Level: X-Spam-Status: No, score=-8.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 NL1ZF7UY1Q6p for ; Thu, 28 Jul 2016 09:29:51 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 85FEE12D567 for ; Thu, 28 Jul 2016 09:29:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EHAgAgMppX/yYyC4ddHQGCWSEtVoECj?= =?us-ascii?q?SWpO4IPgX0khXkCgTM4FAEBAQEBAQEDWhwLglE5PAEBAQEBASMCPjEDEhteARU?= =?us-ascii?q?VViYBBBsaiA8BDZ4uhROYIwEKAQEBHgWGK4kOgkcLWIISHQWOFoscAYYXkk+FV?= =?us-ascii?q?ZAmHjaCRYE1iHABfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2EHAgAgMppX/yYyC4ddHQGCWSEtVoECjSWpO4IPgX0khXk?= =?us-ascii?q?CgTM4FAEBAQEBAQEDWhwLglE5PAEBAQEBASMCPjEDEhteARUVViYBBBsaiA8BD?= =?us-ascii?q?Z4uhROYIwEKAQEBHgWGK4kOgkcLWIISHQWOFoscAYYXkk+FVZAmHjaCRYE1iHA?= =?us-ascii?q?BfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,434,1464667200"; d="scan'208,217";a="163896446" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Jul 2016 12:29:47 -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/AES256-SHA; 28 Jul 2016 12:29:35 -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.0294.000; Thu, 28 Jul 2016 18:29:33 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: WGLC comments for https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ Thread-Index: AdHo7TchdlymFToqTtaQ9LHMVZN7lA== Date: Thu, 28 Jul 2016 16:29:32 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA75254AD4@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA75254AD4AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] WGLC comments for https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 16:29:53 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA75254AD4AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few (mostly) editorial and clarification comments for https://datatracker= .ietf.org/doc/draft-ietf-lmap-information-model/: 1. Section 3, pag. 8: 'It should be clear that the top-level behavior= of an MA is simply to execute Schedules.' - what does 'top-level behavior'= exactly mean? 2. Section 3.3.2, pag. 16, definition of ma-suppression-match - s/An = optional and possibly empty unordered set of match pattern/ An optional and= possibly empty unordered set of match patterns/ 3. Section 3.8.1, pag 34, definition of ma-channel-interface-name - '= If not present, the system will select a suitable interface.' - who is 'the= system' here?' 4. Section 3.9, pag. 36: 'A reporting task might also have a flag par= ameter'- capitalize Reporting Task for consistency Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA75254AD4AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A few (mostly) editorial and clarification comments = for https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/:

 

1.    =
   Section 3, pag. 8: ‘It should be c=
lear that the top-level behavior of an MA is simply to execute Schedules.’ – what does ‘top-level behavior’ exactly mea=
n? 
2.    =
   Section 3.3.2, pag. 16, definition of ma-suppression-mat=
ch – s/An optional and possibly empty unordered set of match pattern/=
 An optional and possibly empty unordered set of match patterns/=

3.    =
   Section 3.8.1, pag 34, definition of ma-channel-interfac=
e-name – ‘If not present, the system will select a suitable int=
erface.’ – who is ‘the system’ here?’
4.    =
   Section 3.9, pag. 36: ‘A reporting task might also=
 have a flag parameter’- capitalize Reporting Task for consistency
 
Regards,
 
Dan
 
 
 
--_000_9904FB1B0159DA42B0B887B7FA8119CA75254AD4AZFFEXMB04globa_-- From nobody Sun Jul 31 08:21:45 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DB412B071 for ; Sun, 31 Jul 2016 08:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.206 X-Spam-Level: X-Spam-Status: No, score=-8.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 e97aPkifJZVT for ; Sun, 31 Jul 2016 08:21:42 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 6C9A612B010 for ; Sun, 31 Jul 2016 08:21:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EOAgCCFp5X/yYyC4ddHoJZIS1WfAa5B?= =?us-ascii?q?YF9JIV5AoEkOBQBAQEBAQEBA1ocC4JTIhcQAQEBAQEBTwI+MQMSG14BFRVWJgE?= =?us-ascii?q?EGxMHiA8BDaBchROaHgEKAQEBHgWGK4h2GIJHC1iCLwWZMwGYaIVVkCceNoN6b?= =?us-ascii?q?gGHAwF+AQEB?= X-IPAS-Result: =?us-ascii?q?A2EOAgCCFp5X/yYyC4ddHoJZIS1WfAa5BYF9JIV5AoEkOBQ?= =?us-ascii?q?BAQEBAQEBA1ocC4JTIhcQAQEBAQEBTwI+MQMSG14BFRVWJgEEGxMHiA8BDaBch?= =?us-ascii?q?ROaHgEKAQEBHgWGK4h2GIJHC1iCLwWZMwGYaIVVkCceNoN6bgGHAwF+AQEB?= X-IronPort-AV: E=Sophos;i="5.28,450,1464667200"; d="scan'208,217";a="164188113" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 31 Jul 2016 11:21:37 -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/AES256-SHA; 31 Jul 2016 11:21:37 -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.0294.000; Sun, 31 Jul 2016 17:21:35 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: comments on https://www.ietf.org/id/draft-ietf-lmap-restconf-03.txt Thread-Index: AdHrPza1VMJeXcQ/QIqm937s6Q6dJQ== Date: Sun, 31 Jul 2016 15:21:34 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA752572F2@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_9904FB1B0159DA42B0B887B7FA8119CA752572F2AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] comments on https://www.ietf.org/id/draft-ietf-lmap-restconf-03.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jul 2016 15:21:44 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA752572F2AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The WGLC for https://www.ietf.org/id/draft-ietf-lmap-restconf-03.txt expire= s today. Obviously, the document is not yet ready for submission to the IES= G. Let me try to recap shortly what was discussed in the meeting at IETF 96= and how we can progress this document from here. - The consensus in the room at IETF 96 was that this document is b= asically an application statement, that describes how RESTONF and call-home= are being used to meet the required functionality of the LMAP configuratio= n protocol and LMAP reporting protocol. - The introduction paragraph should mention the fact that the WG p= rotocol selection process gave preference to a solution that reuses existin= g IETF protocols rather than inventing new ones - The current text is pretty much trimmed down - but there was at = least one comment (from Tim) that asked to document more in detail how call= -home is being used and the fact that the MA initiates the communication - = i.e. the MA needs to implement both a server (for the configuration protoco= l) and a client (for the reporting protocol) - Rework and clarify the example - Add Security Considerations - guidance for when information is c= ommunicated, reference to the RESTCONF security considerations - Make draft-ietf-netconf-call-home a normative reference; one can= not implement the LMAP reporting protocol without it - Obviously RESTCONF and call-home are dependencies. The plan is t= o edit and post a revised version after the LC expires and park the documen= t until RESTCONF and call-home will be approved Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA752572F2AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WGLC for https://www.ietf.org/id/draft-ietf-lmap-restconf-03.txt expires today. = Obviously, the document is not yet ready for submission to the IESG. Let me= try to recap shortly what was discussed in the meeting at IETF 96 and how = we can progress this document from here.

 

-     &= nbsp;    The consensus in the room = at IETF 96 was that this document is basically an application statement, th= at describes how RESTONF and call-home are being used to meet the required = functionality of the LMAP configuration protocol and LMAP reporting protocol.

-     &= nbsp;    The introduction paragraph= should mention the fact that the WG protocol selection process gave prefer= ence to a solution that reuses existing IETF protocols rather than inventin= g new ones

-     &= nbsp;    The current text is pretty= much trimmed down – but there was at least one comment (from Tim) th= at asked to document more in detail how call-home is being used and the fac= t that the MA initiates the communication – i.e. the MA needs to implement both a server (for the configuratio= n protocol) and a client (for the reporting protocol)

-     &= nbsp;    Rework and clarify the exa= mple

-     &= nbsp;    Add Security Consideration= s – guidance for when information is communicated, reference to the R= ESTCONF security considerations

-     &= nbsp;    Make draft-ietf-netconf-ca= ll-home a normative reference; one cannot implement the LMAP reporting prot= ocol without it

-     &= nbsp;    Obviously RESTCONF and cal= l-home are dependencies. The plan is to edit and post a revised version aft= er the LC expires and park the document until RESTCONF and call-home will b= e approved

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA752572F2AZFFEXMB04globa_--