From nobody Tue Dec 2 00:50:59 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF591A02BE for ; Tue, 2 Dec 2014 00:50:58 -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 2YlYUsLWACTp for ; Tue, 2 Dec 2014 00:50:57 -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 CD1841A0377 for ; Tue, 2 Dec 2014 00:50:55 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9D45B1013; Tue, 2 Dec 2014 09:50:54 +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 cENuOGaKxszI; Tue, 2 Dec 2014 09:50:47 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 2 Dec 2014 09:50:54 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E482D2002C; Tue, 2 Dec 2014 09:50:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RmA6NU7PP5B3; Tue, 2 Dec 2014 09:50:52 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 699B520017; Tue, 2 Dec 2014 09:50:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 53EB52FE756D; Tue, 2 Dec 2014 09:50:52 +0100 (CET) Date: Tue, 2 Dec 2014 09:50:52 +0100 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20141202085052.GD23117@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, lmap@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/0fKg8cjdfYje7gLzZ51ljFCa77g Cc: lmap@ietf.org Subject: Re: [lmap] Information Model proposed changes for version 03 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 08:50:58 -0000 On Thu, Nov 20, 2014 at 05:25:21PM +0000, trevor.burbridge@bt.com wrote: > For anyone not at the LMAP session in Honolulu, please see the proposed changes that were suggested to the LMAP Information Model: > http://www.ietf.org/proceedings/91/slides/slides-91-lmap-1.pptx > > If I do not hear any objections I will start to implement the changes and issue version 03. > - Slide #5: I guess I will have to accept this. It would be nice though if the models (and in particular the data models) allow implementations to augment the base models with information about queues. - Slide #6: My proposal was to consider the parameters an ordered set and to add parameters by prepending or appending. Overriding does not make much sense to me (overriding assumes every parameter can only appear once which is so far not required). - Slide #7: OK - Slide #8: OK - Slide #9: OK - Slide #10: I do not understand the second bullet. Why do we have to spell out separate pre-configuration for factory reset? - Slide #11: I prefer to remove the JSON examples since it will be very irritating if LMAP protocols / data models will deviate from them. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Dec 2 06:19:04 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A77D1A1B3D for ; Tue, 2 Dec 2014 06:18: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 VFNjiVM1VUMr for ; Tue, 2 Dec 2014 06:18:42 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009A81A1B80 for ; Tue, 2 Dec 2014 06:18:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0GAG3JfVSHCzIm/2dsb2JhbABbgkMhIyIwWgOzUQEBAQEBAQaTCRsBCYYfAoEeFgEBAQEBAXyEBAEBAxIbXgEMCRVWJgEEGwEZiB4BDK8+hHihWIYziguCbA9EIoEfBZBhjFGDOIMIEY0kg3uCNYEBAQEB X-IronPort-AV: E=Sophos; i="5.07,501,1413259200"; d="scan'208,217"; a="82826324" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Dec 2014 09:18:38 -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; 02 Dec 2014 09:18:37 -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, 2 Dec 2014 15:18:35 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: IETF-91 draft minutes Thread-Index: AdAOOttDh2E926xCTl2/T27gK3n0eQ== Date: Tue, 2 Dec 2014 14:18:34 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C917F20@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C917F20AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/6r2MVlBdwfLSN0wfOnYEKzRj-WU Subject: [lmap] IETF-91 draft minutes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 14:18:50 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C917F20AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft minutes of the LMAP WG meeting at IETF-91 are now available at ht= tp://www.ietf.org/proceedings/91/minutes/minutes-91-lmap. Thanks to Barbara Stark and Marius Georgescu for taking the meeting notes. = This is an important task and their contribution is highly appreciated. Please read and let me know if we missed anything or something was caught w= rong. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C917F20AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft minutes of the LMAP WG meeting at IETF-91 = are now available at http= ://www.ietf.org/proceedings/91/minutes/minutes-91-lmap.

 

Thanks to Barbara Stark and Marius Georgescu for tak= ing the meeting notes. This is an important task and their contribution is = highly appreciated.

 

Please read and let me know if we missed anything or= something was caught wrong.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C917F20AZFFEXMB04globa_-- From nobody Tue Dec 2 10:23:15 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA32D1A2119 for ; Tue, 2 Dec 2014 10:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 E6tngPfpv5eq for ; Tue, 2 Dec 2014 10:23:09 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53E71A1AA7 for ; Tue, 2 Dec 2014 10:23:08 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id r20so30867188wiv.0 for ; Tue, 02 Dec 2014 10:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1L86t615lyiOlc7zO7hPRDBdSKDdapmHlGb9DTU/w7w=; b=E47nKw8IHCStcaa757duo/Qw8O2XpzOrCFEiIVBWbsSOUmA5vPPGA+VB3FFIgbsJsn TzeL58LXUCTPdq3Prao8tjG3XSI5/5IRGCZCxKL7zr4XUK2+c2PAGGZCtshMZ1owd9m7 o+GWAcEVfrn/DKU5A2+wxLOy2CAygXZosrhuxckEFMV/SIK9Uvmsbe3X0OhduamoUfkS yzLfeQDxbYCrCA2hIEU9cTY7LOPl70cEmu4D8d10ZWbuiHOm4eufIcSnWnMcu3EFPDF4 DU+s8AlXybx+bBhJ180fL0ERIl+DwJNgMR4b3TWfJe03iuYczJyXkImLfsf1Ejxcrpd8 WifA== X-Received: by 10.180.89.133 with SMTP id bo5mr42110208wib.78.1417544587365; Tue, 02 Dec 2014 10:23:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.84.73 with HTTP; Tue, 2 Dec 2014 10:22:26 -0800 (PST) In-Reply-To: <20141202085052.GD23117@elstar.local> References: <20141202085052.GD23117@elstar.local> From: James Miller Date: Tue, 2 Dec 2014 13:22:26 -0500 Message-ID: To: Juergen Schoenwaelder , "trevor.burbridge@bt.com" , "lmap@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f3ba10995554b05093fd1d2 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/yuhzD2rDywD1niuQ2nU9RaV-Xp8 Cc: Walter Johnston , James Miller , Scott Jordan , Henning Schulzrinne Subject: Re: [lmap] Information Model proposed changes for version 03 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:23:12 -0000 --e89a8f3ba10995554b05093fd1d2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On slide #11 and on the inclusion of JSON examples, we employ a CSV row export for the FCC Measuring Broadband America Program's fixed effort but JSON is the native client export for the current smartphone application in the mobile effort. I agree with Juergen that programs, especially as they evolve, may have a mix of data formats and the data model should endeavor to be neutral with respect to a particular data format. I've received feedback in the past that the example snippets are very useful in our technical briefing and data descriptions. I'd offer the feedback as a reference point but don't have a particular preference and agree with Juergen that you have to follow the examples and keep documentation current lest you invite confusion. When we started working up the Fixed documentation I didn't include CSV example snippets (thinking users would likely be viewing the raw CSV files) but I did include an example in the Mobile data dictionary and received good feedback on the inclusion. Rainy snowy weather in DC but hoping you all are enjoying sunshine and surfing weather! References: Mobile Performance Data Dictionary https://github.com/FCC/mobile-mba-androidapp/wiki/Data-Representation MBA Fixed Data Dictionary http://www.fcc.gov/measuring-broadband-america/2014/validated-data-fixed-20= 14#dict MBA Fixed Data Developer FAQ http://www.fcc.gov/measuring-broadband-america/2013/developer-and-researche= r-faq-measuring-broadband-america-feb-2013 -- JamesMillerEsquire@Gmail.com "Wovon man nicht sprechen kann, dar=C3=BCber mu=C3=9F man schweigen." (What we cannot speak about we must pass over in silence. ) Ludwig Josef Johann Wittgenstein On Tue, Dec 2, 2014 at 3:50 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Nov 20, 2014 at 05:25:21PM +0000, trevor.burbridge@bt.com wrote: > > For anyone not at the LMAP session in Honolulu, please see the proposed > changes that were suggested to the LMAP Information Model: > > http://www.ietf.org/proceedings/91/slides/slides-91-lmap-1.pptx > > > > If I do not hear any objections I will start to implement the changes > and issue version 03. > > > > - Slide #5: I guess I will have to accept this. It would be nice > though if the models (and in particular the data models) allow > implementations to augment the base models with information about > queues. > > - Slide #6: My proposal was to consider the parameters an ordered set > and to add parameters by prepending or appending. Overriding does > not make much sense to me (overriding assumes every parameter can > only appear once which is so far not required). > > - Slide #7: OK > > - Slide #8: OK > > - Slide #9: OK > > - Slide #10: I do not understand the second bullet. Why do we have to > spell out separate pre-configuration for factory reset? > > - Slide #11: I prefer to remove the JSON examples since it will be > very irritating if LMAP protocols / data models will deviate from > them. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > --e89a8f3ba10995554b05093fd1d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On slide #11 and on the inclusion of JSON examples, we emp= loy a CSV row export for the FCC Measuring Broadband America Program's = fixed effort but JSON is the native client export for the current smartphon= e application in the mobile effort.=C2=A0 I agree with Juergen that program= s, especially as they evolve, may have a mix of data formats and the data m= odel should endeavor to be neutral with respect to a particular data format= .

I've received feedback in the past that the exampl= e snippets are very useful in our technical briefing and data descriptions.= =C2=A0 I'd offer the feedback as a reference point but don't have a= particular preference and agree with Juergen that you have to follow the e= xamples and keep documentation current lest you invite confusion.=C2=A0 Whe= n we started working up the Fixed documentation I didn't include CSV ex= ample snippets (thinking users would likely be viewing the raw CSV files) b= ut I did include an example in the Mobile data dictionary and received good= feedback on the inclusion.

Rainy snowy weather in DC bu= t hoping you all are enjoying sunshine and surfing weather!

--
JamesMillerEsquire@Gmail.com

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

On Tue, Dec 2, 2014 at 3:50 AM, Juergen Scho= enwaelder <j.schoenwaelder@jacobs-university.de>= wrote:
On Thu, N= ov 20, 2014 at 05:25:21PM +0000, trevor.burbridge@bt.com wrote:
> For anyone not at the LMAP session in Honolulu, please see the propose= d changes that were suggested to the LMAP Information Model:
> http://www.ietf.org/proceedings/91/slides/slides-91= -lmap-1.pptx
>
> If I do not hear any objections I will start to implement the changes = and issue version 03.
>

- Slide #5: I guess I will have to accept this. It would be nice
=C2=A0 though if the models (and in particular the data models) allow
=C2=A0 implementations to augment the base models with information about =C2=A0 queues.

- Slide #6: My proposal was to consider the parameters an ordered set
=C2=A0 and to add parameters by prepending or appending. Overriding does =C2=A0 not make much sense to me (overriding assumes every parameter can =C2=A0 only appear once which is so far not required).

- Slide #7: OK

- Slide #8: OK

- Slide #9: OK

- Slide #10: I do not understand the second bullet. Why do we have to
=C2=A0 spell out separate pre-configuration for factory reset?

- Slide #11: I prefer to remove the JSON examples since it will be
=C2=A0 very irritating if LMAP protocols / data models will deviate from =C2=A0 them.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1, 28759 Bre= men, Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-univ= ersity.de/>

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

--e89a8f3ba10995554b05093fd1d2-- From nobody Wed Dec 10 09:01:30 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81A61A03AA for ; Wed, 10 Dec 2014 09:01:23 -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 moLb_0Zxzacs for ; Wed, 10 Dec 2014 09:01:20 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37A81A8712 for ; Wed, 10 Dec 2014 09:01:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEKAKh7iFTGmAcV/2dsb2JhbABZgkMhIiIwWQOzKgwGBgWQCoIYGwELhWwCgRkWAQEBAQEBfIQOAQEDEhteAQwJFVYmAQQbARmIFgEMsT+EeKIvhg2JRYJpDkEhgRUFjgKJfYJcgiaLTIFFDIIdgjN+AQEB X-IronPort-AV: E=Sophos; i="5.07,553,1413259200"; d="scan'208,217"; a="84114683" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Dec 2014 12:01:16 -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; 10 Dec 2014 12:01:16 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Wed, 10 Dec 2014 12:01:14 -0500 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP WG Interim meeting - Monday 12/15 - draft agenda Thread-Index: AdAUmuej7M8GYY8KTAmvfoErJtbQ5g== Date: Wed, 10 Dec 2014 17:01:14 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C92A8EC@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_9904FB1B0159DA42B0B887B7FA8119CA5C92A8ECAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/MN24nwmLaMuMEpHbBhPehiZFvKg Subject: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 17:01:24 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C92A8ECAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have uploaded a draft agenda for the Monday 12/15 interim meeting schedul= ed to start at 9AM PST / noon EST / 6PM CET. http://www.ietf.org/proceedings/interim/2014/12/15/lmap/agenda/agenda-inter= im-2014-lmap-2 Please let us know if there are other items that you would like to present = and discuss. The usual request for volunteers to take notes apply. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C92A8ECAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have uploaded a draft agenda for the Monday 12/15 = interim meeting scheduled to start at 9AM PST / noon EST / 6PM CET.

 

http://www.ietf.org/proce= edings/interim/2014/12/15/lmap/agenda/agenda-interim-2014-lmap-2

 

Please let us know if there are other items that you= would like to present and discuss.

 

The usual request for volunteers to take notes apply= .

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C92A8ECAZFFEXMB04globa_-- From nobody Wed Dec 10 10:02:56 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4F61A8784 for ; Wed, 10 Dec 2014 10:02:51 -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 ezYN7OuC2XTW for ; Wed, 10 Dec 2014 10:02:50 -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 7671E1A876E for ; Wed, 10 Dec 2014 10:02:42 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3B3719E3; Wed, 10 Dec 2014 19:02:41 +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 6Wj-_vaWbVZO; Wed, 10 Dec 2014 19:02:30 +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; Wed, 10 Dec 2014 19:02:40 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4385520017; Wed, 10 Dec 2014 19:02:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Pi6xfZsqszK5; Wed, 10 Dec 2014 19:02:39 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1317E2002C; Wed, 10 Dec 2014 19:02:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8573D2FF0FB6; Wed, 10 Dec 2014 19:02:37 +0100 (CET) Date: Wed, 10 Dec 2014 19:02:36 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20141210180236.GA47533@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA5C92A8EC@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C92A8EC@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/IM-zkLzOLcSFubTRdhEnm_Wvndo Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 18:02:51 -0000 On Wed, Dec 10, 2014 at 05:01:14PM +0000, Romascanu, Dan (Dan) wrote: > Hi, > > I have uploaded a draft agenda for the Monday 12/15 interim meeting scheduled to start at 9AM PST / noon EST / 6PM CET. > > http://www.ietf.org/proceedings/interim/2014/12/15/lmap/agenda/agenda-interim-2014-lmap-2 > > Please let us know if there are other items that you would like to present and discuss. > I thought we would talk about protocols. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Dec 10 10:05:12 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C729C1A8827 for ; Wed, 10 Dec 2014 10:05:09 -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 C2I1aEHgYwfF for ; Wed, 10 Dec 2014 10:05:04 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1501A066C for ; Wed, 10 Dec 2014 10:04:18 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgFALWJiFSHCzIm/2dsb2JhbABWA4JkIlJYBLM3BgaQD4I9hW4CgRoWAQEBAQEBfIQMAQEBAQMSKD8MAgICAQgNAQIBBAEBAQoUCQcbFxQJCAEBBA4FCBqIFgEMtiuiDAEBAQEBAQEBAQEBAQEBAQEBAQEBARcEhgmJRSEQBwYLgxCBFQWOAoNAhj0wgiyCJotMg25uAYFEfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,553,1413259200"; d="scan'208";a="84125625" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Dec 2014 13:04:16 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 10 Dec 2014 13:04:15 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Wed, 10 Dec 2014 19:04:13 +0100 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft agenda Thread-Index: AdAUmuej7M8GYY8KTAmvfoErJtbQ5gAMnugAAAp1mAA= Date: Wed, 10 Dec 2014 18:04:13 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C92A9AB@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C92A8EC@AZ-FFEXMB04.global.avaya.com> <20141210180236.GA47533@elstar.local> In-Reply-To: <20141210180236.GA47533@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/HGzg3RGU7oOxhc5WOge-xzZ8kW8 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 18:05:10 -0000 This is a draft agenda. We have time for the protocols. Who will run the di= scussion?=20 Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Wednesday, December 10, 2014 8:03 PM > To: Romascanu, Dan (Dan) > Cc: lmap@ietf.org > Subject: Re: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft > agenda >=20 > On Wed, Dec 10, 2014 at 05:01:14PM +0000, Romascanu, Dan (Dan) wrote: > > Hi, > > > > I have uploaded a draft agenda for the Monday 12/15 interim meeting > scheduled to start at 9AM PST / noon EST / 6PM CET. > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__www.ietf.org_proceedings_interim_2014_12_15_lmap_agenda_agend > a-2Dinterim-2D2014-2Dlmap- > 2D2&d=3DAAIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiL > QfucBXRucPvdrphpBsFA&m=3DTN1gRF3X6GwBrsS8SewpsU0qNmsl9iFrKxQcM > ekhNXQ&s=3D4I_8tBEF86Xc6Sn09eEjz7UCPY152LbGszP79nM3uzM&e=3D > > > > Please let us know if there are other items that you would like to pres= ent > and discuss. > > >=20 > I thought we would talk about protocols. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > 2Duniversity.de_&d=3DAAIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DTN1gRF3X6GwBrsS8SewpsU0qN > msl9iFrKxQcMekhNXQ&s=3DLeW5MuRrp3lNY1e8VqVop2chmnMuQb0o5fWmK > 83A-4E&e=3D > From nobody Wed Dec 10 10:17:43 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F751A8952 for ; Wed, 10 Dec 2014 10:17:34 -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 vznnvKYs7vqE for ; Wed, 10 Dec 2014 10:17:29 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA2E1A87AD for ; Wed, 10 Dec 2014 10:17:21 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkFADuNiFSHCzIm/2dsb2JhbABWA4JkIlJYBLM3BgaQD4I9hW4CgRoWAQEBAQEBfIQMAQEBAQMSKDQLDAICAgEIDQECAQQBAQEKFAkHGxcUCQgBAQQOBQgaiBYBDLY6og8BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIYJiUUhEAcGC4MQgRUFjgKDQIY9MIIsgiaLTINubgGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.07,553,1413259200"; d="scan'208";a="84127588" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Dec 2014 13:17:19 -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; 10 Dec 2014 13:17:18 -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; Wed, 10 Dec 2014 19:17:17 +0100 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft agenda Thread-Index: AdAUmuej7M8GYY8KTAmvfoErJtbQ5gAMnugAAAp1mAAAFHmssA== Date: Wed, 10 Dec 2014 18:17:16 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C92A9F3@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C92A8EC@AZ-FFEXMB04.global.avaya.com> <20141210180236.GA47533@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5C92A9AB@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C92A9AB@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/fmkPs4jYHss0ElJ3N_XQ9S4_Hug Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 18:17:34 -0000 I missed to include the 'Protocol Selection Criteria' which is an Action It= em from IETF-91 owned by Barbara and Tim.=20 I updated the draft agenda to add these.=20 If there are other contributions, please let us know.=20 Thanks and Regards, Dan > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) > Sent: Wednesday, December 10, 2014 8:04 PM > To: Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft > agenda >=20 > This is a draft agenda. We have time for the protocols. Who will run the > discussion? >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Wednesday, December 10, 2014 8:03 PM > > To: Romascanu, Dan (Dan) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft > > agenda > > > > On Wed, Dec 10, 2014 at 05:01:14PM +0000, Romascanu, Dan (Dan) wrote: > > > Hi, > > > > > > I have uploaded a draft agenda for the Monday 12/15 interim meeting > > scheduled to start at 9AM PST / noon EST / 6PM CET. > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > > 3A__www.ietf.org_proceedings_interim_2014_12_15_lmap_agenda_agend > > a-2Dinterim-2D2014-2Dlmap- > > > 2D2&d=3DAAIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiL > > > QfucBXRucPvdrphpBsFA&m=3DTN1gRF3X6GwBrsS8SewpsU0qNmsl9iFrKxQcM > > ekhNXQ&s=3D4I_8tBEF86Xc6Sn09eEjz7UCPY152LbGszP79nM3uzM&e=3D > > > > > > Please let us know if there are other items that you would like to > > > present > > and discuss. > > > > > > > I thought we would talk about protocols. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > 2Duniversity.de_&d=3DAAIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DTN1gRF3X6GwBrsS8SewpsU0qN > > > msl9iFrKxQcMekhNXQ&s=3DLeW5MuRrp3lNY1e8VqVop2chmnMuQb0o5fWmK > > 83A-4E&e=3D > >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_lmap&d=3DAAICAg&c=3DBFpWQw8bsuKpl1 > SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DkMMyq > yX7oC3iSKS33Q6wWSuinEqMxMpOVp7RcwZUncU&s=3DhuZlaAUYcbt5In8aGPF > uZIeM5pUY3VqHePLwDJbrc2I&e=3D From nobody Wed Dec 10 18:51:37 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBDE1A1B75 for ; Wed, 10 Dec 2014 18:51:35 -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 Ml6zERx0scwP for ; Wed, 10 Dec 2014 18:51:33 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1701A1A91 for ; Wed, 10 Dec 2014 18:51:33 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id z20so7615928igj.16 for ; Wed, 10 Dec 2014 18:51:32 -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=OKQsFzQVj5tQTKYZ19vTnbeiIcv7b68qKWK6p71lr8Y=; b=cBB6lLdjSiaZMxZxAbYEmGuoyAyN2kiYgUdcPxNPrn8swYh7d0snbapVPZawLSuHH3 qHBwHZo2183rZK1xurzvGU4/tmud5rmx1WLicPysru3PIfnt8T1/B8LIk+PaKdZw02Kg jaw5k9ZYwTsUpNtpBe5K3LCBfaD8mlYMgtRCwUtpLVko05/nyZsi6+oNYjaYHW2Eb/mA QkSwewgY9KFLAxsgw3q7eyK/SHLtUhFXn40qRkwQ2Vy+1ITFbAZeKnPLAFX1dOJ3EDj9 lMjr9SYdezCQetUd1qPK6TLqb+ibv2LVD49zzz8547M1Ri7hST8LUw/gVrs5BtUtXcok tKDQ== MIME-Version: 1.0 X-Received: by 10.50.66.234 with SMTP id i10mr29297154igt.25.1418266292402; Wed, 10 Dec 2014 18:51:32 -0800 (PST) Received: by 10.107.174.168 with HTTP; Wed, 10 Dec 2014 18:51:32 -0800 (PST) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C92A9F3@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C92A8EC@AZ-FFEXMB04.global.avaya.com> <20141210180236.GA47533@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5C92A9AB@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C92A9F3@AZ-FFEXMB04.global.avaya.com> Date: Thu, 11 Dec 2014 10:51:32 +0800 Message-ID: From: Greg Mirsky To: "Romascanu, Dan (Dan)" Content-Type: multipart/alternative; boundary=047d7bdc1a6c8e3e520509e7da3f Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/-2DEJnj_VDWB-cY70veE5RfuMxA Cc: Juergen Schoenwaelder , "lmap@ietf.org" Subject: Re: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft agenda 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, 11 Dec 2014 02:51:35 -0000 --047d7bdc1a6c8e3e520509e7da3f Content-Type: text/plain; charset=UTF-8 Hi Dan, et. al, my apologies but I cannot find webex/dial-in information to connect/participate in the meeting. Greatly appreciate your help. Regards, Greg On Thu, Dec 11, 2014 at 2:17 AM, Romascanu, Dan (Dan) wrote: > I missed to include the 'Protocol Selection Criteria' which is an Action > Item from IETF-91 owned by Barbara and Tim. > > I updated the draft agenda to add these. > > If there are other contributions, please let us know. > > Thanks and Regards, > > Dan > > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan > > (Dan) > > Sent: Wednesday, December 10, 2014 8:04 PM > > To: Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: Re: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft > > agenda > > > > This is a draft agenda. We have time for the protocols. Who will run the > > discussion? > > > > Dan > > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > university.de] > > > Sent: Wednesday, December 10, 2014 8:03 PM > > > To: Romascanu, Dan (Dan) > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft > > > agenda > > > > > > On Wed, Dec 10, 2014 at 05:01:14PM +0000, Romascanu, Dan (Dan) wrote: > > > > Hi, > > > > > > > > I have uploaded a draft agenda for the Monday 12/15 interim meeting > > > scheduled to start at 9AM PST / noon EST / 6PM CET. > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=http- > > > > > 3A__www.ietf.org_proceedings_interim_2014_12_15_lmap_agenda_agend > > > a-2Dinterim-2D2014-2Dlmap- > > > > > 2D2&d=AAIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiL > > > > > QfucBXRucPvdrphpBsFA&m=TN1gRF3X6GwBrsS8SewpsU0qNmsl9iFrKxQcM > > > ekhNXQ&s=4I_8tBEF86Xc6Sn09eEjz7UCPY152LbGszP79nM3uzM&e= > > > > > > > > Please let us know if there are other items that you would like to > > > > present > > > and discuss. > > > > > > > > > > I thought we would talk about protocols. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > > Fax: +49 421 200 3103 > > > > > > > 2Duniversity.de_&d=AAIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O > > > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=TN1gRF3X6GwBrsS8SewpsU0qN > > > > > msl9iFrKxQcMekhNXQ&s=LeW5MuRrp3lNY1e8VqVop2chmnMuQb0o5fWmK > > > 83A-4E&e= > > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_mailman_listinfo_lmap&d=AAICAg&c=BFpWQw8bsuKpl1 > > SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=kMMyq > > yX7oC3iSKS33Q6wWSuinEqMxMpOVp7RcwZUncU&s=huZlaAUYcbt5In8aGPF > > uZIeM5pUY3VqHePLwDJbrc2I&e= > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > --047d7bdc1a6c8e3e520509e7da3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dan, et. al,
my apologies but I cannot find webex/d= ial-in information to connect/participate in the meeting.
Greatly= appreciate your help.

Regards,
Greg

On Thu, D= ec 11, 2014 at 2:17 AM, Romascanu, Dan (Dan) <dromasca@avaya.com>= wrote:
I missed to include the &#= 39;Protocol Selection Criteria' which is an Action Item from IETF-91 ow= ned by Barbara and Tim.

I updated the draft agenda to add these.

If there are other contributions, please let us know.

Thanks and Regards,

Dan


> -----Original Message-----
> From: lmap [mailto:lmap-bounc= es@ietf.org] On Behalf Of Romascanu, Dan
> (Dan)
> Sent: Wednesday, December 10, 2014 8:04 PM
> To: Juergen Schoenwaelder
> Cc: lmap@ietf.org
> Subject: Re: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft
> agenda
>
> This is a draft agenda. We have time for the protocols. Who will run t= he
> discussion?
>
> Dan
>
>
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> > university.de<= /a>]
> > Sent: Wednesday, December 10, 2014 8:03 PM
> > To: Romascanu, Dan (Dan)
> > Cc: lmap@ietf.org
> > Subject: Re: [lmap] LMAP WG Interim meeting - Monday 12/15 - draf= t
> > agenda
> >
> > On Wed, Dec 10, 2014 at 05:01:14PM +0000, Romascanu, Dan (Dan) wr= ote:
> > > Hi,
> > >
> > > I have uploaded a draft agenda for the Monday 12/15 interim = meeting
> > scheduled to start at 9AM PST / noon EST / 6PM CET.
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp-=
> >
> 3A__www.ietf.org_proceedings_interim_2014_12_15_lmap_agenda_agend
> > a-2Dinterim-2D2014-2Dlmap-
> >
> 2D2&d=3DAAIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcN= XCJfQzvlsiL
> >
> QfucBXRucPvdrphpBsFA&m=3DTN1gRF3X6GwBrsS8SewpsU0qNmsl9iFrKxQcM
> > ekhNXQ&s=3D4I_8tBEF86Xc6Sn09eEjz7UCPY152LbGszP79nM3uzM&e= =3D
> > >
> > > Please let us know if there are other items that you would l= ike to
> > > present
> > and discuss.
> > >
> >
> > I thought we would talk about protocols.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1, 28759 Bremen, Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103
> > <https://urldefense.proofpoint.com/v2/url= ?u=3Dhttp-3A__www.jacobs-
> >
> 2Duniversity.de_&d=3DAAIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r= =3DI4dzGxR31O
> > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DTN1gRF3X6GwBrsS8SewpsU0= qN
> >
> msl9iFrKxQcMekhNXQ&s=3DLeW5MuRrp3lNY1e8VqVop2chmnMuQb0o5fWmK
> > 83A-4E&e=3D >
>
> _______________________________________________
> lmap mailing list
> lmap@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-=
> 3A__www.ietf.org_mailman_listinfo_lmap&d=3DAAICAg&c=3DBFpWQw8b= suKpl1
> SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3Dk= MMyq
> yX7oC3iSKS33Q6wWSuinEqMxMpOVp7RcwZUncU&s=3DhuZlaAUYcbt5In8aGPF
> uZIeM5pUY3VqHePLwDJbrc2I&e=3D

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

--047d7bdc1a6c8e3e520509e7da3f-- From nobody Wed Dec 10 22:17:36 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CD11A1B2C for ; Wed, 10 Dec 2014 22:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flLA4LyYGz6I for ; Wed, 10 Dec 2014 22:17:33 -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 914241A19E3 for ; Wed, 10 Dec 2014 22:17:32 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4GALs1iVSHCzIm/2dsb2JhbABWA4JkIlJYBLMfAQEBAQEHkj2FbgKBGRYBAQEBAQF8hAwBAQEBAxIoLAgXAgICAQgNBAQBAQsKBAYGAwcbFxQHAQEFAgECAQMTCBqICgEMtW+PdJEfAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwQEhXiGPYJpEyEXBgsHgn6BEwWNf4M+iz6DO4dpIoMeTm6BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,556,1413259200"; d="scan'208";a="95896048" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Dec 2014 01:17:31 -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; 11 Dec 2014 01:17:31 -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; Thu, 11 Dec 2014 07:17:30 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [lmap] LMAP WG Virtual Interim Meeting: December 15, 2014 Thread-Index: AQHQCAkf+W++O6Qaq0qI9o2aXjfuRpyKA/1g Date: Thu, 11 Dec 2014 06:17:29 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C92B1B5@AZ-FFEXMB04.global.avaya.com> References: <20141124170627.6401.13882.idtracker@ietfa.amsl.com> In-Reply-To: <20141124170627.6401.13882.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ExGx8i4HTRVa38c_j85JDRaBeLM Subject: [lmap] FW: LMAP WG Virtual Interim Meeting: December 15, 2014 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, 11 Dec 2014 06:17:35 -0000 Hi, Here is a reminder with the WebEx information for the virtual meeting on Mo= nday. Regards, Dan > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of IESG Secretary > Sent: Monday, November 24, 2014 7:06 PM > To: IETF Announcement List > Cc: lmap@ietf.org > Subject: [lmap] LMAP WG Virtual Interim Meeting: December 15, 2014 >=20 > The LMAP WG decided to hold 2 or 3 interim meetings between IETF-91 and > IETF-92. The first meeting will be on Monday, December 15, starting at no= on > EST, for a duration of 3 hours. WebEx details are below: >=20 >=20 > LMAP > Monday, December 15, 2014 > 9:00 am | Pacific Standard Time (San Francisco, GMT-08:00) | 3 hr >=20 > Join WebEx meeting: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__ietf.webex.com_ietf_j.php-3FMTID- > 3Dmc477babd9eef5bedb78f11a9855d98b7&d=3DAAICAg&c=3DBFpWQw8bsuKpl1 > SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DiqkheTo > Bahigrn58pQVBq- > mg0X9zDV08Slvf97H993M&s=3DzsyKBaL9F8InZ9ZWBZiULIaG0bwyHXjR8cT0N52- > L2s&e=3D > Meeting number: 648 675 238 > Meeting password: 1234 >=20 > Join by phone > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) Access code: 648 675 238 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_lmap&d=3DAAICAg&c=3DBFpWQw8bsuKpl1 > SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DiqkheTo > Bahigrn58pQVBq-mg0X9zDV08Slvf97H993M&s=3DXclhlp- > ZdSMseWszY4yteMzGhWPyNVpwAaCD0tRaQwU&e=3D From nobody Fri Dec 12 00:28:00 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CF31AC429 for ; Fri, 12 Dec 2014 00:27:59 -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 30ili4NT08I0 for ; Fri, 12 Dec 2014 00:27:57 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E661AC41E for ; Fri, 12 Dec 2014 00:27:56 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 12 Dec 2014 08:28:08 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Fri, 12 Dec 2014 08:27:53 +0000 From: To: , Date: Fri, 12 Dec 2014 08:27:53 +0000 Thread-Topic: LMAP WG Interim meeting - Monday 12/15 - draft agenda Thread-Index: AdAUmuej7M8GYY8KTAmvfoErJtbQ5gBSmvQw Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C92A8EC@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C92A8EC@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_A2E337CDB7BC4145B018B9BEE8EB3E0D413BCFA5ACEMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/fZTnC6NQuTEZl1linuTTtHJnOec Subject: Re: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 08:27:59 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413BCFA5ACEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll submit an update for the framework before the call. I believe we have = agreed changes from the AD, secarea etc reviews. I can take about this very briefly - it shouldn't take more than a few minu= tes. Thanks phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: 10 December 2014 17:01 To: lmap@ietf.org Subject: [lmap] LMAP WG Interim meeting - Monday 12/15 - draft agenda Hi, I have uploaded a draft agenda for the Monday 12/15 interim meeting schedul= ed to start at 9AM PST / noon EST / 6PM CET. http://www.ietf.org/proceedings/interim/2014/12/15/lmap/agenda/agenda-inter= im-2014-lmap-2 Please let us know if there are other items that you would like to present = and discuss. The usual request for volunteers to take notes apply. Thanks and Regards, Dan --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413BCFA5ACEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll sub= mit an update for the framework before the call. I believe we have agreed c= hanges from the AD, secarea etc reviews.

I can take about this very briefly – it shouldn’t tak= e more than a few minutes.

 

Thanks

=

phil

 

= From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of <= /b>Romascanu, Dan (Dan)
Sent: 10 December 2014 17:01
To: lmap@ietf.org
Subject: [lmap] LMAP WG Interim meeting - Monday = 12/15 - draft agenda

=  

Hi,=

 =

I have uploaded a draft agenda = for the Monday 12/15 interim meeting scheduled to start at 9AM PST / noon E= ST / 6PM CET.

 

http://www.ietf.org/proceedings/interim/2014/12/15/lma= p/agenda/agenda-interim-2014-lmap-2

 

Please let us know if there are other items that you wo= uld like to present and discuss.

 

The usual request for volunteers to take notes apply.

 

Thanks and Regards,

 

Dan

 

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413BCFA5ACEMV67UKRDdoma_-- From nobody Fri Dec 12 08:30:02 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4141A6F38; Fri, 12 Dec 2014 08:29: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 YHYSpk-U8NNE; Fri, 12 Dec 2014 08:29:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 334C51A7004; Fri, 12 Dec 2014 08:29:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141212162941.15095.43894.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 08:29:41 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/y8cWUR94j8lxjmLxU-GL4Uoveus Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-framework-09.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: Fri, 12 Dec 2014 16:29:53 -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-09.txt Pages : 57 Date : 2014-12-12 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 12 08:36:17 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7181A2130 for ; Fri, 12 Dec 2014 08:36:16 -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 ubYBMDzPT2Cx for ; Fri, 12 Dec 2014 08:36:14 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A041A1F16 for ; Fri, 12 Dec 2014 08:36:14 -0800 (PST) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 12 Dec 2014 16:36:18 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Fri, 12 Dec 2014 16:35:53 +0000 From: To: Date: Fri, 12 Dec 2014 16:35:51 +0000 Thread-Topic: [lmap] I-D Action: draft-ietf-lmap-framework-09.txt Thread-Index: AdAWKOKPAuTDYukqQzOKHbvmZAqL3gAAGRPQ Message-ID: References: <20141212162941.15095.43894.idtracker@ietfa.amsl.com> In-Reply-To: <20141212162941.15095.43894.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/W5NBIzMwOLTIjyJWKx4_jP_hQo8 Subject: Re: [lmap] I-D Action: draft-ietf-lmap-framework-09.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 16:36:16 -0000 Hi, Just to let you know I submitted a new version to address: - Benoit's comments - especially about making it less active-centric - Radia's comments - security review - email I sent 11 nov about proposed fwk changes. Thanks phil > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 12 December 2014 16:30 > To: i-d-announce@ietf.org > Cc: lmap@ietf.org > Subject: [lmap] I-D Action: draft-ietf-lmap-framework-09.txt >=20 >=20 > 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. >=20 > 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-09.txt > Pages : 57 > Date : 2014-12-12 >=20 > 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). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-lmap-framework-09 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-framework-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Dec 15 07:54:05 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B351A7005 for ; Mon, 15 Dec 2014 07:54:04 -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 K8FHIM-P_92H for ; Mon, 15 Dec 2014 07:54:02 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECEE01A1AFB for ; Mon, 15 Dec 2014 07:54:01 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 15 Dec 2014 15:54:01 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 15 Dec 2014 15:53:48 +0000 From: To: Date: Mon, 15 Dec 2014 15:53:47 +0000 Thread-Topic: Stephen Farrell's COMMENT on draft-ietf-lmap-use-cases-05: (with COMMENT) Thread-Index: AdAYeD/pOAMjzsNXSJSCOPZHFYH42wABvJZw Message-ID: References: <548EF82E.7050406@cs.tcd.ie> In-Reply-To: <548EF82E.7050406@cs.tcd.ie> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/GzqeP1EqauU_P0tL_mw1jm7Ri1o Subject: [lmap] FW: Stephen Farrell's COMMENT on draft-ietf-lmap-use-cases-05: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 15:54:04 -0000 VGhpcyBtYXkgYmUgd29ydGggZGlzY3Vzc2luZyBvbiB0aGUgaW50ZXJpbSBsYXRlciB0b2RheQ0K UGhpbA0KDQpUaGlzIGlzIGEgZGlzY3Vzc2lvbiBkdXJpbmcgdGhlIGllc2cgcmV2aWV3DQotLS0N Cg0KDQpPbiAxNS8xMi8xNCAxNDoyMSwgcGhpbGlwLmVhcmRsZXlAYnQuY29tIHdyb3RlOg0KPiBF YXJsaWVyLCBTdGVwaGVuIHdyb3RlOg0KPj4gLSBzZWN0aW9uIDY6IEknbSB3b25kZXJpbmcgaWYg aXQncyByZWFsbHkgd2lzZSB0byBpbmNsdWRlIGJvdGggDQo+PiBtZWFzdXJlbWVudCBhbmQgdHJv dWJsZXNob290aW5nIGNhcGFiaWxpdGllcyBpbiB0aGUgc2FtZSB0aGluZy4gSSBzZWUgDQo+PiB0 aGUgYXR0cmFjdGlvbiBidXQgdGhlIGxhdHRlciBtYXkgaGF2ZSBtb3JlIG9uZXJvdXMgc2VjdXJp dHkgDQo+PiByZXF1aXJlbWVudHMgdGhhdCB3b3VsZCB0ZW5kIG5vdCB0byBiZSBtZXQgYnkgaW1w bGVtZW50YXRpb25zIG9mIHRoZSANCj4+IGZvcm1lci4NCj4gDQo+IFtwaGlsXSB3b3VsZCBpdCBo ZWxwIHRvIGFkZCBzb21ldGhpbmcgbGlrZSB0aGlzIChpbiB0aGUgbmV3IHN1Yi1idWxsZXQgDQo+ IGFib3V0IHRoZSBuZXR3b3JrIG9wZXJhdG9yJ3MgcGVyc3BlY3RpdmUpOiBSZWZlcnJpbmcgdG8g dGhlIHN1YiB1c2UgDQo+IGNhc2VzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMsIHVzaW5nIG1lYXN1 cmVtZW50cyBmb3IgJ2lkZW50aWZ5aW5nLCANCj4gaXNvbGF0aW5nIGFuZCBmaXhpbmcgbmV0d29y ayBwcm9ibGVtcycgbWF5IHJhaXNlIG1vcmUgb25lcm91cyBzZWN1cml0eSANCj4gcmVxdWlyZW1l bnRzIHRoYW4gdXNpbmcgbWVhc3VyZW1lbnRzIGZvciAndW5kZXJzdGFuZGluZyB0aGUgcXVhbGl0 eSANCj4gZXhwZXJpZW5jZWQgYnkgY3VzdG9tZXJzJyAtIHNpbmNlIHRoZSBmb3JtZXIgd2lsbCBk aXJlY3RseSBsZWFkIHRvIA0KPiBjaGFuZ2VzIGluIHRoZSBvcGVyYXRpb24gb2YgdGhlIG5ldHdv cmsuDQoNCkkgZG9uJ3QgdGhpbmsgdGhhdCByZWFsbHkgZG9lcyBoZWxwIHRoYXQgbXVjaC4NCg0K SSBqdXN0IHRoaW5rIGl0J3MgYW4gZXJyb3IgdG8gY29uZmxhdGUgbWVhc3VyZW1lbnQgYW5kIHRy b3VibGVzaG9vdGluZy9yZXBhaXJpbmcgYSBuL3cuIEFuZCBJIGRvbid0IHJlY2FsbCB0aGF0IHRo ZSBsYXR0ZXIgaXMgY292ZXJlZCBpbiB0aGUgd2cgY2hhcnRlci4gU28gaWYgSSdtIHN0aWxsIG9u IHRoZSBJRVNHIHdoZW4gTE1BUCBwcm90b2NvbCBkb2NzIHN0YXJ0IGNvbWluZyBieSBhbmQgaWYg dGhvc2UgcHJvdG9jb2xzIGFsbG93IGZvciBjaGFuZ2luZyB0aGUgbi93IGFzIG9wcG9zZWQgdG8g anVzdCBtZWFzdXJpbmcgaXQsIHRoZW4gSSdsbCBsaWtlbHkgYmUgZGlzY3Vzc2luZyB0aG9zZSBm ZWF0dXJlcyBhbmQgYXNraW5nIHdoYXQgdGhleSBoYXZlIHRvIGRvIHdpdGggbWVhc3VyZW1lbnQg YW5kIHRoaXMgd2cncyBjaGFydGVyLiBPciBpZiB0aGUgd2cgcmVhbGx5IHJlYWxseSB3YW50IHRv IGFsc28gY292ZXIgdHJvdWJsZXNob290aW5nL3JlcGFpcmluZyB0aGUgbi93IHRoZW4gSSB0aGlu ayB5b3UnZCBiZSB3aXNlIHRvIHRyeSByZS1jaGFydGVyIHNvIGFzIHRvIGVzdGFibGlzaCB0aGF0 IHRoZXJlIGlzIGFuIElFVEYgY29uc2Vuc3VzIGZvciB0aGF0IGJlaW5nIGRvbmUgaGVyZS4NCg0K Rm9yIHRoaXMgZG9jdW1lbnQsIEknZCBwcmVmZXIgaWYgeW91IHNhaWQgdGhhdCByZXBhaXJpbmcg dGhlIG4vdyBpcyBqdXN0IHBsYWluIG91dCBvZiBzY29wZSBvZiBsbWFwIG15c2VsZi4gVGhlIG1v cmUgSSB0aGluayBhYm91dCB0aGlzLCB0aGUgbGVzcyBhbmQgbGVzcyBJIGxpa2UgdGhlIGlkZWEg dGhhdCBuZXR3b3JrIHJlcGFpciBiZSBhIHdhcnQgb24gdGhlIHNpZGUgb2YgbmV0d29yayBtZWFz dXJlbWVudC4NCg0KQ2hlZXJzLA0KUy4NCg0KDQo= From nobody Mon Dec 15 07:59:27 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F451A7034 for ; Mon, 15 Dec 2014 07:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 LMWnBxthNTup for ; Mon, 15 Dec 2014 07:59:22 -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 3847B1A701E for ; Mon, 15 Dec 2014 07:59:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6235; q=dns/txt; s=iport; t=1418659162; x=1419868762; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=zyQbD4IfEKZhELyvqF/sqEgY29inmaHsmRf6ODVRQjg=; b=KcMnMPqOaj9IlmCXIAk6XhVuQlb7KBsGqHGmYxtqdTEQBQ6lXoL4NjI6 +AE4gbxUtUzlFAhVd4vF77RTqJMs9zJR1Iha7NnKeWVTANidCc5jaoK2U t035J7OkQi3lXK68Fh6Xa7R2QV9gRLJcS30zhFpA6dJO77SQbzgpF/rCB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYEACEFj1StJssW/2dsb2JhbABag1hYxVWFegKBMwEBAQEBfYQMAQEBBHgNBBwDAQIKFg8JAwIBAgE7AggGDQYCAQEQiBjTWwEBAQEBAQQBAQEBAQEBG48QEQE/GAaEIwWRQIUxgQswgi6CEIgGgzgig209MAGBC4E3AQEB X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208,217";a="270949164" 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; 15 Dec 2014 15:59:10 +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 sBFFx9Hm021513 for ; Mon, 15 Dec 2014 15:59:10 GMT Message-ID: <548F054D.9080503@cisco.com> Date: Mon, 15 Dec 2014 16:59:09 +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: <5481B5CB.50701@cisco.com> In-Reply-To: <5481B5CB.50701@cisco.com> X-Forwarded-Message-Id: <5481B5CB.50701@cisco.com> Content-Type: multipart/alternative; boundary="------------080104080505070903070206" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/WOzhaXxWFKN1pcYUlY55Jf2YNx4 Subject: [lmap] Fwd: draft-ietf-lmap-use-cases status after the IESG telechat X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 15:59:25 -0000 This is a multi-part message in MIME format. --------------080104080505070903070206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I just realized that I only sent this email to the authors. This might useful for our interim meeting today. Regards, Benoit -------- Original Message -------- Subject: draft-ietf-lmap-use-cases status after the IESG telechat Date: Fri, 05 Dec 2014 14:40:27 +0100 From: Benoit Claise To: draft-ietf-lmap-use-cases.all@tools.ietf.org Dear all, Here is the status after the IESG telechat. There are 2 ABSTAINs on the document: let's not spend time on this. Some of us believe this is an useful document to publish. _Pete's DISCUSS:_ Dwelling on how markets should be regulated is not the right way. On top of that, the text is too US+Europe-centric. Changing the text to, let's say, "this is what some people are thinking" or "the community believes" Please engage with Pete on text proposal. Kathleen's DISCUSS: From Kathleen: The next part of my sentence finished and expanded the thought, so this shouldn't be pulled out separately.By traffic being blocked, I was referring to the practice of network security folks from blocking probes as it can provide a means to gather information about an organizations network, operational practices, paths to the network that can be attacked (DoS), in other words possible ways to compromise a network. This is probably similar to your phrasing of "gaming the system". I asked Kathleen the type of text she had in mind Answer: not blocking so much as reconnaissance... message from Philip explained use of "business confidentiality"... I'd ask to expand the text on that I explained that the business confidentiality is more about ISPs not happy to share their own information Kathleen mentioned it should be an extra bullet point then, and that this exposure could enable DoS-attack, etc Please engage with Kathleen on text proposal. There are also others COMMENT to deal with. The best way to proceed is to engage in the email discussion before posting a new draft version. Regards, Benoit --------------080104080505070903070206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I just realized that I only sent this email to the authors.
This might useful for our interim meeting today.

Regards, Benoit


-------- Original Message --------
Subject: draft-ietf-lmap-use-cases status after the IESG telechat
Date: Fri, 05 Dec 2014 14:40:27 +0100
From: Benoit Claise <bclaise@cisco.com>
To: draft-ietf-lmap-use-cases.all@tools.ietf.org <draft-ietf-lmap-use-cases.all@tools.ietf.org>


Dear all,

Here is the status after the IESG telechat.

There are 2 ABSTAINs on the document: let's not spend time on this. Some of us believe this is an useful document to publish.

Pete's DISCUSS:
Dwelling on how markets should be regulated is not the right way. On top of that, the text is too US+Europe-centric. Changing the text to, let's say, "this is what some people are thinking" or "the community believes"
Please engage with Pete on text proposal.

Kathleen's DISCUSS:
From Kathleen: The next part of my sentence finished and expanded the thought, so
this shouldn't be pulled out separately.  By traffic being blocked, I
was referring to the practice of network security folks from blocking
probes as it can provide a means to gather information about an
organizations network, operational practices, paths to the network
that can be attacked (DoS), in other words possible ways to compromise
a network.  This is probably similar to your phrasing of "gaming the
system".

I asked Kathleen the type of text she had in mind
Answer: not blocking so much as reconnaissance... message from Philip explained use of "business confidentiality"... I'd ask to expand the text on that
I explained that the business confidentiality is more about ISPs not happy to share their own information
Kathleen mentioned it should be an extra bullet point then, and that this exposure could enable DoS-attack, etc
Please engage with Kathleen on text proposal.

There are also others COMMENT to deal with.
The best way to proceed is to engage in the email discussion before posting a new draft version.

Regards, Benoit


--------------080104080505070903070206-- From nobody Mon Dec 15 08:52:40 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06F81A8033 for ; Mon, 15 Dec 2014 08:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 9Y3eNVZBaYOa for ; Mon, 15 Dec 2014 08:52:24 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7421A8029 for ; Mon, 15 Dec 2014 08:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=108197; q=dns/txt; s=iport; t=1418662342; x=1419871942; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=5cS9dH2M97221HYoClxY4ZCPohB4HawlFH1uBMauJA4=; b=WFMrimucgoUTKRgXaZHtJzSplwrRskPZe6kAKVwzxgGLGEapd3E9lGzx Ob4aUHm3O5zWoNMUXpVp96ir2tKf2f8jH+7QLnldkevc2be9kdMtNnTBS adLnpwmn91vbW/ng4WsgX8ori+79vrJfChhS7nty00wnw3bQQM0eHeH27 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwEAEYRj1StJssW/2dsb2JhbABXAxaCLYEVWLwhiTIBC4VwAoE1AQEBAQF9hAwBAQEEGgESRAECBA0EHAMBAQEBCQQICgEBBgcJAwIBAgE0BwIIBgoDBgIBAQULAQaIEQ3BBZMFAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4oKhQYRASoFCQcBFgEGBAeCHEyBMAWFH4cNhRSBfoFAgXOBCw0jgi6CECGFBgyCUzyCfCKCMIE9PTABgQuBNwEBAQ X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208,217";a="271068372" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 15 Dec 2014 16:52:17 +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 sBFGqGuF002865 for ; Mon, 15 Dec 2014 16:52:16 GMT Message-ID: <548F11C0.1030104@cisco.com> Date: Mon, 15 Dec 2014 17:52:16 +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: <548F0E0C.1050505@qti.qualcomm.com> In-Reply-To: <548F0E0C.1050505@qti.qualcomm.com> X-Forwarded-Message-Id: <548F0E0C.1050505@qti.qualcomm.com> Content-Type: multipart/alternative; boundary="------------000008080706090007090208" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/e04AiDWAs0zlGp-sflf40BvOAOw Subject: [lmap] Fwd: Re: SV: Pete Resnick's Discuss on draft-ietf-lmap-use-cases-05: (with DISCUSS) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 16:52:38 -0000 This is a multi-part message in MIME format. --------------000008080706090007090208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit FYI, for our interim today. Note: the "send notice" for all WG documents in the tracker now includes the LMAP WG. Each update from the IESG (DISCUSS/COMMENT) will now reach the WG. This is now the default for now documents, but was not changed for old documents. Regards, Benoit -------- Original Message -------- Subject: Re: SV: Pete Resnick's Discuss on draft-ietf-lmap-use-cases-05: (with DISCUSS) Date: Mon, 15 Dec 2014 10:36:28 -0600 From: Pete Resnick To: "Sørensen, Frode" CC: iesg@ietf.org , bclaise@cisco.com , philip.eardley@bt.com , lmap-chairs@tools.ietf.org , brian@innovationslab.net , draft-ietf-lmap-use-cases@tools.ietf.org Hi Frode, I'll be joining the interim call today so that we can discuss the issue, but let me talk about your suggested text below. First let me say that I think it's *vital* that regulators protocol needs are brought to the table and I have absolutely no concerns at all about documenting those needs is this draft. The important issue to me is that we're documenting their *protocol needs*, the same way we do with any users of any of our protocols. What we don't do is document their philosophies and missions; we don't have to know those things to provide them with the protocol elements they require. What concerned me about a great deal of the text about the regulators in particular (though there is some in the ISP use case as well) is that it was framed as a discussion of their internal philosophies and political mission instead of the actual use case for the protocol. For example, take the first paragraph of the ISP section: A network operator needs to understand the performance of their networks, the performance of the suppliers (downstream and upstream networks), the performance of Internet access services, and the impact that such performance has on the experience of their customers. Largely, the processes that ISPs operate (which are based on network measurement) include: That speaks in terms of the information that the ISP wants to get out of measuring the broadband network. Now, compare that to even your replacement first paragraph for the regulators: Regulators in some jurisdictions around the world are responding to consumers' adoption of Internet access services for traditional telecommunications and media services by promoting competition among providers of electronic communications. These regulators seek to use competition to increase the choice, price, and quality for users of Internet access services. This is more effective with better information, so some regulators have developed large-scale measurement programs, e.g. [FCC MBA] and [EC QBS], to gathering data to perform analysis and reporting on diverse aspects of broadband performance. That speaks in terms of promotion of competition, choice, and price, not what the regulators wish to measure. In the last sentence, it finally starts to head toward what is needed, but it doesn't come right out and say it, and then the second paragraph jumps right back into philosophical statements about "consumer, industry, and regulatory concerns". Switching to using "many" or "some" does help make the text a bit less problematic, but I really think the overall structure of the regulatory discussion makes it read as if the document has a political mission. Changing things around to describe the kind of information the regulators need, as against their political purposes in wanting that information, would allay my concerns. pr On 12/7/14 11:45 AM, Sørensen, Frode wrote: > > Pete, all, > > Thank you for your review and comments. I agree that telecoms > regulation varies around the globe, but the decision to include the > regulator use case in this draft was taken at an early stage. If IESG > stick to that conclusion, we need to describe what regulators actually > do. But this use case may not be relevant in every country, and this > was well-known when it was decided to include regulators in the LMAP work. > > I would also like to add that lots of jurisdictions outside US and EU > have regulators which encourage competition in the telecoms market. We > have REGULATEL (Latin American Forum of > Telecoms Regulators), EMERG > (Euro-Mediterranean Regulators Group) encompassing regulators from > South Europe, North Africa and the Middle East, as well as EaP > (Eastern Partnership) covering > Armenia, Azerbaijan, Belarus, Georgia, Moldova and Ukraine. These are > examples I know about based on my work in BEREC, but I assume there > may be others as well. But I also agree that in some countries there > may not be any regulator. > > Also net neutrality is becoming a target of telecoms regulation in > many regions of the world. Chile was one of the first countries, at > least before any European country, to introduce statutory net > neutrality. And I was personally attending a meeting with REGULATEL > discussing net neutrality regulation, and recently lawmakers have been > active in many countries in Latin America introducing net neutrality > laws. Also some African and Asian countries are reported to have or to > consider this. This implies that regulators may also need to measure > network traffic to assess compliance with net neutrality regulation. > > Of course, if IESG don't want to cover the regulator use case, or > don't want to cover LMAP use cases at all, I accept this. But I would > like to propose an update, which I hope will be acceptable, of the > description of the regulator use case which goes like this: We take on > board the suggestions from Alissa and Phil, in addition we can also > change from "many" to "some" in Phil's version, and we can move the > specific US and EU measurement programs to informative references, > while generalizing the related text in sections 2.2 and 4.2. This > would lead to the version below. > > Thanks, > > Frode > > 2.2 Regulator Use Case > > ---------------------------- > > Regulators in some jurisdictions around the world are responding to > > consumers' adoption of Internet access services for traditional > > telecommunications and media services by promoting competition among > > providers of electronic communications. These regulators seek to use > > competition to increase the choice, price, and quality for users of > Internet > > access services. This is more effective with better information, so some > > regulators have developed large-scale measurement programs, e.g. > > [FCC MBA] and [EC QBS], to gathering data to perform analysis and > > reporting on diverse aspects of broadband performance. > > While each jurisdiction responds to distinct consumer, industry, and > > regulatory concerns, much commonality exists in the need to produce > > datasets that can be used to compare multiple Internet access service > > providers, diverse technical solutions, geographic and regional > > distributions, and marketed and provisioned levels and combinations > > of broadband Internet access services. In some jurisdictions, the > > role of measuring is provided by a measurement provider. > > Measurement providers measure network performance from users towards > > multiple content and application providers, including dedicated test > > measurement servers, to show the performance of the actual Internet > > access service provided by different ISPs. Users need to know the > > performance that they are achieving from their own ISP. In addition, > > they need to know the performance of other ISPs of same location as > > background information for selecting their ISP. Measurement providers > > will provide measurement results with associated measurement methods > > and measurement metrics. > > From a consumer perspective, the differentiation between fixed and > > mobile (cellular) Internet access services is blurring as the > > applications used are very similar. Hence, regulators are measuring > > both fixed and mobile Internet access services. > > A regulator's role in the development and enforcement of broadband > > Internet access service policies also requires that the measurement > > approaches meet a high level of verifiability, accuracy and provider- > > independence to support valid and meaningful comparisons of Internet > > access service performance. > > LMAP standards could answer regulators shared needs by providing > > scalable, cost-effective, scientifically robust solutions to the > > measurement and collection of broadband Internet access service > > performance information. > > 4 Details of Regulator Use Case > > -------------------------------------- > > 4.1 Promoting competition through transparency > > ------------------------------------------------------------ > > Competition plays a vital role in regulation of some electronic > > communications markets. For competition to successfully discipline > > operators' behavior in the interests of their customers, end users > > must be fully aware of the characteristics of the ISPs' access > > offers. In some jurisdictions regulators mandate that transparent > > information made available about service offers. > > End users need effective transparency to be able to make informed > > choices throughout the different stages of their relationship with > > ISPs, when selecting Internet access service offers, and when > > considering switching service offer within an ISP or to an > > alternative ISP. Quality information about service offers could > > include speed, delay, and jitter. Regulators can publish such > > information to facilitate end users' choice of service provider and > > offer. It may also encourage ISPs to use the same metrics in their > > service level contracts, which would further help end users to choose > > an ISP. Finally, transparency may help content, application, service > > and device providers develop their Internet offerings. > > The published information needs to be: > > o Accurate - the measurement results must be correct and not > > influenced by errors or side effects. The results should be > > reproducible and consistent over time. > > o Comparable - common metrics should be used across different > > ISPs and service offerings so that measurement results can be > > compared. > > o Meaningful - the metrics used for measurements need to reflect > > what end users value about their broadband Internet access service > > o Reliable - the number and distribution of measurement agents, > > and the statistical processing of the raw measurement data, needs > > to be appropriate > > A set of measurement parameters and associated measurement methods > > are used over time, e.g. speed, delay, and jitter. Then the > > measurement raw data are collected and go through statistical post- > > processing before the results can be published in an Internet access > > service quality index to facilitate end users' choice of service > > provider and offer. > > The regulator can also promote competition through transparency by > > encouraging end users to monitor the performance of their own > > broadband Internet access service. They might use this information to > > check that the performance meets that specified in their contract or > > to understand whether their current subscription is the most > > appropriate. > > 4.2 Promoting broadband deployment > > ----------------------------------------------- > > Governments sometimes set strategic goals for high-speed broadband > > penetration as an important component of the economic, cultural and > > social development of the society. To evaluate the effect of the > > stimulated growth over time, broadband Internet access take-up and > > penetration of high-speed access can be monitored through measurement > > campaigns. An example of such an initiative is [DAE]. > > To monitor actual broadband Internet access performance in a specific > > country or a region, extensive measurement campaigns are needed. A > > panel can be built based on operators and packages in the market, > > spread over urban, suburban and rural areas. Probes can then be > > distributed to the participants of the campaign. > > Periodic tests running on the probes can for example measure actual > > speed at peak and off-peak hours, but also other detailed quality > > metrics like delay and jitter. Collected data goes afterwards through > > statistical analysis, deriving estimates for the whole population > > which can then be presented and published regularly. > > Using a harmonized or standardized measurement methodology, or even a > > common quality measurement platform, measurement results could also > > be used for benchmarking of providers and/or countries. > > 4.3 Monitoring "net neutrality" > > -------------------------------------- > > Regulatory approaches related to net neutrality and the open Internet > > has been introduced in some jurisdictions. Examples of such efforts > > are the Internet policy as outlined by the Body of European > > Regulators for Electronic Communications Guidelines for quality of > > service [BEREC Guidelines] and US FCC Preserving the Open Internet > > Report and Order [FCC R&O]. Although legal challenges can change the > > status of policy, the take-away for LMAP purposes is that > policy-makers are looking for > > measurement solutions to assist them in discovering biased treatment > > of traffic flows. The exact definitions and requirements vary from > > one jurisdiction to another; the comments below provide some hints > > about the potential role of measurements. > > A regulator may want to monitor traffic management practices or compare > > the performance of Internet access service with specialized services > offered > > in parallel to but separate from Internet access service (for example > IPTV). > > A regulator could monitor departures from application agnosticism > > such as blocking or throttling of traffic from specific applications, > > and preferential treatment of specific applications. A measurement > > system could send, or passively monitor, application-specific traffic > > and then measure in detail the transfer of the different packets. > > Whilst it is relatively easy to measure port blocking, it is a > > research topic how to detect other types of differentiated treatment. > > The paper, "Glasnost: Enabling End Users to Detect Traffic > > Differentiation" [M-Labs NSDI 2010] and follow-on tool "Glasnost" > > [Glasnost] are examples of work in this area. > > A regulator could also monitor the performance of the broadband > > service over time, to try and detect if the specialized service is > > provided at the expense of the Internet access service. Comparison > > between ISPs or between different countries may also be relevant for > > this kind of evaluation. > > *Fra:*Sørensen, Frode [mailto:frode.sorensen@npt.no] > *Sendt:* 4. desember 2014 10:23 > *Til:* philip.eardley@bt.com; bclaise@cisco.com; > presnick@qti.qualcomm.com; iesg@ietf.org > *Kopi:* draft-ietf-lmap-use-cases@tools.ietf.org; > lmap-chairs@tools.ietf.org; brian@innovationslab.net > *Emne:* SV: Pete Resnick's Discuss on draft-ietf-lmap-use-cases-05: > (with DISCUSS) > > Pete, all, > > Thanks for clarifying the background of the use case document, Blaise. > And thanks for your rephrasing, Phil, I support these proposals. I am > of course open to rephrase other parts as well, if needed. The way I > understand Pete's response, it is principally against the regulator > use case's style. Personally, I find this stuff relevant to the use > case, since it describes the motivation behind the use case, but of > course the appropriateness of this has to be decided by IESG. > > Best, > > Frode > > *Fra:*philip.eardley@bt.com > [mailto:philip.eardley@bt.com] > *Sendt:* 4. desember 2014 09:57 > *Til:* bclaise@cisco.com ; > presnick@qti.qualcomm.com ; > iesg@ietf.org > *Kopi:* draft-ietf-lmap-use-cases@tools.ietf.org > ; > lmap-chairs@tools.ietf.org ; > brian@innovationslab.net > *Emne:* RE: Pete Resnick's Discuss on draft-ietf-lmap-use-cases-05: > (with DISCUSS) > > Pete, > > I can see your point. To take your specific examples, I have a couple > of proposals. Frode -- feel free to disagree! > > OLD > > Competition plays a vital role in regulation of the electronic > communications markets. > > NEW > Competition plays a vital role in regulation of many electronic > communications markets. > > [I take your point that not all regulators will rely on competition to play a vital role] > > > << Governments sometimes set strategic goals for high-speed broadband > penetration as an important component of the economic, cultural and > > social development of the society.>> > > I think "sometimes" makes this sentence ok -- isn't it just a > statement of fact? > > Similarly, suggest we slightly tone down things like this:- > > OLD > > Regulators in jurisdictions around the world are responding to > consumers' adoption of Internet access services for traditional > telecommunications and media services by promoting competition among > providers of electronic communications, to ensure that users derive > maximum benefit in terms of choice, price, and quality. > > NEW > > Regulators in many jurisdictions around the world are responding to > consumers' adoption of Internet access services for traditional > telecommunications and media services by promoting competition among > providers of electronic communications. These regulators seek to use competition to increase the choice, price, and quality for users of Internet access services. > > Best wishes > > phil > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* 04 December 2014 08:16 > *To:* Pete Resnick; The IESG > *Cc:* draft-ietf-lmap-use-cases@tools.ietf.org > ; > lmap-chairs@tools.ietf.org ; 'Brian > Haberman' > *Subject:* Re: Pete Resnick's Discuss on draft-ietf-lmap-use-cases-05: > (with DISCUSS) > > Pete, Brian, > > [Let me cover Brian's abstain as well: > http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ballot/#brian-haberman] > > Let's go back to the BoF and chartering. > >From the the BoF, two primary use cases were identified: the ISP and > the regulators. > The charter has been created to make sure that both use cases are > taken into account. It's like doing the homework before specifying the > solution. > While ISPs typically participate to the IETF, it's not the case for > the regulators. > > What is the appropriate way to work with regulators? Not sure it's a WIKI. > This is the reason why the charter clearly mentions: > > The LMAP WG will produce the following work items: > 1. ... > 2. The LMAP Use Cases - provides the motivating use cases as a basis > for the work > > The LMAP community did a good job to reach out to regulators. Having a > regulator in the author list, who has been acting as a point of > contact for many regulators in Europe, is an achievement > > While I support the recent trend in the IETF/IESG to move away from > requirements and use cases when we have a clear problem statement, I > believe that: > 1. having a use cases document for LMAP is appropriate > 2. the IESG should push back on this type of document at charter > creation time, > not when the WG provides the document. > > Regarding the specific wording of some paragraph, it could be > improved, some paragraphs might be removed but ... I'm not shocked by > the text. > > Let's discuss during the IESG telechat. > > Regards, Benoit > > Pete Resnick has entered the following ballot position for > > draft-ietf-lmap-use-cases-05: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer tohttp://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > In the end, I'm not going to stand in the way of this document if there > > is consensus on its content; it is just Informational. But on our agenda, > > we are specifically asked regarding Informational documents: "Is this > > document a reasonable contribution to the area of Internet engineering > > which it covers?" And I'd like to take a moment to DISCUSS that > > question. > > > > There's a significant amount of the discussion of the ISP Use Case that > > contains a lot of fluff about business and operational models that I > > think probably doesn't belong in an IETF document, though it's nothing > > out of hand. But I'm having some real trouble with some of the discussion > > on the Regulator Use Case. Some examples: > > > > 2.2 Regulator Use Case > > > > Regulators in jurisdictions around the world are responding to > > consumers' adoption of Internet access services for traditional > > telecommunications and media services by promoting competition among > > providers of electronic communications, to ensure that users derive > > maximum benefit in terms of choice, price, and quality. > > > > Competition is more effective with better information, so some > > regulators have developed large-scale measurement programs. For > > example, programs such as the U.S. Federal Communications > > Commission's (FCC) Measuring Broadband America (MBA)... > > > > 4.1 Promoting competition through transparency > > > > Competition plays a vital role in regulation of the electronic > > communications markets. For competition to successfully discipline > > operators' behavior in the interests of their customers, end users > > must be fully aware of the characteristics of the ISPs' access > > offers. In some jurisdictions regulators mandate that transparent > > information imade available about service offers. > > > > [...] > > > > 4.2 Promoting broadband deployment > > > > Governments sometimes set strategic goals for high-speed broadband > > penetration as an important component of the economic, cultural and > > social development of the society. To evaluate the effect of the > > stimulated growth over time, broadband Internet access take-up and > > penetration of high-speed access can be monitored through measurement > > campaigns. > > > > An example of such an initiative is the "Digital Agenda for > > Europe"... > > > > It seems completely inappropriate for an Internet *Engineering* Task > > Force Working Group to be making proclamations about economic competition > > and the merits (and no notable demerits!) thereof, talking about > > competitions's "vital role in the regulation of electronic communications > > markets", and touting programs for "economic, cultural and social > > development of the society." I think it's a bit unseemly, and at some > > level (and certainly for folks from different cultures) potentially > > offensive. (And I haven't mentioned the whole net neutrality discussion > > that Alissa points out.) > > > > Is this really appropriate material for an IETF consensus document? I can > > see it as an IAB document, I can see it as an independent submission, but > > as an IETF WG document? > > > > I'd really like to hear other IESG members' opinions on this. As I said, > > in the end I won't stand in the way, but before I ABSTAIN, I'd like to > > hear what others think. > > > > > > > > > > . > > > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------000008080706090007090208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI, for our interim today.

Note: the "send notice" for all WG documents in the tracker now includes the LMAP WG.
Each update from the IESG (DISCUSS/COMMENT) will now reach the WG. This is now the default for now documents, but was not changed for old documents.

Regards, Benoit


-------- Original Message --------
Subject: Re: SV: Pete Resnick's Discuss on draft-ietf-lmap-use-cases-05: (with DISCUSS)
Date: Mon, 15 Dec 2014 10:36:28 -0600
From: Pete Resnick <presnick@qti.qualcomm.com>
To: "Sørensen, Frode" <frode.sorensen@npt.no>
CC: iesg@ietf.org <iesg@ietf.org>, bclaise@cisco.com <bclaise@cisco.com>, philip.eardley@bt.com <philip.eardley@bt.com>, lmap-chairs@tools.ietf.org <lmap-chairs@tools.ietf.org>, brian@innovationslab.net <brian@innovationslab.net>, draft-ietf-lmap-use-cases@tools.ietf.org <draft-ietf-lmap-use-cases@tools.ietf.org>


Hi Frode,

I'll be joining the interim call today so that we can discuss the issue, but let me talk about your suggested text below.

First let me say that I think it's *vital* that regulators protocol needs are brought to the table and I have absolutely no concerns at all about documenting those needs is this draft. The important issue to me is that we're documenting their *protocol needs*, the same way we do with any users of any of our protocols. What we don't do is document their philosophies and missions; we don't have to know those things to provide them with the protocol elements they require. What concerned me about a great deal of the text about the regulators in particular (though there is some in the ISP use case as well) is that it was framed as a discussion of their internal philosophies and political mission instead of the actual use case for the protocol. For example, take the first paragraph of the ISP section:

   A network operator needs to understand the performance of their
   networks, the performance of the suppliers (downstream and upstream
   networks), the performance of Internet access services, and the
   impact that such performance has on the experience of their
   customers. Largely, the processes that ISPs operate (which are based
   on network measurement) include:

That speaks in terms of the information that the ISP wants to get out of measuring the broadband network. Now, compare that to even your replacement first paragraph for the regulators:

   Regulators in some jurisdictions around the world are responding to
   consumers’ adoption of Internet access services for traditional
   telecommunications and media services by promoting competition among
   providers of electronic communications. These regulators seek to use
   competition to increase the choice, price, and quality for users of
   Internet access services. This is more effective with better
   information, so some regulators have developed large-scale
   measurement programs, e.g. [FCC MBA] and [EC QBS], to gathering data
   to perform analysis and reporting on diverse aspects of broadband
   performance.

That speaks in terms of promotion of competition, choice, and price, not what the regulators wish to measure.  In the last sentence, it finally starts to head toward what is needed, but it doesn't come right out and say it, and then the second paragraph jumps right back into philosophical statements about "consumer, industry, and regulatory concerns".

Switching to using "many" or "some" does help make the text a bit less problematic, but I really think the overall structure of the regulatory discussion makes it read as if the document has a political mission. Changing things around to describe the kind of information the regulators need, as against their political purposes in wanting that information, would allay my concerns.

pr

On 12/7/14 11:45 AM, Sørensen, Frode wrote:

Pete, all,

 

Thank you for your review and comments. I agree that telecoms regulation varies around the globe, but the decision to include the regulator use case in this draft was taken at an early stage. If IESG stick to that conclusion, we need to describe what regulators actually do. But this use case may not be relevant in every country, and this was well-known when it was decided to include regulators in the LMAP work.

 

I would also like to add that lots of jurisdictions outside US and EU have regulators which encourage competition in the telecoms market. We have REGULATEL (Latin American Forum of Telecoms Regulators), EMERG (Euro-Mediterranean Regulators Group) encompassing regulators from South Europe, North Africa and the Middle East, as well as EaP  (Eastern Partnership) covering Armenia, Azerbaijan, Belarus, Georgia, Moldova and Ukraine. These are examples I know about based on my work in BEREC, but I assume there may be others as well. But I also agree that in some countries there may not be any regulator.

 

Also net neutrality is becoming a target of telecoms regulation in many regions of the world. Chile was one of the first countries, at least before any European country, to introduce statutory net neutrality. And I was personally attending a meeting with REGULATEL discussing net neutrality regulation, and recently lawmakers have been active in many countries in Latin America introducing net neutrality laws. Also some African and Asian countries are reported to have or to consider this. This implies that regulators may also need to measure network traffic to assess compliance with net neutrality regulation.

 

Of course, if IESG don’t want to cover the regulator use case, or don’t want to cover LMAP use cases at all, I accept this. But I would like to propose an update, which I hope will be acceptable, of the description of the regulator use case which goes like this: We take on board the suggestions from Alissa and Phil, in addition we can also change from “many” to “some” in Phil’s version, and we can move the specific US and EU measurement programs to informative references, while generalizing the related text in sections 2.2 and 4.2. This would lead to the version below.

 

Thanks,

Frode

 

 

2.2 Regulator Use Case

----------------------------

Regulators in some jurisdictions around the world are responding to

consumers’ adoption of Internet access services for traditional

telecommunications and media services by promoting competition among

providers of electronic communications. These regulators seek to use

competition to increase the choice, price, and quality for users of Internet

access services. This is more effective with better information, so some

regulators have developed large-scale measurement programs, e.g.

[FCC MBA] and [EC QBS], to gathering data to perform analysis and

reporting on diverse aspects of broadband performance.

 

While each jurisdiction responds to distinct consumer, industry, and

regulatory concerns, much commonality exists in the need to produce

datasets that can be used to compare multiple Internet access service

providers, diverse technical solutions, geographic and regional

distributions, and marketed and provisioned levels and combinations

of broadband Internet access services. In some jurisdictions, the

role of measuring is provided by a measurement provider.

 

Measurement providers measure network performance from users towards

multiple content and application providers, including dedicated test

measurement servers, to show the performance of the actual Internet

access service provided by different ISPs. Users need to know the

performance that they are achieving from their own ISP. In addition,

they need to know the performance of other ISPs of same location as

background information for selecting their ISP. Measurement providers

will provide measurement results with associated measurement methods

and measurement metrics.

 

From a consumer perspective, the differentiation between fixed and

mobile (cellular) Internet access services is blurring as the

applications used are very similar. Hence, regulators are measuring

both fixed and mobile Internet access services.

 

A regulator’s role in the development and enforcement of broadband

Internet access service policies also requires that the measurement

approaches meet a high level of verifiability, accuracy and provider-

independence to support valid and meaningful comparisons of Internet

access service performance.

 

LMAP standards could answer regulators shared needs by providing

scalable, cost-effective, scientifically robust solutions to the

measurement and collection of broadband Internet access service

performance information.

 

4 Details of Regulator Use Case

--------------------------------------

4.1 Promoting competition through transparency

------------------------------------------------------------

Competition plays a vital role in regulation of some electronic

communications markets. For competition to successfully discipline

operators’ behavior in the interests of their customers, end users

must be fully aware of the characteristics of the ISPs’ access

offers. In some jurisdictions regulators mandate that transparent

information made available about service offers.

 

End users need effective transparency to be able to make informed

choices throughout the different stages of their relationship with

ISPs, when selecting Internet access service offers, and when

considering switching service offer within an ISP or to an

alternative ISP. Quality information about service offers could

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

information to facilitate end users’ choice of service provider and

offer. It may also encourage ISPs to use the same metrics in their

service level contracts, which would further help end users to choose

an ISP. Finally, transparency may help content, application, service

and device providers develop their Internet offerings.

 

The published information needs to be:

o Accurate - the measurement results must be correct and not

influenced by errors or side effects. The results should be

reproducible and consistent over time.

o Comparable - common metrics should be used across different

ISPs and service offerings so that measurement results can be

compared.

o Meaningful - the metrics used for measurements need to reflect

what end users value about their broadband Internet access service

o Reliable - the number and distribution of measurement agents,

and the statistical processing of the raw measurement data, needs

to be appropriate

 

A set of measurement parameters and associated measurement methods

are used over time, e.g. speed, delay, and jitter. Then the

measurement raw data are collected and go through statistical post-

processing before the results can be published in an Internet access

service quality index to facilitate end users’ choice of service

provider and offer.

 

The regulator can also promote competition through transparency by

encouraging end users to monitor the performance of their own

broadband Internet access service. They might use this information to

check that the performance meets that specified in their contract or

to understand whether their current subscription is the most

appropriate.

 

4.2 Promoting broadband deployment

-----------------------------------------------

Governments sometimes set strategic goals for high-speed broadband

penetration as an important component of the economic, cultural and

social development of the society. To evaluate the effect of the

stimulated growth over time, broadband Internet access take-up and

penetration of high-speed access can be monitored through measurement

campaigns. An example of such an initiative is [DAE].

 

To monitor actual broadband Internet access performance in a specific

country or a region, extensive measurement campaigns are needed. A

panel can be built based on operators and packages in the market,

spread over urban, suburban and rural areas. Probes can then be

distributed to the participants of the campaign.

 

Periodic tests running on the probes can for example measure actual

speed at peak and off-peak hours, but also other detailed quality

metrics like delay and jitter. Collected data goes afterwards through

statistical analysis, deriving estimates for the whole population

which can then be presented and published regularly.

 

Using a harmonized or standardized measurement methodology, or even a

common quality measurement platform, measurement results could also

be used for benchmarking of providers and/or countries.

 

4.3 Monitoring "net neutrality"

--------------------------------------

Regulatory approaches related to net neutrality and the open Internet

has been introduced in some jurisdictions. Examples of such efforts

are the Internet policy as outlined by the Body of European

Regulators for Electronic Communications Guidelines for quality of

service [BEREC Guidelines] and US FCC Preserving the Open Internet

Report and Order [FCC R&O]. Although legal challenges can change the

status of policy, the take-away for LMAP purposes is that policy-makers are looking for

measurement solutions to assist them in discovering biased treatment

of traffic flows. The exact definitions and requirements vary from

one jurisdiction to another; the comments below provide some hints

about the potential role of measurements.

 

A regulator may want to monitor traffic management practices or compare

the performance of Internet access service with specialized services offered

in parallel to but separate from Internet access service  (for example IPTV).

A regulator could monitor departures from application agnosticism

such as blocking or throttling of traffic from specific applications,

and preferential treatment of specific applications. A measurement

system could send, or passively monitor, application-specific traffic

and then measure in detail the transfer of the different packets.

Whilst it is relatively easy to measure port blocking, it is a

research topic how to detect other types of differentiated treatment.

The paper, "Glasnost: Enabling End Users to Detect Traffic

Differentiation" [M-Labs NSDI 2010] and follow-on tool "Glasnost"

[Glasnost] are examples of work in this area.

 

A regulator could also monitor the performance of the broadband

service over time, to try and detect if the specialized service is

provided at the expense of the Internet access service. Comparison

between ISPs or between different countries may also be relevant for

this kind of evaluation.

 

 

Fra: Sørensen, Frode [mailto:frode.sorensen@npt.no]
Sendt: 4. desember 2014 10:23
Til: philip.eardley@bt.com; bclaise@cisco.com; presnick@qti.qualcomm.com; iesg@ietf.org
Kopi: draft-ietf-lmap-use-cases@tools.ietf.org; lmap-chairs@tools.ietf.org; brian@innovationslab.net
Emne: SV: Pete Resnick's Discuss on draft-ietf-lmap-use-cases-05: (with DISCUSS)

 

Pete, all,

 

Thanks for clarifying the background of the use case document, Blaise. And thanks for your rephrasing, Phil, I support these proposals. I am of course open to rephrase other parts as well, if needed. The way I understand Pete’s response, it is principally against the regulator use case’s style. Personally, I find this stuff relevant to the use case, since it describes the motivation behind the use case, but of course the appropriateness of this has to be decided by IESG.

 

Best,

Frode

 

Fra: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sendt: 4. desember 2014 09:57
Til: bclaise@cisco.com; presnick@qti.qualcomm.com; iesg@ietf.org
Kopi: draft-ietf-lmap-use-cases@tools.ietf.org; lmap-chairs@tools.ietf.org; brian@innovationslab.net
Emne: RE: Pete Resnick's Discuss on draft-ietf-lmap-use-cases-05: (with DISCUSS)

 

Pete,

I can see your point. To take your specific examples, I have a couple of proposals. Frode – feel free to disagree!

 

OLD

   Competition plays a vital role in regulation of the electronic
   communications markets. 
 
NEW
   Competition plays a vital role in regulation of many electronic
   communications markets. 
 
[I take your point that not all regulators will rely on competition to play a vital role]
 

 

<< Governments sometimes set strategic goals for high-speed broadband
   penetration as an important component of the economic, cultural and

   social development of the society.>>

I think “sometimes” makes this sentence ok – isn’t it just a statement of fact?

 

 

Similarly, suggest we slightly tone down things like this:-

OLD

Regulators in jurisdictions around the world are responding to
   consumers' adoption of Internet access services for traditional
   telecommunications and media services by promoting competition among
   providers of electronic communications, to ensure that users derive
   maximum benefit in terms of choice, price, and quality.

 

NEW

Regulators in many jurisdictions around the world are responding to
   consumers' adoption of Internet access services for traditional
   telecommunications and media services by promoting competition among
   providers of electronic communications. These regulators seek to use competition to increase the choice, price, and quality for users of Internet access services.

 

Best wishes

phil

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: 04 December 2014 08:16
To: Pete Resnick; The IESG
Cc: draft-ietf-lmap-use-cases@tools.ietf.org; lmap-chairs@tools.ietf.org; 'Brian Haberman'
Subject: Re: Pete Resnick's Discuss on draft-ietf-lmap-use-cases-05: (with DISCUSS)

 

Pete, Brian,

[Let me cover Brian's abstain as well: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ballot/#brian-haberman]

Let's go back to the BoF and chartering.
>From the the BoF, two primary use cases were identified: the ISP and the regulators.
The charter has been created to make sure that both use cases are taken into account. It's like doing the homework before specifying the solution.
While ISPs typically participate to the IETF, it's not the case for the regulators.

What is the appropriate way to work with regulators? Not sure it's a WIKI.
This is the reason why the charter clearly mentions:

The LMAP WG will produce the following work items:
1. ...
2. The LMAP Use Cases - provides the motivating use cases as a basis for the work

The LMAP community did a good job to reach out to regulators. Having a regulator in the author list, who has been acting as a point of contact for many regulators in Europe, is an achievement

While I support the recent trend in the IETF/IESG to move away from requirements and use cases when we have a clear problem statement, I believe that:
    1. having a use cases document for LMAP is appropriate
    2. the IESG should push back on this type of document at charter creation time,
        not when the WG provides the document.

Regarding the specific wording of some paragraph, it could be improved, some paragraphs might be removed but ... I'm not shocked by the text.

Let's discuss during the IESG telechat.

Regards, Benoit

Pete Resnick has entered the following ballot position for
draft-ietf-lmap-use-cases-05: Discuss
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/
 
 
 
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
 
In the end, I'm not going to stand in the way of this document if there
is consensus on its content; it is just Informational. But on our agenda,
we are specifically asked regarding Informational documents: "Is this
document a reasonable contribution to the area of Internet engineering
which it covers?" And I'd like to take a moment to DISCUSS that
question.
 
There's a significant amount of the discussion of the ISP Use Case that
contains a lot of fluff about business and operational models that I
think probably doesn't belong in an IETF document, though it's nothing
out of hand. But I'm having some real trouble with some of the discussion
on the Regulator Use Case. Some examples:
 
2.2 Regulator Use Case
 
   Regulators in jurisdictions around the world are responding to
   consumers' adoption of Internet access services for traditional
   telecommunications and media services by promoting competition among
   providers of electronic communications, to ensure that users derive
   maximum benefit in terms of choice, price, and quality.
 
   Competition is more effective with better information, so some
   regulators have developed large-scale measurement programs. For
   example, programs such as the U.S. Federal Communications
   Commission's (FCC) Measuring Broadband America (MBA)...
   
4.1 Promoting competition through transparency
 
   Competition plays a vital role in regulation of the electronic
   communications markets. For competition to successfully discipline
   operators' behavior in the interests of their customers, end users
   must be fully aware of the characteristics of the ISPs' access
   offers. In some jurisdictions regulators mandate that transparent
   information imade available about service offers.
   
   [...]
 
4.2 Promoting broadband deployment
 
   Governments sometimes set strategic goals for high-speed broadband
   penetration as an important component of the economic, cultural and
   social development of the society. To evaluate the effect of the
   stimulated growth over time, broadband Internet access take-up and
   penetration of high-speed access can be monitored through measurement
   campaigns.
 
   An example of such an initiative is the "Digital Agenda for
Europe"...
 
It seems completely inappropriate for an Internet *Engineering* Task
Force Working Group to be making proclamations about economic competition
and the merits (and no notable demerits!) thereof, talking about
competitions's "vital role in the regulation of electronic communications
markets", and touting programs for "economic, cultural and social
development of the society." I think it's a bit unseemly, and at some
level (and certainly for folks from different cultures) potentially
offensive. (And I haven't mentioned the whole net neutrality discussion
that Alissa points out.)
 
Is this really appropriate material for an IETF consensus document? I can
see it as an IAB document, I can see it as an independent submission, but
as an IETF WG document?
 
I'd really like to hear other IESG members' opinions on this. As I said,
in the end I won't stand in the way, but before I ABSTAIN, I'd like to
hear what others think.
 
 
 
 
.
 

 


-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478


--------------000008080706090007090208-- From nobody Mon Dec 15 09:43:45 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFEB1A8709 for ; Mon, 15 Dec 2014 09:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 Oexs6Wmqu6QH for ; Mon, 15 Dec 2014 09:43:41 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C401A8714 for ; Mon, 15 Dec 2014 09:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13894; q=dns/txt; s=iport; t=1418665420; x=1419875020; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=lTX+V58xxVkPvdx3DLbNd5J+aup6IBsaNkIVpQ1L3Ak=; b=gX4xedpuPu0dNU4b9+PprmtxGTgXESjI4Q1VfJFkOEUbZZ+A45DW7Cc5 ExexMobwjo16+KC0tzBCFjHGGLrL3Ekik5DSufOuMYJILy32rvpj91Apr Fl4HeMIMpp5Y+I/LRov4NZtGQCFpU77yCnnFxP5sDGz4FUYXDKROfobm3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAIwcj1StJssW/2dsb2JhbABag1hYgwa5G4k8hXICgTcBAQEBAX2EDAEBAQQjVQ0EHAMBAgoWCwICCQMCAQIBDywCCAYNBgIBAQUSh30DEQ29a5BdDYUyAQEBAQEBAQECAQEBAQEBAQEBAQEXjUqBRhEBLhEYBoJigUEFhR+HDYUUg26BQ4ELMIIughAhhRI6ghmDOCKCMIE9PTABgQuBNwEBAQ X-IronPort-AV: E=Sophos;i="5.07,581,1413244800"; d="scan'208,217";a="275208477" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 15 Dec 2014 17:43:37 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBFHhaDF017580 for ; Mon, 15 Dec 2014 17:43:36 GMT Message-ID: <548F1DC8.3080608@cisco.com> Date: Mon, 15 Dec 2014 18:43:36 +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: <20141203150933.21842.60071.idtracker@ietfa.amsl.com> In-Reply-To: <20141203150933.21842.60071.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141203150933.21842.60071.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------060602090300070207050409" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/uc9_E-_OHFQd94WRreqGy5Pa_xk Subject: [lmap] Fwd: Kathleen Moriarty's Discuss on draft-ietf-lmap-use-cases-05: (with DISCUSS) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 17:43:44 -0000 This is a multi-part message in MIME format. --------------060602090300070207050409 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI. Regards, Benoit -------- Original Message -------- Subject: Kathleen Moriarty's Discuss on draft-ietf-lmap-use-cases-05: (with DISCUSS) Date: Wed, 3 Dec 2014 07:09:33 -0800 From: Kathleen Moriarty To: The IESG CC: , Kathleen Moriarty has entered the following ballot position for draft-ietf-lmap-use-cases-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The draft is well written and easy to read, thank you for that. I just have one concerns I'd like to chat about: Section 3.1, second to last paragraph This discusses the probes nicely in terms of privacy concerns, but leaves out the security concerns that have resulted in any type of probe traffic being blocked in the past. If you are going to leave the privacy concerns in this section, you should also have the security concerns with network mapping and the ability to use this information to assess open ports as well as path information that could be used in the first case to attack/compromise a host or for denial of service attacks for the first and second case. Path information is mentioned in 3.3, so perhaps the DoS mention would be better there and the general security along with the privacy in section 3.1. Later section 5 mentioned the use of an app to gather information from the end user as opposed to their gateway. Security and privacy considerations should be mentioned here as well since they differ from the the probe scenario. I would not recommend going in depth on this topic as this is just the use case document, but rather mentioning it. It would be out-of-scope to get to deep into application security and protections from compromise or the ability to gather privacy information about the user patterns. A high level statement of those concerns is enough (IMO) and can get addressed in the solution documents. Apps and desktop tools can be directly associated with a user as opposed to a home and can lead to desktop compromise, so this is different than the previously mentioned privacy concerns in section 3. I am aware that these types of services are available today via web pages and is up to the user to initiate. Section 7 First bullet I'd keep DoS attacks restricted to the degradation of service and have the points on privacy and business confidentiality listed separately as merging them confusing the points and attack vectors. Both can potentially use information gathered from the probes or the actual management station itself, but in different ways, this isn't clear from the bullet. The DoS could be launched directly from the management station or information about the network and path to hosts could be used to launch a targeted DoS attack. The accuracy of the measurement system mentioned in the last part of the bullet makes sense combined with the Dos Attack. For privacy, you could collect patterns of use to understand user behavior (already in bullet 2). Additionally, one could use the information gathered from probes to determine open ports and potential vulnerabilities that could be used to compromise the end point (security concern). For business confidentiality, I'm not sure what you mean here. Is this referring to an ability to gather endpoint information to monitor along paths for a business? I would assume that the probe traffic will be designed to include innocuous information and will just be used for measurement data. It looks as is the SecDir reviewer had similar concerns with the connections between points made in bullet one, so it would be good to fix this and I hope my above explanation is enough to help you adjust the text and add the additional considerations. I'm happy to help with the text if needed. The suggested text to the SecDir review is helpful, but would need to change to address the additional concerns I raised (thanks for your work on that with Hannes!). http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security The SecDir review had a few other good points for bullet 6 that you have addressed with proposed text and your proposed text is included here for tracking purposes: Part of Hannes' request: * prevent unauthorized access to collected measurement data, * give users the ability to view collected data, * give users the ability to exert control over sharing, and * enforce retention periods. ** Editor's proposed text on all points for bullet 6: 6. a measurement system that does not indicate who is responsible for the collection and processing of personal data and who is responsible for fulfilling the rights of users. The responsible party (often termed the "data controller") should, as good practice, consider issues such as defining:- the purpose for which the data is collected and used; how the data is stored, accessed, and processed; how long it is retained for; and how the end user can view, update, and even delete their personal data. If anonymised personal data is shared with a third party, the data controller should consider the possibility that the third party can de-anonymise it by combining it with other information. . --------------060602090300070207050409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI.

Regards, Benoit


-------- Original Message --------
Subject: Kathleen Moriarty's Discuss on draft-ietf-lmap-use-cases-05: (with DISCUSS)
Date: Wed, 3 Dec 2014 07:09:33 -0800
From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
CC: <draft-ietf-lmap-use-cases@tools.ietf.org>, <lmap-chairs@tools.ietf.org> 


Kathleen Moriarty has entered the following ballot position for
draft-ietf-lmap-use-cases-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The draft is well written and easy to read, thank you for that.

I just have one concerns I'd like to chat about:

Section 3.1, second to last paragraph
This discusses the probes nicely in terms of privacy concerns, but leaves
out the security concerns that have resulted in any type of probe traffic
being blocked in the past.  If you are going to leave the privacy
concerns in this section, you should also have the security concerns with
network mapping and the ability to use this information to assess open
ports as well as path information that could be used in the first case to
attack/compromise a host or for denial of service attacks for the first
and second case.  Path information is mentioned in 3.3, so perhaps the
DoS mention would be better there and the general security along with the
privacy in section 3.1.

Later section 5 mentioned the use of an app to gather information from
the end user as opposed to their gateway.  Security and privacy
considerations should be mentioned here as well since they differ from
the the probe scenario.  I would not recommend going in depth on this
topic as this is just the use case document, but rather mentioning it. 
It would be out-of-scope to get to deep into application security and
protections from compromise or the ability to gather privacy information
about the user patterns.  A high level statement of those concerns is
enough (IMO) and can get addressed in the solution documents.  Apps and
desktop tools can be directly associated with a user as opposed to a home
and can lead to desktop compromise, so this is different than the
previously mentioned privacy concerns in section 3.  I am aware that
these types of services are available today via web pages and is up to
the user to initiate.

Section 7
First bullet
I'd keep DoS attacks restricted to the degradation of service and have
the points on privacy and business confidentiality listed separately as
merging them confusing the points and attack vectors.  Both can
potentially use information gathered from the probes or the actual
management station itself, but in different ways, this isn't clear from
the bullet.  The DoS could be launched directly from the management
station or information about the network and path to hosts could be used
to launch a targeted DoS attack.  The accuracy of the measurement system
mentioned in the last part of the bullet makes sense combined with the
Dos Attack.
For privacy, you could collect patterns of use to understand user
behavior (already in bullet 2).  Additionally, one could use the
information gathered from probes to determine open ports and potential
vulnerabilities that could be used to compromise the end point (security
concern).  
For business confidentiality, I'm not sure what you mean here.  Is this
referring to an ability to gather endpoint information to monitor along
paths for a business?  I would assume that the probe traffic will be
designed to include innocuous information and will just be used for
measurement data.

It looks as is the SecDir reviewer had similar concerns with the
connections between points made in bullet one, so it would be good to fix
this and I hope my above explanation is enough to help you adjust the
text and add the additional considerations.  I'm happy to help with the
text if needed.  The suggested text to the SecDir review is helpful, but
would need to change to address the additional concerns I raised (thanks
for your work on that with Hannes!).

http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security

The SecDir review had a few other good points for bullet 6 that you have
addressed with proposed text and your proposed text is included here for
tracking purposes:
Part of Hannes' request:

 * prevent unauthorized access to collected measurement data,
 * give users the ability to view collected data,
 * give users the ability to exert control over sharing, and
 * enforce retention periods.

** Editor's proposed text on all points for bullet 6:
6. a measurement system that does not indicate who is responsible for the
collection and processing of personal data and who is responsible for
fulfilling the rights of users. The responsible party (often termed the
"data controller") should, as good practice, consider issues such as
defining:- the purpose for which the data is collected and used; how the
data is stored, accessed, and processed; how long it is retained for; and
how the end user can view, update, and even delete their personal data.
If anonymised personal data is shared with a third party, the data
controller should consider the possibility that the third party can
de-anonymise it by combining it with other information.




.


--------------060602090300070207050409-- From nobody Mon Dec 15 10:46:45 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D9B1A875D for ; Mon, 15 Dec 2014 10:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.908 X-Spam-Level: X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, TVD_SPACE_RATIO=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 JzAxe2GazMi2 for ; Mon, 15 Dec 2014 10:46:41 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011411A8761 for ; Mon, 15 Dec 2014 10:46:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcFAMorj1TGmAcV/2dsb2JhbABagkMhIiIwWASzEAEBAQEBAQaSESMBC4VwAoElFgEBAQEBAXgEhA4BAQMSG14BDAkVVh8HAQQbARmICgEMriuEeaEhhgCJQYJlDEAdgRMFjgKOfosoIoFRghtuAYFEfgEBAQ X-IronPort-AV: E=Sophos; i="5.07,581,1413259200"; d="scan'208,217"; a="84736550" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Dec 2014 13:46:05 -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 Dec 2014 13:46:04 -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; Mon, 15 Dec 2014 19:46:03 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: today's meeting proceedings Thread-Index: AdAYl2AEWBuNs32xRdGD8uIdifLQtQ== Date: Mon, 15 Dec 2014 18:46:02 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C930AAF@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_9904FB1B0159DA42B0B887B7FA8119CA5C930AAFAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/xpl9oQocruv4dCZ3Tnl-zZJiAQs Subject: [lmap] today's meeting proceedings X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 18:46:44 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C930AAFAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The proceedings of the LMAP WG meeting today are available at http://www.ie= tf.org/proceedings/interim/2014/12/15/lmap/proceedings.html. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C930AAFAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The proceedings of the LMAP WG meeting today are ava= ilable at http://www.ietf.org/proceedings/interim/2014/12/15/lmap/proceedings.html.

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C930AAFAZFFEXMB04globa_-- From nobody Tue Dec 16 04:25:40 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61D51A1AF1 for ; Tue, 16 Dec 2014 04:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 Cbax5ax-hi8V for ; Tue, 16 Dec 2014 04:25:34 -0800 (PST) Received: from worker2.doodle.com (worker2.doodle.com [94.230.219.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449511A1ACE for ; Tue, 16 Dec 2014 04:25:34 -0800 (PST) Received: from worker2.doodle.com (localhost [127.0.0.1]) by worker2.doodle.com (Postfix) with ESMTP id 07618928411 for ; Tue, 16 Dec 2014 13:25:32 +0100 (CET) Date: Tue, 16 Dec 2014 13:25:32 +0100 (CET) From: "Dan Romascanu (via Doodle)" To: Message-ID: <848498526.3968072.1418732732028.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE.doodle@worker2> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3968071_2117292069.1418732732027" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/v5qu7DMFKwiJ0206Dy-1_qCanP8 Subject: [lmap] February 2015 LMAP WG Virtual Interim Meeting X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Dan Romascanu List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 12:25:37 -0000 ------=_Part_3968071_2117292069.1418732732027 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi there, Dan Romascanu (dromasca@avaya.com) invites you to participate in the Doodle poll "February 2015 LMAP WG Virtual Interim Meeting". Dan Romascanu says: Virtual Interim meeting of the IETF LMAP WG Participate now https://doodle.com/uiq9q7ymd7f5ewub?tmail=3Dpoll_invitecontact_participant_= invitation_with_message&tlink=3Dpollbtn What is Doodle? Doodle is a web service that helps Dan Romascanu to find a suitable date for meeting with a group of people. Learn more about how Doodle works. (https://doodle.com/main.html?tlink=3DcheckOutLink&tmail=3Dpoll_inviteconta= ct_participant_invitation_with_message) ---------------------------------------------------------------------- You have received this e-mail because "Dan Romascanu" has invited you to participate in the Doodle poll "February 2015 LMAP WG Virtual Interim Meeting." ---- Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich ------=_Part_3968071_2117292069.1418732732027 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =
=09
Dan Romascanu invites you t= o participate in the Doodle poll "February 2015 LMAP WG Virtual Interi= m Meeting."
=09
=09 =09 =09
=09 =09=09 =09=09 =09=09=09=09=09=09=09 =09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09
=09=09 =09=09=09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09=09=09 =09=09 =09=09 =09=09 =09=09 =09 =09=09 =09=09
=09=09 =09 =09=09 =09 =09=09=09 =09 =09=09=09
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =20 =20 =09=09=09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
"February 201= 5 LMAP WG Virtual Interim Meeting". =09=09=09=09=09=09
=09=09=09=09=09
=09=09 =09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09Dan Romascanu says: =09=09=09=09=09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09Virtual Interim meeting of the IETF LMAP WG =09=09=09=09=09=09
=09=09=09=09=09
=20 =09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=
=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09=09=09Participate now =09=09=09=09=09=09=09
=09=09=09=09=09
=
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09
=20 =09=09=09=09=09=09=09 What is Doodle? Doodle is a web service that helps Dan Romascanu to find a suitable date= for meeting with a group of people. Learn more about how Doodle works.
=20 =09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09=09 =20 =09=09
=09=09 =09You have received this e-mail because "Dan Romascanu&= quot; has invited you to participate in the Doodle poll "February 2015= LMAP WG Virtual Interim Meeting." =09=09
=09
=20
Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich

------=_Part_3968071_2117292069.1418732732027--