From nobody Mon Jan 5 02:29:25 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17FC1A3BA0 for ; Mon, 5 Jan 2015 02:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRJJZLQx0sfU for ; Mon, 5 Jan 2015 02:29:21 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B6E1A1B8A for ; Mon, 5 Jan 2015 02:29:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIGAFNmqlSHCzIm/2dsb2JhbABcFoItISJSWASDAbBUAQEBAQEHkjmFcgIcahYBAQEBAQF8hAwBAQEBAwUNEQIIAVsCAQgNBAQBAQYBAQECCBUDAgICBRANAgwUCQgCBBIBCAYUiAoBDJ5LikmTPQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgwuCeIZEgn8tCgGCaC6BEwWOFYJyAUwWhiuCaYIkh32DOSKDbm8BAYFDfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,698,1413259200"; d="jpg'145?scan'145,208,217,145";a="98751105" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Jan 2015 05:29:09 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 05 Jan 2015 05:29:09 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Mon, 5 Jan 2015 05:29:08 -0500 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [lmap] February 2015 LMAP WG Virtual Interim Meeting Thread-Index: AQHQGStps8vNx61HCEGUJvLnPEdCpZyxcjCA Date: Mon, 5 Jan 2015 10:29:07 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C95BB1B@AZ-FFEXMB04.global.avaya.com> References: <848498526.3968072.1418732732028.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE.doodle@worker2> In-Reply-To: <848498526.3968072.1418732732028.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE.doodle@worker2> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/related; boundary="_005_9904FB1B0159DA42B0B887B7FA8119CA5C95BB1BAZFFEXMB04globa_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/4AtSCaWMtXDYInISE7mm_bCv4jE Subject: Re: [lmap] February 2015 LMAP WG Virtual Interim Meeting X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 10:29:24 -0000 --_005_9904FB1B0159DA42B0B887B7FA8119CA5C95BB1BAZFFEXMB04globa_ Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C95BB1BAZFFEXMB04globa_" --_000_9904FB1B0159DA42B0B887B7FA8119CA5C95BB1BAZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk9uZSBtb3JlIHJlbWluZGVyIHRvIGV4cHJlc3MgeW91ciBwcmVmZXJlbmNlcyBmb3Ig dGhlIGRhdGUgYW5kIHRpbWUgb2YgdGhlIEZlYnJ1YXJ5IExNQVAgV0cgaW50ZXJpbSBtZWV0aW5n LCBpZiB5b3UgZGlkIG5vdCBkbyBpdCB5ZXQuDQoNClRoYW5rcyBhbmQgUmVnYXJkcywNCg0KRGFu DQoNCg0KRnJvbTogbG1hcCBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIERhbiBSb21hc2NhbnUgKHZpYSBEb29kbGUpDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAx NiwgMjAxNCAyOjI2IFBNDQpUbzogbG1hcEBpZXRmLm9yZw0KU3ViamVjdDogW2xtYXBdIEZlYnJ1 YXJ5IDIwMTUgTE1BUCBXRyBWaXJ0dWFsIEludGVyaW0gTWVldGluZw0KDQpEYW4gUm9tYXNjYW51 IGludml0ZXMgeW91IHRvIHBhcnRpY2lwYXRlIGluIHRoZSBEb29kbGUgcG9sbCAiRmVicnVhcnkg MjAxNSBMTUFQIFdHIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nLiINCg0KDQoNCltJbWFnZSByZW1v dmVkIGJ5IHNlbmRlci5dPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fZG9vZGxlLmNvbV8tM0Z0bWFpbC0zRHBvbGwtNUZpbnZpdGVjb250YWN0LTVG cGFydGljaXBhbnQtNUZpbnZpdGF0aW9uLTVGd2l0aC01Rm1lc3NhZ2UtMjZ0bGluay0zRGxvZ28m ZD1BQU1GYVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9STRkekd4UjMxT2NOWENKZlF6dmxz aUxRZnVjQlhSdWNQdmRycGhwQnNGQSZtPVVuY1hIaFFmajEwanJ2dDZiQzk5c0d3OGtia2NsYnJO RUJzNVg3WVZmVDgmcz16cjV0RTkxUkhPMEUyMHp5bVFHRDN3SDF0aVVBMC1mbmJpclZfeGFkVnp3 JmU9Pg0KDQoNCg0KSGkgdGhlcmUsDQoNCg0KDQoNCg0KRGFuIFJvbWFzY2FudSAoZHJvbWFzY2FA YXZheWEuY29tKSBpbnZpdGVzIHlvdSB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgRG9vZGxlIHBvbGwg IkZlYnJ1YXJ5IDIwMTUgTE1BUCBXRyBWaXJ0dWFsIEludGVyaW0gTWVldGluZyIuDQoNCg0KRGFu IFJvbWFzY2FudSBzYXlzOg0KVmlydHVhbCBJbnRlcmltIG1lZXRpbmcgb2YgdGhlIElFVEYgTE1B UCBXRw0KDQoNCg0KUGFydGljaXBhdGUgbm93PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZG9vZGxlLmNvbV91aXE5cTd5bWQ3ZjVld3ViLTNGdG1h aWwtM0Rwb2xsLTVGaW52aXRlY29udGFjdC01RnBhcnRpY2lwYW50LTVGaW52aXRhdGlvbi01Rndp dGgtNUZtZXNzYWdlLTI2dGxpbmstM0Rwb2xsYnRuJmQ9QUFNRmFRJmM9QkZwV1F3OGJzdUtwbDFT Z2laSDY0USZyPUk0ZHpHeFIzMU9jTlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBocEJzRkEmbT1V bmNYSGhRZmoxMGpydnQ2YkM5OXNHdzhrYmtjbGJyTkVCczVYN1lWZlQ4JnM9bVcyRTVOMFBiMXpx OW01U1lXdEs1RjNYNGN5STVzOE9QeHgwM29ZSW5lSSZlPT4NCg0KDQoNCg0KW0ltYWdlIHJlbW92 ZWQgYnkgc2VuZGVyLl0NCg0KV2hhdCBpcyBEb29kbGU/IERvb2RsZSBpcyBhIHdlYiBzZXJ2aWNl IHRoYXQgaGVscHMgRGFuIFJvbWFzY2FudSB0byBmaW5kIGEgc3VpdGFibGUgZGF0ZSBmb3IgbWVl dGluZyB3aXRoIGEgZ3JvdXAgb2YgcGVvcGxlLiBMZWFybiBtb3JlIGFib3V0IGhvdyBEb29kbGUg d29ya3MuPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fZG9vZGxlLmNvbV9tYWluLmh0bWwtM0Z0bGluay0zRGNoZWNrT3V0TGluay0yNnRtYWlsLTNE cG9sbC01Rmludml0ZWNvbnRhY3QtNUZwYXJ0aWNpcGFudC01Rmludml0YXRpb24tNUZ3aXRoLTVG bWVzc2FnZSZkPUFBTUZhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1JNGR6R3hSMzFPY05Y Q0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09VW5jWEhoUWZqMTBqcnZ0NmJDOTlzR3c4 a2JrY2xick5FQnM1WDdZVmZUOCZzPVc3T2RGM2cyYU9HeTZMMWxLMW1MNGJPbFk3TGd0UzRfSGI5 YkpXRTRwXzAmZT0+DQoNCg0KDQpZb3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBiZWNhdXNl ICJEYW4gUm9tYXNjYW51IiBoYXMgaW52aXRlZCB5b3UgdG8gcGFydGljaXBhdGUgaW4gdGhlIERv b2RsZSBwb2xsICJGZWJydWFyeSAyMDE1IExNQVAgV0cgVmlydHVhbCBJbnRlcmltIE1lZXRpbmcu Ig0KDQoNCg0KRG9vZGxlIEFHLCBXZXJkc3RyYXNzZSAyMSwgODAyMSBaw7xyaWNoDQoNCg0KDQoN Cg== --_000_9904FB1B0159DA42B0B887B7FA8119CA5C95BB1BAZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQoJcGFub3NlLTE6MiA3IDQgOSAyIDIgNSAyIDQgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQoJcGFub3NlLTE6MiA3IDQgOSAy IDIgNSAyIDQgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhv bWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9uZSBtb3JlIHJlbWluZGVyIHRvIGV4cHJlc3Mg eW91ciBwcmVmZXJlbmNlcyBmb3IgdGhlIGRhdGUgYW5kIHRpbWUgb2YgdGhlIEZlYnJ1YXJ5IExN QVAgV0cgaW50ZXJpbSBtZWV0aW5nLCBpZiB5b3UgZGlkIG5vdCBkbyBpdCB5ZXQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGFua3MgYW5kIFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkRhbiBSb21hc2NhbnUgKHZpYSBEb29kbGUpPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IERlY2VtYmVyIDE2LCAyMDE0IDI6MjYgUE08YnI+DQo8Yj5Ubzo8L2I+IGxtYXBAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2xtYXBdIEZlYnJ1YXJ5IDIwMTUgTE1BUCBXRyBWaXJ0dWFs IEludGVyaW0gTWVldGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkRhbiBSb21hc2Nh bnUgaW52aXRlcyB5b3UgdG8gcGFydGljaXBhdGUgaW4gdGhlIERvb2RsZSBwb2xsICZxdW90O0Zl YnJ1YXJ5IDIwMTUgTE1BUCBXRyBWaXJ0dWFsIEludGVyaW0gTWVldGluZy4mcXVvdDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBhbGlnbj0iY2VudGVyIj4NCjx0YWJsZSBjbGFzcz0iTXNv Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJTtiYWNrZ3JvdW5kOndoaXRlO2hlaWdodDox MDAlIWltcG9ydGFudDt3aWR0aDoxMDAlIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQg dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8ZGl2IGFsaWdu PSJjZW50ZXIiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs c3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI0ODAiIHN0eWxlPSJ3aWR0aDozNjAu MHB0O2JhY2tncm91bmQ6d2hpdGUiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MjEuMHB0 Ij4NCjx0ZCBjb2xzcGFuPSI0IiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0 OjIxLjBwdCI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAw Y20gMGNtIj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNw YWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNDgwIiBzdHlsZT0id2lkdGg6MzYwLjBw dDtiYWNrZ3JvdW5kOndoaXRlIiBpZD0idGVtcGxhdGVIZWFkZXIiPg0KPHRib2R5Pg0KPHRyIHN0 eWxlPSJoZWlnaHQ6MjEuMHB0Ij4NCjx0ZCBjb2xzcGFuPSI0IiBzdHlsZT0icGFkZGluZzowY20g MGNtIDBjbSAwY207aGVpZ2h0OjIxLjBwdCI+PC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdo dDoxOS41cHQiPg0KPHRkIHdpZHRoPSIxNSIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDox MS4yNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxOS41cHQiPg0KPC90ZD4NCjx0 ZCB3aWR0aD0iMTIwIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjkwLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTkuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fZG9vZGxlLmNvbV8tM0Z0bWFpbC0zRHBvbGwtNUZpbnZpdGVjb250YWN0LTVGcGFydGljaXBh bnQtNUZpbnZpdGF0aW9uLTVGd2l0aC01Rm1lc3NhZ2UtMjZ0bGluay0zRGxvZ28mYW1wO2Q9QUFN RmFRJmFtcDtjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmYW1wO3I9STRkekd4UjMxT2NOWENKZlF6 dmxzaUxRZnVjQlhSdWNQdmRycGhwQnNGQSZhbXA7bT1VbmNYSGhRZmoxMGpydnQ2YkM5OXNHdzhr YmtjbGJyTkVCczVYN1lWZlQ4JmFtcDtzPXpyNXRFOTFSSE8wRTIwenltUUdEM3dIMXRpVUEwLWZu YmlyVl94YWRWencmYW1wO2U9Ij48c3BhbiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdpbmRvd3RleHQg MS4wcHQ7cGFkZGluZzowY207dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiB3 aWR0aD0iMjYiIGhlaWdodD0iMjYiIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iY2lkOmltYWdlMDAx LmpwZ0AwMUQwMjhFMy4zMDExRTIzMCIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci4iPjwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIzMzAiIHZhbGlnbj0i Ym90dG9tIiBzdHlsZT0id2lkdGg6MjQ3LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWln aHQ6MTkuNXB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1IiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9 IndpZHRoOjExLjI1cHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjE5LjVwdCI+DQo8 L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjkuMHB0Ij4NCjx0ZCBjb2xzcGFuPSI0IiBz dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjkuMHB0Ij48L3RkPg0KPC90cj4N CjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBj bSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0K PHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMEU3 RjAgMS4wcHQ7YmFja2dyb3VuZDojRjVGOUZEO3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNl bGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+ DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjE1LjBwdCAxMS4yNXB0IDBj bSAxMS4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxOC43 NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5IaSB0aGVyZSwNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20g MGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y1 RjlGRDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRh YmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjEw MCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9w IiBzdHlsZT0icGFkZGluZzowY20gMTEuMjVwdCAwY20gMTEuMjVwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTc1NzU3 Ij4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90 ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249 InRvcCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y1RjlGRDtwYWRkaW5nOjBjbSAxMS4yNXB0IDE1LjBw dCAxMS4yNXB0Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2Vs bHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEw MC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBj bSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTguNzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzU3NTc1NyI+RGFuIFJvbWFzY2FudSAoZHJvbWFzY2FA YXZheWEuY29tKSBpbnZpdGVzIHlvdSB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgRG9vZGxlIHBvbGwN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mcXVvdDtGZWJydWFyeSAyMDE1IExNQVAg V0cgVmlydHVhbCBJbnRlcmltIE1lZXRpbmcmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzU3 NTc1NyI+Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3Rk Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0i cGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0iYmFja2dyb3VuZDojRjVGOUZEO3BhZGRpbmc6MGNtIDExLjI1cHQgMTMuNXB0 IDExLjI1cHQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs c3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAw LjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNEMEUzRkIgMi4yNXB0O3BhZGRpbmc6Ni4wcHQgMGNtIDYuMHB0 IDEwLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTYuNXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9y OiMyMjIyMjIiPkRhbiBSb21hc2NhbnUgc2F5czoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNi41cHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6IzU3NTc1NyI+Vmly dHVhbCBJbnRlcmltIG1lZXRpbmcgb2YgdGhlIElFVEYgTE1BUCBXRw0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBj bSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20i PjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJiYWNrZ3JvdW5kOiNERkVDRkM7cGFkZGlu ZzowY20gMGNtIDBjbSAwY20iPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0i d2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjcuNXB0Ij4NCjx0ZCB3 aWR0aD0iMTUiIGNvbHNwYW49IjMiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTEuMjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6Ny41cHQiPg0KPC90ZD4NCjwvdHI+DQo8dHI+ DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2JveC1zaGFkb3c6IDBweCAwcHgg MnB4IDAgcmdiKDAsIDAsIDAuMjgpO2JvcmRlci1yYWRpdXM6IDNweCI+DQo8dGFibGUgY2xhc3M9 Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVy LXNwYWNpbmc6IDE0cHggMHB4Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0iYmFja2dyb3Vu ZDojMDA2NkREO3BhZGRpbmc6My4wcHQgNS4yNXB0IDMuMHB0IDUuMjVwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6Mi4y NXB0O21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0OjEzLjVwdDttYXJnaW4tYm90dG9tOi4w MDAxcHQ7bGluZS1oZWlnaHQ6MTMuNXB0Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fZG9vZGxlLmNvbV91aXE5cTd5bWQ3ZjVld3ViLTNGdG1haWwtM0Rwb2xsLTVGaW52aXRl Y29udGFjdC01RnBhcnRpY2lwYW50LTVGaW52aXRhdGlvbi01RndpdGgtNUZtZXNzYWdlLTI2dGxp bmstM0Rwb2xsYnRuJmFtcDtkPUFBTUZhUSZhbXA7Yz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJmFt cDtyPUk0ZHpHeFIzMU9jTlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBocEJzRkEmYW1wO209VW5j WEhoUWZqMTBqcnZ0NmJDOTlzR3c4a2JrY2xick5FQnM1WDdZVmZUOCZhbXA7cz1tVzJFNU4wUGIx enE5bTVTWVd0SzVGM1g0Y3lJNXM4T1B4eDAzb1lJbmVJJmFtcDtlPSI+PHNwYW4gc3R5bGU9ImNv bG9yOndoaXRlO3RleHQtZGVjb3JhdGlvbjpub25lIj5QYXJ0aWNpcGF0ZSZuYnNwO25vdzwvc3Bh bj48L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5 Pg0KPC90YWJsZT4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48 L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjwvdHI+DQo8 dHIgc3R5bGU9ImhlaWdodDo3LjVwdCI+DQo8dGQgd2lkdGg9IjE1IiBjb2xzcGFuPSIzIiB2YWxp Z249InRvcCIgc3R5bGU9IndpZHRoOjExLjI1cHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY207aGVp Z2h0OjcuNXB0Ij4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRk IHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGlu ZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20g MGNtIj48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpz b2xpZCAjREZFQ0ZDIDEuMHB0O3BhZGRpbmc6MTEuMjVwdCAxMS4yNXB0IDExLjI1cHQgMTEuMjVw dCI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5n PSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0K PHRib2R5Pg0KPHRyPg0KPHRkIHdpZHRoPSIzNSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoy Ni4yNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+PGlt ZyBib3JkZXI9IjAiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTAwIiBpZD0iX3gwMDAwX2kxMDI2IiBz cmM9ImNpZDp+V1JEMDAwLmpwZyIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci4iPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE2LjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIi PldoYXQgaXMgRG9vZGxlPzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzU3 NTc1NyI+IERvb2RsZSBpcyBhIHdlYiBzZXJ2aWNlIHRoYXQgaGVscHMNCiBEYW4gUm9tYXNjYW51 IHRvIGZpbmQgYSBzdWl0YWJsZSBkYXRlIGZvciBtZWV0aW5nIHdpdGggYSBncm91cCBvZiBwZW9w bGUuIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fZG9vZGxlLmNvbV9tYWluLmh0bWwtM0Z0bGluay0zRGNoZWNrT3V0TGluay0yNnRt YWlsLTNEcG9sbC01Rmludml0ZWNvbnRhY3QtNUZwYXJ0aWNpcGFudC01Rmludml0YXRpb24tNUZ3 aXRoLTVGbWVzc2FnZSZhbXA7ZD1BQU1GYVEmYW1wO2M9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZh bXA7cj1JNGR6R3hSMzFPY05YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJmFtcDttPVVu Y1hIaFFmajEwanJ2dDZiQzk5c0d3OGtia2NsYnJORUJzNVg3WVZmVDgmYW1wO3M9VzdPZEYzZzJh T0d5NkwxbEsxbUw0Yk9sWTdMZ3RTNF9IYjliSldFNHBfMCZhbXA7ZT0iPg0KTGVhcm4gbW9yZSBh Ym91dCBob3cgRG9vZGxlIHdvcmtzLjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRk aW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBj bSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0K PC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0Y1RjlGRCAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8ZGl2IGFs aWduPSJjZW50ZXIiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj ZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWln aHQ6MTguMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjE4 LjBwdCI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5n OjBjbSAxMS4yNXB0IDYuNzVwdCAxMS4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTk5 OTk5Ij5Zb3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBiZWNhdXNlICZxdW90O0RhbiBSb21h c2NhbnUmcXVvdDsgaGFzIGludml0ZWQgeW91IHRvIHBhcnRpY2lwYXRlIGluIHRoZSBEb29kbGUg cG9sbCAmcXVvdDtGZWJydWFyeSAyMDE1IExNQVAgV0cgVmlydHVhbA0KIEludGVyaW0gTWVldGlu Zy4mcXVvdDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9 ImhlaWdodDo5LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdo dDo5LjBwdCI+PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvZGl2Pg0KPC90ZD4N Cjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBh ZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20g MGNtIDBjbSI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNEREREREQgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSAwY20iPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3Bh Y2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAl Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6OS4wcHQg MTEuMjVwdCAxNS4wcHQgMTEuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTIuNzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5OTk5OTki PkRvb2RsZSBBRywgV2VyZHN0cmFzc2UgMjEsIDgwMjEgWsO8cmljaA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBj bSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20i PjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0K PC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9904FB1B0159DA42B0B887B7FA8119CA5C95BB1BAZFFEXMB04globa_-- --_005_9904FB1B0159DA42B0B887B7FA8119CA5C95BB1BAZFFEXMB04globa_ Content-Type: image/jpeg; name="~WRD000.jpg" Content-Description: ~WRD000.jpg Content-Disposition: inline; filename="~WRD000.jpg"; size=823; creation-date="Mon, 05 Jan 2015 10:27:55 GMT"; modification-date="Mon, 05 Jan 2015 10:27:55 GMT" Content-ID: <~WRD000.jpg> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_005_9904FB1B0159DA42B0B887B7FA8119CA5C95BB1BAZFFEXMB04globa_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=344; creation-date="Mon, 05 Jan 2015 10:29:06 GMT"; modification-date="Mon, 05 Jan 2015 10:29:06 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAAaABoBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKK/ /9k= --_005_9904FB1B0159DA42B0B887B7FA8119CA5C95BB1BAZFFEXMB04globa_-- From nobody Tue Jan 6 00:59:49 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBEE1A9112 for ; Tue, 6 Jan 2015 00:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBQy3Nap4Swu for ; Tue, 6 Jan 2015 00:59:46 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B3A1A1EEE for ; Tue, 6 Jan 2015 00:59:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFAO6iq1SHCzIm/2dsb2JhbABcgkMhIlJcs3cBAQEBAQeYLQKBDhYBAQEBAQF8hA4BAQMSG14BDAkVViYBBBsaiAoBng+Ee55nDAEfhgSGRIJ/g06BEwWOIIoCgmiCKYgCgzkig26CNH4BAQE X-IronPort-AV: E=Sophos; i="5.07,706,1413259200"; d="scan'208,217"; a="98917184" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Jan 2015 03:59:44 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 06 Jan 2015 03:59:45 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Tue, 6 Jan 2015 09:59:43 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP Virtual Interim Date - Thursday February 12, 12-2PM EST Thread-Index: AdApjxv4TmE2a6wjTT62FEK1sZAiTg== Date: Tue, 6 Jan 2015 08:59:42 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C95D645@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_9904FB1B0159DA42B0B887B7FA8119CA5C95D645AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/HWJ1JUnzK1oIpME7kVoix38bh3M Subject: [lmap] LMAP Virtual Interim Date - Thursday February 12, 12-2PM EST X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 08:59:48 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C95D645AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Doodle has spoken. The clear majority of the participants in the poll chose= Thursday February 12, between noon and 2PM as date and time of the second = LMAP virtual interim meeting. Please mark this date and time in your schedu= les. I will ask the secretariat to send Webex information. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C95D645AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Doodle has spoken. The clear majority of the partici= pants in the poll chose Thursday February 12, between noon and 2PM as date = and time of the second LMAP virtual interim meeting. Please mark this date = and time in your schedules. I will ask the secretariat to send Webex information.

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C95D645AZFFEXMB04globa_-- From nobody Tue Jan 6 15:29:19 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3744E1A871B; Tue, 6 Jan 2015 15:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ospas79ePO6p; Tue, 6 Jan 2015 15:29:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A41551A016A; Tue, 6 Jan 2015 15:29:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150106232914.4753.57378.idtracker@ietfa.amsl.com> Date: Tue, 06 Jan 2015 15:29:14 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/NrvmmXSFSMEAWK5iO72LvGdszB4 Cc: lmap@ietf.org Subject: [lmap] LMAP WG Virtual Interim Meeting, February 12, 2015 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iesg-secretary@ietf.org List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 23:29:16 -0000 The LMAP WG will hold a virtual interim meeting on Thursday, February 12, 2015, between noon and 2:00PM EST (1700-1900 UTC). ------------------------- LMAP Virtual Interim Meeting Thursday, February 12, 2015 12:00 pm | Eastern Standard Time (New York, GMT-05:00) | 2 hr Join WebEx meeting: https://ietf.webex.com/ietf/j.php?MTID=m7f02a060d018e8c17780318de9084c6b Meeting number: 645 771 127 Meeting password: 1234 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 645 771 127 Toll-free calling restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Add this meeting to your calendar: https://ietf.webex.com/ietf/j.php?MTID=ma1a9b1ecdacf17cbc99dff93a9040d6a Can't join the meeting? Contact support: https://ietf.webex.com/ietf/mc IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. From nobody Thu Jan 8 03:25:20 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393911ACD10 for ; Thu, 8 Jan 2015 03:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDoJjeS4seJE for ; Thu, 8 Jan 2015 03:25:15 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227431ACD16 for ; Thu, 8 Jan 2015 03:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1152; q=dns/txt; s=iport; t=1420716315; x=1421925915; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=+wljIVCofdVuXE8Q7qobHdLYJd1C5raF4gy1MWpSHAs=; b=e3C2RpxgBj8yzQVNgH67lCB+DdQf61zTkd0+9O/zkYWhPZMpAq2SB806 8A8jdT7rhtUMFYz4dfFwCiV2/ZP4A2yxy5Yr9zJpnjhx1JzBQ4kJXnVx/ IJ/O7rceFFVFyiUznePiQsQmRK3+EsKPMWsdnAelryfMWY9y8Qp3adYUP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0EAGVorlStJssW/2dsb2JhbABcg1hYxgKFaQqBVQEBAQEBfYRLNgoBPBYYAwIBAgFLDQEHAQGIKA3GHAEBAQEBAQEDAQEBAQEBARcEjygBAU+EMAEEk3mDQYEOgnGCF4tYIoNvPTEBgQuBNwEBAQ X-IronPort-AV: E=Sophos;i="5.07,722,1413244800"; d="scan'208";a="299506980" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 08 Jan 2015 11:25:13 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t08BPDBu029268; Thu, 8 Jan 2015 11:25:13 GMT Message-ID: <54AE6919.2030302@cisco.com> Date: Thu, 08 Jan 2015 12:25:13 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "lmap@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: 'Alissa Cooper' Subject: [lmap] LMAP WG transition to Alissa as Responsible AD X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 11:25:17 -0000 Dear all, In order to execute the IESG YANG Model Work Redistribution plan (see https://www.ietf.org/mail-archive/web/ietf/current/msg90926.html) and in accordance with the IETF areas re-organisation steps (see https://www.ietf.org/mail-archive/web/ietf/current/msg91015.html), Alissa Cooper will become the LMAP responsible AD. You will be in good hands with Alissa since she was involved day one in LMAP, with the BoF, if you recall. Note that LMAP WG will remain in the OPS area. While Alissa will be the responsible starting now, this change will only appear on the charter page in a little bit (we're targeting mid February). Indeed, the tooling aspects will have to checked: we might face a few issues when a non-OPS AD is responsible for an OPS WG. Since I started the LMAP framework AD review (and there are some issues currently being discussed), I will continue with the ownership of this document. Final note: I don't disappear from the IESG and I'm always available if you require my help. Please let us know if you have any questions before I announce this to the mailing list. Regards, Benoit From nobody Thu Jan 8 03:52:31 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9CE1A89F1 for ; Thu, 8 Jan 2015 03:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqKanMpZRy0T for ; Thu, 8 Jan 2015 03:52:27 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4A01A3B9F for ; Thu, 8 Jan 2015 03:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1499; q=dns/txt; s=iport; t=1420717947; x=1421927547; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=knyAWFEDS+Ej4lv/SAWjxO6/FpVRKTCgs7IBuMgp4Co=; b=UEt0Woh2rJfLzT3KIdnICUwHXXldp7skckIGlshMPSifY80zNQt89bTW XyreixOr92v7AjMFPYPqQng7u7fxLsydlrLVFVSa/zOHu8mkigb7CQQrG 4U+JtzcVS2XIyF5gFY+LAbtVDDm2iL+3eZqoaDQMxLzc7xeKgcUjqXj/9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAEAD1urlStJssW/2dsb2JhbABcg1hYxXgKhWkKAoFUAQEBAQF9hA0BAQQBAQE1NgsQCxgJJQ8CFjAGDQEFAgEBiCgNxi4BAQEBAQEBAQEBAQEBAQEBAQEBAQETBI8XEAIBTweEKQEEk3mDQYEOgnGCF4tYIoNvPTEBgkIBAQE X-IronPort-AV: E=Sophos;i="5.07,722,1413244800"; d="scan'208";a="299532179" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 08 Jan 2015 11:52:25 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t08BqOZk030644; Thu, 8 Jan 2015 11:52:25 GMT Message-ID: <54AE6F78.40007@cisco.com> Date: Thu, 08 Jan 2015 12:52:24 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "lmap@ietf.org" References: <54AE6919.2030302@cisco.com> In-Reply-To: <54AE6919.2030302@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: 'Alissa Cooper' Subject: Re: [lmap] LMAP WG transition to Alissa as Responsible AD X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 11:52:29 -0000 On 08/01/2015 12:25, Benoit Claise wrote: > Dear all, > > In order to execute the IESG YANG Model Work Redistribution plan (see > https://www.ietf.org/mail-archive/web/ietf/current/msg90926.html) and > in accordance with the IETF areas re-organisation steps (see > https://www.ietf.org/mail-archive/web/ietf/current/msg91015.html), > Alissa Cooper will become the LMAP responsible AD. You will be in good > hands with Alissa since she was involved day one in LMAP, with the > BoF, if you recall. > > Note that LMAP WG will remain in the OPS area. While Alissa will be > the responsible starting now, this change will only appear on the > charter page in a little bit (we're targeting mid February). Indeed, > the tooling aspects will have to checked: we might face a few issues > when a non-OPS AD is responsible for an OPS WG. > > Since I started the LMAP framework AD review (and there are some > issues currently being discussed), I will continue with the ownership > of this document. > > Final note: I don't disappear from the IESG and I'm always available > if you require my help. > Please let us know if you have any questions before I announce this to > the mailing list. ACTION ITEM BENOIT: DONE :-) Basic cut/paste error from my previous email to the LMAP chairs Regards, Benoit > > Regards, Benoit > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > From nobody Thu Jan 8 06:39:35 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F94D1A8859 for ; Thu, 8 Jan 2015 06:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci4PuxEWB3RK for ; Thu, 8 Jan 2015 06:39:32 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750611A017D for ; Thu, 8 Jan 2015 06:39:26 -0800 (PST) Received: by mail-oi0-f42.google.com with SMTP id v63so7629027oia.1 for ; Thu, 08 Jan 2015 06:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7rD4gsDdsAUm1MAzs9pDM4quPFH4y0LCbXMJ4/lRRX0=; b=MeukAcmheonQOYXP3eO2igOiDmXfrSaok5qKWzjMic60QuwvSoIKynBUzhJDvn7zYi dEMAzyB6v8J6eUZiIQ7m4ziYODMJrNl1xGza+fvNQjBC1UiXFlTUwQUIvM0td971l0vj WZNDlSg7Vz5CumDoJ1c7FiPTw2GYWs0HVf8xmObaYnb58EquMnl52KNwoFhlDzJRgvq/ ekNV7PW9yJ0/qw7KOJCkCFCyODH1uiv4A1wXEyYkK11o1AzvqeiLIJ0pSpgCg+M/3WOM VZN9srDt/WrzykzTXoA6cBJfvCSr53/lyNo3ih7MjoQ/TCpng0d2BAM7W2R8AxUc9P2r 8NHg== MIME-Version: 1.0 X-Received: by 10.202.184.135 with SMTP id i129mr5538324oif.68.1420727965781; Thu, 08 Jan 2015 06:39:25 -0800 (PST) Received: by 10.202.7.132 with HTTP; Thu, 8 Jan 2015 06:39:25 -0800 (PST) Received: by 10.202.7.132 with HTTP; Thu, 8 Jan 2015 06:39:25 -0800 (PST) In-Reply-To: <54AE6919.2030302@cisco.com> References: <54AE6919.2030302@cisco.com> Date: Thu, 8 Jan 2015 09:39:25 -0500 Message-ID: From: James Miller To: Benoit Claise Content-Type: multipart/alternative; boundary=001a113ce1b8b91723050c2501cc Archived-At: Cc: Alissa Cooper , lmap@ietf.org Subject: Re: [lmap] LMAP WG transition to Alissa as Responsible AD X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:39:34 -0000 --001a113ce1b8b91723050c2501cc Content-Type: text/plain; charset=UTF-8 Thanks for your great work Benoit, Nd congrats to Alissa on taking on the role as AD. On Jan 8, 2015 6:25 AM, "Benoit Claise" wrote: > Dear all, > > In order to execute the IESG YANG Model Work Redistribution plan (see > https://www.ietf.org/mail-archive/web/ietf/current/msg90926.html) and in > accordance with the IETF areas re-organisation steps (see > https://www.ietf.org/mail-archive/web/ietf/current/msg91015.html), Alissa > Cooper will become the LMAP responsible AD. You will be in good hands with > Alissa since she was involved day one in LMAP, with the BoF, if you recall. > > Note that LMAP WG will remain in the OPS area. While Alissa will be the > responsible starting now, this change will only appear on the charter page > in a little bit (we're targeting mid February). Indeed, the tooling aspects > will have to checked: we might face a few issues when a non-OPS AD is > responsible for an OPS WG. > > Since I started the LMAP framework AD review (and there are some issues > currently being discussed), I will continue with the ownership of this > document. > > Final note: I don't disappear from the IESG and I'm always available if > you require my help. > Please let us know if you have any questions before I announce this to the > mailing list. > > Regards, Benoit > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > --001a113ce1b8b91723050c2501cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks for your great work Benoit, Nd congrats to Alissa on = taking on the role as AD.

On Jan 8, 2015 6:25 AM, "Benoit Claise"= ; <bclaise@cisco.com> wrote:=
Dear all,

In order to execute the IESG YANG Model Work Redistribution plan (see https://www.ietf.org/mail-archive/web/ietf/current/msg90926.html) and in accordance with the IETF areas re-organisati= on steps (see https://www.ietf.org/mail-archive/= web/ietf/current/msg91015.html), Alissa Cooper will become the L= MAP responsible AD. You will be in good hands with Alissa since she was inv= olved day one in LMAP, with the BoF, if you recall.

Note that LMAP WG will remain in the OPS area. While Alissa will be the res= ponsible starting now, this change will only appear on the charter page in = a little bit (we're targeting mid February). Indeed, the tooling aspect= s will have to checked: we might face a few issues when a non-OPS AD is res= ponsible for an OPS WG.

Since I started the LMAP framework AD review (and there are some issues cur= rently being discussed), I will continue with the ownership of this documen= t.

Final note: I don't disappear from the IESG and I'm always availabl= e if you require my help.
Please let us know if you have any questions before I announce this to the = mailing list.

Regards, Benoit

_______________________________________________
lmap mailing list
lmap@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lmap
--001a113ce1b8b91723050c2501cc-- From nobody Thu Jan 8 06:54:33 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20221A6FFC for ; Thu, 8 Jan 2015 06:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlEjuOyDHzHj for ; Thu, 8 Jan 2015 06:54:30 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C091A1F01 for ; Thu, 8 Jan 2015 06:54:28 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcGAHWZrlTGmAcV/2dsb2JhbABcgkMhIlJcszYBAQEBAQEGBZgpAoEPQwEBAQEBAXyEDgEBAxIbXgEMCRVWJgEEGxqICgGjS4R7ni4MAR+GBYlDg06BEwWOM48zi0Iig26CNH4BAQE X-IronPort-AV: E=Sophos;i="5.07,723,1413259200"; d="scan'208,217";a="101930185" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 08 Jan 2015 09:54:26 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 08 Jan 2015 09:54:26 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Thu, 8 Jan 2015 15:54:24 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP WG meeting at IETF-92 Thread-Index: AdArUvyHtlECeOw8Q8yV7j3gZqP93g== Date: Thu, 8 Jan 2015 14:54:24 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9613DD@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_9904FB1B0159DA42B0B887B7FA8119CA5C9613DDAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP WG meeting at IETF-92 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:54:32 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9613DDAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It's time to request meeting slots for IETF-92. At IETF-91 we met for 2.5 h= ours. Should we ask for a similar meeting time at IETF-92? The conflict list at IETF-91 included: ippm ecrit bmwg dispatch lmap mptcp netconf netmod dime opsarea opsawg rade= xt sacm xrblock rtcweb tictoc irtfopen ianaplan Do we need to include anything else? Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9613DDAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

It’s time to request meeting slots for IETF-92= . At IETF-91 we met for 2.5 hours. Should we ask for a similar meeting time= at IETF-92?

 

The conflict list at IETF-91 included:

 

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

 

Do we need to include anything else?

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C9613DDAZFFEXMB04globa_-- From nobody Thu Jan 8 09:26:16 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82ED91A8AEB; Thu, 8 Jan 2015 09:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrwxfR-yW0zU; Thu, 8 Jan 2015 09:26:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A22481A882E; Thu, 8 Jan 2015 09:26:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108172611.28321.94308.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 09:26:11 -0800 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-03.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 17:26:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance Working Group of the IETF. Title : Information Model for Large-Scale Measurement Platforms (LMAP) Authors : Trevor Burbridge Philip Eardley Marcelo Bagnulo Juergen Schoenwaelder Filename : draft-ietf-lmap-information-model-03.txt Pages : 38 Date : 2015-01-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 MA or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the MA that can be implemented via one or more Control and Report protocols. 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: http://tools.ietf.org/html/draft-ietf-lmap-information-model-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-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 Thu Jan 8 09:26:27 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5A91A8AEF for ; Thu, 8 Jan 2015 09:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM8WW1p0TKQs; Thu, 8 Jan 2015 09:26:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC151A8AE7; Thu, 8 Jan 2015 09:26:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: draft-ietf-lmap-information-model.all@tools.ietf.org, lmap-chairs@tools.ietf.org, lmap@ietf.org, bclaise@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108172611.28321.3082.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 09:26:11 -0800 Archived-At: Subject: [lmap] New Version Notification - draft-ietf-lmap-information-model-03.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 17:26:17 -0000 A new version (-03) has been submitted for draft-ietf-lmap-information-model: http://www.ietf.org/internet-drafts/draft-ietf-lmap-information-model-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-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. IETF Secretariat. From nobody Thu Jan 8 12:29:13 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334E81A0545 for ; Thu, 8 Jan 2015 12:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B32N9dmc1MRr for ; Thu, 8 Jan 2015 12:29:09 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A4841A0102 for ; Thu, 8 Jan 2015 12:29:08 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 59BB05A90D5 for ; Thu, 8 Jan 2015 20:29:04 +0000 (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 t08KT5Nl016327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 8 Jan 2015 15:29:05 -0500 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.185]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 15:29:05 -0500 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: Use of role in the LMAP information model Thread-Index: AdArgb2bNcAR6mWcQ3OUDhI9biFkog== Date: Thu, 8 Jan 2015 20:29:04 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7735006220@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_9966516C6EB5FC4381E05BF80AA55F7735006220US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Use of role in the LMAP information model X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 20:29:11 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7735006220US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, I was reviewing draft-ietf-lmap-information-model-03 in order to update the= BBF data model. I noticed that the concept of a role in the task and task reporting was not= in the information model. Did we not include the role concept? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F7735006220US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

I was reviewing draft-ietf-lmap-information-model-0= 3 in order to update the BBF data model.

 

I noticed that the concept of a role in the task an= d task reporting was not in the information model.

Did we not include the role concept?

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F7735006220US70UWXCHMBA05z_-- From nobody Fri Jan 9 01:15:35 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC201A86EB for ; Fri, 9 Jan 2015 01:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArRL0NQ28m9d for ; Fri, 9 Jan 2015 01:15:10 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA721A701C for ; Fri, 9 Jan 2015 01:15:09 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 9 Jan 2015 09:15:06 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.224]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 9 Jan 2015 09:15:00 +0000 From: To: , Date: Fri, 9 Jan 2015 09:14:57 +0000 Thread-Topic: Use of role in the LMAP information model Thread-Index: AdArgb2bNcAR6mWcQ3OUDhI9biFkogAao6Kg Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7735006220@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7735006220@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72F10F7AD0DEMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] Use of role in the LMAP information model X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 09:15:20 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72F10F7AD0DEMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is a decision to be made in the registry area as to whether the URL i= s sufficient to determine both the method and role, or whether a registry U= RL is needed in conjunction with the role information. I have dropped role = from the IM in expectation that it might be the former and the view that "l= ess is more" until we get told that we actually need role separately from t= he registry URL. It will be easy to re-instantiate if needed following more= work on the registry. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Research & Innovation Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: 08 January 2015 20:29 To: lmap@ietf.org Subject: [lmap] Use of role in the LMAP information model Trevor, I was reviewing draft-ietf-lmap-information-model-03 in order to update the= BBF data model. I noticed that the concept of a role in the task and task reporting was not= in the information model. Did we not include the role concept? BR, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72F10F7AD0DEMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There is a decision to be made in the registry area as to whe= ther the URL is sufficient to determine both the method and role, or whethe= r a registry URL is needed in conjunction with the role information. I have= dropped role from the IM in expectation that it might be the former and th= e view that “less is more” until we get told that we actually n= eed role separately from the registry URL. It will be easy to re-instantiat= e if needed following more work on the registry.

 

<= p class=3DMsoNormal>Trevor.=

 

Trevor Burbridge
Network Infra= structure & Innovation | BT Research & Innovation
Tel: 01473 645= 115
Fax: 01473 640929

This email contains BT information, which may be privileged or con= fidential. It's meant only for the individual(s) or entity named above. If = you're not the intended recipient, note that disclosing, copying, distribut= ing or using this information is prohibited. If you've received this email = in error, please let me know immediately on the email address above. Thank = you.
We monitor our email system, and may record your emails.
British Telecommunications plcRegistered office: 81 Newgate Street London EC1A 7AJ
Registered in Engl= and no: 1800000

=

 <= /span>

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timot= hy (Timothy)
Sent: 08 January 2015 20:29
To: lmap@ietf.= org
Subject: [lmap] Use of role in the LMAP information model

 

Trevor,

 

I was reviewing draft-ietf-lmap-information-model-0= 3 in order to update the BBF data model.

I noticed that the concept of = a role in the task and task reporting was not in the information model.

Did we not include the role concept?<= /o:p>

 

B= R,

Tim

= --_000_ED51D9282D1D3942B9438CA8F3372EB72F10F7AD0DEMV64UKRDdoma_-- From nobody Fri Jan 9 05:19:24 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3231A87A1 for ; Fri, 9 Jan 2015 05:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXeuO6F5cw6u for ; Fri, 9 Jan 2015 05:19:14 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26D41A87A0 for ; Fri, 9 Jan 2015 05:19:13 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 3C25A7AE5D161; Fri, 9 Jan 2015 13:19:08 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t09DJ9un031228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Jan 2015 08:19:09 -0500 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.185]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 08:19:09 -0500 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: Use of role in the LMAP information model Thread-Index: AdArgb2bNcAR6mWcQ3OUDhI9biFkogAao6KgAAib8OA= Date: Fri, 9 Jan 2015 13:19:09 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7735006794@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7735006220@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F7735006794US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] Use of role in the LMAP information model X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 13:19:18 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7735006794US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, Thanks for the clarification. BR, Tim From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Friday, January 09, 2015 3:15 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: Use of role in the LMAP information model There is a decision to be made in the registry area as to whether the URL i= s sufficient to determine both the method and role, or whether a registry U= RL is needed in conjunction with the role information. I have dropped role = from the IM in expectation that it might be the former and the view that "l= ess is more" until we get told that we actually need role separately from t= he registry URL. It will be easy to re-instantiate if needed following more= work on the registry. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Research & Innovation Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: 08 January 2015 20:29 To: lmap@ietf.org Subject: [lmap] Use of role in the LMAP information model Trevor, I was reviewing draft-ietf-lmap-information-model-03 in order to update the= BBF data model. I noticed that the concept of a role in the task and task reporting was not= in the information model. Did we not include the role concept? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F7735006794US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

Thanks for the clarification.

 

BR,

Tim

 

From: trevor.b= urbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Friday, January 09, 2015 3:15 AM
To: Carey, Timothy (Timothy); lmap@ietf.org
Subject: RE: Use of role in the LMAP information model

 

There i= s a decision to be made in the registry area as to whether the URL is suffi= cient to determine both the method and role, or whether a registry URL is n= eeded in conjunction with the role information. I have dropped role from the IM in expectation that it might be the former= and the view that “less is more” until we get told that we act= ually need role separately from the registry URL. It will be easy to re-ins= tantiate if needed following more work on the registry.

&n= bsp;

Trevor.=

&n= bsp;

Trevor Bu= rbridge
Network Infrastructure & Innovation | BT Research & Innovation
Tel: 01473 645115
Fax: 01473 640929

This email contains BT inform= ation, which may be privileged or confidential. It's meant only for the ind= ividual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this infor= mation is prohibited. If you've received this email in error, please let me= know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications pl= c
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

&n= bsp;

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 08 January 2015 20:29
To: lmap@ietf.org
Subject: [lmap] Use of role in the LMAP information model=

 

Trevor,

 

I was reviewing draft-ietf-lmap-information-model-0= 3 in order to update the BBF data model.

 

I noticed that the concept of a role in the task an= d task reporting was not in the information model.

Did we not include the role concept?

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F7735006794US70UWXCHMBA05z_-- From nobody Fri Jan 9 06:20:54 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8DB1A89B3 for ; Fri, 9 Jan 2015 06:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNIq5MmmwCu0 for ; Fri, 9 Jan 2015 06:20:36 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBB451A8987 for ; Fri, 9 Jan 2015 06:20:36 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 06B1EED9D9893 for ; Fri, 9 Jan 2015 14:20:31 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t09EKX2W020923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 9 Jan 2015 09:20:33 -0500 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.185]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 09:20:33 -0500 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: Use of options in Reports in the Information Model Thread-Index: AdAsF20Yiw4+vqqeS6OThoG0JI6s7Q== Date: Fri, 9 Jan 2015 14:20:34 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77350068F9@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.16] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77350068F9US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Use of options in Reports in the Information Model X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 14:20:48 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77350068F9US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, I was reviewing draft-ietf-lmap-information-model-03 in order to update the= BBF data model. In section 3.6 Reporting Information: I noticed we removed the concept of Cross traffic from the Reporting task's= result row thinking that the Cross traffic option could be defined a name/= value pair entry scheduled task options in the Report task object. The text in the section is somewhat unclear as to what would be in the opti= ons field and what is in the result row in this regard. So if I see 3000 bytes of cross traffic for a result instance. Would the re= sult of the Cross Traffic be in the result row and the Options just specify= the need to sense the Cross traffic? I would think this would be the case - we would have a Header for Cross Tra= ffic that would be available for each result row as defined by the options = in the scheduled task and recorded in the Reporting task option to look for= Cross Traffic? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77350068F9US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

I was reviewing draft-ietf-lmap-information-model-0= 3 in order to update the BBF data model.

 

In section 3.6 Reporting Information:

 

I noticed we removed the concept of Cross traffic f= rom the Reporting task’s result row thinking that the Cross traffic o= ption could be defined a name/value pair entry scheduled task options in the Report task object.

 

The text in the section is somewhat unclear as to w= hat would be in the options field and what is in the result row in this reg= ard.

 

So if I see 3000 bytes of cross traffic for a resul= t instance. Would the result of the Cross Traffic be in the result row and = the Options just specify the need to sense the Cross traffic?

 

I would think this would be the case – we wou= ld have a Header for Cross Traffic that would be available for each result = row as defined by the options in the scheduled task and recorded in the Reporting task option to look for Cross Traffic?<= /p>

 

BR,

Tim

 

 

 

--_000_9966516C6EB5FC4381E05BF80AA55F77350068F9US70UWXCHMBA05z_-- From nobody Fri Jan 9 07:47:21 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1171A0233 for ; Fri, 9 Jan 2015 07:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUxRQ5V9o_JH for ; Fri, 9 Jan 2015 07:47:18 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id F17061A0067 for ; Fri, 9 Jan 2015 07:47:17 -0800 (PST) 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 553CE1213E7; Fri, 9 Jan 2015 11:00:44 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-green.research.att.com (Postfix) with ESMTP id 4863FE03AF; Fri, 9 Jan 2015 10:43:46 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Fri, 9 Jan 2015 10:47:17 -0500 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Timothy)" , "trevor.burbridge@bt.com" , "lmap@ietf.org" Date: Fri, 9 Jan 2015 10:47:16 -0500 Thread-Topic: Use of role in the LMAP information model Thread-Index: AdArgb2bNcAR6mWcQ3OUDhI9biFkogAao6KgAAib8OAABGrULQ== Message-ID: <4AF73AA205019A4C8A1DDD32C034631D85493941@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F7735006220@US70UWXCHMBA05.zam.alcatel-lucent.com> , <9966516C6EB5FC4381E05BF80AA55F7735006794@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7735006794@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] Use of role in the LMAP information model X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 15:47:20 -0000 Whoa Trevor, let's put it this way: Role is an input parameter in the current registry draft, where we list the= possible roles. This doesn't match the information model, as Tim points out, but that's the= current decision from the registry area. We have considered making similar configuration options "fixed", like the t= est protocol (e.g., TWAMP), but as we discussed at the workshop this creates lots of redundant entries = for the same metric and we should avoid this artificial growth of entries. It causes a maintena= nce problem, among many. If we make Role a fixed parameter, we get two almost duplicate entries for = each Role (when there are two Roles, of course). So, we understand the implications, = and they=20 are not attractive.=20 I'd like to understand the full implications of including the role concept = in the Information Model, as Tim suggested. Then we can make an informed decision, and not be forced = one way or the other because of lack of support. thanks, Al ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy) [t= imothy.carey@alcatel-lucent.com] Sent: Friday, January 09, 2015 8:19 AM To: trevor.burbridge@bt.com; lmap@ietf.org Subject: Re: [lmap] Use of role in the LMAP information model Trevor, Thanks for the clarification. BR, Tim From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Friday, January 09, 2015 3:15 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: Use of role in the LMAP information model There is a decision to be made in the registry area as to whether the URL i= s sufficient to determine both the method and role, or whether a registry U= RL is needed in conjunction with the role information. I have dropped role = from the IM in expectation that it might be the former and the view that = =93less is more=94 until we get told that we actually need role separately = from the registry URL. It will be easy to re-instantiate if needed followin= g more work on the registry. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Research & Innovation Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: 08 January 2015 20:29 To: lmap@ietf.org Subject: [lmap] Use of role in the LMAP information model Trevor, I was reviewing draft-ietf-lmap-information-model-03 in order to update the= BBF data model. I noticed that the concept of a role in the task and task reporting was not= in the information model. Did we not include the role concept? BR, Tim From nobody Fri Jan 9 07:54:32 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D8A1A6EE6 for ; Fri, 9 Jan 2015 07:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHTplikQs5F4 for ; Fri, 9 Jan 2015 07:54:28 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B66DA1A01F2 for ; Fri, 9 Jan 2015 07:54:27 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 9 Jan 2015 15:54:31 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.224]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 9 Jan 2015 15:54:11 +0000 From: To: , Date: Fri, 9 Jan 2015 15:54:09 +0000 Thread-Topic: Use of options in Reports in the Information Model Thread-Index: AdAsF20Yiw4+vqqeS6OThoG0JI6s7QACPCdw Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F77350068F9@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77350068F9@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72F10F7AFF0EMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] Use of options in Reports in the Information Model X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 15:54:31 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72F10F7AFF0EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >Trevor, > >I was reviewing draft-ietf-lmap-information-model-03 in order to update th= e BBF data model. > >In section 3.6 Reporting Information: > >I noticed we removed the concept of Cross traffic from the Reporting task'= s result row thinking that the Cross traffic option >could be defined a name/value pair entry scheduled task options in the Rep= ort task object. > >The text in the section is somewhat unclear as to what would be in the opt= ions field and what is in the result row in this regard. > >So if I see 3000 bytes of cross traffic for a result instance. Would the r= esult of the Cross Traffic be in the result row and the >Options just specify the need to sense the Cross traffic? Yes exactly so. >I would think this would be the case - we would have a Header for Cross Tr= affic that would be available for each result row as >defined by the options in the scheduled task and recorded in the Reporting= task option to look for Cross Traffic? Yes again! --_000_ED51D9282D1D3942B9438CA8F3372EB72F10F7AFF0EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>Trevor,=

> 

&g= t;I was reviewing draft-ietf-lmap-information-model-03 in order to update t= he BBF data model.

> 

>In section 3.6 Reporting Information:

> 

>could be defined a name/value pair entry sched= uled task options in the Report task object.

> 

>The text in the s= ection is somewhat unclear as to what would be in the options field and wha= t is in the result row in this regard.

= > 

>So if I see 3000 bytes o= f cross traffic for a result instance. Would the result of the Cross Traffi= c be in the result row and the

<= span lang=3DEN-US style=3D'font-family:"Trebuchet MS","sans-serif"'>>Opt= ions just specify the need to sense the Cross traffic?

 

Yes exactly so.<= o:p>

 

>I would think this would be the case – we would have a Header= for Cross Traffic that would be available for each result row as

>defined by the options in the scheduled tas= k and recorded in the Reporting task option to look for Cross Traffic?=

 

= Yes again!

 

=

 

 

= --_000_ED51D9282D1D3942B9438CA8F3372EB72F10F7AFF0EMV64UKRDdoma_-- From nobody Fri Jan 9 08:49:19 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A961A8873 for ; Fri, 9 Jan 2015 08:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYsISGg5OFEv for ; Fri, 9 Jan 2015 08:49:15 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F3E1A87CE for ; Fri, 9 Jan 2015 08:49:15 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id F1D0786E5439 for ; Fri, 9 Jan 2015 16:49:10 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t09GnCap023692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 9 Jan 2015 11:49:12 -0500 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.185]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 11:49:12 -0500 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: Reporting suppressed tasked in results Thread-Index: AQHQLCwxgPveTA+YcE6gF9aNBFXsYA== Date: Fri, 9 Jan 2015 16:49:13 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7735006DF5@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.16] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F7735006DF5US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Reporting suppressed tasked in results X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 16:49:17 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7735006DF5US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, In the draft-ietf-lmap-information-model-03 I didn't see the how we record = in the report that a task was suppressed therefore making the results suspe= ct. Is this also part of the options that a task would define? I would suspect all these well known " task option names" (e.g., cross traf= fic, suppressed task) would have to be defined in the task registry for the= task? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F7735006DF5US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

In the draft-ietf-lmap-information-model-03 I didn&= #8217;t see the how we record in the report that a task was suppressed ther= efore making the results suspect.

 

Is this also part of the options that a task would = define?

 

I would suspect all these well known “ task o= ption names” (e.g., cross traffic, suppressed task) would have to be = defined in the task registry for the task?

 

BR,

Tim

 

--_000_9966516C6EB5FC4381E05BF80AA55F7735006DF5US70UWXCHMBA05z_-- From nobody Fri Jan 9 12:30:22 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4731A8AE7 for ; Fri, 9 Jan 2015 12:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhjqzfCjjaVn for ; Fri, 9 Jan 2015 12:30:18 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171391A1A34 for ; Fri, 9 Jan 2015 12:30:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5E2C6669; Fri, 9 Jan 2015 21:30:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id OJcbgM-N2CWl; Fri, 9 Jan 2015 21:30:06 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 9 Jan 2015 21:30:15 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4882A2002C; Fri, 9 Jan 2015 21:30:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hQWcl6EMpyV1; Fri, 9 Jan 2015 21:30:14 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F68B20017; Fri, 9 Jan 2015 21:30:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1589030A627E; Fri, 9 Jan 2015 21:30:12 +0100 (CET) Date: Fri, 9 Jan 2015 21:30:12 +0100 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150109203012.GA1377@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F7735006DF5@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7735006DF5@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Reporting suppressed tasked in results X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 20:30:20 -0000 On Fri, Jan 09, 2015 at 04:49:13PM +0000, Carey, Timothy (Timothy) wrote: > Trevor, > > In the draft-ietf-lmap-information-model-03 I didn't see the how we record in the report that a task was suppressed therefore making the results suspect. > > Is this also part of the options that a task would define? > > I would suspect all these well known " task option names" (e.g., cross traffic, suppressed task) would have to be defined in the task registry for the task? > I would assume that a suppressed task does not produce results. /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 Jan 9 13:38:58 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D15B1A0395 for ; Fri, 9 Jan 2015 13:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqmo9WJWxstt for ; Fri, 9 Jan 2015 13:38:53 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CFED1A010F for ; Fri, 9 Jan 2015 13:38:52 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id D777BE3BC53A7; Fri, 9 Jan 2015 21:38:45 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t09LclpD025650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Jan 2015 16:38:47 -0500 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.185]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 16:38:47 -0500 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Reporting suppressed tasked in results Thread-Index: AQHQLCwxgPveTA+YcE6gF9aNBFXsYJy4kZwA//++GGA= Date: Fri, 9 Jan 2015 21:38:46 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77350071D6@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7735006DF5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150109203012.GA1377@elstar.local> In-Reply-To: <20150109203012.GA1377@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] Reporting suppressed tasked in results X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 21:38:56 -0000 Ok - Sorry - I see suppression is only for new tasks (page 11). So existing= tasks would complete and suppressed tasks wouldn't report. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, January 09, 2015 2:30 PM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] Reporting suppressed tasked in results On Fri, Jan 09, 2015 at 04:49:13PM +0000, Carey, Timothy (Timothy) wrote: > Trevor, >=20 > In the draft-ietf-lmap-information-model-03 I didn't see the how we recor= d in the report that a task was suppressed therefore making the results sus= pect. >=20 > Is this also part of the options that a task would define? >=20 > I would suspect all these well known " task option names" (e.g., cross tr= affic, suppressed task) would have to be defined in the task registry for t= he task? > I would assume that a suppressed task does not produce results. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Jan 9 13:50:08 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AD41A0A85 for ; Fri, 9 Jan 2015 13:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCeyxu3SueTP for ; Fri, 9 Jan 2015 13:49:59 -0800 (PST) Received: from p01c12o149.mxlogic.net (p01c12o149.mxlogic.net [208.65.145.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9B31A01E1 for ; Fri, 9 Jan 2015 13:49:58 -0800 (PST) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c12o149.mxlogic.net(mxl_mta-8.2.0-3) with ESMTP id 70d40b45.2b951f204940.45260.00-574.129488.p01c12o149.mxlogic.net (envelope-from ); Fri, 09 Jan 2015 14:49:59 -0700 (MST) X-MXL-Hash: 54b04d0709f5df2e-31f5c9cd30a7ed2cf21a6368fd6b2b8900316ffc Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c12o149.mxlogic.net(mxl_mta-8.2.0-3) over TLS secured channel with ESMTP id 7fc40b45.0.45134.00-378.129140.p01c12o149.mxlogic.net (envelope-from ); Fri, 09 Jan 2015 14:49:47 -0700 (MST) X-MXL-Hash: 54b04cfb018d3f96-1b5e87a5fc173ecc5e602b13b8a168dce6c500cf Received: from ex-mb3.corp.adtran.com ([fe80::60aa:f95:ad49:a0f1]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0210.002; Fri, 9 Jan 2015 15:49:43 -0600 From: KEN KO To: "Carey, Timothy (Timothy)" , "Juergen Schoenwaelder" Thread-Topic: [lmap] Reporting suppressed tasked in results Thread-Index: AQHQLCwxgPveTA+YcE6gF9aNBFXsYJy4ol8AgAATKAD//534IA== Date: Fri, 9 Jan 2015 21:49:43 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7735006DF5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150109203012.GA1377@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77350071D6@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77350071D6@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=U4mGDIbu c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=P8-0W2aUS8QA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=YlVTAMxIAAAA:8 a=YNv0rlydsVwA:10 a=48vgC7mUAAAA:] X-AnalysisOut: [8 a=j3Z76cjpAAAA:8 a=h-h-a3PNaPAm-xjJhnUA:9 a=Fb5P_LA_uGV7] X-AnalysisOut: [k9jD:21 a=aai7f7Bwn7DYgzBJ:21 a=CjuIK1q_8ugA:10 a=FvgKqOQ4] X-AnalysisOut: [4qUA:10 a=JrSEOxZJtCQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2015010924); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Reporting suppressed tasked in results X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 21:50:01 -0000 Not always - a suppression message can request (not require) that existing = tasks terminate immediately. However, even those tasks that are started and= then terminated should probably not report results in most cases. Ken -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: Friday, January 09, 2015 4:39 PM To: Juergen Schoenwaelder Cc: lmap@ietf.org Subject: Re: [lmap] Reporting suppressed tasked in results Ok - Sorry - I see suppression is only for new tasks (page 11). So existing= tasks would complete and suppressed tasks wouldn't report. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, January 09, 2015 2:30 PM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] Reporting suppressed tasked in results On Fri, Jan 09, 2015 at 04:49:13PM +0000, Carey, Timothy (Timothy) wrote: > Trevor, >=20 > In the draft-ietf-lmap-information-model-03 I didn't see the how we recor= d in the report that a task was suppressed therefore making the results sus= pect. >=20 > Is this also part of the options that a task would define? >=20 > I would suspect all these well known " task option names" (e.g., cross tr= affic, suppressed task) would have to be defined in the task registry for t= he task? > I would assume that a suppressed task does not produce results. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Jan 9 13:55:38 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7CF1A1A5F for ; Fri, 9 Jan 2015 13:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeYNwV8Q7twk for ; Fri, 9 Jan 2015 13:55:34 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6144F1A0039 for ; Fri, 9 Jan 2015 13:55:34 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 609DA816BA6E0; Fri, 9 Jan 2015 21:55:28 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t09LtUAQ024361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Jan 2015 16:55:30 -0500 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.185]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 16:55:30 -0500 From: "Carey, Timothy (Timothy)" To: KEN KO , Juergen Schoenwaelder Thread-Topic: [lmap] Reporting suppressed tasked in results Thread-Index: AQHQLCwxgPveTA+YcE6gF9aNBFXsYJy4kZwA//++GGCAAFgfgP//rUfQ Date: Fri, 9 Jan 2015 21:55:28 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7735007216@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7735006DF5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150109203012.GA1377@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77350071D6@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: 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] Reporting suppressed tasked in results X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 21:55:37 -0000 Ken, You are correct: Page 12 Suppression stops new Tasks from executing. In addtion, the Suppression information also supports an additional Boolean that is used to select whether on-going tasks are also to be terminated. So I guess the question still stands - how to reflect the results of a supp= ressed on-going task. Is it as Juergen say - they simply don't report? -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com]=20 Sent: Friday, January 09, 2015 3:50 PM To: Carey, Timothy (Timothy); Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] Reporting suppressed tasked in results Not always - a suppression message can request (not require) that existing = tasks terminate immediately. However, even those tasks that are started and= then terminated should probably not report results in most cases. Ken -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: Friday, January 09, 2015 4:39 PM To: Juergen Schoenwaelder Cc: lmap@ietf.org Subject: Re: [lmap] Reporting suppressed tasked in results Ok - Sorry - I see suppression is only for new tasks (page 11). So existing= tasks would complete and suppressed tasks wouldn't report. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, January 09, 2015 2:30 PM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] Reporting suppressed tasked in results On Fri, Jan 09, 2015 at 04:49:13PM +0000, Carey, Timothy (Timothy) wrote: > Trevor, >=20 > In the draft-ietf-lmap-information-model-03 I didn't see the how we recor= d in the report that a task was suppressed therefore making the results sus= pect. >=20 > Is this also part of the options that a task would define? >=20 > I would suspect all these well known " task option names" (e.g., cross tr= affic, suppressed task) would have to be defined in the task registry for t= he task? > I would assume that a suppressed task does not produce results. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Jan 9 14:01:25 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956DB1A01E1 for ; Fri, 9 Jan 2015 14:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81poPcz7ZoGi for ; Fri, 9 Jan 2015 14:01:20 -0800 (PST) Received: from p02c11o144.mxlogic.net (p02c11o144.mxlogic.net [208.65.144.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C01F1A0039 for ; Fri, 9 Jan 2015 14:01:20 -0800 (PST) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c11o144.mxlogic.net(mxl_mta-8.2.0-3) with ESMTP id 0bf40b45.2b6671a28940.52240.00-550.142380.p02c11o144.mxlogic.net (envelope-from ); Fri, 09 Jan 2015 15:01:20 -0700 (MST) X-MXL-Hash: 54b04fb029c6deec-2c9be7557620c4292c3de307c3c36c37cf785991 Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c11o144.mxlogic.net(mxl_mta-8.2.0-3) over TLS secured channel with ESMTP id 09f40b45.0.51901.00-353.141395.p02c11o144.mxlogic.net (envelope-from ); Fri, 09 Jan 2015 15:00:56 -0700 (MST) X-MXL-Hash: 54b04f98132ad4ae-65e79c2604f74aa69f1dc68c39fcc18cf1ee1a72 Received: from ex-mb3.corp.adtran.com ([fe80::60aa:f95:ad49:a0f1]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0210.002; Fri, 9 Jan 2015 16:00:47 -0600 From: KEN KO To: "Carey, Timothy (Timothy)" , "Juergen Schoenwaelder" Thread-Topic: [lmap] Reporting suppressed tasked in results Thread-Index: AQHQLCwxgPveTA+YcE6gF9aNBFXsYJy4ol8AgAATKAD//534IIAAZrMA//+cCKA= Date: Fri, 9 Jan 2015 22:00:46 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7735006DF5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150109203012.GA1377@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77350071D6@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7735007216@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7735007216@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=dIqymYpb c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=P8-0W2aUS8QA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=YlVTAMxIAAAA:8 a=YNv0rlydsVwA:10 a=gxZvrgisAAAA:] X-AnalysisOut: [8 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=TsHpG95Yr6VQPKo2M3YA] X-AnalysisOut: [:9 a=0s3YkMoDpn9pSm3V:21 a=5dbN5x7auKrWoFSZ:21 a=CjuIK1q_8] X-AnalysisOut: [ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2015010925); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Reporting suppressed tasked in results X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 22:01:22 -0000 I think the normal case is exactly that - they don't report. I suppose there could be specific measurement methods where it makes sense = to report, even if the task is terminated by a suppression message. In that= case, I think it would have to be specified in the task options. -----Original Message----- From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]=20 Sent: Friday, January 09, 2015 4:55 PM To: KEN KO; Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] Reporting suppressed tasked in results Ken, You are correct: Page 12 Suppression stops new Tasks from executing. In addtion, the Suppression inf= ormation also supports an additional Boolean that is used to select whether= on-going tasks are also to be terminated. So I guess the question still stands - how to reflect the results of a supp= ressed on-going task. Is it as Juergen say - they simply don't report? -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com] Sent: Friday, January 09, 2015 3:50 PM To: Carey, Timothy (Timothy); Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] Reporting suppressed tasked in results Not always - a suppression message can request (not require) that existing = tasks terminate immediately. However, even those tasks that are started and= then terminated should probably not report results in most cases. Ken -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: Friday, January 09, 2015 4:39 PM To: Juergen Schoenwaelder Cc: lmap@ietf.org Subject: Re: [lmap] Reporting suppressed tasked in results Ok - Sorry - I see suppression is only for new tasks (page 11). So existing= tasks would complete and suppressed tasks wouldn't report. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Friday, January 09, 2015 2:30 PM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] Reporting suppressed tasked in results On Fri, Jan 09, 2015 at 04:49:13PM +0000, Carey, Timothy (Timothy) wrote: > Trevor, >=20 > In the draft-ietf-lmap-information-model-03 I didn't see the how we recor= d in the report that a task was suppressed therefore making the results sus= pect. >=20 > Is this also part of the options that a task would define? >=20 > I would suspect all these well known " task option names" (e.g., cross tr= affic, suppressed task) would have to be defined in the task registry for t= he task? > I would assume that a suppressed task does not produce results. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Jan 9 14:18:21 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205DC1A1AA6 for ; Fri, 9 Jan 2015 14:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2ELv8B0i_tB for ; Fri, 9 Jan 2015 14:18:12 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBFA1A1A6F for ; Fri, 9 Jan 2015 14:18:11 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id D5E72E3295C40; Fri, 9 Jan 2015 22:18:05 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t09MI7AC020561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Jan 2015 17:18:07 -0500 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.185]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 17:18:07 -0500 From: "Carey, Timothy (Timothy)" To: KEN KO , Juergen Schoenwaelder Thread-Topic: [lmap] Reporting suppressed tasked in results Thread-Index: AQHQLCwxgPveTA+YcE6gF9aNBFXsYJy4kZwA//++GGCAAFgfgP//rUfQgABVzwD//63FYA== Date: Fri, 9 Jan 2015 22:18:05 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7735007282@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7735006DF5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150109203012.GA1377@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77350071D6@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7735007216@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: 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] Reporting suppressed tasked in results X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 22:18:15 -0000 Well we probably need to specify some default behavior in the draft when th= e options don't exist. Are we keeping track of these "well-known" task options like cross traffic = and report suspended task, etc. BR, Tim -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com]=20 Sent: Friday, January 09, 2015 4:01 PM To: Carey, Timothy (Timothy); Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] Reporting suppressed tasked in results I think the normal case is exactly that - they don't report. I suppose there could be specific measurement methods where it makes sense = to report, even if the task is terminated by a suppression message. In that= case, I think it would have to be specified in the task options. -----Original Message----- From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]=20 Sent: Friday, January 09, 2015 4:55 PM To: KEN KO; Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] Reporting suppressed tasked in results Ken, You are correct: Page 12 Suppression stops new Tasks from executing. In addtion, the Suppression inf= ormation also supports an additional Boolean that is used to select whether= on-going tasks are also to be terminated. So I guess the question still stands - how to reflect the results of a supp= ressed on-going task. Is it as Juergen say - they simply don't report? -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com] Sent: Friday, January 09, 2015 3:50 PM To: Carey, Timothy (Timothy); Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] Reporting suppressed tasked in results Not always - a suppression message can request (not require) that existing = tasks terminate immediately. However, even those tasks that are started and= then terminated should probably not report results in most cases. Ken -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: Friday, January 09, 2015 4:39 PM To: Juergen Schoenwaelder Cc: lmap@ietf.org Subject: Re: [lmap] Reporting suppressed tasked in results Ok - Sorry - I see suppression is only for new tasks (page 11). So existing= tasks would complete and suppressed tasks wouldn't report. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Friday, January 09, 2015 2:30 PM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] Reporting suppressed tasked in results On Fri, Jan 09, 2015 at 04:49:13PM +0000, Carey, Timothy (Timothy) wrote: > Trevor, >=20 > In the draft-ietf-lmap-information-model-03 I didn't see the how we recor= d in the report that a task was suppressed therefore making the results sus= pect. >=20 > Is this also part of the options that a task would define? >=20 > I would suspect all these well known " task option names" (e.g., cross tr= affic, suppressed task) would have to be defined in the task registry for t= he task? > I would assume that a suppressed task does not produce results. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Jan 13 12:29:15 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85B31ACDBE for ; Tue, 13 Jan 2015 12:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL7V90EjO5VC for ; Tue, 13 Jan 2015 12:29:12 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127D91ACD87 for ; Tue, 13 Jan 2015 12:29:11 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id AA8DD80F794C for ; Tue, 13 Jan 2015 20:29:05 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t0DKT7Ri003718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 13 Jan 2015 15:29:08 -0500 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.185]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 15:28:38 -0500 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: LMAP Information Model rev3 - Communication channels Thread-Index: AdAvb4InCMBCsnrlSFeZwGq1LM7I6Q== Date: Tue, 13 Jan 2015 20:28:37 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F773500998D@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.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F773500998DUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP Information Model rev3 - Communication channels X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 20:29:14 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F773500998DUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, I was trying to see how the instruction would configure the communication c= hange that would convey the results of a scheduled task to a collector. In rev02 of the information model the was a Channel object in the Schedule = Task. In fact page 6 still references the object BTW "The references are achieved by each object (Channel, Task Configuration, Timing)" but the diagram and object definitions remove the Channel object. My assumption is that the channel would be referenced in the Reporting task= as described in page 7. 2. Data Transfer Tasks A. Reporting Tasks report the results of Measurement Tasks to Collectors And page 11. The results can be communicated to other Tasks or a Task may implement a Reporting Protocol and communicate results over Report Channels. When I look at the data model it seems we moved Channel references into tas= ks or scheduled tasks options field. Oddly though the Report example doesn't show a channel name in the task opt= ions That I think would have been {"name": "channel", "value": "Collector A"]} Based on the Task report. Did I understand this correctly? Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F773500998DUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,<= /span>

 

I was trying to see= how the instruction would configure the communication change that would co= nvey the results of a scheduled task to a collector.

 

In rev02 of the inf= ormation model the was a Channel object in the Schedule Task. In fact page = 6 still references the object BTW

“The references are achieved by

each object (Channe= l, Task Configuration, Timing)”

 

but the diagram and= object definitions remove the Channel object.

 

 

My assumption is th= at the channel would be referenced in the Reporting task as described in pa= ge 7.

 

2. Data Transfer Tasks

A. Reporting Tasks report the results of Measurement Tasks to Co= llectors

 

And page 11.

The results

can be communicated to other Tasks or a Task may implement a

Reporting Protocol = and communicate results over Report Channels.

 

 

When I look at the = data model it seems we moved Channel references into tasks or scheduled tas= ks options field.

 

Oddly though the Re= port example doesn’t show a channel name in the task options

That I think would = have been

{"name": = "channel", "value": "Collector A"]}

 

Based on the Task r= eport.

 

 

Did I understand this correctly?<= /p>

 

Thanks,

Tim

 

--_000_9966516C6EB5FC4381E05BF80AA55F773500998DUS70UWXCHMBA05z_-- From nobody Wed Jan 14 01:00:54 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA001A8A42; Wed, 14 Jan 2015 01:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeZvzbkqPveJ; Wed, 14 Jan 2015 01:00:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF2F1B2C23; Wed, 14 Jan 2015 01:00:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114090047.21548.58976.idtracker@ietfa.amsl.com> Date: Wed, 14 Jan 2015 01:00:47 -0800 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-framework-10.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 09:00:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance Working Group of the IETF. Title : A framework for large-scale measurement platforms (LMAP) Authors : Philip Eardley Al Morton Marcelo Bagnulo Trevor Burbridge Paul Aitken Aamer Akhter Filename : draft-ietf-lmap-framework-10.txt Pages : 58 Date : 2015-01-14 Abstract: Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (large-scale measurement platforms). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-framework-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-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 Wed Jan 14 01:01:03 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6051B2C31 for ; Wed, 14 Jan 2015 01:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQbTSSA7GdxC; Wed, 14 Jan 2015 01:00:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F251B2C2A; Wed, 14 Jan 2015 01:00:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: dromasca@avaya.com, draft-ietf-lmap-framework.all@tools.ietf.org, lmap-chairs@tools.ietf.org, lmap@ietf.org, bclaise@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114090047.21548.85278.idtracker@ietfa.amsl.com> Date: Wed, 14 Jan 2015 01:00:47 -0800 Archived-At: Subject: [lmap] New Version Notification - draft-ietf-lmap-framework-10.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 09:00:58 -0000 A new version (-10) has been submitted for draft-ietf-lmap-framework: http://www.ietf.org/internet-drafts/draft-ietf-lmap-framework-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-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. IETF Secretariat. From nobody Wed Jan 14 01:04:56 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3001A8ADF for ; Wed, 14 Jan 2015 01:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ou445XYRfG_r for ; Wed, 14 Jan 2015 01:04:53 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8161A8A42 for ; Wed, 14 Jan 2015 01:04:52 -0800 (PST) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 14 Jan 2015 09:04:49 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.55]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 14 Jan 2015 09:04:12 +0000 From: To: Date: Wed, 14 Jan 2015 09:04:11 +0000 Thread-Topic: New Version Notification for draft-ietf-lmap-framework-10.txt Thread-Index: AdAv2KjdkHfUYZe/RSiCXXM7qLO1/QAACClg Message-ID: References: <20150114090047.21548.79393.idtracker@ietfa.amsl.com> In-Reply-To: <20150114090047.21548.79393.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-10.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 09:04:55 -0000 TmV3IHZlcnNpb24gd2l0aCBzbWFsbCBjaGFuZ2VzLg0KVGhpcyBpcyB0byBoYW5kbGUgZnVydGhl ciBmb2xsb3ctdXBzIGZyb20gQmVub2l0J3MgcmV2aWV3LCBpbiBwYXJ0aWN1bGFyIHRvIGJyaW5n IG91dCAicGFzc2l2ZSIgbWVhc3VyZW1lbnQgY29uc2lkZXJhdGlvbnMgaW4gYSBjb3VwbGUgb2Yg cGxhY2VzICh0aGFua3MgdG8gQWFtZXIgb24gdGhpcykNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10gDQpTZW50OiAxNCBKYW51YXJ5IDIwMTUgMDk6MDENClRvOiBBbCBDLiBN b3J0b247IEVhcmRsZXksUEwsUGhpbGlwLFRVQjggUjsgQWFtZXIgQWtodGVyOyBBbCBNb3J0b247 IE1hcmNlbG8gQmFnbnVsbzsgQWFtZXIgQWtodGVyOyBFYXJkbGV5LFBMLFBoaWxpcCxUVUI4IFI7 IFBhdWwgQWl0a2VuOyBNYXJjZWxvIEJhZ251bG87IFBhdWwgQWl0a2VuOyBCdXJicmlkZ2UsVCxU cmV2b3IsVFVCOCBSOyBCdXJicmlkZ2UsVCxUcmV2b3IsVFVCOCBSDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMTAudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMTAudHh0 IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGhpbGlwIEVhcmRsZXkgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtaWV0Zi1sbWFwLWZy YW1ld29yaw0KUmV2aXNpb246CTEwDQpUaXRsZToJCUEgZnJhbWV3b3JrIGZvciBsYXJnZS1zY2Fs ZSBtZWFzdXJlbWVudCBwbGF0Zm9ybXMgKExNQVApDQpEb2N1bWVudCBkYXRlOgkyMDE1LTAxLTE0 DQpHcm91cDoJCWxtYXANClBhZ2VzOgkJNTgNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTEwLnR4dCAN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWxtYXAtZnJhbWV3b3JrLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMTANCkRpZmY6ICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTEw DQoNCkFic3RyYWN0Og0KICAgTWVhc3VyaW5nIGJyb2FkYmFuZCBzZXJ2aWNlIG9uIGEgbGFyZ2Ug c2NhbGUgcmVxdWlyZXMgYSBkZXNjcmlwdGlvbg0KICAgb2YgdGhlIGxvZ2ljYWwgYXJjaGl0ZWN0 dXJlIGFuZCBzdGFuZGFyZGlzYXRpb24gb2YgdGhlIGtleSBwcm90b2NvbHMNCiAgIHRoYXQgY29v cmRpbmF0ZSBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0aGUgY29tcG9uZW50cy4gIFRoZSBkb2N1bWVu dA0KICAgcHJlc2VudHMgYW4gb3ZlcmFsbCBmcmFtZXdvcmsgZm9yIGxhcmdlLXNjYWxlIG1lYXN1 cmVtZW50cy4gIEl0IGFsc28NCiAgIGRlZmluZXMgdGVybWlub2xvZ3kgZm9yIExNQVAgKGxhcmdl LXNjYWxlIG1lYXN1cmVtZW50IHBsYXRmb3JtcykuDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCg== From nobody Wed Jan 14 03:00:50 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CA71B2C47 for ; Wed, 14 Jan 2015 03:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbeuXrnicilm for ; Wed, 14 Jan 2015 03:00:44 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5B01ACE4C for ; Wed, 14 Jan 2015 03:00:43 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 14 Jan 2015 11:00:40 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.93]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Wed, 14 Jan 2015 11:00:41 +0000 From: To: , Date: Wed, 14 Jan 2015 11:00:39 +0000 Thread-Topic: LMAP Information Model rev3 - Communication channels Thread-Index: AdAvb4InCMBCsnrlSFeZwGq1LM7I6QAcpCSg Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F773500998D@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F773500998D@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72F1182B912EMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] LMAP Information Model rev3 - Communication channels X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 11:00:48 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72F1182B912EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >Trevor, > >I was trying to see how the instruction would configure the communication = change that would convey the results of a scheduled task to a collector. > >In rev02 of the information model the was a Channel object in the Schedule= Task. In fact page 6 still references the object BTW >"The references are achieved by >each object (Channel, Task Configuration, Timing)" Missed that one - I will correct (remove the reference to Channel). >but the diagram and object definitions remove the Channel object. > >My assumption is that the channel would be referenced in the Reporting tas= k as described in page 7. Yes - true. >2. Data Transfer Tasks >A. Reporting Tasks report the results of Measurement Tasks to Collectors > >And page 11. >The results >can be communicated to other Tasks or a Task may implement a >Reporting Protocol and communicate results over Report Channels. > > >When I look at the data model it seems we moved Channel references into ta= sks or scheduled tasks options field. Yes that's correct. >Oddly though the Report example doesn't show a channel name in the task op= tions >That I think would have been >{"name": "channel", "value": "Collector A"]} > >Based on the Task report. I thought I'd corrected/revised the example, but I obviously forgot to put = this in! >Did I understand this correctly? > >Thanks, >Tim Sounds like you understand just fine! Thanks for pointing out the correctio= ns, Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: 13 January 2015 20:29 To: lmap@ietf.org Subject: [lmap] LMAP Information Model rev3 - Communication channels Trevor, I was trying to see how the instruction would configure the communication c= hange that would convey the results of a scheduled task to a collector. In rev02 of the information model the was a Channel object in the Schedule = Task. In fact page 6 still references the object BTW "The references are achieved by each object (Channel, Task Configuration, Timing)" but the diagram and object definitions remove the Channel object. My assumption is that the channel would be referenced in the Reporting task= as described in page 7. 2. Data Transfer Tasks A. Reporting Tasks report the results of Measurement Tasks to Collectors And page 11. The results can be communicated to other Tasks or a Task may implement a Reporting Protocol and communicate results over Report Channels. When I look at the data model it seems we moved Channel references into tas= ks or scheduled tasks options field. Oddly though the Report example doesn't show a channel name in the task opt= ions That I think would have been {"name": "channel", "value": "Collector A"]} Based on the Task report. Did I understand this correctly? Thanks, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72F1182B912EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>Trevor,

> 

>I was trying to see how the instruction would configure the communi= cation change that would convey the results of a scheduled task to a collec= tor.

> 

>In rev02 of the information m= odel the was a Channel object in the Schedule Task. In fact page 6 still re= ferences the object BTW

>R= 20;The references are achieved by

>each object (Channel, Ta= sk Configuration, Timing)”

=  

<= p class=3DMsoNormal>Missed th= at one – I will correct (remove the reference to Channel).=

 

>but the diagram and object definitions remove th= e Channel object.

> 

>My assumption is= that the channel would be referenced in the Reporting task as described in= page 7.

 

Yes – true.

 

>2. Data Transfer Tasks<= o:p>

>A. Reporting Tasks report th= e results of Measurement Tasks to Collectors

> <= /o:p>

>And page 11.

>The= results

>can be communicated= to other Tasks or a Task may implement a

>Reporting Protoc= ol and communicate results over Report Channels.

>&nbs= p;

> 

>When I look at the data model it se= ems we moved Channel references into tasks or scheduled tasks options field= .

 

Yes that’s correct.

=  

>Oddly though the Report example doesn’t sho= w a channel name in the task options

>That I think would ha= ve been

>{"name": "channel", "val= ue": "Collector A"]}

> 

&g= t;Based on the Task report.

 =

I thought I’d corrected/revised the e= xample, but I obviously forgot to put this in!

 

>Did I understand thi= s correctly?

> 

>Thanks,

= >Ti= m

 

Sounds like you understand just fine! Thanks for pointing out the co= rrections,

 

=

Trevor.

 

 

 

From: lmap= [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy= )
Sent: 13 January 2015 20:29
To: lmap@ietf.org
S= ubject: [lmap] LMAP Information Model rev3 - Communication channels

 

Trevor,

 

I was trying to see how the instruction would= configure the communication change that would convey the results of a sche= duled task to a collector.

 

In rev02 of the= information model the was a Channel object in the Schedule Task. In fact p= age 6 still references the object BTW

“The references are achieved by

each object (Cha= nnel, Task Configuration, Timing)”

 

b= ut the diagram and object definitions remove the Channel object.=

 

 

My assumption is that the channe= l would be referenced in the Reporting task as described in page 7.

 

2. Data Transfer Ta= sks

A. Reporting Tasks report th= e results of Measurement Tasks to Collectors

 

And page 11.

The results

can be communicated to other Tasks = or a Task may implement a

Reporting Protocol and communicate r= esults over Report Channels.

 

 

When I look at the data model it seems we moved Channel references i= nto tasks or scheduled tasks options field.

 

Oddly though the Report example doesn’t show a channel name in th= e task options

That I think would have been =

{&qu= ot;name": "channel", "value": "Collector A&qu= ot;]}

 

Based on the Task report.=

 

= &= nbsp;

Did I understand this correctly?<= /o:p>

 

T= hanks,

Tim

 

= --_000_ED51D9282D1D3942B9438CA8F3372EB72F1182B912EMV64UKRDdoma_-- From nobody Wed Jan 14 06:56:47 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32AE1A005B for ; Wed, 14 Jan 2015 06:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRJNa0SdFu1j for ; Wed, 14 Jan 2015 06:56:40 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CEDF1A1AA6 for ; Wed, 14 Jan 2015 06:56:40 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id D86DD357D617B; Wed, 14 Jan 2015 14:56:34 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t0EEsoqG015375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Jan 2015 09:56:36 -0500 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.185]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Wed, 14 Jan 2015 09:56:26 -0500 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: LMAP Information Model rev3 - Communication channels Thread-Index: AdAvb4InCMBCsnrlSFeZwGq1LM7I6QAcpCSgAAnxvEA= Date: Wed, 14 Jan 2015 14:56:25 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F773500A3D2@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F773500998D@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F773500A3D2US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] LMAP Information Model rev3 - Communication channels X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 14:56:44 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F773500A3D2US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, Ok - Do we need to have a section here of "well-known" options needed in th= e information model - like Channel. I can understand things like cross traffic would be method specific but a C= hannel is a construct of the information model; Actually I would never had = made it an option but since it is; we should document the well known name o= ption. BR, Tim From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Wednesday, January 14, 2015 5:01 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: LMAP Information Model rev3 - Communication channels >Trevor, > >I was trying to see how the instruction would configure the communication = change that would convey the results of a scheduled task to a collector. > >In rev02 of the information model the was a Channel object in the Schedule= Task. In fact page 6 still references the object BTW >"The references are achieved by >each object (Channel, Task Configuration, Timing)" Missed that one - I will correct (remove the reference to Channel). >but the diagram and object definitions remove the Channel object. > >My assumption is that the channel would be referenced in the Reporting tas= k as described in page 7. Yes - true. >2. Data Transfer Tasks >A. Reporting Tasks report the results of Measurement Tasks to Collectors > >And page 11. >The results >can be communicated to other Tasks or a Task may implement a >Reporting Protocol and communicate results over Report Channels. > > >When I look at the data model it seems we moved Channel references into ta= sks or scheduled tasks options field. Yes that's correct. >Oddly though the Report example doesn't show a channel name in the task op= tions >That I think would have been >{"name": "channel", "value": "Collector A"]} > >Based on the Task report. I thought I'd corrected/revised the example, but I obviously forgot to put = this in! >Did I understand this correctly? > >Thanks, >Tim Sounds like you understand just fine! Thanks for pointing out the correctio= ns, Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: 13 January 2015 20:29 To: lmap@ietf.org Subject: [lmap] LMAP Information Model rev3 - Communication channels Trevor, I was trying to see how the instruction would configure the communication c= hange that would convey the results of a scheduled task to a collector. In rev02 of the information model the was a Channel object in the Schedule = Task. In fact page 6 still references the object BTW "The references are achieved by each object (Channel, Task Configuration, Timing)" but the diagram and object definitions remove the Channel object. My assumption is that the channel would be referenced in the Reporting task= as described in page 7. 2. Data Transfer Tasks A. Reporting Tasks report the results of Measurement Tasks to Collectors And page 11. The results can be communicated to other Tasks or a Task may implement a Reporting Protocol and communicate results over Report Channels. When I look at the data model it seems we moved Channel references into tas= ks or scheduled tasks options field. Oddly though the Report example doesn't show a channel name in the task opt= ions That I think would have been {"name": "channel", "value": "Collector A"]} Based on the Task report. Did I understand this correctly? Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F773500A3D2US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

Ok – Do we need to have a secti= on here of “well-known” options needed in the information model= – like Channel.

 

I can understand things like cross tr= affic would be method specific but a Channel is a construct of the informat= ion model; Actually I would never had made it an option but since it is; we should document the well known name option.=

 

BR,

Tim

 

From: trevor.b= urbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Wednesday, January 14, 2015 5:01 AM
To: Carey, Timothy (Timothy); lmap@ietf.org
Subject: RE: LMAP Information Model rev3 - Communication channels

 

>Trevor,

> 

>I was trying to= see how the instruction would configure the communication change that woul= d convey the results of a scheduled task to a collector.<= /p>

> 

>In rev02 of the= information model the was a Channel object in the Schedule Task. In fact p= age 6 still references the object BTW

>“The references are achieved by

>each object (Ch= annel, Task Configuration, Timing)”

 

Missed that one = 211; I will correct (remove the reference to Channel).

 

>but the diagram= and object definitions remove the Channel object.

> 

>My assumption i= s that the channel would be referenced in the Reporting task as described i= n page 7.

 

Yes – true.

 

>2. Data Transfer Tasks

>A. Reporting Tasks report the results of Measurement Tasks t= o Collectors

> 

>And page 11.

>The results

>can be communicated to other Tasks or a Task may implement a=

>Reporting Proto= col and communicate results over Report Channels.

> 

> 

>When I look at = the data model it seems we moved Channel references into tasks or scheduled= tasks options field.

 

Yes that’s co= rrect.

 

>Oddly though th= e Report example doesn’t show a channel name in the task options=

>That I think wo= uld have been

>{"name&quo= t;: "channel", "value": "Collector A"]}<= /o:p>

> 

>Based on the Ta= sk report.

 

I thought I’d corrected/revised the example, = but I obviously forgot to put this in!

 

>Did I understand this correctly?

> 

>Thanks,

>Tim

 

Sounds like you understand just fine! Thanks for po= inting out the corrections,

 

Trevor.

 

&n= bsp;

&n= bsp;

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 13 January 2015 20:29
To: lmap@ietf.org
Subject: [lmap] LMAP Information Model rev3 - Communication channels=

 

Trevor,<= /span>

 

I was trying to see= how the instruction would configure the communication change that would co= nvey the results of a scheduled task to a collector.

 

In rev02 of the inf= ormation model the was a Channel object in the Schedule Task. In fact page = 6 still references the object BTW

“The references are achieved by

each object (Channe= l, Task Configuration, Timing)”

 

but the diagram and= object definitions remove the Channel object.

 

 

My assumption is th= at the channel would be referenced in the Reporting task as described in pa= ge 7.

 

2. Data Transfer Tasks

A. Reporting Tasks report the results of Measurement Tasks to Co= llectors

 

And page 11.

The results

can be communicated to other Tasks or a Task may implement a

Reporting Protocol = and communicate results over Report Channels.

 

 

When I look at the = data model it seems we moved Channel references into tasks or scheduled tas= ks options field.

 

Oddly though the Re= port example doesn’t show a channel name in the task options

That I think would = have been

{"name": = "channel", "value": "Collector A"]}

 

Based on the Task r= eport.

 

 

Did I understand this correctly?<= /p>

 

Thanks,

Tim

 

--_000_9966516C6EB5FC4381E05BF80AA55F773500A3D2US70UWXCHMBA05z_-- From nobody Thu Jan 15 06:57:49 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D6A1B2BFB for ; Thu, 15 Jan 2015 06:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEV-R3G-_MGg for ; Thu, 15 Jan 2015 06:57:44 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801D61B2B24 for ; Thu, 15 Jan 2015 06:57:44 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id 765d7b45.0.5380405.00-2113.15039352.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 15 Jan 2015 14:57:44 +0000 (UTC) X-MXL-Hash: 54b7d5687ff04b8e-f585d54f41c639872052dbb905c84dedb3a29f25 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0FEvhfn023424 for ; Thu, 15 Jan 2015 09:57:43 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0FEvZnL023357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 15 Jan 2015 09:57:37 -0500 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi132.aldc.att.com (RSA Interceptor) for ; Thu, 15 Jan 2015 14:57:25 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.10]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0195.001; Thu, 15 Jan 2015 09:57:25 -0500 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt Thread-Index: AQHQMMmRHuSVv7mMnEmea+HAnj8NKZzBRO0Q Date: Thu, 15 Jan 2015 14:57:24 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130EEB6B8@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20150115134538.6095.77506.idtracker@ietfa.amsl.com> In-Reply-To: <20150115134538.6095.77506.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.137.239] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NJ9iDTGg c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=Rdfbwb88Q98A:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=YNv0rlydsVwA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=Mvx56vXwvbIDxIIz5sYA:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: [lmap] FW: New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 14:57:47 -0000 VGhpcyBpcyB0aGUgZHJhZnQgdGhhdCBUaW0gQ2FyZXkgYW5kIEkgcHV0IHRvZ2V0aGVyIGZvciBM TUFQIHByb3RvY29sIHNlbGVjdGlvbiBjcml0ZXJpYS4gSXQgaXMgdGFrZW4gZnJvbSB0aGUgc2xp ZGVzIHdlIHByZXNlbnRlZCBvbiB0aGUgRGVjZW1iZXIgdGVsZWNvbmZlcmVuY2UsIHdpdGggYSBm ZXcgY2hhbmdlcyBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBkdXJpbmcgdGhhdCBjYWxsLg0KQmFy YmFyYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFRodXJz ZGF5LCBKYW51YXJ5IDE1LCAyMDE1IDg6NDYgQU0NClRvOiBTVEFSSywgQkFSQkFSQSBIOyBTVEFS SywgQkFSQkFSQSBIDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXN0YXJrY2FyZXktbG1hcC1wcm90b2NvbC1jcml0ZXJpYS0wMC50eHQNCg0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtc3RhcmtjYXJleS1sbWFwLXByb3RvY29sLWNyaXRlcmlhLTAwLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCYXJiYXJhIFN0YXJrIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXN0YXJrY2FyZXkt bG1hcC1wcm90b2NvbC1jcml0ZXJpYQ0KUmV2aXNpb246CTAwDQpUaXRsZToJCUxNQVAgUHJvdG9j b2wgU2VsZWN0aW9uIENyaXRlcmlhDQpEb2N1bWVudCBkYXRlOgkyMDE1LTAxLTE1DQpHcm91cDoJ CUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk2DQpVUkw6ICAgICAgICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc3RhcmtjYXJleS1sbWFwLXByb3Rv Y29sLWNyaXRlcmlhLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXN0YXJrY2FyZXktbG1hcC1wcm90b2NvbC1jcml0ZXJpYS8NCkh0 bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zdGFya2NhcmV5 LWxtYXAtcHJvdG9jb2wtY3JpdGVyaWEtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQg aWRlbnRpZmllcyBjcml0ZXJpYSB0byBiZSB1c2VkIGluIGV2YWx1YXRpbmcgYW5kIHNlbGVjdGlu Zw0KICAgQ29udHJvbCBhbmQgUmVwb3J0aW5nIFByb3RvY29scyBkZXNjcmliZWQgYnkNCiAgIFtJ LUQuaWV0Zi1sbWFwLWZyYW1ld29ya10uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== From nobody Thu Jan 15 08:14:17 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AFA1B2CE0 for ; Thu, 15 Jan 2015 08:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nh7fIoB_C7Dx for ; Thu, 15 Jan 2015 08:14:02 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B54A1B2D10 for ; Thu, 15 Jan 2015 08:14:00 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQIACXmt1TGmAcV/2dsb2JhbABagmQiUlgEszYMAQEBAQEBBpJEhXECgRNDAQEBAQEBfIQMAQEBAQMSKDQJDgQCAQgNBAQBAQsUCQcyFAkIAgQBEggaiAoBDLNwnlEBAQEBAQEEAQEBAQEBAQEBAQEXhgWJQzgGgxCBEwWOTINHhlcwgkOCMguLSyKDbm+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.09,404,1418101200"; d="scan'208";a="100151381" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Jan 2015 11:13:58 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 15 Jan 2015 11:13:59 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Thu, 15 Jan 2015 17:13:05 +0100 From: "Romascanu, Dan (Dan)" To: "STARK, BARBARA H" , "lmap@ietf.org" Thread-Topic: New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt Thread-Index: AQHQMMmRHuSVv7mMnEmea+HAnj8NKZzBRO0QgAAVUSA= Date: Thu, 15 Jan 2015 16:13:04 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C96ADA5@AZ-FFEXMB04.global.avaya.com> References: <20150115134538.6095.77506.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E61130EEB6B8@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130EEB6B8@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 16:14:11 -0000 Thanks, Barbara and Tim! All WG participants - please read and comment. Remember that this document = aims to be a reference and help tool in the protocols selection process.=20 Regards, Dan > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: Thursday, January 15, 2015 4:57 PM > To: lmap@ietf.org > Subject: [lmap] FW: New Version Notification for draft-starkcarey-lmap- > protocol-criteria-00.txt >=20 > This is the draft that Tim Carey and I put together for LMAP protocol sel= ection > criteria. It is taken from the slides we presented on the December > teleconference, with a few changes based on the discussion during that ca= ll. > Barbara >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, January 15, 2015 8:46 AM > To: STARK, BARBARA H; STARK, BARBARA H > Subject: New Version Notification for draft-starkcarey-lmap-protocol- > criteria-00.txt >=20 >=20 > A new version of I-D, draft-starkcarey-lmap-protocol-criteria-00.txt > has been successfully submitted by Barbara Stark and posted to the IETF > repository. >=20 > Name: draft-starkcarey-lmap-protocol-criteria > Revision: 00 > Title: LMAP Protocol Selection Criteria > Document date: 2015-01-15 > Group: Individual Submission > Pages: 6 > URL: https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__www.ietf.org_internet-2Ddrafts_draft-2Dstarkcarey-2Dlmap- > 2Dprotocol-2Dcriteria- > 2D00.txt&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQ > zvlsiLQfucBXRucPvdrphpBsFA&m=3DXIN9C1RI85JcLlc_HK4JmbtSpeNxLXsPfKInZ > 3TM5DE&s=3DiICyiTfARFWNLQ0nYcKm8ZPu566aGDwcFFnLgS_IG64&e=3D > Status: https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dstarkcarey-2Dlmap-2Dprotocol- > 2Dcriteria_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJ > fQzvlsiLQfucBXRucPvdrphpBsFA&m=3DXIN9C1RI85JcLlc_HK4JmbtSpeNxLXsPfKI > nZ3TM5DE&s=3D2gt4tnmgmwjx4-w3530xDA0goc1qR8bCfyBfR2e8lbw&e=3D > Htmlized: https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__tools.ietf.org_html_draft-2Dstarkcarey-2Dlmap-2Dprotocol-2Dcriteria- > 2D00&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvls > iLQfucBXRucPvdrphpBsFA&m=3DXIN9C1RI85JcLlc_HK4JmbtSpeNxLXsPfKInZ3T > M5DE&s=3DV31dBlNm5qEW5oYktaORSpaT_-hXOvAf8uyD4S1KJLU&e=3D >=20 >=20 > Abstract: > This draft identifies criteria to be used in evaluating and selecting > Control and Reporting Protocols described by > [I-D.ietf-lmap-framework]. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_lmap&d=3DAwICAg&c=3DBFpWQw8bsuKpl > 1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DXIN9C1 > RI85JcLlc_HK4JmbtSpeNxLXsPfKInZ3TM5DE&s=3DEIGzvXolZ7jKxm1NoOMSbML > AFc0FaDbViOExWfdxwNU&e=3D From nobody Wed Jan 21 07:31:57 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492F91A1AE0 for ; Wed, 21 Jan 2015 07:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjrqGQR1yvmf for ; Wed, 21 Jan 2015 07:31:48 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B5F1A1ADB for ; Wed, 21 Jan 2015 07:31:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8GALrFv1SHCzIm/2dsb2JhbABbgkMhIlJZA7NFAQEBAwaSSYVvAoElQwEBAQEBAXyEDgEBAxIbXgEMCRVWJgEEGwEZiAoBDK4hhH+fb4YFiUODToETBY5ZiiuCfII1i2UigVGCHYI0fgEBAQ X-IronPort-AV: E=Sophos;i="5.09,442,1418101200"; d="scan'208,217";a="103499426" 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 Jan 2015 10:31:27 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 21 Jan 2015 10:31:26 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Wed, 21 Jan 2015 16:31:25 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: minutes of the 12/15 virtual interim meeting Thread-Index: AdA1j1CspCWyr7zQS+6/9LanKWf0cw== Date: Wed, 21 Jan 2015 15:31:24 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9714BF@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_9904FB1B0159DA42B0B887B7FA8119CA5C9714BFAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] minutes of the 12/15 virtual interim meeting X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 15:31:50 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9714BFAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I uploaded the minutes of the 12/15 interim meeting at http://www.ietf.org/= proceedings/interim/2014/12/15/lmap/minutes/minutes-interim-2014-lmap-2. They are based on the notes taken by Barbara Stark - thanks, Barbara! Please let me know if there are any questions, important missing items, or = things that were recorded inaccurately. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9714BFAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I uploaded the minutes of the 12/15 interim meeting = at http://www.ietf.org/proceedings/interim/2014/12/15/lmap/minutes/minutes-int= erim-2014-lmap-2.

 

They are based on the notes taken by Barbara Stark &= #8211; thanks, Barbara!

 

Please let me know if there are any questions, impor= tant missing items, or things that were recorded inaccurately.

 

Thanks and Regards,

 

Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C9714BFAZFFEXMB04globa_-- From nobody Thu Jan 22 01:07:35 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2171A1BEE for ; Thu, 22 Jan 2015 01:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnDh_z67LwCE for ; Thu, 22 Jan 2015 01:07:26 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2875C1A03A2 for ; Thu, 22 Jan 2015 01:07:25 -0800 (PST) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 22 Jan 2015 09:07:27 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.55]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Thu, 22 Jan 2015 09:07:23 +0000 From: To: , Date: Thu, 22 Jan 2015 09:07:22 +0000 Thread-Topic: minutes of the 12/15 virtual interim meeting Thread-Index: AdA1j1CspCWyr7zQS+6/9LanKWf0cwAklUhg Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C9714BF@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C9714BF@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413DED487AEMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] minutes of the 12/15 virtual interim meeting X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 09:07:31 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413DED487AEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Dan. A few follow-ups:- * On the use cases, we have worked with the IESG on various bits of= new text that resolve all the IESG discusses (& comments). This week Marc = is producing a revised i-d including these changes. Then IESG can check & (= hopefully) sign off their discusses. * On the framework, Aamer reviewed it and we agreed some changes an= d issued a new i-d. So we are waiting for Benoit to check he's happy for it= to go to IESG or needs further changes first. * Can you remind me when the next interim is please? phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: 21 January 2015 15:31 To: lmap@ietf.org Subject: [lmap] minutes of the 12/15 virtual interim meeting I uploaded the minutes of the 12/15 interim meeting at http://www.ietf.org/= proceedings/interim/2014/12/15/lmap/minutes/minutes-interim-2014-lmap-2. They are based on the notes taken by Barbara Stark - thanks, Barbara! Please let me know if there are any questions, important missing items, or = things that were recorded inaccurately. Thanks and Regards, Dan --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413DED487AEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Dan.

A few follow-ups:-

 

<= span style=3D'mso-list:Ignore'>·         On the use cases, we have worked with the IESG on various b= its of new text that resolve all the IESG discusses (& comments). This = week Marc is producing a revised i-d including these changes. Then IESG can= check & (hopefully) sign off their discusses.

·         On the framework, Aamer reviewed it and we ag= reed some changes and issued a new i-d. So we are waiting for Benoit to che= ck he’s happy for it to go to IESG or needs further changes first.

·=      =     Can you remind me when = the next interim is please?

 

phil

=

 

<= p class=3DMsoNormal>From: lmap [mailto:lmap-bounces= @ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: 21 Janu= ary 2015 15:31
To: lmap@ietf.org
Subject: [lmap] minute= s of the 12/15 virtual interim meeting

 

I uploaded the minutes of the 12/15 interim meeting at http://www.ietf.org/proceedings/interim/2014/12/15/lmap/minute= s/minutes-interim-2014-lmap-2.

 

They are based on the notes taken by Barbara Stark – t= hanks, Barbara!

 

Pleas= e let me know if there are any questions, important missing items, or thing= s that were recorded inaccurately.

 

Thanks and Regards,

 

Dan

 

 

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413DED487AEMV67UKRDdoma_-- From nobody Thu Jan 22 02:05:26 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987081A1BEE for ; Thu, 22 Jan 2015 02:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AniUj17lfLlf for ; Thu, 22 Jan 2015 02:05:17 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6221A19E9 for ; Thu, 22 Jan 2015 02:05:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgFAKfKwFTGmAcV/2dsb2JhbABAFwOCQyEiUlgEhQWuXgwBAQEBAQEGkiAdAQiFcgKBGUMBAQEBAQF8hAwBAQEBAQISGzkjAgEIDQQEAQELCgQMAwcyFAkHAQEBBAESCAEZiAoBDDeyQo92jyYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXhgWJMBMhDAoBEQeCFUwdgRMFhTmHRYFfg0eGYzaCSII2hUyCYIM9IoFbgUVObwEBAYFCfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,448,1418101200"; d="scan'208,217";a="100955078" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Jan 2015 05:05:15 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 22 Jan 2015 05:05:15 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Thu, 22 Jan 2015 05:05:13 -0500 From: "Romascanu, Dan (Dan)" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: minutes of the 12/15 virtual interim meeting Thread-Index: AdA1j1CspCWyr7zQS+6/9LanKWf0cwAklUhgAAI6ydA= Date: Thu, 22 Jan 2015 10:05:12 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9723F9@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C9714BF@AZ-FFEXMB04.global.avaya.com> In-Reply-To: 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_9904FB1B0159DA42B0B887B7FA8119CA5C9723F9AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] minutes of the 12/15 virtual interim meeting X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 10:05:24 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9723F9AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thanks for the updates. The next virtual Interim is scheduled for Thursday 2/12. LMAP Virtual Interim Meeting Thursday, February 12, 2015 12:00 pm | Eastern Standard Time (New York, GMT-05:00) | 2 hr Join WebEx meeting: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= ietf.webex.com_ietf_j.php-3FMTID-3Dm7f02a060d018e8c17780318de9084c6b&d=3DAw= ICaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphp= BsFA&m=3D9KQf_sZbfpkkKPVid3HmyTmKDDkJ1NLMsTFrZ6LA7oo&s=3D01FwIKl2v8eB3sQaE1= EVs-D0tbHSjJ7CDn8h3iX1xeY&e=3D Meeting number: 645 771 127 Meeting password: 1234 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 645 771 127 Tol= l-free calling restrictions: https://urldefense.proofpoint.com/v2/url?u=3Dh= ttp-3A__www.webex.com_pdf_tollfree-5Frestrictions.pdf&d=3DAwICaQ&c=3DBFpWQw= 8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3D9KQf_s= ZbfpkkKPVid3HmyTmKDDkJ1NLMsTFrZ6LA7oo&s=3Dd85E67WS8MdXR2TH3qmE7csbytLxN-3_I= OjHMTK3jus&e=3D Add this meeting to your calendar: https://urldefense.proofpoint.com/v2/url= ?u=3Dhttps-3A__ietf.webex.com_ietf_j.php-3FMTID-3Dma1a9b1ecdacf17cbc99dff93= a9040d6a&d=3DAwICaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQ= fucBXRucPvdrphpBsFA&m=3D9KQf_sZbfpkkKPVid3HmyTmKDDkJ1NLMsTFrZ6LA7oo&s=3Dg1J= 8KGa0g-StCdVExiM6FgnckXZejSMQ-gTGb4n4CcQ&e Regards, Dan From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Thursday, January 22, 2015 11:07 AM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: RE: minutes of the 12/15 virtual interim meeting Thanks Dan. A few follow-ups:- * On the use cases, we have worked with the IESG on various bits of= new text that resolve all the IESG discusses (& comments). This week Marc = is producing a revised i-d including these changes. Then IESG can check & (= hopefully) sign off their discusses. * On the framework, Aamer reviewed it and we agreed some changes an= d issued a new i-d. So we are waiting for Benoit to check he's happy for it= to go to IESG or needs further changes first. * Can you remind me when the next interim is please? phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: 21 January 2015 15:31 To: lmap@ietf.org Subject: [lmap] minutes of the 12/15 virtual interim meeting I uploaded the minutes of the 12/15 interim meeting at http://www.ietf.org/= proceedings/interim/2014/12/15/lmap/minutes/minutes-interim-2014-lmap-2. They are based on the notes taken by Barbara Stark - thanks, Barbara! Please let me know if there are any questions, important missing items, or = things that were recorded inaccurately. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9723F9AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Thanks for the updates= .

 

The next virtual Inter= im is scheduled for Thursday 2/12.

 

LMAP Virtual Interim Meeting

Thursday, February 12, 2015

12:00 pm  |  Eastern Standard Time (New= York, GMT-05:00)  |  2 hr

Join WebEx meeting: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__ietf.webex.com_ietf_= j.php-3FMTID-3Dm7f02a060d018e8c17780318de9084c6b&d=3DAwICaQ&c=3DBFp= WQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&= ;m=3D9KQf_sZbfpkkKPVid3HmyTmKDDkJ1NLMsTFrZ6LA7oo&s=3D01FwIKl2v8eB3sQaE1= EVs-D0tbHSjJ7CDn8h3iX1xeY&e=3D

Meeting number:     &nbs= p;      645 771 127

Meeting password:     &n= bsp;   1234

Join by phone

1-877-668-4493 Call-in toll free number (US/Canad= a)

1-650-479-3208 Call-in toll number (US/Canada) Ac= cess code: 645 771 127 Toll-free calling restrictions: https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.webex.com_pdf_tol= lfree-5Frestrictions.pdf&d=3DAwICaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&= r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3D9KQf_sZbfpkkKPVid3H= myTmKDDkJ1NLMsTFrZ6LA7oo&s=3Dd85E67WS8MdXR2TH3qmE7csbytLxN-3_IOjHMTK3ju= s&e=3D

 

Add this meeting to your calendar: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__ietf.webex.com_ietf_= j.php-3FMTID-3Dma1a9b1ecdacf17cbc99dff93a9040d6a&d=3DAwICaQ&c=3DBFp= WQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&= ;m=3D9KQf_sZbfpkkKPVid3HmyTmKDDkJ1NLMsTFrZ6LA7oo&s=3Dg1J8KGa0g-StCdVExi= M6FgnckXZejSMQ-gTGb4n4CcQ&e

 

Regards,

 

Dan

 

 

From: philip.e= ardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Thursday, January 22, 2015 11:07 AM
To: Romascanu, Dan (Dan); lmap@ietf.org
Subject: RE: minutes of the 12/15 virtual interim meeting=

 

Thanks Dan.

A few follow-up= s:-

 

·   &nbs= p;     On the use cases, we have worked with the IESG on various= bits of new text that resolve all the IESG discusses (& comments). This week Marc is producing a revised i-d including these changes. Then IE= SG can check & (hopefully) sign off their discusses.<= /p>

·   &nbs= p;     On the framework, Aamer reviewed it and we agreed some ch= anges and issued a new i-d. So we are waiting for Benoit to check he’s happy for it to go to IESG or needs further changes first= .

·   &nbs= p;     Can you remind me when the next interim is please?

 

phil=

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: 21 January 2015 15:31
To: lmap@ietf.org
Subject: [lmap] minutes of the 12/15 virtual interim meeting

 

I uploaded the minutes of the 12/15 interim meeting = at http://www.ietf.org/proceedings/interim/2014/12/15/lmap/minutes/minutes-int= erim-2014-lmap-2.

 

They are based on the notes taken by Barbara Stark &= #8211; thanks, Barbara!

 

Please let me know if there are any questions, impor= tant missing items, or things that were recorded inaccurately.

 

Thanks and Regards,

 

Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C9723F9AZFFEXMB04globa_-- From nobody Thu Jan 22 09:25:51 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62BA1ACD75 for ; Thu, 22 Jan 2015 09:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYkktad9Kdsx for ; Thu, 22 Jan 2015 09:25:45 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5CC1ACD76 for ; Thu, 22 Jan 2015 09:24:39 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id t0MHObRm007463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Jan 2015 11:24:37 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 1691D1E006A for ; Thu, 22 Jan 2015 10:24:32 -0700 (MST) Received: from lxdnp32k.corp.intranet (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id F11571E004E for ; Thu, 22 Jan 2015 10:24:31 -0700 (MST) Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id t0MHOV8q019828 for ; Thu, 22 Jan 2015 10:24:31 -0700 Received: from [127.0.0.1] (ddc-f5-snat1-prod-vln103-hsrp5.corp.intranet [151.119.98.202]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id t0MHOLLo019315; Thu, 22 Jan 2015 10:24:31 -0700 Message-ID: <54C1323F.2010202@centurylink.com> Date: Thu, 22 Jan 2015 10:24:15 -0700 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: lmap@ietf.org References: <20150115134538.6095.77506.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E61130EEB6B8@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130EEB6B8@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [lmap] FW: New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: charles.cook2@centurylink.com List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 17:25:49 -0000 Barbara Tim, I generally like what is conveyed in the draft. Question: Is there a need to indicate that the protocol(s) have the ability to support encryption? Or would encryption, if used, be transparent to the protocol(s)? Charles On 1/15/2015 7:57 AM, STARK, BARBARA H wrote: > This is the draft that Tim Carey and I put together for LMAP protocol selection criteria. It is taken from the slides we presented on the December teleconference, with a few changes based on the discussion during that call. > Barbara > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, January 15, 2015 8:46 AM > To: STARK, BARBARA H; STARK, BARBARA H > Subject: New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt > > > A new version of I-D, draft-starkcarey-lmap-protocol-criteria-00.txt > has been successfully submitted by Barbara Stark and posted to the IETF repository. > > Name: draft-starkcarey-lmap-protocol-criteria > Revision: 00 > Title: LMAP Protocol Selection Criteria > Document date: 2015-01-15 > Group: Individual Submission > Pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-starkcarey-lmap-protocol-criteria-00.txt > Status: https://datatracker.ietf.org/doc/draft-starkcarey-lmap-protocol-criteria/ > Htmlized: http://tools.ietf.org/html/draft-starkcarey-lmap-protocol-criteria-00 > > > Abstract: > This draft identifies criteria to be used in evaluating and selecting > Control and Reporting Protocols described by > [I-D.ietf-lmap-framework]. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com From nobody Fri Jan 23 08:33:50 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3F51A8BC2 for ; Fri, 23 Jan 2015 08:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOU0n-mdbuKH for ; Fri, 23 Jan 2015 08:33:45 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9AD1A1AD8 for ; Fri, 23 Jan 2015 08:33:45 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2F030F88 for ; Fri, 23 Jan 2015 17:33:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id JNu982lanNAi for ; Fri, 23 Jan 2015 17:33:16 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 23 Jan 2015 17:33:43 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A69E720036 for ; Fri, 23 Jan 2015 17:33:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MxbO_RHr-gW0; Fri, 23 Jan 2015 17:33:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42A9D20035; Fri, 23 Jan 2015 17:33:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C479430E5CC7; Fri, 23 Jan 2015 17:33:38 +0100 (CET) Date: Fri, 23 Jan 2015 17:33:37 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20150123163337.GA41446@elstar.local> Mail-Followup-To: lmap@ietf.org, Vaibhav Bajpai References: <20150123161328.11811.43687.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150123161328.11811.43687.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Vaibhav Bajpai Subject: Re: [lmap] I-D Action: draft-schoenw-lmap-yang-02.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 16:33:47 -0000 Hi, we have updated the YANG data model in order to align it with the latest update of the information model. A couple of questions came up during the process, which we will post in a separate message. We also added an instance document in XML and the same rendered in JSON. Both have been validated against the YANG data model using the pyang toolchain. /js On Fri, Jan 23, 2015 at 08:13:28AM -0800, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : A YANG Data Model for LMAP Measurement Agents > Authors : Juergen Schoenwaelder > Vaibhav Bajpai > Filename : draft-schoenw-lmap-yang-02.txt > Pages : 38 > Date : 2015-01-23 > > 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-schoenw-lmap-yang/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-schoenw-lmap-yang-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-schoenw-lmap-yang-02 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -- 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 Jan 25 09:57:33 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B521A6EE4 for ; Sun, 25 Jan 2015 09:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRUYAWg9KF8q for ; Sun, 25 Jan 2015 09:57:30 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1618D1A1B3D for ; Sun, 25 Jan 2015 09:57:30 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id D7646200B996E; Sun, 25 Jan 2015 09:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pollere.net; h=from:to :references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding; s=pollere.net; bh=9jSfr bKG7kf1OadsbMuqQuiY0rg=; b=XlckdzhfV33sEEbWcIch6rYMwAM0e3Nk/6ZT+ X2Rt0sZbkxKYXdJIGjCGeJXngJtIXftE5nNK8f7bUGhGa1hsI7u2EWFZ4sDsytxm v9sUjkQAmHcBFEZyoTgqhTTULwghFZ6/fqJNm0Wb/VsFC33JxdlX5meq0LTtT3YW bOKFfA= Received: from JoanTower (user-0c2ihcg.cable.earthlink.net [24.41.69.144]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: joan.luciani@pollere.net) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 283C9200B9969; Sun, 25 Jan 2015 09:57:28 -0800 (PST) From: "Joan Luciani" To: "'Romascanu, Dan \(Dan\)'" , "'STARK, BARBARA H'" , References: <20150115134538.6095.77506.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E61130EEB6B8@GAALPA1MSGUSRBF.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C96ADA5@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C96ADA5@AZ-FFEXMB04.global.avaya.com> Date: Sun, 25 Jan 2015 12:57:25 -0500 Message-ID: <1a7d01d038c8$61a592c0$24f0b840$@pollere.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMfoVpv030Xv9bs/DTN5K+i94Y/rQKmsT6UAfGwU4yaDYjBsA== Content-Language: en-us Archived-At: Subject: Re: [lmap] New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 17:57:31 -0000 Hello, Thank you for putting this document together. Definitely gets one thinking about these issues and think this will be a very insightful and helpful document. Some questions and comments below. Thanks, -Joan Specific Comments: Section 2.0 Would it be possible to include a list of protocols that currently meet these criteria? Not necessarily an inclusive list, but something like: Although this is not an complete list, examples of protocols that meet these criteria are:...then list a few examples? Section 2.1 The sentence which starts: "Note that although..." is confusing to me. It seems to be saying, follow these criteria, but if it is not in the protocol, that's okay. Is this what is meant? CP-MUST-1 and CP-MUST-2, suggest saying "securely established", instead of just "established". The word "must" is used, and so was wondering if this is "MUST" as outlined in section 1.1 (using key words)? Section 2.2 Same comment as above with regard to the sentence that starts "Note that although..." Some of these CP-DIFF list items seem to be information that the protocol needs to make available to the operator (CP-DIFF-1, CP-DIFF-2, CP-DIFF-5). Maybe these items (data) should be a sub-category? (Would some consideration about rate limit be appropriate?) CP-DIFF-8 If possible, could examples be given? CP-DIFF-11 Would like to see this mandatory. To ask a related question is there a benefit from not having version number? If so, what is that benefit? CP-DIFF-12 is a subquestion of CP-DIFF-11. Could the be combined with CP-DIFF-11? My understanding is that these protocols are standardized (or on the standards track), doesn't the standards process provide a requirement for versioning? Is that adequate for protocol numbering or is something else wanted by LMAP? Section 3.1 RP-MUST-1 and RP-MUST-2 Is this "must" or "MUST" as outlined in the key words section? RP-DIFF-4 Personally, would like to see compression mandatory depending on the amount of data. RP-DIFF-5 Is this a MUST? ( as in MUST specify the bytes of overhead required...) RP-DIFF-6 What determines "widely used"? I am not certain that I see this as a criterion. While maybe a focus initially, do not think this needs to be a criterion long-term (just my opinion) but yes, I think that LMAP would like to focus on protocols that are widely used initially. RP-DIFF-7 Who determines interoperability? Are folks envisioning independent interoperability testing? RP-DIFF-10 and RP-DIFF-11 same comments as for the CP-DIFF-11 and CP-DIFF-12 above. -- > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) > Sent: Thursday, January 15, 2015 11:13 AM > To: STARK, BARBARA H; lmap@ietf.org > Subject: Re: [lmap] New Version Notification for draft-starkcarey-lmap- > protocol-criteria-00.txt > > Thanks, Barbara and Tim! > > All WG participants - please read and comment. Remember that this > document aims to be a reference and help tool in the protocols selection > process. > > Regards, > > Dan > > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA > > H > > Sent: Thursday, January 15, 2015 4:57 PM > > To: lmap@ietf.org > > Subject: [lmap] FW: New Version Notification for > > draft-starkcarey-lmap- protocol-criteria-00.txt > > > > This is the draft that Tim Carey and I put together for LMAP protocol > > selection criteria. It is taken from the slides we presented on the > > December teleconference, with a few changes based on the discussion > during that call. > > Barbara > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Thursday, January 15, 2015 8:46 AM > > To: STARK, BARBARA H; STARK, BARBARA H > > Subject: New Version Notification for draft-starkcarey-lmap-protocol- > > criteria-00.txt > > > > > > A new version of I-D, draft-starkcarey-lmap-protocol-criteria-00.txt > > has been successfully submitted by Barbara Stark and posted to the > > IETF repository. > > > > Name: draft-starkcarey-lmap-protocol-criteria > > Revision: 00 > > Title: LMAP Protocol Selection Criteria > > Document date: 2015-01-15 > > Group: Individual Submission > > Pages: 6 > > URL: https://urldefense.proofpoint.com/v2/url?u=http- > > 3A__www.ietf.org_internet-2Ddrafts_draft-2Dstarkcarey-2Dlmap- > > 2Dprotocol-2Dcriteria- > > > 2D00.txt&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQ > > > zvlsiLQfucBXRucPvdrphpBsFA&m=XIN9C1RI85JcLlc_HK4JmbtSpeNxLXsPfKInZ > > 3TM5DE&s=iICyiTfARFWNLQ0nYcKm8ZPu566aGDwcFFnLgS_IG64&e= > > Status: https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__datatracker.ietf.org_doc_draft-2Dstarkcarey-2Dlmap-2Dprotocol- > > > 2Dcriteria_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJ > > > fQzvlsiLQfucBXRucPvdrphpBsFA&m=XIN9C1RI85JcLlc_HK4JmbtSpeNxLXsPfKI > > nZ3TM5DE&s=2gt4tnmgmwjx4-w3530xDA0goc1qR8bCfyBfR2e8lbw&e= > > Htmlized: https://urldefense.proofpoint.com/v2/url?u=http- > > 3A__tools.ietf.org_html_draft-2Dstarkcarey-2Dlmap-2Dprotocol-2Dcriteri > > a- > 2D00&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvls > > > iLQfucBXRucPvdrphpBsFA&m=XIN9C1RI85JcLlc_HK4JmbtSpeNxLXsPfKInZ3T > > M5DE&s=V31dBlNm5qEW5oYktaORSpaT_-hXOvAf8uyD4S1KJLU&e= > > > > > > Abstract: > > This draft identifies criteria to be used in evaluating and selecting > > Control and Reporting Protocols described by > > [I-D.ietf-lmap-framework]. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https- > > > 3A__www.ietf.org_mailman_listinfo_lmap&d=AwICAg&c=BFpWQw8bsuKpl > > > 1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=XIN9C1 > > > RI85JcLlc_HK4JmbtSpeNxLXsPfKInZ3TM5DE&s=EIGzvXolZ7jKxm1NoOMSbML > > AFc0FaDbViOExWfdxwNU&e= > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Jan 26 02:32:06 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD4E1A88A8 for ; Mon, 26 Jan 2015 02:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZU-tpIbFAZC for ; Mon, 26 Jan 2015 02:32:03 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F8E1A8897 for ; Mon, 26 Jan 2015 02:32:03 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E326B1032 for ; Mon, 26 Jan 2015 11:32:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id VLpH9SZ14JmI for ; Mon, 26 Jan 2015 11:31:59 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 26 Jan 2015 11:32:00 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E06C20037 for ; Mon, 26 Jan 2015 11:32:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vAeOoP7W5WFK for ; Mon, 26 Jan 2015 11:31:58 +0100 (CET) Received: from exchange.jacobs-university.de (shubcas01.jacobs.jacobs-university.de [10.70.0.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id BC3F220036 for ; Mon, 26 Jan 2015 11:31:58 +0100 (CET) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS01.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0224.002; Mon, 26 Jan 2015 11:31:58 +0100 From: "Bajpai, Vaibhav" To: "" Thread-Topic: review: draft-ietf-lmap-information-model-03 Thread-Index: AQHQOVNPzEgvcMa2FkS5D7o5TWD65w== Date: Mon, 26 Jan 2015 10:31:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.50.203.30] Content-Type: multipart/signed; boundary="Apple-Mail=_8CF5928B-17A8-476D-BEB1-2195C1BD0CC8"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: "Bajpai, Vaibhav" Subject: [lmap] review: draft-ietf-lmap-information-model-03 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 10:32:05 -0000 --Apple-Mail=_8CF5928B-17A8-476D-BEB1-2195C1BD0CC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii LMAP, > On 23 Jan 2015, at 17:33, Juergen Schoenwaelder = wrote: >=20 > we have updated the YANG data model in order to align it with the > latest update of the information model. A couple of questions came up > during the process, which we will post in a separate message. We also > added an instance document in XML and the same rendered in JSON. Both > have been validated against the YANG data model using the pyang > toolchain. Below is our review of the information model -03: Capability and Status Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > datetime ma-last-task; > datetime ma-last-report; > datetime ma-last-instruction; > datetime ma-last-configuration; The semantics of ma-last-* is unclear. 'Last' means last executed or = last succeessfuly completed? Additionally, how does the LMAP implementation = know whether task X is a measurement task, a reporting task, et al.? If not = how would the implementation fill in the datetime fields. In the YANG data model [1], we have added 'last-execution' (to all known tasks) and it records the last invocation of the task (but it should = really be a pair 'last-invocation' and 'last-completion'. But the point here is to report this for each tasks instead of a grouping of tasks by function. Condition Codes ~~~~~~~~~~~~~~~ > [ma-condition-obj ma-conditions<0..*>;] > object { > string ma-condition-code; > string ma-condition-text; > } ma-condition-obj This is a list of condition codes. Each condition code in this list = needs to associate to a task. How do we make the association? In the YANG data model [1], we have added 'last-failed-execution' (to = all known tasks) and it records the last failed execution together with a = status code and a status message. This makes sure that a subsequent successful execution is not removing the error code and message. We also believe = that (at least in the data model) we need to define a set of suitable status = codes in order to be interoperable. Reporting ~~~~~~~~~ > object { > string ma-report-task-name; > [uri ma-report-task-registry-entry;] > [name-value-pair ma-report-scheduled-task-options<0..*>]; > [string ma-report-task-cycle-id;] > string ma-report-task-column-labels<0..*>; > ma-result-row-obj ma-report-task-rows<0..*>; > } ma-report-task-obj; How about introducing a configuration version number? This will remove = remove the need to send entire task configuration as part of the report, since = only config version numbers would need to be matched. Schedules ~~~~~~~~~ > object { > string ma-schedule-task-name; > [name-value-pair ma-schedule-task-options<0..*>]; > [ma-sched-downstream-tasks-obj = ma-schedule-destination-tasks<0..*>;] > } ma-sched-task-obj; a) Task options are now part of both schedule and task configurations (Thanks!). However, it's unclear whether schedule options are = prepended or appended to the task options. We think schedule options should be = appended to the task options because schedules are more frequently updated than = task configurations. In the YANG data model [1], we have specified that options are = appended. b) Task and downstream relationship is not clear. Is it: $ a | b (a streaming data to b) (or) $ a ; b (b running after a is completed) In case of the latter, does the destination task wait for the = upstream task to be completed? For example, with an upstream task sending = results to a reporter, is the reporter blocking until there is data from the upstream task? The behavior is not currently defined in the = document. The behavior of ^ relationship is unclear, when for example a = periodic scheduled task forwards data to an immediate schedule report (or an immediate forwards to another immediate). In such cases, what would immediate mean if a task consumes data from another task? c) Let's not introduce a new 'name-value-pair' type. Instead it would = be better to refer to an options object which has a name and a value = elements. > object { > [string ma-schedule-task-destination-schedule-name]; > [string = ma-schedule-task-destination-task-configuration-name]; > [int ma-schedule-task-output-selection<0..*>;] // = default: all > } ma-sched-destination-tasks-obj; The notion of an upstream task being able to direct outputs with = different file descriptions to different destination tasks (which themselves are referred to by a schedule name) was challenging to grasp from the ^ = snippet. Perhaps more description on this would be nice. > Measurement Task > Output 1 -----+----> "Hourly Schedule":"Hourly Reporting Task" > Output 2 ----/ In the ^ example, how do we decide the the order of directing results = into the hourly reporting task? References ~~~~~~~~~~ > [I-D.ietf-lmap-framework] > Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., > Aitken, P., and A. Akhter, "A framework for large-scale > measurement platforms (LMAP)", draft-ietf-lmap- > framework-03 (work in progress), January 2014. Needs an update. > [I-D.bagnulo-ippm-new-registry] > Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., = and > A. Morton, "A registry for commonly used metrics", = draft- > bagnulo-ippm-new-registry-01 (work in progress), July > 2013. Needs an update. JSON Data Model Example ~~~~~~~~~~~~~~~~~~~~~~~ As part of the YANG data model definition [1], we now provide both a XML = and a JSON encoded example for reference. The example is validated against = the YANG data model definition. Can we remove the JSON example from this = document? [1] http://tools.ietf.org/html/draft-schoenw-lmap-yang-02 Editorial Comments: ~~~~~~~~~~~~~~~~~~~ A lot of new spelling errors were spotted when examining the diff. [1] http://tools.ietf.org/html/draft-schoenw-lmap-yang-02 Best, Vaibhav =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Vaibhav Bajpai Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --Apple-Mail=_8CF5928B-17A8-476D-BEB1-2195C1BD0CC8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUxhedAAoJEHR3XKwTWKOZjWIH/ird8FHKdbaoAUwXcd99nFKH AP7Whg3lUnhvfAhrpYm56PU+XhoXBLK6RfkpEEhxAM9WphI33BQOwBJshipbLR8y 5Vx80fX6oGYLms3V/JtqYvBzmk+LyQV0YFRqgv8eDic4noxyaT6BgKR9U8YSj4bn 54pCHKilfWpH0zTuVhnbOJpO2ECW0Lr4r+VrmR5MlbfRshrCOATa55pxyd+zVjI8 S7/3uEBMwaKbSJgxodVFnHRT/Q79ExOAJJuVm3nuyQIHn2T5vIj3JgCWMQGN3Ty7 rngDs9qLlXGoWnWIXMz/RAn7GCVy0IKfsUDw7gfXKTZDAu8H1XNsL41UiBMt+pc= =GMRw -----END PGP SIGNATURE----- --Apple-Mail=_8CF5928B-17A8-476D-BEB1-2195C1BD0CC8-- From nobody Mon Jan 26 02:37:59 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446A71A88B4 for ; Mon, 26 Jan 2015 02:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYEKZ7-eLh3m for ; Mon, 26 Jan 2015 02:37:54 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33DAB1A8897 for ; Mon, 26 Jan 2015 02:37:54 -0800 (PST) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 26 Jan 2015 10:37:58 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.224]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Mon, 26 Jan 2015 10:37:35 +0000 From: To: , Date: Mon, 26 Jan 2015 10:37:34 +0000 Thread-Topic: review: draft-ietf-lmap-information-model-03 Thread-Index: AQHQOVNPzEgvcMa2FkS5D7o5TWD655zSNSOw Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] review: draft-ietf-lmap-information-model-03 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 10:37:57 -0000 Thanks Vaibhav, I'll pick these up during the interim discussion and get the agreed changes= in for the 04 edit. Trevor. >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bajpai, Vaibhav >Sent: 26 January 2015 10:32 >To: >Cc: Bajpai, Vaibhav >Subject: [lmap] review: draft-ietf-lmap-information-model-03 > >LMAP, > >> On 23 Jan 2015, at 17:33, Juergen Schoenwaelder university.de> wrote: >> >> we have updated the YANG data model in order to align it with the >> latest update of the information model. A couple of questions came up >> during the process, which we will post in a separate message. We also >> added an instance document in XML and the same rendered in JSON. Both >> have been validated against the YANG data model using the pyang >> toolchain. > >Below is our review of the information model -03: > > > >Capability and Status Information >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > datetime ma-last-task; > > datetime ma-last-report; > > datetime ma-last-instruction; > > datetime ma-last-configuration; > >The semantics of ma-last-* is unclear. 'Last' means last executed or last >succeessfuly completed? Additionally, how does the LMAP implementation kno= w >whether task X is a measurement task, a reporting task, et al.? If not how= would >the implementation fill in the datetime fields. > >In the YANG data model [1], we have added 'last-execution' (to all known >tasks) and it records the last invocation of the task (but it should reall= y be a pair >'last-invocation' and 'last-completion'. But the point here is to report t= his for each >tasks instead of a grouping of tasks by function. > > > >Condition Codes >~~~~~~~~~~~~~~~ > > > [ma-condition-obj ma-conditions<0..*>;] > > > object { > > string ma-condition-code; > > string ma-condition-text; > > } ma-condition-obj > >This is a list of condition codes. Each condition code in this list needs= to associate >to a task. How do we make the association? > >In the YANG data model [1], we have added 'last-failed-execution' (to all = known >tasks) and it records the last failed execution together with a status cod= e and a >status message. This makes sure that a subsequent successful execution is = not >removing the error code and message. We also believe that (at least in the= data >model) we need to define a set of suitable status codes in order to be >interoperable. > > > >Reporting >~~~~~~~~~ > > > object { > > string ma-report-task-name; > > [uri ma-report-task-registry-entry;] > > [name-value-pair ma-report-scheduled-task-options<0..*>]; > > [string ma-report-task-cycle-id;] > > string ma-report-task-column-labels<0..*>; > > ma-result-row-obj ma-report-task-rows<0..*>; > > } ma-report-task-obj; > >How about introducing a configuration version number? This will remove re= move >the need to send entire task configuration as part of the report, since on= ly config >version numbers would need to be matched. > > > >Schedules >~~~~~~~~~ > > > object { > > string ma-schedule-task-name; > > [name-value-pair ma-schedule-task-options<0..*>]; > > [ma-sched-downstream-tasks-obj ma-schedule-destination-tasks<0..*>= ;] > > } ma-sched-task-obj; > > > a) Task options are now part of both schedule and task configurations > (Thanks!). However, it's unclear whether schedule options are prepended = or > appended to the task options. We think schedule options should be append= ed to > the task options because schedules are more frequently updated than task > configurations. > > In the YANG data model [1], we have specified that options are appended. > > > b) Task and downstream relationship is not clear. Is it: > > $ a | b (a streaming data to b) (or) > $ a ; b (b running after a is completed) > > In case of the latter, does the destination task wait for the upstream > task to be completed? For example, with an upstream task sending resul= ts > to a reporter, is the reporter blocking until there is data from the > upstream task? The behavior is not currently defined in the document. > > The behavior of ^ relationship is unclear, when for example a periodic > scheduled task forwards data to an immediate schedule report (or an > immediate forwards to another immediate). In such cases, what would > immediate mean if a task consumes data from another task? > > > > c) Let's not introduce a new 'name-value-pair' type. Instead it would be > better to refer to an options object which has a name and a value elemen= ts. > > > > object { > > [string ma-schedule-task-destination-schedule-name]; > > [string ma-schedule-task-destination-task-configuration-name]; > > [int ma-schedule-task-output-selection<0..*>;] // default:= all > > } ma-sched-destination-tasks-obj; > >The notion of an upstream task being able to direct outputs with different= file >descriptions to different destination tasks (which themselves are referred= to by a >schedule name) was challenging to grasp from the ^ snippet. >Perhaps more description on this would be nice. > > > Measurement Task > > Output 1 -----+----> "Hourly Schedule":"Hourly Reporting Task" > > Output 2 ----/ > >In the ^ example, how do we decide the the order of directing results into= the >hourly reporting task? > > > > >References >~~~~~~~~~~ > > > [I-D.ietf-lmap-framework] > > Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., > > Aitken, P., and A. Akhter, "A framework for large-scale > > measurement platforms (LMAP)", draft-ietf-lmap- > > framework-03 (work in progress), January 2014. > >Needs an update. > > > [I-D.bagnulo-ippm-new-registry] > > Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and > > A. Morton, "A registry for commonly used metrics", draft- > > bagnulo-ippm-new-registry-01 (work in progress), July > > 2013. > >Needs an update. > > > > >JSON Data Model Example >~~~~~~~~~~~~~~~~~~~~~~~ > >As part of the YANG data model definition [1], we now provide both a XML a= nd a >JSON encoded example for reference. The example is validated against the Y= ANG >data model definition. Can we remove the JSON example from this document? > >[1] http://tools.ietf.org/html/draft-schoenw-lmap-yang-02 > > > >Editorial Comments: >~~~~~~~~~~~~~~~~~~~ > >A lot of new spelling errors were spotted when examining the diff. > > >[1] http://tools.ietf.org/html/draft-schoenw-lmap-yang-02 > > >Best, Vaibhav > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >Vaibhav Bajpai > >Research I, Room 91 >Computer Networks and Distributed Systems (CNDS) Lab School of Engineering >and Sciences Jacobs University Bremen, Germany > >www.vaibhavbajpai.com >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D From nobody Tue Jan 27 07:49:34 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1871A891A for ; Tue, 27 Jan 2015 07:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5Ee0K-aVLBa for ; Tue, 27 Jan 2015 07:49:19 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E18D1A88AD for ; Tue, 27 Jan 2015 07:46:01 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 9b2b7c45.2aedf220f940.5314111.00-2445.14833421.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 27 Jan 2015 15:46:01 +0000 (UTC) X-MXL-Hash: 54c7b2b90e6a13a2-0e209101e7662316aca5f991640e18a868c8eded Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 3b2b7c45.0.5314022.00-2164.14833126.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 27 Jan 2015 15:45:57 +0000 (UTC) X-MXL-Hash: 54c7b2b516245d8a-149a7530ba6d851ecd4d5240bd94e922092a9306 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0RFjt2G024901; Tue, 27 Jan 2015 10:45:55 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0RFjoH9024831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Jan 2015 10:45:53 -0500 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi133.aldc.att.com (RSA Interceptor); Tue, 27 Jan 2015 15:45:37 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.10]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0195.001; Tue, 27 Jan 2015 10:45:37 -0500 From: "STARK, BARBARA H" To: Joan Luciani , "'Romascanu, Dan (Dan)'" , "lmap@ietf.org" Thread-Topic: [lmap] New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt Thread-Index: AQHQMMmRHuSVv7mMnEmea+HAnj8NKZzBRO0QgAAVUSCAECjAgIACl/eg Date: Tue, 27 Jan 2015 15:45:36 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130F03BAC@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20150115134538.6095.77506.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E61130EEB6B8@GAALPA1MSGUSRBF.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C96ADA5@AZ-FFEXMB04.global.avaya.com> <1a7d01d038c8$61a592c0$24f0b840$@pollere.net> In-Reply-To: <1a7d01d038c8$61a592c0$24f0b840$@pollere.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.46.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=BpYqN/r5 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=5O8u3lYahuoA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=YNv0rlydsVwA:10 a=wAG2Ez88W] X-AnalysisOut: [_fF1JdPot4A:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [lmap] New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 15:49:26 -0000 Thanks for the comments. Replies in-line. Barbara > Section 2.0 > Would it be possible to include a list of protocols that currently meet > these criteria? Not necessarily an inclusive list, but something like: > Although this is not an complete list, examples of protocols that meet th= ese > criteria are:...then list a few examples? I believe the idea is that other people in the WG will propose protocols th= at they believe meet the mandatory criteria and that do a good job with the= comparative criteria. The WG would then focus itself on assessing just tho= se protocols. I believe it would be inappropriate for the two of us who ini= tially created this list of criteria to try to provide examples of protocol= s, unless we are actually proposing those protocols for LMAP consideration.= There has been a call for protocol proposals into LMAP. This draft is inte= nded purely as a list of criteria for evaluating whatever protocols are pro= posed. Effort spent discussing and evaluating whether and how well some pro= tocol satisfies the criteria would be a waste of effort (IMO) if that proto= col is not being proposed by someone for consideration. > Section 2.1 > The sentence which starts: "Note that although..." is confusing to me. = It > seems to be saying, follow these criteria, but if it is not in > the protocol, that's okay. Is this what is meant? ... > Section 2.2 Same comment as above with regard to the sentence that start= s > "Note that although..." No. The protocol (that LMAP WG selects) MUST define how the criterion is ac= hieved in the context of that protocol. It is not required that the protoco= l mandate that all implementations do it. It would be possible for LMAP (if= LMAP selected the protocol) to mandate that LMAP implementations do it (or= do it in certain cases). > CP-MUST-1 and CP-MUST-2, suggest saying "securely established", instead > of just "established". The word "must" is used, and so was wondering if = this > is "MUST" as outlined in section 1.1 (using key words)? Yes, I need to capitalize all such normative language in the next revision.= Thx. =20 > Some of these CP-DIFF list items seem to be information that the protocol > needs to make available to the operator (CP-DIFF-1, CP-DIFF-2, CP-DIFF-5= ). > Maybe these items (data) should be a sub-category? =20 This list of criteria is not intended for operator use. It is intended for = use by the LMAP WG in assessing and comparing protocols submitted to LMAP W= G for consideration as the LMAP WG selected and recommended protocol. Some = operators may choose not to make use of the protocol recommended by LMAP WG= . If that is the case, then those operators will have their own set of eval= uation criteria and methodology for evaluating. I do not believe that helpi= ng operators do their own evaluation is in scope of LMAP WG. I do not belie= ve there is any intention of this draft ever achieving RFC status. It is fo= r internal WG use only. If there are criteria listed that are not appropria= te for WG use in protocol assessment, then these criteria need to be remove= d. > (Would some consideration about rate limit be appropriate?) It may indeed be appropriate. What do others think? Would anyone care to pr= opose a criterion around rate limiting? =20 > CP-DIFF-8 If possible, could examples be given? Yes. If others think it is useful, I could include a list of examples, such= as "(e.g., test tools, plugfests, certification programs, reference implem= entations)". =20 > CP-DIFF-11 Would like to see this mandatory. To ask a related question = is > there a benefit from not having version number? If so, what is that bene= fit? > > CP-DIFF-12 is a subquestion of CP-DIFF-11. Could the be combined with CP= - > DIFF-11? My understanding is that these protocols are standardized (or o= n > the standards track), doesn't the standards process provide a requirement > for versioning? Is that adequate for protocol numbering or is something e= lse > wanted by LMAP? What do others think? I have no strong opinion. > Section 3.1 > RP-MUST-1 and RP-MUST-2 Is this "must" or "MUST" as outlined in the key > words section? Yes, I need to capitalize all such normative language in the next revision.= Thx. =20 > RP-DIFF-4 Personally, would like to see compression mandatory depending > on the amount of data. What do others think? I have no strong opinion. =20 > RP-DIFF-5 Is this a MUST? ( as in MUST specify the bytes of overhead > required...) >=20 > RP-DIFF-6 What determines "widely used"? I am not certain that I see thi= s as > a criterion. While maybe a focus initially, do not think this needs to be= a > criterion long-term (just my opinion) but yes, I think that LMAP would li= ke to > focus on protocols that are widely used initially. LMAP WG needs to determine "widely used" when it compares different protoco= l proposals in the very near future. How much weight LMAP wishes to give th= is criterion is up to LMAP. These criteria are not expected to be long-term= , as they are not expected to be maintained once LMAP has made its near-fut= ure protocol selection. =20 > RP-DIFF-7 Who determines interoperability? Are folks envisioning > independent interoperability testing? I can provide the same list of examples as I suggested for the Controller p= rotocol: "(e.g., test tools, plugfests, certification programs, reference i= mplementations)". LMAP WG would need to decide whether it is likely that im= plementations of a protocol will be interoperable, based on the available m= echanisms (and any known history regarding interoperability). Since these c= riteria are strictly for use by LMAP WG in its near-future protocol selecti= on exercise, LMAP WG will make all determinations for proposed protocols. A= ll are welcome to participate in LMAP WG to help make these determinations. =20 > RP-DIFF-10 and RP-DIFF-11 same comments as for the CP-DIFF-11 and > CP-DIFF-12 above. What do others think? I have no strong opinion. From nobody Wed Jan 28 10:58:12 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737E41A1AB1 for ; Wed, 28 Jan 2015 10:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1Uc2n6BPRFc for ; Wed, 28 Jan 2015 10:58:08 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB9A1A19FE for ; Wed, 28 Jan 2015 10:58:07 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 6FF4C61B7A3EB; Wed, 28 Jan 2015 18:58:01 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t0SIw3ls014546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Jan 2015 13:58:03 -0500 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.185]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 13:58:03 -0500 From: "Carey, Timothy (Timothy)" To: "STARK, BARBARA H" , Joan Luciani , "'Romascanu, Dan (Dan)'" , "lmap@ietf.org" Thread-Topic: [lmap] New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt Thread-Index: AQHQOmwm4ZStqmHqx0eMyz5wt+FQcJzV3ATg Date: Wed, 28 Jan 2015 18:58:03 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77350183C3@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20150115134538.6095.77506.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E61130EEB6B8@GAALPA1MSGUSRBF.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C96ADA5@AZ-FFEXMB04.global.avaya.com> <1a7d01d038c8$61a592c0$24f0b840$@pollere.net> <2D09D61DDFA73D4C884805CC7865E61130F03BAC@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130F03BAC@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] New Version Notification for draft-starkcarey-lmap-protocol-criteria-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 18:58:10 -0000 Joan and Barbara, My comments to Barbara's inline BR, Tim -----Original Message----- From: STARK, BARBARA H [mailto:bs7652@att.com]=20 Sent: Tuesday, January 27, 2015 9:46 AM To: Joan Luciani; 'Romascanu, Dan (Dan)'; lmap@ietf.org Subject: Re: [lmap] New Version Notification for draft-starkcarey-lmap-prot= ocol-criteria-00.txt Thanks for the comments. Replies in-line. Barbara > Section 2.0 > Would it be possible to include a list of protocols that currently meet > these criteria? Not necessarily an inclusive list, but something like: > Although this is not an complete list, examples of protocols that meet=20 > these criteria are:...then list a few examples? I believe the idea is that other people in the WG will propose protocols th= at they believe meet the mandatory criteria and that do a good job with the= comparative criteria. The WG would then focus itself on assessing just tho= se protocols. I believe it would be inappropriate for the two of us who ini= tially created this list of criteria to try to provide examples of protocol= s, unless we are actually proposing those protocols for LMAP consideration.= There has been a call for protocol proposals into LMAP. This draft is inte= nded purely as a list of criteria for evaluating whatever protocols are pro= posed. Effort spent discussing and evaluating whether and how well some pro= tocol satisfies the criteria would be a waste of effort (IMO) if that proto= col is not being proposed by someone for consideration. > Section 2.1 > The sentence which starts: "Note that although..." is confusing to=20 > me. It seems to be saying, follow these criteria, but if it is not in > the protocol, that's okay. Is this what is meant? ... > Section 2.2 Same comment as above with regard to the sentence that=20 > starts "Note that although..." No. The protocol (that LMAP WG selects) MUST define how the criterion is ac= hieved in the context of that protocol. It is not required that the protoco= l mandate that all implementations do it. It would be possible for LMAP (if= LMAP selected the protocol) to mandate that LMAP implementations do it (or= do it in certain cases). > CP-MUST-1 and CP-MUST-2, suggest saying "securely established",=20 > instead of just "established". The word "must" is used, and so was=20 > wondering if this is "MUST" as outlined in section 1.1 (using key words)? Yes, I need to capitalize all such normative language in the next revision.= Thx. Actually we saw CP-MUST-3 as providing the "secure" session. What we = want to make sure of is that a secure session capability is possible but ag= ain we would let LMAP WG determine if a implementation is mandated to use a= secure session through some normative text in the Framework, IM or Protoco= ls drafts. =20 > Some of these CP-DIFF list items seem to be information that the=20 > protocol needs to make available to the operator (CP-DIFF-1, CP-DIFF-2, = CP-DIFF-5). > Maybe these items (data) should be a sub-category? =20 This list of criteria is not intended for operator use. It is intended for = use by the LMAP WG in assessing and comparing protocols submitted to LMAP W= G for consideration as the LMAP WG selected and recommended protocol. Some = operators may choose not to make use of the protocol recommended by LMAP WG= . If that is the case, then those operators will have their own set of eval= uation criteria and methodology for evaluating. I do not believe that helpi= ng operators do their own evaluation is in scope of LMAP WG. I do not belie= ve there is any intention of this draft ever achieving RFC status. It is fo= r internal WG use only. If there are criteria listed that are not appropria= te for WG use in protocol assessment, then these criteria need to be remove= d. > (Would some consideration about rate limit be appropriate?) It may indeed be appropriate. What do others think? Would anyone care to pr= opose a criterion around rate limiting? Yes I can see asking if there are inherent rate limiting (throttling)= capabilities in a protocol for comparative purposes. The actual requiremen= ts for what is means to rate limit would have to be developed in the protoc= ol draft. My guess is that this feature would be something that needs added= -onto any specific base protocol but you never know. =20 > CP-DIFF-8 If possible, could examples be given? Yes. If others think it is useful, I could include a list of examples, such= as "(e.g., test tools, plugfests, certification programs, reference implem= entations)". I would think examples are useful - the examples seem to clarify by w= hat we meant by interoperable. =20 > CP-DIFF-11 Would like to see this mandatory. To ask a related=20 > question is there a benefit from not having version number? If so, what = is that benefit? > > CP-DIFF-12 is a subquestion of CP-DIFF-11. Could the be combined with=20 > CP- DIFF-11? My understanding is that these protocols are=20 > standardized (or on the standards track), doesn't the standards=20 > process provide a requirement for versioning? Is that adequate for=20 > protocol numbering or is something else wanted by LMAP? What do others think? I have no strong opinion. Hmmm - if we are saying a protocol will not be considered for selecti= on if it does not handle elements with different versions - then yes we nee= d to make this mandatory. Frankly I would elevate this to a requirement. On CP-DIFF-12 - Versioning and Extensibility are 2 separate things. I= might be able to live with a protocol that doesn't provide a mechanism for= vendor extension but I couldn't live with a protocol that didn't allow for= different versions. > Section 3.1 > RP-MUST-1 and RP-MUST-2 Is this "must" or "MUST" as outlined in the=20 > key words section? Yes, I need to capitalize all such normative language in the next revision.= Thx. =20 > RP-DIFF-4 Personally, would like to see compression mandatory=20 > depending on the amount of data. What do others think? I have no strong opinion. Again this is more of a requirement that would need to be placed on a= protocol; like versioning. We aren't creating requirements for a protocol = but for comparing and selecting protocols. So again if we are saying we wil= l not select a protocol that doesn't provide a compression capability then = it should be a requirement not a comparative criteria. I don't think compre= ssion elevates to that "status". It is important though. =20 > RP-DIFF-5 Is this a MUST? ( as in MUST specify the bytes of overhead > required...) >=20 > RP-DIFF-6 What determines "widely used"? I am not certain that I see=20 > this as a criterion. While maybe a focus initially, do not think this=20 > needs to be a criterion long-term (just my opinion) but yes, I think=20 > that LMAP would like to focus on protocols that are widely used initially= . LMAP WG needs to determine "widely used" when it compares different protoco= l proposals in the very near future. How much weight LMAP wishes to give th= is criterion is up to LMAP. These criteria are not expected to be long-term= , as they are not expected to be maintained once LMAP has made its near-fut= ure protocol selection. =20 > RP-DIFF-7 Who determines interoperability? Are folks envisioning=20 > independent interoperability testing? I can provide the same list of examples as I suggested for the Controller p= rotocol: "(e.g., test tools, plugfests, certification programs, reference i= mplementations)". LMAP WG would need to decide whether it is likely that im= plementations of a protocol will be interoperable, based on the available m= echanisms (and any known history regarding interoperability). Since these c= riteria are strictly for use by LMAP WG in its near-future protocol selecti= on exercise, LMAP WG will make all determinations for proposed protocols. A= ll are welcome to participate in LMAP WG to help make these determinations. =20 > RP-DIFF-10 and RP-DIFF-11 same comments as for the CP-DIFF-11 and > CP-DIFF-12 above. What do others think? I have no strong opinion. I would think versioning is a requirement; extensibility is comparati= ve.