From marcelo@it.uc3m.es Thu Oct 4 22:10:11 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148BC21F85F3 for ; Thu, 4 Oct 2012 22:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqdZb4lQkSuS for ; Thu, 4 Oct 2012 22:10:10 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4858821F85EF for ; Thu, 4 Oct 2012 22:10:09 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (222.38.218.87.dynamic.jazztel.es [87.218.38.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 9799B9D7209 for ; Fri, 5 Oct 2012 07:10:06 +0200 (CEST) Message-ID: <506E6BAB.2010606@it.uc3m.es> Date: Fri, 05 Oct 2012 07:10:03 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: lmap@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTHACL 134 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Fri, 05 Oct 2012 07:10:06 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19242.001 X-TM-AS-Result: No--1.496-7.0-31-1 X-imss-scan-details: No--1.496-7.0-31-1 Subject: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 05:10:11 -0000 Hi, I just saw that the LMAP BOF was not approved for Atlanta. Does anybody knows why it was not approved? What are the next steps? Regards, marcelo From hannes.tschofenig@gmx.net Thu Oct 4 23:59:13 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EE221F85C7 for ; Thu, 4 Oct 2012 23:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOaInN0kdtrK for ; Thu, 4 Oct 2012 23:59:12 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4BE5521F85C6 for ; Thu, 4 Oct 2012 23:59:12 -0700 (PDT) Received: (qmail invoked by alias); 05 Oct 2012 06:59:11 -0000 Received: from unknown (EHLO [10.255.128.40]) [194.251.119.201] by mail.gmx.net (mp036) with SMTP; 05 Oct 2012 08:59:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/F2iQWaqHFPtbJbY9z+PJtRtvkP3me6Qn95lic7E PZ9cwu1M09+MKp Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <506E6BAB.2010606@it.uc3m.es> Date: Fri, 5 Oct 2012 09:59:08 +0300 Content-Transfer-Encoding: 7bit Message-Id: <4C54A1BF-9D02-4CE7-BA58-985A5F881B7A@gmx.net> References: <506E6BAB.2010606@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig , lmap@ietf.org Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 06:59:13 -0000 Nobody did any preparation for the BOF. Look at the mailing list: no discussion regarding a BOF. On Oct 5, 2012, at 8:10 AM, marcelo bagnulo braun wrote: > Hi, > > I just saw that the LMAP BOF was not approved for Atlanta. > Does anybody knows why it was not approved? > What are the next steps? > > Regards, marcelo > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From jason_livingood@cable.comcast.com Fri Oct 5 06:20:03 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BA921F8714 for ; Fri, 5 Oct 2012 06:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5p9O6TfDkMj for ; Fri, 5 Oct 2012 06:20:03 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id C3B9621F870B for ; Fri, 5 Oct 2012 06:20:02 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.36343057; Fri, 05 Oct 2012 06:46:55 -0600 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.64]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 09:09:37 -0400 From: "Livingood, Jason" To: Hannes Tschofenig , marcelo bagnulo braun Thread-Topic: [lmap] BOF not approved? Thread-Index: AQHNore3VXTel7BurEKSo4ljwsWnGpeqi3MAgAAkdgA= Date: Fri, 5 Oct 2012 13:09:37 +0000 Message-ID: <10229F86C86EB444898E629583FD417118C703CA@PACDCEXMB06.cable.comcast.com> In-Reply-To: <4C54A1BF-9D02-4CE7-BA58-985A5F881B7A@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: <41B534319E9D4D409D3C378243A67733@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:20:03 -0000 My original suggestion to a few folks (before this list was established) was to do this work in the IRTF. Perhaps we can arrange something there, even if an informal discussion of what is needed and how we might proceed? Failing that, a bar BoF would be helpful. Jason On 10/5/12 2:59 AM, "Hannes Tschofenig" wrote: >Nobody did any preparation for the BOF. > >Look at the mailing list: no discussion regarding a BOF. > >On Oct 5, 2012, at 8:10 AM, marcelo bagnulo braun wrote: > >> Hi, >>=20 >> I just saw that the LMAP BOF was not approved for Atlanta. >> Does anybody knows why it was not approved? >> What are the next steps? >>=20 >> Regards, marcelo >>=20 >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From lars@netapp.com Fri Oct 5 06:46:14 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7554521F8768 for ; Fri, 5 Oct 2012 06:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugvLtOcTUdKA for ; Fri, 5 Oct 2012 06:46:14 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 01C0721F8767 for ; Fri, 5 Oct 2012 06:46:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,541,1344236400"; d="p7s'?scan'208";a="697682236" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 05 Oct 2012 06:46:13 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q95DkCm6001094; Fri, 5 Oct 2012 06:46:13 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.46]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0309.002; Fri, 5 Oct 2012 06:46:11 -0700 From: "Eggert, Lars" To: "Livingood, Jason" Thread-Topic: [lmap] BOF not approved? Thread-Index: AQHNore1iDgskRV33EWTDeqJd7hdtpeqvb0AgABng4CAAAougA== Date: Fri, 5 Oct 2012 13:46:11 +0000 Message-ID: References: <10229F86C86EB444898E629583FD417118C703CA@PACDCEXMB06.cable.comcast.com> In-Reply-To: <10229F86C86EB444898E629583FD417118C703CA@PACDCEXMB06.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_7A3A1082-E0FA-4DAC-9709-905B58706C17"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: marcelo bagnulo braun , Hannes Tschofenig , "lmap@ietf.org" Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:46:14 -0000 --Apple-Mail=_7A3A1082-E0FA-4DAC-9709-905B58706C17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 5, 2012, at 15:09, "Livingood, Jason" = wrote: > My original suggestion to a few folks (before this list was = established) > was to do this work in the IRTF. Perhaps we can arrange something = there, > even if an informal discussion of what is needed and how we might = proceed? > Failing that, a bar BoF would be helpful. I'm happy to get you guys a room for an IRTF-related meeting. Lars= --Apple-Mail=_7A3A1082-E0FA-4DAC-9709-905B58706C17 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAwNTEzNDYwM1owIwYJKoZIhvcNAQkEMRYEFM0Q i4htrVu4cabRsk4QAsmJg0zVMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAGxQlMRl 4h2CdlwbpeLwZQLw7oBEd2AayvpC8J+7F/RdQjvpjCj13y0boCzzO/7+OCc1T+S/E9UE4mbuHbdf L9BVgjwqZ6W8vM3EiRgHIlt86avqsgVxDJ54hBZc0Mt1MlYlWmkUJMjP0CzFjXZSXpwRw5pKWIZ5 2xZ0G+ZDPKPicLzw77+mBUfFw2uqBtLJYzuUoK3n8XIv2nCwr6I/OpkFg+CIIybTAZ1D6pvfy6a6 0dLDXXK9me0ikITsesxL4Rj81bppGjhkYZ21wIW/1NTlsSYse3hq5s7zAa3Jy6G1r+R/bPdRRemc R3Sl0n5msKqrt/jIydTgo8s1aaBi/tEAAAAAAAA= --Apple-Mail=_7A3A1082-E0FA-4DAC-9709-905B58706C17-- From ford@isoc.org Fri Oct 5 06:55:40 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29F421F857A for ; Fri, 5 Oct 2012 06:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.863 X-Spam-Level: X-Spam-Status: No, score=-102.863 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES2WW7xDA4sm for ; Fri, 5 Oct 2012 06:55:39 -0700 (PDT) Received: from smtp140.dfw.emailsrvr.com (smtp140.dfw.emailsrvr.com [67.192.241.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1C221F86E2 for ; Fri, 5 Oct 2012 06:55:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp14.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id CDF92298DFA; Fri, 5 Oct 2012 09:55:38 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp14.relay.dfw1a.emailsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id EA0CF298E40; Fri, 5 Oct 2012 09:55:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Matthew Ford In-Reply-To: <10229F86C86EB444898E629583FD417118C703CA@PACDCEXMB06.cable.comcast.com> Date: Fri, 5 Oct 2012 14:55:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10229F86C86EB444898E629583FD417118C703CA@PACDCEXMB06.cable.comcast.com> To: "Livingood, Jason" X-Mailer: Apple Mail (2.1498) Cc: marcelo bagnulo braun , Hannes Tschofenig , "lmap@ietf.org" Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:55:40 -0000 On 5 Oct 2012, at 14:09, "Livingood, Jason" = wrote: > My original suggestion to a few folks (before this list was = established) > was to do this work in the IRTF. Perhaps we can arrange something = there, > even if an informal discussion of what is needed and how we might = proceed? > Failing that, a bar BoF would be helpful. >=20 I don't have a strong opinion about IRTF vs. bar BoF but I would = strongly support having a meeting in Atlanta to review the situation, = potentially hear more about requirements from others, and try to figure = out a (sustainable) way forward for this initiative. Mat= From trammell@tik.ee.ethz.ch Fri Oct 5 07:29:32 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C227821F86B3 for ; Fri, 5 Oct 2012 07:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.799 X-Spam-Level: X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4Mgr4bpHVJQ for ; Fri, 5 Oct 2012 07:29:32 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 39D3921F86AD for ; Fri, 5 Oct 2012 07:29:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7A159D930C; Fri, 5 Oct 2012 16:29:31 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id U8CrgogTAG1b; Fri, 5 Oct 2012 16:29:31 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 31C2DD9305; Fri, 5 Oct 2012 16:29:31 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Fri, 5 Oct 2012 16:29:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10229F86C86EB444898E629583FD417118C703CA@PACDCEXMB06.cable.comcast.com> To: Matthew Ford X-Mailer: Apple Mail (2.1283) Cc: marcelo bagnulo braun , Hannes Tschofenig , "Livingood, Jason" , "lmap@ietf.org" Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:29:32 -0000 On Oct 5, 2012, at 3:55 PM, Matthew Ford wrote: >=20 > On 5 Oct 2012, at 14:09, "Livingood, Jason" = wrote: >=20 >> My original suggestion to a few folks (before this list was = established) >> was to do this work in the IRTF. Perhaps we can arrange something = there, >> even if an informal discussion of what is needed and how we might = proceed? >> Failing that, a bar BoF would be helpful. >>=20 >=20 > I don't have a strong opinion about IRTF vs. bar BoF but I would = strongly support having a meeting in Atlanta to review the situation, = potentially hear more about requirements from others, and try to figure = out a (sustainable) way forward for this initiative. +1 -- also no strong opinion about forming an RG or a WG at this point, = but it makes sense to get together in Atlanta and see the next steps = from here are. Cheers, Brian= From Henning.Schulzrinne@fcc.gov Fri Oct 5 07:36:13 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6547E21F873C for ; Fri, 5 Oct 2012 07:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUzDlWQ5PDpy for ; Fri, 5 Oct 2012 07:36:12 -0700 (PDT) Received: from dmz-mail2.fcc.gov (dmz-mail2.fcc.gov [192.104.54.11]) by ietfa.amsl.com (Postfix) with ESMTP id 580FD21F870E for ; Fri, 5 Oct 2012 07:36:11 -0700 (PDT) Received: from P2PXMB13.fccnet.win.fcc.gov ([fe80::6593:6526:65f8:66b7]) by p2pxcas01.fccnet.win.fcc.gov ([fe80::1d27:de47:ad2e:9062%13]) with mapi id 14.01.0379.000; Fri, 5 Oct 2012 10:36:10 -0400 From: Henning Schulzrinne To: Brian Trammell , Matthew Ford Thread-Topic: [lmap] BOF not approved? Thread-Index: AQHNore1GWTBvyC/v0+Df7FltQ/AE5eqi3MAgABng4CAAAzWAIAACX2A//+9CdE= Date: Fri, 5 Oct 2012 14:36:09 +0000 Message-ID: References: <10229F86C86EB444898E629583FD417118C703CA@PACDCEXMB06.cable.comcast.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: marcelo bagnulo braun , Hannes Tschofenig , "Livingood, Jason" , "lmap@ietf.org" Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:36:13 -0000 I'd like to see a Bar BOF and plan to (help) organize that. Which of the da= ys would work best for folks?=0A= =0A= I'm thinking of either Tuesday, Wednesday or Thursday. (I will be speaking = at the plenary on Wednesday.)=0A= =0A= I think this is beyond the "research" stage, given actual deployments.=0A= =0A= I've set up a Doodle poll=0A= http://www.doodle.com/78t3r4m3mfrea5yp=0A= to see if there's a strong preference.=0A= =0A= ________________________________________=0A= From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Brian Tram= mell [trammell@tik.ee.ethz.ch]=0A= Sent: Friday, October 05, 2012 10:29 AM=0A= To: Matthew Ford=0A= Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood, Jason; lmap= @ietf.org=0A= Subject: Re: [lmap] BOF not approved?=0A= =0A= On Oct 5, 2012, at 3:55 PM, Matthew Ford wrote:=0A= =0A= >=0A= > On 5 Oct 2012, at 14:09, "Livingood, Jason" wrote:=0A= >=0A= >> My original suggestion to a few folks (before this list was established)= =0A= >> was to do this work in the IRTF. Perhaps we can arrange something there,= =0A= >> even if an informal discussion of what is needed and how we might procee= d?=0A= >> Failing that, a bar BoF would be helpful.=0A= >>=0A= >=0A= > I don't have a strong opinion about IRTF vs. bar BoF but I would strongly= support having a meeting in Atlanta to review the situation, potentially h= ear more about requirements from others, and try to figure out a (sustainab= le) way forward for this initiative.=0A= =0A= +1 -- also no strong opinion about forming an RG or a WG at this point, but= it makes sense to get together in Atlanta and see the next steps from here= are.=0A= =0A= Cheers, Brian=0A= _______________________________________________=0A= lmap mailing list=0A= lmap@ietf.org=0A= https://www.ietf.org/mailman/listinfo/lmap=0A= From bclaise@cisco.com Fri Oct 5 07:53:29 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843BC21F847F for ; Fri, 5 Oct 2012 07:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.707 X-Spam-Level: X-Spam-Status: No, score=-8.707 tagged_above=-999 required=5 tests=[AWL=1.892, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEtbJotwtTqU for ; Fri, 5 Oct 2012 07:53:28 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BAB9121F847A for ; Fri, 5 Oct 2012 07:53:25 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q95EqxK1016870; Fri, 5 Oct 2012 16:52:59 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q95EquaB026123; Fri, 5 Oct 2012 16:52:58 +0200 (CEST) Message-ID: <506EF447.2010909@cisco.com> Date: Fri, 05 Oct 2012 16:52:55 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Henning Schulzrinne References: <10229F86C86EB444898E629583FD417118C703CA@PACDCEXMB06.cable.comcast.com> , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Matthew Ford , "lmap@ietf.org" , marcelo bagnulo braun , Hannes Tschofenig , "Livingood, Jason" , Brian Trammell Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:53:30 -0000 Hi Henning, A Bar BoF is a good idea, and I want to participate. Howevr,, before answering in doodle, I would prefer to wait for the final IETF agenda. Regards, Benoit. > I'd like to see a Bar BOF and plan to (help) organize that. Which of the days would work best for folks? > > I'm thinking of either Tuesday, Wednesday or Thursday. (I will be speaking at the plenary on Wednesday.) > > I think this is beyond the "research" stage, given actual deployments. > > I've set up a Doodle poll > http://www.doodle.com/78t3r4m3mfrea5yp > to see if there's a strong preference. > > ________________________________________ > From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Brian Trammell [trammell@tik.ee.ethz.ch] > Sent: Friday, October 05, 2012 10:29 AM > To: Matthew Ford > Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood, Jason; lmap@ietf.org > Subject: Re: [lmap] BOF not approved? > > On Oct 5, 2012, at 3:55 PM, Matthew Ford wrote: > >> On 5 Oct 2012, at 14:09, "Livingood, Jason" wrote: >> >>> My original suggestion to a few folks (before this list was established) >>> was to do this work in the IRTF. Perhaps we can arrange something there, >>> even if an informal discussion of what is needed and how we might proceed? >>> Failing that, a bar BoF would be helpful. >>> >> I don't have a strong opinion about IRTF vs. bar BoF but I would strongly support having a meeting in Atlanta to review the situation, potentially hear more about requirements from others, and try to figure out a (sustainable) way forward for this initiative. > +1 -- also no strong opinion about forming an RG or a WG at this point, but it makes sense to get together in Atlanta and see the next steps from here are. > > Cheers, Brian > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > From wes@mti-systems.com Fri Oct 5 07:59:55 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC1321F86DA for ; Fri, 5 Oct 2012 07:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qa2TKOOR60zT for ; Fri, 5 Oct 2012 07:59:54 -0700 (PDT) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id B349921F86C6 for ; Fri, 5 Oct 2012 07:59:54 -0700 (PDT) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id q95ExrLS008667 for ; Fri, 5 Oct 2012 10:59:53 -0400 Received: (qmail 26185 invoked by uid 0); 5 Oct 2012 14:59:53 -0000 Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.169.129) by 0 with ESMTPA; 5 Oct 2012 14:59:53 -0000 Message-ID: <506EF5D8.2090205@mti-systems.com> Date: Fri, 05 Oct 2012 10:59:36 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Matthew Ford References: <10229F86C86EB444898E629583FD417118C703CA@PACDCEXMB06.cable.comcast.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: marcelo bagnulo braun , Hannes Tschofenig , "Livingood, Jason" , "lmap@ietf.org" Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:59:55 -0000 On 10/5/2012 9:55 AM, Matthew Ford wrote: > > On 5 Oct 2012, at 14:09, "Livingood, Jason" wrote: > >> My original suggestion to a few folks (before this list was established) >> was to do this work in the IRTF. Perhaps we can arrange something there, >> even if an informal discussion of what is needed and how we might proceed? >> Failing that, a bar BoF would be helpful. >> > > I don't have a strong opinion about IRTF vs. bar BoF but I would strongly support having a meeting in Atlanta to review the situation, potentially hear more about requirements from others, and try to figure out a (sustainable) way forward for this initiative. > Obviously some work has to take place to further identify what exactly people would like to do, and then the choice of goal for IETF or IRTF group would be more obvious, based on the desired outcome (e.g. standards or BCP work would indicate an IETF WG, or it may turn out that some work could fit within existing groups like IPPM). Until this is clear, I would suggest to just have a pure side-meeting. -- Wes Eddy MTI Systems From Henning.Schulzrinne@fcc.gov Fri Oct 5 08:05:03 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA6D21F875C for ; Fri, 5 Oct 2012 08:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yz6QyoddPCCP for ; Fri, 5 Oct 2012 08:05:02 -0700 (PDT) Received: from dmz-mail2.fcc.gov (dmz-mail2.fcc.gov [192.104.54.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3289021F8750 for ; Fri, 5 Oct 2012 08:05:02 -0700 (PDT) Received: from P2PXMB13.fccnet.win.fcc.gov ([fe80::6593:6526:65f8:66b7]) by p2pxcas01.fccnet.win.fcc.gov ([fe80::1d27:de47:ad2e:9062%13]) with mapi id 14.01.0379.000; Fri, 5 Oct 2012 11:05:01 -0400 From: Henning Schulzrinne To: Wesley Eddy , Matthew Ford Thread-Topic: [lmap] BOF not approved? Thread-Index: AQHNore1GWTBvyC/v0+Df7FltQ/AE5eqi3MAgABng4CAAAzWAIAAEeQA//+9Njk= Date: Fri, 5 Oct 2012 15:05:00 +0000 Message-ID: References: <10229F86C86EB444898E629583FD417118C703CA@PACDCEXMB06.cable.comcast.com> , <506EF5D8.2090205@mti-systems.com> In-Reply-To: <506EF5D8.2090205@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: marcelo bagnulo braun , Hannes Tschofenig , "Livingood, Jason" , "lmap@ietf.org" Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 15:05:03 -0000 I can't speak for all the LMAP participants, obviously, but I was hoping th= at the LMAP requirements I-D made it reasonably clear that at least our nee= ds are primarily in defining a specific set of protocols, with the metrics = being delegated to IPPM (or successor). Thus, this would not be a BCP, but = at least experimental. If the draft failed to make the point, I have obviou= sly some work to do...=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Wesley Edd= y [wes@mti-systems.com]=0A= Sent: Friday, October 05, 2012 10:59 AM=0A= To: Matthew Ford=0A= Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood, Jason; lmap= @ietf.org=0A= Subject: Re: [lmap] BOF not approved?=0A= =0A= On 10/5/2012 9:55 AM, Matthew Ford wrote:=0A= >=0A= > On 5 Oct 2012, at 14:09, "Livingood, Jason" wrote:=0A= >=0A= >> My original suggestion to a few folks (before this list was established)= =0A= >> was to do this work in the IRTF. Perhaps we can arrange something there,= =0A= >> even if an informal discussion of what is needed and how we might procee= d?=0A= >> Failing that, a bar BoF would be helpful.=0A= >>=0A= >=0A= > I don't have a strong opinion about IRTF vs. bar BoF but I would strongly= support having a meeting in Atlanta to review the situation, potentially h= ear more about requirements from others, and try to figure out a (sustainab= le) way forward for this initiative.=0A= >=0A= =0A= =0A= Obviously some work has to take place to further identify what=0A= exactly people would like to do, and then the choice of goal=0A= for IETF or IRTF group would be more obvious, based on the=0A= desired outcome (e.g. standards or BCP work would indicate an=0A= IETF WG, or it may turn out that some work could fit within=0A= existing groups like IPPM).=0A= =0A= Until this is clear, I would suggest to just have a pure=0A= side-meeting.=0A= =0A= --=0A= Wes Eddy=0A= MTI Systems=0A= _______________________________________________=0A= lmap mailing list=0A= lmap@ietf.org=0A= https://www.ietf.org/mailman/listinfo/lmap=0A= From wes@mti-systems.com Fri Oct 5 08:05:23 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE8921F8786 for ; Fri, 5 Oct 2012 08:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZmgNl2UpeVc for ; Fri, 5 Oct 2012 08:05:21 -0700 (PDT) Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id 704EA21F87B9 for ; Fri, 5 Oct 2012 08:05:20 -0700 (PDT) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id q95F5Jmx009062 for ; Fri, 5 Oct 2012 11:05:19 -0400 Received: (qmail 8161 invoked by uid 0); 5 Oct 2012 15:05:16 -0000 Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.169.129) by 0 with ESMTPA; 5 Oct 2012 15:05:16 -0000 Message-ID: <506EF71B.9030208@mti-systems.com> Date: Fri, 05 Oct 2012 11:04:59 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: marcelo bagnulo braun References: <506E6BAB.2010606@it.uc3m.es> In-Reply-To: <506E6BAB.2010606@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lmap@ietf.org Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 15:05:23 -0000 On 10/5/2012 1:10 AM, marcelo bagnulo braun wrote: > Hi, > > I just saw that the LMAP BOF was not approved for Atlanta. > Does anybody knows why it was not approved? > What are the next steps? > The request was incomplete, and by the time it was received, there was no time for us to help flesh it out. For instance, there was no indication of whether it was to be a WG-forming BoF or not, and a WG-forming BoF would make us want to see a draft charter in the works, and actual multi- party discussion with some level of convergence happening on the mailing list. Hopefully the proponents will keep this in mind if we want to go for a BoF in Orlando. -- Wes Eddy MTI Systems From mattmathis@google.com Fri Oct 5 16:12:52 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F133621F8587 for ; Fri, 5 Oct 2012 16:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-uQnE+1zqrz for ; Fri, 5 Oct 2012 16:12:51 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD6521F858E for ; Fri, 5 Oct 2012 16:12:50 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1070748wib.13 for ; Fri, 05 Oct 2012 16:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=Ty61LTt7+1HPzo7pMpE70LnwKuhfFsFFsakaFcS4iDI=; b=mJBXAbRqL0rH0ue3CKACgntBToxROqLewYJQM3Pn96wDKHfIW5kMIYWVwnu6T3x+sL l9B6aGGo6KbEDZmwU95+oSobQgVRrhmtEBhY5q0CN2sEMtHHDb9QYYx2rD+dvtx+qC/i P3MtDeDWh+xrlXX4kTQY9e4xEZebrd9TRLz6hFmw7GNPPz0nFr2PPPHhFCBedMSEX4EV LsYaxvSP67OWckbAmPj7DlwJtOcbdeK8aLocFwL+gWsMqhj+EtfwE8V0G/5l3XIleACi FdXc0jZm14+dONib3obfHPmesEP+MeblE4tGJe9y5D9ityKvFz3JZo75R4k0fcL0ZoO3 Y1IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=Ty61LTt7+1HPzo7pMpE70LnwKuhfFsFFsakaFcS4iDI=; b=DCcBDkeZzq2VBJXxdl6Vsjp/eVmKkv9Sd+i3DJg0Z/P2xrmgdR1Mxugw3tGiwMUy/T OW3xqIjAMqA56zmfw26mO9B/tnEsaUG8ftKzow9ifPuJXHL8n58cUDgu6/YTx+Lmm0eu NX9Yt+vxAtjU0ie+2SeYLxEoJE8mKhz1lz6xQgprKhB4xlhwK/VdSEpT4tbl/Yl508pp pZI0z8d4EPNbm/ZHAzmlLwIXsBwgNO/6wC/nJVcDCAPN1lpLxF20JGD2jCmg3fuct/5G olh8/CtwZC67Sg4SXxJmXgoLLzuQJd060bltH+csY6PuiiBut2xI2m66NH9Xd0GDJ9sH WqUg== MIME-Version: 1.0 Received: by 10.180.95.130 with SMTP id dk2mr6177152wib.18.1349478769622; Fri, 05 Oct 2012 16:12:49 -0700 (PDT) Received: by 10.195.12.99 with HTTP; Fri, 5 Oct 2012 16:12:49 -0700 (PDT) In-Reply-To: References: <10229F86C86EB444898E629583FD417118C703CA@PACDCEXMB06.cable.comcast.com> <506EF5D8.2090205@mti-systems.com> Date: Fri, 5 Oct 2012 16:12:49 -0700 Message-ID: From: Matt Mathis To: Henning Schulzrinne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmuilN9oHCDOwzMOGnt4pxotH33zqTnoLCKalJ+aPRkt/yccQAt137LQHNX6bWnHbNuSLD52tnwdHtmkKtRmsm7q4d8DKCd1Hi3yjz9PK/jxXG+XQGeMY6en+oSoW4NvkplvKSq6Tp3MTDysE7xXt91JyzD/xTcADQ3UazCgANAoJgvpPDIYtsh6BFKP8GWQsfQ+6fZ Cc: Matthew Ford , "lmap@ietf.org" , Wesley Eddy , ippm@ietf.org, marcelo bagnulo braun , Hannes Tschofenig , "Livingood, Jason" Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 23:12:52 -0000 +IPPM Consider doing this entire effort within IPPM. A protocol to control measurement is absolutely in scope (See for example RFC 4656) as are discussions about the choice of measurement vantage points and requirements for measurement platforms, etc. Many of the topics that might be out of scope for IPPM, are likely to be out of scope for both IETF and IRTF, for example the design on a media specific link layer control protocol probably belongs in some other forum entirely. For things that are on the edge of IPPM's scope and don't fit elsewhere, it would be far easier to tweak IPPM than to spin a new WG. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Fri, Oct 5, 2012 at 8:05 AM, Henning Schulzrinne wrote: > I can't speak for all the LMAP participants, obviously, but I was hoping = that the LMAP requirements I-D made it reasonably clear that at least our n= eeds are primarily in defining a specific set of protocols, with the metric= s being delegated to IPPM (or successor). Thus, this would not be a BCP, bu= t at least experimental. If the draft failed to make the point, I have obvi= ously some work to do... > > Henning > > ________________________________________ > From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Wesley E= ddy [wes@mti-systems.com] > Sent: Friday, October 05, 2012 10:59 AM > To: Matthew Ford > Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood, Jason; lm= ap@ietf.org > Subject: Re: [lmap] BOF not approved? > > On 10/5/2012 9:55 AM, Matthew Ford wrote: >> >> On 5 Oct 2012, at 14:09, "Livingood, Jason" wrote: >> >>> My original suggestion to a few folks (before this list was established= ) >>> was to do this work in the IRTF. Perhaps we can arrange something there= , >>> even if an informal discussion of what is needed and how we might proce= ed? >>> Failing that, a bar BoF would be helpful. >>> >> >> I don't have a strong opinion about IRTF vs. bar BoF but I would strongl= y support having a meeting in Atlanta to review the situation, potentially = hear more about requirements from others, and try to figure out a (sustaina= ble) way forward for this initiative. >> > > > Obviously some work has to take place to further identify what > exactly people would like to do, and then the choice of goal > for IETF or IRTF group would be more obvious, based on the > desired outcome (e.g. standards or BCP work would indicate an > IETF WG, or it may turn out that some work could fit within > existing groups like IPPM). > > Until this is clear, I would suggest to just have a pure > side-meeting. > > -- > Wes Eddy > MTI Systems > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From BCheck@NCTA.com Sun Oct 7 13:28:15 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7690E21F870E for ; Sun, 7 Oct 2012 13:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzPmHB067HhI for ; Sun, 7 Oct 2012 13:28:14 -0700 (PDT) Received: from mail-3.ncta.com (mail-3.ncta.com [209.23.210.3]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0FC21F870B for ; Sun, 7 Oct 2012 13:28:14 -0700 (PDT) Received: from MAILSTORE-A.ncta.com ([::1]) by Mailhubcas.ncta.com ([::1]) with mapi id 14.01.0379.000; Sun, 7 Oct 2012 16:28:13 -0400 From: William Check To: "lmap@ietf.org" Thread-Topic: [lmap] BOF not approved? Thread-Index: AQHNore22m37bPHIg0qKpN1WSxYJ6Jeqi3MAgABng4CAAAzWAIAAEeQAgAABgwCAAIhLgIACstuAgAAAuwA= Date: Sun, 7 Oct 2012 20:28:12 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [212.147.27.54] Content-Type: multipart/alternative; boundary="_000_CC975E0547926bchecknctacom_" MIME-Version: 1.0 Subject: [lmap] FW: BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 20:28:15 -0000 --_000_CC975E0547926bchecknctacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I tend to agree that an informal discussion within the IRTF would be a good= way to proceed=85. Bill From: Matt Mathis > Date: Friday, October 5, 2012 7:12 PM To: Henning Schulzrinne > Cc: Matthew Ford >, "lmap@ietf.org" >, Wesley Eddy >, "ippm@ietf.org" >, marcelo bagnulo braun >, Hannes Tschofenig >, Jason Livingood > Subject: Re: [lmap] BOF not approved? +IPPM Consider doing this entire effort within IPPM. A protocol to control measurement is absolutely in scope (See for example RFC 4656) as are discussions about the choice of measurement vantage points and requirements for measurement platforms, etc. Many of the topics that might be out of scope for IPPM, are likely to be out of scope for both IETF and IRTF, for example the design on a media specific link layer control protocol probably belongs in some other forum entirely. For things that are on the edge of IPPM's scope and don't fit elsewhere, it would be far easier to tweak IPPM than to spin a new WG. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Fri, Oct 5, 2012 at 8:05 AM, Henning Schulzrinne > wrote: I can't speak for all the LMAP participants, obviously, but I was hoping th= at the LMAP requirements I-D made it reasonably clear that at least our nee= ds are primarily in defining a specific set of protocols, with the metrics = being delegated to IPPM (or successor). Thus, this would not be a BCP, but = at least experimental. If the draft failed to make the point, I have obviou= sly some work to do... Henning ________________________________________ From: lmap-bounces@ietf.org [lmap-bounces@iet= f.org] on behalf of Wesley Eddy [wes@mti-syst= ems.com] Sent: Friday, October 05, 2012 10:59 AM To: Matthew Ford Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood, Jason; lmap= @ietf.org Subject: Re: [lmap] BOF not approved? On 10/5/2012 9:55 AM, Matthew Ford wrote: On 5 Oct 2012, at 14:09, "Livingood, Jason" > wrote: My original suggestion to a few folks (before this list was established) was to do this work in the IRTF. Perhaps we can arrange something there, even if an informal discussion of what is needed and how we might proceed? Failing that, a bar BoF would be helpful. I don't have a strong opinion about IRTF vs. bar BoF but I would strongly s= upport having a meeting in Atlanta to review the situation, potentially hea= r more about requirements from others, and try to figure out a (sustainable= ) way forward for this initiative. Obviously some work has to take place to further identify what exactly people would like to do, and then the choice of goal for IETF or IRTF group would be more obvious, based on the desired outcome (e.g. standards or BCP work would indicate an IETF WG, or it may turn out that some work could fit within existing groups like IPPM). Until this is clear, I would suggest to just have a pure side-meeting. -- Wes Eddy MTI Systems _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap --_000_CC975E0547926bchecknctacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I tend to agree that an informal discussion within the IRTF would be a= good way to proceed=85.  Bill


From: Matt Mathis <mattmathis@google.com>
Date: Friday, October 5, 2012 7:12 = PM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>=
Cc: Matthew Ford <ford@isoc.org>, "lmap@ietf.org" <lmap@iet= f.org>, Wesley Eddy <wes@m= ti-systems.com>, "ippm@ietf.org" <ippm@ietf.org>, marcelo bagnulo braun <= marcelo@it.uc3m.es>, Hannes Ts= chofenig <hannes.tschofenig= @gmx.net>, Jason Livingood <j= ason_livingood@cable.comcast.com>
Subject: Re: [lmap] BOF not approve= d?

+IPPM

Consider doing this entire effort within IPPM.    = A protocol to
control measurement is absolutely in scope (See for example RFC 4656)<= /div>
as are discussions about the choice of measurement vantage points and<= /div>
requirements for measurement platforms, etc.   Many of the t= opics that
might be out of scope for IPPM, are likely to be out of scope for both=
IETF and IRTF, for example the design on a media specific link layer
control protocol probably belongs in some other forum entirely.

For things that are on the edge of IPPM's scope and don't fit
elsewhere, it would be far easier to tweak IPPM than to spin a new WG.=

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan = Kay


On Fri, Oct 5, 2012 at 8:05 AM, Henning Schulzrinne
I can't speak for all the LMAP participants, obviously, but I was hopi= ng that the LMAP requirements I-D made it reasonably clear that at least ou= r needs are primarily in defining a specific set of protocols, with the met= rics being delegated to IPPM (or successor). Thus, this would not be a BCP, but at least experimental. If t= he draft failed to make the point, I have obviously some work to do...

Henning

________________________________________
Sent: Friday, October 05, 2012 10:59 AM
To: Matthew Ford
Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood,  &n= bsp;     Jason; lmap@ietf.org
Subject: Re: [lmap] BOF not approved?

On 10/5/2012 9:55 AM, Matthew Ford wrote:

On 5 Oct 2012, at 14:09, "Livingood, Jason" <Jason_Livingood@cable.comcast.com<= /a>> wrote:

My original suggestion to a few folks (before this list was establishe= d)
was to do this work in the IRTF. Perhaps we can arrange something ther= e,
even if an informal discussion of what is needed and how we might proc= eed?
Failing that, a bar BoF would be helpful.


I don't have a strong opinion about IRTF vs. bar BoF but I would stron= gly support having a meeting in Atlanta to review the situation, potentiall= y hear more about requirements from others, and try to figure out a (sustai= nable) way forward for this initiative.



Obviously some work has to take place to further identify what
exactly people would like to do, and then the choice of goal
for IETF or IRTF group would be more obvious, based on the
desired outcome (e.g. standards or BCP work would indicate an
IETF WG, or it may turn out that some work could fit within
existing groups like IPPM).

Until this is clear, I would suggest to just have a pure
side-meeting.

--
Wes Eddy
MTI Systems
_______________________________________________
lmap mailing list
_______________________________________________
lmap mailing list
_______________________________________________
lmap mailing list


--_000_CC975E0547926bchecknctacom_-- From acmorton@att.com Sun Oct 7 19:13:35 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F26921F8712; Sun, 7 Oct 2012 19:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqVieXLN-hEi; Sun, 7 Oct 2012 19:13:34 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4B14821F86C2; Sun, 7 Oct 2012 19:13:34 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id dc632705.0.141120.00-429.383209.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 08 Oct 2012 02:13:34 +0000 (UTC) X-MXL-Hash: 507236ce0533a418-268e4e19941b7dbbc070f3607b2553ca2763fd6f Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q982DX2H014536; Sun, 7 Oct 2012 22:13:33 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q982DRnZ014527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Oct 2012 22:13:28 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor); Sun, 7 Oct 2012 22:13:12 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q982DB5R011980; Sun, 7 Oct 2012 22:13:12 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q982D6W3011608; Sun, 7 Oct 2012 22:13:07 -0400 Received: from lt-hp1044652.att.com (vpn-130-10-228-200.vpn.sest.att.com[130.10.228.200](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121008021205gw100sspeme>; Mon, 8 Oct 2012 02:12:10 +0000 X-Originating-IP: [130.10.228.200] Message-Id: <7.0.1.0.0.20121007220252.0745c538@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 07 Oct 2012 22:12:31 -0400 To: Matt Mathis , Henning Schulzrinne From: Al Morton In-Reply-To: References: <10229F86C86EB444898E629583FD417118C703CA@PACDCEXMB06.cable.comcast.com> <506EF5D8.2090205@mti-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=DfugXIRW c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=Ae4mP6Td2dcA:10 a=uZN-4-ycT8gA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=whDpgFbH] X-AnalysisOut: [l3sA:10 a=48vgC7mUAAAA:8 a=-Cb5Q1N6AAAA:8 a=6MyZ0KW2AAAA:8] X-AnalysisOut: [ a=1g_KX55Nkd4XcXew2roA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=czfYQaGQYtkA:10] Cc: Matthew Ford , ippm@ietf.org, Wesley Eddy , "lmap@ietf.org" , marcelo bagnulo braun , Hannes Tschofenig , "Livingood, Jason" Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 02:13:35 -0000 Thinking about the main classes of requirements in the draft, both passive and active measurement systems are desired. This may turn-out to be good combination. While IPPM is strong in metric definitions and test protocols for active measurements, I think there is some room for growth in collection protocols (especially with the degree of inter-communication envisaged in the requirements). But this is where the IETF developments to support passive measurements might help fill the gap (ipfix is the best example I can think of). regards, Al At 07:12 PM 10/5/2012, Matt Mathis wrote: >+IPPM > >Consider doing this entire effort within IPPM. A protocol to >control measurement is absolutely in scope (See for example RFC 4656) >as are discussions about the choice of measurement vantage points and >requirements for measurement platforms, etc. Many of the topics that >might be out of scope for IPPM, are likely to be out of scope for both >IETF and IRTF, for example the design on a media specific link layer >control protocol probably belongs in some other forum entirely. > >For things that are on the edge of IPPM's scope and don't fit >elsewhere, it would be far easier to tweak IPPM than to spin a new WG. > >Thanks, >--MM-- >The best way to predict the future is to create it. - Alan Kay > > >On Fri, Oct 5, 2012 at 8:05 AM, Henning Schulzrinne > wrote: > > I can't speak for all the LMAP participants, obviously, but I was > hoping that the LMAP requirements I-D made it reasonably clear that > at least our needs are primarily in defining a specific set of > protocols, with the metrics being delegated to IPPM (or successor). > Thus, this would not be a BCP, but at least experimental. If the > draft failed to make the point, I have obviously some work to do... > > > > Henning > > > > ________________________________________ > > From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of > Wesley Eddy [wes@mti-systems.com] > > Sent: Friday, October 05, 2012 10:59 AM > > To: Matthew Ford > > Cc: marcelo bagnulo braun; Hannes Tschofenig; > Livingood, Jason; lmap@ietf.org > > Subject: Re: [lmap] BOF not approved? > > > > On 10/5/2012 9:55 AM, Matthew Ford wrote: > >> > >> On 5 Oct 2012, at 14:09, "Livingood, Jason" > wrote: > >> > >>> My original suggestion to a few folks (before this list was established) > >>> was to do this work in the IRTF. Perhaps we can arrange something there, > >>> even if an informal discussion of what is needed and how we > might proceed? > >>> Failing that, a bar BoF would be helpful. > >>> > >> > >> I don't have a strong opinion about IRTF vs. bar BoF but I would > strongly support having a meeting in Atlanta to review the > situation, potentially hear more about requirements from others, > and try to figure out a (sustainable) way forward for this initiative. > >> > > > > > > Obviously some work has to take place to further identify what > > exactly people would like to do, and then the choice of goal > > for IETF or IRTF group would be more obvious, based on the > > desired outcome (e.g. standards or BCP work would indicate an > > IETF WG, or it may turn out that some work could fit within > > existing groups like IPPM). > > > > Until this is clear, I would suggest to just have a pure > > side-meeting. > > > > -- > > Wes Eddy > > MTI Systems > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From jason_livingood@cable.comcast.com Tue Oct 9 07:38:26 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D7621F8518 for ; Tue, 9 Oct 2012 07:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLfpke2Q2wsd for ; Tue, 9 Oct 2012 07:38:25 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9D821F8458 for ; Tue, 9 Oct 2012 07:38:25 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.36778687; Tue, 09 Oct 2012 08:15:24 -0600 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.64]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 10:38:20 -0400 From: "Livingood, Jason" Thread-Topic: [lmap] BOF not approved? Thread-Index: AQHNore3VXTel7BurEKSo4ljwsWnGpeqi3MAgAAkdgCAAE/jAIAACX2AgAAB2oCABgboAA== Date: Tue, 9 Oct 2012 14:38:18 +0000 Message-ID: <10229F86C86EB444898E629583FD417118C7B276@PACDCEXMB06.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Henning Schulzrinne , Brian Trammell , Matthew Ford Cc: marcelo bagnulo braun , Hannes Tschofenig , "lmap@ietf.org" Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:38:26 -0000 FWIW, the social is Tuesday and the (two) plenaries are on Wednesday. On 10/5/12 10:36 AM, "Henning Schulzrinne" wrote: >I'd like to see a Bar BOF and plan to (help) organize that. Which of the >days would work best for folks? > >I'm thinking of either Tuesday, Wednesday or Thursday. (I will be >speaking at the plenary on Wednesday.) > >I think this is beyond the "research" stage, given actual deployments. > >I've set up a Doodle poll >http://www.doodle.com/78t3r4m3mfrea5yp >to see if there's a strong preference. > >________________________________________ >From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Brian >Trammell [trammell@tik.ee.ethz.ch] >Sent: Friday, October 05, 2012 10:29 AM >To: Matthew Ford >Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood, Jason; >lmap@ietf.org >Subject: Re: [lmap] BOF not approved? > >On Oct 5, 2012, at 3:55 PM, Matthew Ford wrote: > >> >> On 5 Oct 2012, at 14:09, "Livingood, Jason" >> wrote: >> >>> My original suggestion to a few folks (before this list was >>>established) >>> was to do this work in the IRTF. Perhaps we can arrange something >>>there, >>> even if an informal discussion of what is needed and how we might >>>proceed? >>> Failing that, a bar BoF would be helpful. >>> >> >> I don't have a strong opinion about IRTF vs. bar BoF but I would >>strongly support having a meeting in Atlanta to review the situation, >>potentially hear more about requirements from others, and try to figure >>out a (sustainable) way forward for this initiative. > >+1 -- also no strong opinion about forming an RG or a WG at this point, >but it makes sense to get together in Atlanta and see the next steps from >here are. > >Cheers, Brian >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From jason_livingood@cable.comcast.com Tue Oct 9 07:42:37 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A83221F8876; Tue, 9 Oct 2012 07:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJp2BqnbCh64; Tue, 9 Oct 2012 07:42:37 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id C8CD221F8873; Tue, 9 Oct 2012 07:42:36 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.36779639; Tue, 09 Oct 2012 08:19:33 -0600 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.64]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 10:42:28 -0400 From: "Livingood, Jason" Thread-Topic: [lmap] BOF not approved? Thread-Index: AQHNore3VXTel7BurEKSo4ljwsWnGpeqi3MAgAAkdgCAAE/jAIAAEeQAgAABggCAAIhMgIAFd7MA Date: Tue, 9 Oct 2012 14:42:27 +0000 Message-ID: <10229F86C86EB444898E629583FD417118C7B367@PACDCEXMB06.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Matt Mathis , Henning Schulzrinne Cc: Matthew Ford , "ippm@ietf.org" , Wesley Eddy , "lmap@ietf.org" , marcelo bagnulo braun , Hannes Tschofenig Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:42:37 -0000 +1, and it's an easy way to get started and focus on the work itself rather than process/logistics of a BoF or WG formation. Jason On 10/5/12 7:12 PM, "Matt Mathis" wrote: >+IPPM > >Consider doing this entire effort within IPPM. A protocol to >control measurement is absolutely in scope (See for example RFC 4656) >as are discussions about the choice of measurement vantage points and >requirements for measurement platforms, etc. Many of the topics that >might be out of scope for IPPM, are likely to be out of scope for both >IETF and IRTF, for example the design on a media specific link layer >control protocol probably belongs in some other forum entirely. > >For things that are on the edge of IPPM's scope and don't fit >elsewhere, it would be far easier to tweak IPPM than to spin a new WG. > >Thanks, >--MM-- >The best way to predict the future is to create it. - Alan Kay > > >On Fri, Oct 5, 2012 at 8:05 AM, Henning Schulzrinne > wrote: >> I can't speak for all the LMAP participants, obviously, but I was >>hoping that the LMAP requirements I-D made it reasonably clear that at >>least our needs are primarily in defining a specific set of protocols, >>with the metrics being delegated to IPPM (or successor). Thus, this >>would not be a BCP, but at least experimental. If the draft failed to >>make the point, I have obviously some work to do... >> >> Henning >> >> ________________________________________ >> From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Wesley >>Eddy [wes@mti-systems.com] >> Sent: Friday, October 05, 2012 10:59 AM >> To: Matthew Ford >> Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood, Jason; >>lmap@ietf.org >> Subject: Re: [lmap] BOF not approved? >> >> On 10/5/2012 9:55 AM, Matthew Ford wrote: >>> >>> On 5 Oct 2012, at 14:09, "Livingood, Jason" >>> wrote: >>> >>>> My original suggestion to a few folks (before this list was >>>>established) >>>> was to do this work in the IRTF. Perhaps we can arrange something >>>>there, >>>> even if an informal discussion of what is needed and how we might >>>>proceed? >>>> Failing that, a bar BoF would be helpful. >>>> >>> >>> I don't have a strong opinion about IRTF vs. bar BoF but I would >>>strongly support having a meeting in Atlanta to review the situation, >>>potentially hear more about requirements from others, and try to figure >>>out a (sustainable) way forward for this initiative. >>> >> >> >> Obviously some work has to take place to further identify what >> exactly people would like to do, and then the choice of goal >> for IETF or IRTF group would be more obvious, based on the >> desired outcome (e.g. standards or BCP work would indicate an >> IETF WG, or it may turn out that some work could fit within >> existing groups like IPPM). >> >> Until this is clear, I would suggest to just have a pure >> side-meeting. >> >> -- >> Wes Eddy >> MTI Systems >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap From jason.weil@twcable.com Tue Oct 9 11:05:04 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7328B1F0CA7; Tue, 9 Oct 2012 11:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCkXSbJLbTjf; Tue, 9 Oct 2012 11:05:03 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 48CB61F0422; Tue, 9 Oct 2012 11:05:02 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,561,1344225600"; d="scan'208";a="432556016" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 09 Oct 2012 14:02:04 -0400 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.45]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 9 Oct 2012 14:02:40 -0400 From: "Weil, Jason" To: "Livingood, Jason" , Matt Mathis , Henning Schulzrinne Date: Tue, 9 Oct 2012 14:02:47 -0400 Thread-Topic: [lmap] BOF not approved? Thread-Index: Ac2mSEWjp6DwORGTQYizXqbZZvpOSQ== Message-ID: In-Reply-To: <10229F86C86EB444898E629583FD417118C7B367@PACDCEXMB06.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Matthew Ford , "lmap@ietf.org" , Wesley Eddy , "ippm@ietf.org" , marcelo bagnulo braun , Hannes Tschofenig Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 18:05:04 -0000 If there is agreement on initiating the discussion in the IPPM group, it might be useful to request a time slot during Tuesday's IPPM meeting fairly quickly to give an overview of the draft and gauge interest on work areas. Jason On 10/9/12 10:42 AM, "Livingood, Jason" wrote: >+1, and it's an easy way to get started and focus on the work itself >rather than process/logistics of a BoF or WG formation. > >Jason > > > >On 10/5/12 7:12 PM, "Matt Mathis" wrote: > >>+IPPM >> >>Consider doing this entire effort within IPPM. A protocol to >>control measurement is absolutely in scope (See for example RFC 4656) >>as are discussions about the choice of measurement vantage points and >>requirements for measurement platforms, etc. Many of the topics that >>might be out of scope for IPPM, are likely to be out of scope for both >>IETF and IRTF, for example the design on a media specific link layer >>control protocol probably belongs in some other forum entirely. >> >>For things that are on the edge of IPPM's scope and don't fit >>elsewhere, it would be far easier to tweak IPPM than to spin a new WG. >> >>Thanks, >>--MM-- >>The best way to predict the future is to create it. - Alan Kay >> >> >>On Fri, Oct 5, 2012 at 8:05 AM, Henning Schulzrinne >> wrote: >>> I can't speak for all the LMAP participants, obviously, but I was >>>hoping that the LMAP requirements I-D made it reasonably clear that at >>>least our needs are primarily in defining a specific set of protocols, >>>with the metrics being delegated to IPPM (or successor). Thus, this >>>would not be a BCP, but at least experimental. If the draft failed to >>>make the point, I have obviously some work to do... >>> >>> Henning >>> >>> ________________________________________ >>> From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Wesley >>>Eddy [wes@mti-systems.com] >>> Sent: Friday, October 05, 2012 10:59 AM >>> To: Matthew Ford >>> Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood, Jason; >>>lmap@ietf.org >>> Subject: Re: [lmap] BOF not approved? >>> >>> On 10/5/2012 9:55 AM, Matthew Ford wrote: >>>> >>>> On 5 Oct 2012, at 14:09, "Livingood, Jason" >>>> wrote: >>>> >>>>> My original suggestion to a few folks (before this list was >>>>>established) >>>>> was to do this work in the IRTF. Perhaps we can arrange something >>>>>there, >>>>> even if an informal discussion of what is needed and how we might >>>>>proceed? >>>>> Failing that, a bar BoF would be helpful. >>>>> >>>> >>>> I don't have a strong opinion about IRTF vs. bar BoF but I would >>>>strongly support having a meeting in Atlanta to review the situation, >>>>potentially hear more about requirements from others, and try to figure >>>>out a (sustainable) way forward for this initiative. >>>> >>> >>> >>> Obviously some work has to take place to further identify what >>> exactly people would like to do, and then the choice of goal >>> for IETF or IRTF group would be more obvious, based on the >>> desired outcome (e.g. standards or BCP work would indicate an >>> IETF WG, or it may turn out that some work could fit within >>> existing groups like IPPM). >>> >>> Until this is clear, I would suggest to just have a pure >>> side-meeting. >>> >>> -- >>> Wes Eddy >>> MTI Systems >>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap >>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Oct 10 08:40:54 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B5121F86C5; Wed, 10 Oct 2012 08:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWIVxkIoxc74; Wed, 10 Oct 2012 08:40:54 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3B321F864A; Wed, 10 Oct 2012 08:40:45 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 5A712633B1; Wed, 10 Oct 2012 17:40:44 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 3187659A8A; Wed, 10 Oct 2012 17:40:44 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: lmap@ietf.org Date: Wed, 10 Oct 2012 17:40:43 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201210101740.43825.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: "ippm@ietf.org" Subject: Re: [lmap] BOF not approved? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 15:40:54 -0000 Hi, at the beginning I though at well that this work might be in scope of IPPM.= =20 But after thinking more deeply about it, I'd say there is quite a lot of wo= rk=20 to do and this might be worth forming an own working group.=20 Then regarding a whole measurement architecture there might still be some m= ore=20 researchy questions but only focussing on the protocol(s) between the=20 measurement entities, I believe the problem and requirements are very clear= =20 to be addressed in the ieft. I would favor having a side meeting in Atlanta. From my point of view the=20 first step would be to get an overview on existing measurement framework to= =20 validate if the requirements listed so far cover their needs. If people tha= t=20 have designed or are administrating thus a framework are on this list and=20 would be willing to present their system that would be great. But I'm afrai= d=20 that there are actually a lot of small companies running these systems (e.g= =2E=20 webpages where private costumers can check their lines) and those people=20 might not be active in the ieft. Mirja =20 On Tuesday 09 October 2012 20:02:47 Weil, Jason wrote: > If there is agreement on initiating the discussion in the IPPM group, it > might be useful to request a time slot during Tuesday's IPPM meeting > fairly quickly to give an overview of the draft and gauge interest on work > areas. > > Jason > > On 10/9/12 10:42 AM, "Livingood, Jason" > > wrote: > >+1, and it's an easy way to get started and focus on the work itself > >rather than process/logistics of a BoF or WG formation. > > > >Jason > > > >On 10/5/12 7:12 PM, "Matt Mathis" wrote: > >>+IPPM > >> > >>Consider doing this entire effort within IPPM. A protocol to > >>control measurement is absolutely in scope (See for example RFC 4656) > >>as are discussions about the choice of measurement vantage points and > >>requirements for measurement platforms, etc. Many of the topics that > >>might be out of scope for IPPM, are likely to be out of scope for both > >>IETF and IRTF, for example the design on a media specific link layer > >>control protocol probably belongs in some other forum entirely. > >> > >>For things that are on the edge of IPPM's scope and don't fit > >>elsewhere, it would be far easier to tweak IPPM than to spin a new WG. > >> > >>Thanks, > >>--MM-- > >>The best way to predict the future is to create it. - Alan Kay > >> > >> > >>On Fri, Oct 5, 2012 at 8:05 AM, Henning Schulzrinne > >> > >> wrote: > >>> I can't speak for all the LMAP participants, obviously, but I was > >>>hoping that the LMAP requirements I-D made it reasonably clear that at > >>>least our needs are primarily in defining a specific set of protocols, > >>>with the metrics being delegated to IPPM (or successor). Thus, this > >>>would not be a BCP, but at least experimental. If the draft failed to > >>>make the point, I have obviously some work to do... > >>> > >>> Henning > >>> > >>> ________________________________________ > >>> From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Wesl= ey > >>>Eddy [wes@mti-systems.com] > >>> Sent: Friday, October 05, 2012 10:59 AM > >>> To: Matthew Ford > >>> Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood, Jason; > >>>lmap@ietf.org > >>> Subject: Re: [lmap] BOF not approved? > >>> > >>> On 10/5/2012 9:55 AM, Matthew Ford wrote: > >>>> On 5 Oct 2012, at 14:09, "Livingood, Jason" > >>>> > >>>> wrote: > >>>>> My original suggestion to a few folks (before this list was > >>>>>established) > >>>>> was to do this work in the IRTF. Perhaps we can arrange something > >>>>>there, > >>>>> even if an informal discussion of what is needed and how we might > >>>>>proceed? > >>>>> Failing that, a bar BoF would be helpful. > >>>> > >>>> I don't have a strong opinion about IRTF vs. bar BoF but I would > >>>>strongly support having a meeting in Atlanta to review the situation, > >>>>potentially hear more about requirements from others, and try to figu= re > >>>>out a (sustainable) way forward for this initiative. > >>> > >>> Obviously some work has to take place to further identify what > >>> exactly people would like to do, and then the choice of goal > >>> for IETF or IRTF group would be more obvious, based on the > >>> desired outcome (e.g. standards or BCP work would indicate an > >>> IETF WG, or it may turn out that some work could fit within > >>> existing groups like IPPM). > >>> > >>> Until this is clear, I would suggest to just have a pure > >>> side-meeting. > >>> > >>> -- > >>> Wes Eddy > >>> MTI Systems > >>> _______________________________________________ > >>> lmap mailing list > >>> lmap@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lmap > >>> _______________________________________________ > >>> lmap mailing list > >>> lmap@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lmap > > > >_______________________________________________ > >lmap mailing list > >lmap@ietf.org > >https://www.ietf.org/mailman/listinfo/lmap > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified th= at > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy of > this E-mail and any printout. > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Oct 10 09:05:19 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E4F21F8487 for ; Wed, 10 Oct 2012 09:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGNxWvKtV5bo for ; Wed, 10 Oct 2012 09:05:19 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 220CD21F8568 for ; Wed, 10 Oct 2012 09:05:19 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id D0DAE633B1 for ; Wed, 10 Oct 2012 18:05:17 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id B2C4459A8A for ; Wed, 10 Oct 2012 18:05:17 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: lmap@ietf.org Date: Wed, 10 Oct 2012 18:05:16 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201210101805.16883.mkuehle@ikr.uni-stuttgart.de> Subject: [lmap] Comments on draft-schulzrinne-lmap-requirements-00 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 16:05:19 -0000 Hi again, I also have some more technical comments relating directly to the draft (maybe restarting the technical discussion). 1. I agree with previous comments that the role of the network parameter server is not clear. I would expect rather than having an own entity that the client system would get the needed parameters from the controller. The controller as well as someone how wants to evaluate the data might need these parameters as well. But it not clear how to retrieve those parameters. Some of them might be enter manually, some could be discovered over SNMP. I don't see that there have to be one single entity administrating all parameters. But I'd say all these questions are out of scope. 2. I also agree with previous comments that infact the client and the server might implement the same functionality. Those are simply measurement endpoints. A measurement can be started by the client or the server. During the measurement both endpoints might collect data and either exchange these data between each other or send them directly to a data collector. The case where measurement results need to be exchanged between the endpoints (client and server) is not address in the draft so far. 3. There might also be some kind of hierarchy between data collectors. If I use more than one data collector for load balancing reasons. I guess those single collectors could do some kind of preprocessing but then I still need one entity to correlate all data to get a view on my whole network. Thus maybe a protocol to query the data should be regarded as well. Btw. there can already be some kind of preprocessing at the measurements endpoint (client/server) as well. -> All over we might only need two protocols. One to request or initiate measurements and one to request or exchange measurement data. The first one can be used between the controller and measurement endpoint, as well as between measurement endpoints and between controllers in a hierarchical structure. The second one can be used between the measurement point and the data collector (where the measurement might also be able to store and evaluate the data) and as well between measurement points and data collectors and also between the controller and the data collector/measurement endpoints (as the controller might need previous results to configure new measurement runs). Both protocols will also need some kind of capacity negotiation as well as some kind of authentication and integrity check. What do you think? Mirja From mattmathis@google.com Mon Oct 15 17:01:21 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB9D21F8883 for ; Mon, 15 Oct 2012 17:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YfQl9AM1f+R for ; Mon, 15 Oct 2012 17:01:20 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4637C21F883D for ; Mon, 15 Oct 2012 17:01:20 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so2323450wib.13 for ; Mon, 15 Oct 2012 17:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=nPNc4VGnv3Zq9gGyMnfo4CwbKBr4ICDPaLmqJZtq6Tw=; b=Z85wNGDeynnl8yk4q94xYCc9uhGnpSGV5NcugFNTjpf3Xogax2aLtN/lqVAdHVHiGS zgWWieWbzYb9A8IEoEikaTgbTYJkNQ5aliCjtvb2FIeaVPfhDUbzQHTOS9BBIA0zZsgz D5MWgXx4I6qZcSU0/K5dSQSGlxaypiPtP8K29V0csKqQWccJ1/9X+zeyKW+C3WnNmiZ9 sZP6ZCdyhftvx1PuyB7uEjgG39VhsF7dY5LgN5i//SMFC5RmCZ7g8CQrGwEirk2Pzcj+ 0EH3TBGzlGs7lYF3AhXDMmguV6vHUjDdpBELKx2kOjdGtik8D7rh9SMJjhr8DEJsuD6u RcNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=nPNc4VGnv3Zq9gGyMnfo4CwbKBr4ICDPaLmqJZtq6Tw=; b=Cc/WE0RmlTHGiHIp38uSfGsek50Fm/cqknRDo7ALEmSkKSaaUMkA6sJxm6zCwwtUTF w8oXa8UY2oWyEkhFppaHlICycSLeMY7Fe6p+APkjDRuxELyGiWXuzMrQkOmSpNIOZ/NN mCXWlAxCiPo/TPYyncfDpOI6XKwI/J9PBSxMN3SnCz5ELslVuQyChqBwhdzuJFfV7i1g GwXeilzC4NrM0ZDLMfSpXDZObhVJv4RTDU4oBUj7v6P1kFsYOHUh8kvM/+xv78+kl20o fSqF1QwMtuaqLrwXFbQeGDTHV6QCAMWzTaWAigEWqFdzQUGtIkAh8oy4qd4klhh+WVty s0/w== MIME-Version: 1.0 Received: by 10.216.214.209 with SMTP id c59mr7857835wep.214.1350345679361; Mon, 15 Oct 2012 17:01:19 -0700 (PDT) Received: by 10.194.37.133 with HTTP; Mon, 15 Oct 2012 17:01:19 -0700 (PDT) Date: Mon, 15 Oct 2012 17:01:19 -0700 Message-ID: From: Matt Mathis To: lmap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk6Gy4w2hfqgzspPGQu2z5ZuIF+DjxH2z13jwJk97SgvaDu+cnbON6/DkUILO7lxTEHyRWw6P6kx4ex9lPv8WmSESD6EbBo1N4YzFxAeGCGjSVAaZGkBL49wri9Pski3UDpjyTCQmBTcYVPsc+GSZ1bgEiroGJtpWXMQ+86F72dXZkEs0ckRcuzobYXaefO9Vnv98Pg Subject: [lmap] New drafts posted X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2012 00:01:21 -0000 I just posted two Internet-drafts that may be of interest to this community. Both are quite rough and missing a lot of detail. I will be looking for people who might be interested co-authoring. They are: Model Based Internet Performance Metrics We introduce a new class of model based Internet metrics designed to determine if a long path can be expected to meet a predefined end-to- end application performance target by applying a suite of single property tests to successive sections of the long path. In many cases these single property tests are based on existing IPPM metrics, with the addition of success and validity criteria. The sub-path at a time tests are designed to eliminate all known conditions that might prevent the full path from meeting the target performance. http://www.ietf.org/internet-drafts/draft-mathis-ippm-model-based-metrics-00.txt and Curating Internet Measurement Data This document describes the nomenclature, requirements and framework for handling per-sample metadata for a live archive of Internet measurements. By archive, we mean that once captured, the data MUST NOT be altered or deleted. By live, we mean that new data from ongoing measurements are being continuously appended to the archive. The purpose of the metadata is to support the use of the Scientific Method in the study the archived data. Under the principle of full disclosure, the Scientific Method requires that later researchers be able to repeat earlier studies using the original data, but refined by new insights (such as improved calibration) gained from other intervening studies. http://www.ietf.org/internet-drafts/draft-mathis-ippm-data-curation-00.txt Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. From marcelo@it.uc3m.es Mon Oct 15 22:57:30 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D79021F890C for ; Mon, 15 Oct 2012 22:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.289 X-Spam-Level: X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHEnWfTgOYMm for ; Mon, 15 Oct 2012 22:57:30 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id C9A0721F8909 for ; Mon, 15 Oct 2012 22:57:29 -0700 (PDT) Received: from dummyhost12.it.uc3m.es (dummyhost7.it.uc3m.es [163.117.139.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 5ED5C894A5F for ; Tue, 16 Oct 2012 07:57:28 +0200 (CEST) Message-ID: <507CF747.7040302@it.uc3m.es> Date: Tue, 16 Oct 2012 07:57:27 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: lmap@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Tue, 16 Oct 2012 07:57:28 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19276.004 X-TM-AS-Result: No--13.082-7.0-31-1 X-imss-scan-details: No--13.082-7.0-31-1 Subject: [lmap] starting work description discussion X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2012 05:57:30 -0000 Hi, Irrespectively whether this work takes place in a new WG, a new RG or in the IPPM WG, i guess we should start the discussion on the work description. This is my input on how the work description should look like, based on the draft and the discussion so far. Comments are welcome. Regards, marcelo LMAP Work description Over the last few years, we have witnessed the deployment of large measurement platforms that enable measurements from a vast set of vantage points. Examples of these platforms include SamKnows and RIPE ATLAS, to name a few. Such platforms integrate a large number (in the orders of tens of thousands or more) of measurement agents. These measurement agents are a piece of code that is executed either dedicated hardware or in the end user equipment (e.g. computer or mobile device). A large fraction of these measurement agents are usually located in the end-user premises and they can run measurements against other user agents that are located in strategic locations according to the desired measurements to be performed (typically servers in the core of the network). Thanks to the large number of measurement agents, these platforms can provide data about key indicators of the network performance from the end user perspective. These data is useful to network operators to improve their operations as well to regulators and to end users themselves. In addition to the measurement agents, there are other elements in these large measurement platforms, including (but not limited to): - The Controller that informs the measurement agents about what measurements to perform and when to do them. - The Data collector that collects the results of the measurements performed by the measurement agents (along with additional information such as measurement agent identification and time stamp). Currently deployed platforms use proprietary protocols to exchange information between the different parts. As these platforms grow to become an important tool to understand network performance, it is important to standardize the protocols between the different elements of the platform. The primary work items are: - An architecture document (informational document) that describes the different components of the measurement platform and their interactions. - A use cases document (informational) that describe the main use cases for these large scale measurement. - One or more protocol documents (Standard track) that specify at least the following interactions: (i) The protocol between the measurement agent and the controller, where the controller can specify the measurement to be executed by the agent and their schedule. (ii) the protocol between the measurement agent and the data collector through which the agent can report the results of the measurements performed and provide additional data (agent identification, time stamp). The protocols used to actually perform the measurements are out of the scope of this effort and can be done in the IPPM WG (this should disappear if this becomes part of the IPPM WG) - A document describing data ownership and privacy guidelines. As these platforms collect a large amount of data, data management is a critical element. From j.schoenwaelder@jacobs-university.de Mon Oct 15 23:32:10 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7A721F89B4 for ; Mon, 15 Oct 2012 23:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.222 X-Spam-Level: X-Spam-Status: No, score=-103.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBNZAnXEd6MM for ; Mon, 15 Oct 2012 23:32:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B8CA821F89B3 for ; Mon, 15 Oct 2012 23:32:09 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E03B620A1F; Tue, 16 Oct 2012 08:32:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id u5bjcBWvYLV9; Tue, 16 Oct 2012 08:32:08 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BB5E206D7; Tue, 16 Oct 2012 08:32:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 31624224AF94; Tue, 16 Oct 2012 08:32:06 +0200 (CEST) Date: Tue, 16 Oct 2012 08:32:05 +0200 From: Juergen Schoenwaelder To: marcelo bagnulo braun Message-ID: <20121016063204.GB77090@elstar.local> Mail-Followup-To: marcelo bagnulo braun , lmap@ietf.org References: <507CF747.7040302@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <507CF747.7040302@it.uc3m.es> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: lmap@ietf.org Subject: Re: [lmap] starting work description discussion X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2012 06:32:10 -0000 Marcelo, let me play devil's advocate a bit here... > Currently deployed platforms use proprietary protocols to exchange > information between the different parts. As these platforms grow to > become an important tool to understand network performance, it is > important to standardize the protocols between the different > elements of the platform. [...] > - One or more protocol documents (Standard track) that specify at > least the following interactions: (i) The protocol between the > measurement agent and the controller, where the controller can > specify the measurement to be executed by the agent and their > schedule. (ii) the protocol between the measurement agent and the > data collector through which the agent can report the results of the > measurements performed and provide additional data (agent > identification, time stamp). The protocols used to actually perform > the measurements are out of the scope of this effort and can be done > in the IPPM WG (this should disappear if this becomes part of the > IPPM WG) Taking RIPE Atlas and Sam Knows as examples, I wonder whether we really see the need for a standard allowing RIPE probes to interwork with Sam Knows and vice versa. Is this a realisitic target? How many such large measurement platforms do we expect to be implemented, do we expect an ecosystem of probe suppliers that provide hardware for different large scale measurement platforms? And will an attempt to standardize the protocol between the probes and the controller/collector not potentially hinder evolution? Perhaps it makes more sense to look at standards for protocols that allow systems to access the collected measurement data, taking into account the need to protect data and perhaps to inject additional measurement requests into the control plane of measurement networks. Having an open interface to access data collected by large scale measurement systems may open up new opportunities to use the data by systems that can influence (directly or indirectly) how networks are operated. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From marcelo@it.uc3m.es Mon Oct 15 23:50:29 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4639B21F88DD for ; Mon, 15 Oct 2012 23:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.367 X-Spam-Level: X-Spam-Status: No, score=-106.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYij1abKtGZA for ; Mon, 15 Oct 2012 23:50:28 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACEC21F88DB for ; Mon, 15 Oct 2012 23:50:27 -0700 (PDT) Received: from dummyhost12.it.uc3m.es (unknown [163.117.139.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 9A95ACADF8E for ; Tue, 16 Oct 2012 08:50:26 +0200 (CEST) Message-ID: <507D03B1.6020209@it.uc3m.es> Date: Tue, 16 Oct 2012 08:50:25 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: lmap@ietf.org References: <507CF747.7040302@it.uc3m.es> <20121016063204.GB77090@elstar.local> In-Reply-To: <20121016063204.GB77090@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Tue, 16 Oct 2012 08:50:26 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19276.004 X-TM-AS-Result: No--22.521-7.0-31-1 X-imss-scan-details: No--22.521-7.0-31-1 Subject: Re: [lmap] starting work description discussion X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2012 06:50:29 -0000 Hi Juergen, below... El 16/10/12 08:32, Juergen Schoenwaelder escribió: > Marcelo, > > let me play devil's advocate a bit here... > >> Currently deployed platforms use proprietary protocols to exchange >> information between the different parts. As these platforms grow to >> become an important tool to understand network performance, it is >> important to standardize the protocols between the different >> elements of the platform. > [...] > >> - One or more protocol documents (Standard track) that specify at >> least the following interactions: (i) The protocol between the >> measurement agent and the controller, where the controller can >> specify the measurement to be executed by the agent and their >> schedule. (ii) the protocol between the measurement agent and the >> data collector through which the agent can report the results of the >> measurements performed and provide additional data (agent >> identification, time stamp). The protocols used to actually perform >> the measurements are out of the scope of this effort and can be done >> in the IPPM WG (this should disappear if this becomes part of the >> IPPM WG) > Taking RIPE Atlas and Sam Knows as examples, I wonder whether we > really see the need for a standard allowing RIPE probes to interwork > with Sam Knows and vice versa. Is this a realisitic target? How many > such large measurement platforms do we expect to be implemented, do we > expect an ecosystem of probe suppliers that provide hardware for > different large scale measurement platforms? And will an attempt to > standardize the protocol between the probes and the > controller/collector not potentially hinder evolution? > > My view on this is the following: I would expect that the user agents are either embedded in the CPE (home router) from the vendor, or it can be dowloaded to the end user device (e.ge standard linux app or whatever). Suppose that home router have this measurement agent already built in. then deployment of very large platforms would be much easier, you should simply rely on this existent capability. So, I do believe there is value on standardizing this and i do believe this would make easier to deploy these platforms. > Perhaps it makes more sense to look at standards for protocols that > allow systems to access the collected measurement data, taking into > account the need to protect data and perhaps to inject additional > measurement requests into the control plane of measurement > networks. Having an open interface to access data collected by large > scale measurement systems may open up new opportunities to use the > data by systems that can influence (directly or indirectly) how > networks are operated. Right, i agree with tis (actually i had written in the initial version of the DoW a work item on this, but then i felt it maight be better to have a more narrow scope. I mean, i find that relevant and interesting, i am concerned about having a too broad/large amount of work. Regards, marcelo > /js > From robert@ripe.net Tue Oct 16 00:38:31 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F9921F85EA for ; Tue, 16 Oct 2012 00:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaeb1pKrjWeZ for ; Tue, 16 Oct 2012 00:38:30 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 770DA21F8806 for ; Tue, 16 Oct 2012 00:38:30 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TO1jQ-0001Ly-Oq for lmap@ietf.org; Tue, 16 Oct 2012 09:38:29 +0200 Received: from baboon.ripe.net ([193.0.1.208] helo=Kistel-Mac.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TO1jQ-0007Xs-Ko for lmap@ietf.org; Tue, 16 Oct 2012 09:38:28 +0200 Message-ID: <507D0EF5.1000403@ripe.net> Date: Tue, 16 Oct 2012 09:38:29 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: lmap@ietf.org References: <507CF747.7040302@it.uc3m.es> <20121016063204.GB77090@elstar.local> In-Reply-To: <20121016063204.GB77090@elstar.local> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121016 clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.3 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274e980132c7b1cb436ffa28437e05ec485 Subject: Re: [lmap] starting work description discussion X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2012 07:38:31 -0000 Hi, On 2012.10.16. 8:32, Juergen Schoenwaelder wrote: > Taking RIPE Atlas and Sam Knows as examples, I wonder whether we > really see the need for a standard allowing RIPE probes to interwork > with Sam Knows and vice versa. Is this a realisitic target? How many > such large measurement platforms do we expect to be implemented, do we > expect an ecosystem of probe suppliers that provide hardware for > different large scale measurement platforms? And will an attempt to > standardize the protocol between the probes and the > controller/collector not potentially hinder evolution? This is spot on. I cannot imagine how one could realistically manage multiple control infrastructures for the same set of measurement devices. Speaking for Atlas only: if there was a potential second (third, ...) source of measurement tasks, we would lose our ability to manage measurement capacities, bandwidth, scheduling on the measurement nodes. > Perhaps it makes more sense to look at standards for protocols that > allow systems to access the collected measurement data, taking into > account the need to protect data and perhaps to inject additional > measurement requests into the control plane of measurement > networks. Having an open interface to access data collected by large > scale measurement systems may open up new opportunities to use the > data by systems that can influence (directly or indirectly) how > networks are operated. I think this is a much more interesting approach. It focuses on how to interact with such a system and how to transform the results into a common format. The combination of the two allows for users to leverage the power of the different measurement networks, yet leaves the implementation details to those networks. It's also relatively simple to implement: one only needs to translate the control messages and result data to/from the common format. Robert (who is somewhat involved in the making of RIPE Atlas) From trammell@tik.ee.ethz.ch Tue Oct 16 02:00:38 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BE021F88B8 for ; Tue, 16 Oct 2012 02:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46WHz4hsVY4R for ; Tue, 16 Oct 2012 02:00:38 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9737021F88B4 for ; Tue, 16 Oct 2012 02:00:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id AA2E5D9315; Tue, 16 Oct 2012 11:00:35 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GSPZ+SD8+g7W; Tue, 16 Oct 2012 11:00:35 +0200 (MEST) Received: from [192.168.3.95] (mx.ftw.at [213.235.244.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3489AD930D; Tue, 16 Oct 2012 11:00:35 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <507D0EF5.1000403@ripe.net> Date: Tue, 16 Oct 2012 11:00:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65CA05F0-306D-41F1-B46B-A06E11DF0C79@tik.ee.ethz.ch> References: <507CF747.7040302@it.uc3m.es> <20121016063204.GB77090@elstar.local> <507D0EF5.1000403@ripe.net> To: lmap@ietf.org X-Mailer: Apple Mail (2.1278) Cc: marcelo bagnulo braun , Juergen Schoenwaelder , Robert Kisteleki , =?iso-8859-1?Q?Mirja_K=FChlewind?= Subject: Re: [lmap] starting work description discussion X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2012 09:00:39 -0000 Hi, all, catching up on the backlog, so I'm following a couple of threads at once = here, inline. first from last week: On Oct 10, 2012, at 6:05 PM, Mirja K=FChlewind wrote: > 3. There might also be some kind of hierarchy between data collectors. = If I=20 > use more than one data collector for load balancing reasons. I guess = those=20 > single collectors could do some kind of preprocessing but then I still = need=20 > one entity to correlate all data to get a view on my whole network. = Thus=20 > maybe a protocol to query the data should be regarded as well. Btw. = there can=20 > already be some kind of preprocessing at the measurements endpoint=20 > (client/server) as well.=20 Yep. I presume you'll probably end up with mediators in most large scale = deployments, either to handle load from widely distributed measurements = at collectors, or to consolidate interdomain data exchange (i.e. each = operator has a first-tier collector, which then sends results to a = central collector after applying any data inspection/aggregation/etc = necessary.)=20 One question in this case would then be one of scope: would the = interactions behind the mediator then be subject to control by LMAP, or = does LMAP's responsibility stop with the first tier collector? Is it a = protocol for controlling simple measurements, or for producing answers = by controlling a hierarchy of devices end to end? > -> All over we might only need two protocols. One to request or = initiate=20 > measurements and one to request or exchange measurement data.=20 +1. I'd go further and say it probably makes sense to try and handle = measurement data exchange (from measurement point to collector) using = existing protocols, when they exist -- if I'm doing passive measurement = based on flows, for example, and I have an LMAP-enabled flow meter that = speaks IPFIX and a collector that speaks IPFIX, it makes sense to just = have them talk to each other using the protocol they already know, as = opposed to doing transcoding on both ends. Same goes for OWAMP/TWAMP, = though they do control and data export over the same protocol, so that = might need to be split somehow to fit LMAP as specified. In cases for supporting measurement for which there's no existing export = protocol, it's not clear what to do, though. > The first one can be used between the controller and measurement = endpoint, as=20 > well as between measurement endpoints and between controllers in a=20 > hierarchical structure. Not to do design before we know all the requirements... :) but it seems = to me like this protocol would just be a way to pass "measurement = specifications" around, with all the parameters required: what to = measure, how to measure it, and who to send the results to, with a . = Controllers could split these up and send them down to subordinate = controllers as they see fit. As I noted in an earlier comment, I think it makes sense for the = protocol for exchanging these specifications be initiator-independent -- = it makes sense to have (some subset of) measurement points that can do = on demand active measurement, without waiting for a polling interval, = for cause analysis or differentiation during troubleshooting. These = would probably be owned by the operator, as compared to measurement = points closer to the edge, who might be owned by customers and therefore = should pull their measurement specifications, both to allow customer = control of the measurement as well as to work around NAT. It also makes = sense, if we support a hierarchy of controllers, to allow superordinate = controllers to push specifications to their subordinates. > The second one can be used between the measurement point and the data=20= > collector (where the measurement might also be able to store and = evaluate the=20 > data) and as well between measurement points and data collectors and = also=20 > between the controller and the data collector/measurement endpoints = (as the=20 > controller might need previous results to configure new measurement = runs). > Both protocols will also need some kind of capacity negotiation as = well as=20 > some kind of authentication and integrity check. Hm... what do you mean by capacity negotiation here? In terms of the = measurement load on the network, the number of measurements a = measurement point is willing to handle concurrently, the amount of data = the collector is willing to accept? Actually -- all of these will need = to be handled, I think... and now for this morning's thread: On Oct 16, 2012, at 9:38 AM, Robert Kisteleki wrote: > Hi, >=20 > On 2012.10.16. 8:32, Juergen Schoenwaelder wrote: >> Taking RIPE Atlas and Sam Knows as examples, I wonder whether we >> really see the need for a standard allowing RIPE probes to interwork >> with Sam Knows and vice versa. Is this a realisitic target? How many >> such large measurement platforms do we expect to be implemented, do = we >> expect an ecosystem of probe suppliers that provide hardware for >> different large scale measurement platforms? And will an attempt to >> standardize the protocol between the probes and the >> controller/collector not potentially hinder evolution? >=20 > This is spot on. I cannot imagine how one could realistically manage > multiple control infrastructures for the same set of measurement = devices. > Speaking for Atlas only: if there was a potential second (third, ...) = source > of measurement tasks, we would lose our ability to manage measurement > capacities, bandwidth, scheduling on the measurement nodes. First, I think (as noted above) that the measurement point -> collector = protocol is out of scope; there are already protocols for doing this, = each meeting the requirements of particular measurements, and there's no = need either to reinvent the wheel or to put a lot of effort into writing = transcoders for data that will never leave the probe->collector pipe. I also don't think the right approach is to build multiple control = infrastructures; instead, if we consider a "measurement specification" = as the unit of LMAP control (also as above), these would be an = additional source of instructions, that could be translated into = instructions and configuration for the existing control interface, = subject to local constraints, such as measurement traffic capacity, or = even restrictions of the functions available via LMAP as opposed to via = the "native" control interface. >> Perhaps it makes more sense to look at standards for protocols that >> allow systems to access the collected measurement data, taking into >> account the need to protect data and perhaps to inject additional >> measurement requests into the control plane of measurement >> networks. Having an open interface to access data collected by large >> scale measurement systems may open up new opportunities to use the >> data by systems that can influence (directly or indirectly) how >> networks are operated. A measurement specification could also be seen as a query, of sorts. = I.e., you'd send an LMAP measurement specification to a measurement = point (or it would retrieve a specification, in the pull model) to start = a running measurement, and you'd send the same specification (perhaps = with a different temporal scope) to a collector to retrieve information = already collected.=20 > I think this is a much more interesting approach. It focuses on how to > interact with such a system and how to transform the results into a = common > format. +1. I think there are two separate parts to this common format: one would be = the semantic definition of what each measurement of set of measurements = means, and the other would be the actual representation. I think we = should probably aim to separate the data model from the formatting, both = to keep from getting caught up in a JSON-vs-XML-vs-ASN.1 argument (as = fun as those are), and because the data model is the more interesting = problem, or rather, the one which is most critical to get right. > The combination of the two allows for users to leverage the power of > the different measurement networks, yet leaves the implementation = details to > those networks. >=20 > It's also relatively simple to implement: one only needs to translate = the > control messages and result data to/from the common format. Once the hard decisions are made about the semantic meaning of the data = (and how data from one or another measurement system might need to be = transformed to meet that definition), I agree. For basic measurement, = the IPPM metrics are an obvious choice as a starting point (as, indeed, = mentioned in the lmap draft), though we'll need comparable methods for = passive measurement of these metrics; see = http://tools.ietf.org/html/draft-trammell-ippm-hybrid-ps-00.html for the = very beginning of a problem statement on the subject. Best regards, Brian From marcelo@it.uc3m.es Tue Oct 16 05:24:51 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1845921F87BD for ; Tue, 16 Oct 2012 05:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.413 X-Spam-Level: X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqM2GMESK+97 for ; Tue, 16 Oct 2012 05:24:50 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id DF3A921F8814 for ; Tue, 16 Oct 2012 05:24:49 -0700 (PDT) Received: from dummyhost7.it.uc3m.es (unknown [163.117.139.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 1F614894ACF; Tue, 16 Oct 2012 14:24:48 +0200 (CEST) Message-ID: <507D520F.4010605@it.uc3m.es> Date: Tue, 16 Oct 2012 14:24:47 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Brian Trammell References: <507CF747.7040302@it.uc3m.es> <20121016063204.GB77090@elstar.local> <507D0EF5.1000403@ripe.net> <65CA05F0-306D-41F1-B46B-A06E11DF0C79@tik.ee.ethz.ch> In-Reply-To: <65CA05F0-306D-41F1-B46B-A06E11DF0C79@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Tue, 16 Oct 2012 14:24:48 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19276.006 X-TM-AS-Result: No--39.855-7.0-31-1 X-imss-scan-details: No--39.855-7.0-31-1 Cc: Juergen Schoenwaelder , Robert Kisteleki , =?ISO-8859-1?Q?Mirja_K=FChlewind?= , lmap@ietf.org Subject: Re: [lmap] starting work description discussion X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2012 12:24:51 -0000 below.... El 16/10/12 11:00, Brian Trammell escribió: > Hi, all, > > catching up on the backlog, so I'm following a couple of threads at once here, inline. first from last week: > > On Oct 10, 2012, at 6:05 PM, Mirja Kühlewind wrote: > >> 3. There might also be some kind of hierarchy between data collectors. If I >> use more than one data collector for load balancing reasons. I guess those >> single collectors could do some kind of preprocessing but then I still need >> one entity to correlate all data to get a view on my whole network. Thus >> maybe a protocol to query the data should be regarded as well. Btw. there can >> already be some kind of preprocessing at the measurements endpoint >> (client/server) as well. > Yep. I presume you'll probably end up with mediators in most large scale deployments, either to handle load from widely distributed measurements at collectors, or to consolidate interdomain data exchange (i.e. each operator has a first-tier collector, which then sends results to a central collector after applying any data inspection/aggregation/etc necessary.) MB> that makes sense. It is not obvious to me whether the protocol needs to be different for the measurement clietns and the mediators though. Probably at this point we should leave it open and make sure that the work description allows for both. > One question in this case would then be one of scope: would the interactions behind the mediator then be subject to control by LMAP, or does LMAP's responsibility stop with the first tier collector? Is it a protocol for controlling simple measurements, or for producing answers by controlling a hierarchy of devices end to end? MB> see above. I mean, i guess this should be left for discussion for the actual work. It is not obvious to me how significantly different should these two protocol be. >> -> All over we might only need two protocols. One to request or initiate >> measurements and one to request or exchange measurement data. > +1. > > I'd go further and say it probably makes sense to try and handle measurement data exchange (from measurement point to collector) using existing protocols, when they exist -- if I'm doing passive measurement based on flows, for example, and I have an LMAP-enabled flow meter that speaks IPFIX and a collector that speaks IPFIX, it makes sense to just have them talk to each other using the protocol they already know, as opposed to doing transcoding on both ends. Same goes for OWAMP/TWAMP, though they do control and data export over the same protocol, so that might need to be split somehow to fit LMAP as specified. > > In cases for supporting measurement for which there's no existing export protocol, it's not clear what to do, though. MB> So, my understanding is that current platforms support an extensive set of active measruements that go beyond OWAMP/TWAMP. So, i think more than these two protocols will be needed if we want to support this. I guess the question at this point is how generic a protocol for exchanging measurement results can be when it is not tied to a specfic measurement. I mean, we could define a protocol (or reuse a protocol) that is a general envelope to exchange results from the measurement agent to the data collector, that is generic irrespectively to the actual test being reported. Then for each specific tests, we should add the specific data fields that the report should contain. the generic envelope would carry information about the measurement agent identification, time stamp, and additional security data. I am uncertain whether this has value, but i guess it may. the test specific part shoudl be defined for each test whose results is being reported and it should contain specific fields for the specific test. I agree that we should reuse existing protocols. Do you know an exisitng protocol that could serve as envelope protocol? >> The first one can be used between the controller and measurement endpoint, as >> well as between measurement endpoints and between controllers in a >> hierarchical structure. > Not to do design before we know all the requirements... :) but it seems to me like this protocol would just be a way to pass "measurement specifications" around, with all the parameters required: what to measure, how to measure it, and who to send the results to, with a . Controllers could split these up and send them down to subordinate controllers as they see fit. MB> I think this is one place where the IETF could add value. We should define a registry for measurements that can be perfoemed by the clients and for each of them to have a code identifying the tests, and the set of parameters that are needed as input and the oputput that is needs to be reported. then this protocol should convey to the measurement agent the code for the measurement as defined in the registry as well as the input parameters. (I have seen that the IPPM metrcis registry, that probably looks a bit like this has been deprecated, I wonder if there is something to learn from that experience...) ... > On Oct 16, 2012, at 9:38 AM, Robert Kisteleki wrote: >> Hi, >> >> On 2012.10.16. 8:32, Juergen Schoenwaelder wrote: >>> Taking RIPE Atlas and Sam Knows as examples, I wonder whether we >>> really see the need for a standard allowing RIPE probes to interwork >>> with Sam Knows and vice versa. Is this a realisitic target? How many >>> such large measurement platforms do we expect to be implemented, do we >>> expect an ecosystem of probe suppliers that provide hardware for >>> different large scale measurement platforms? And will an attempt to >>> standardize the protocol between the probes and the >>> controller/collector not potentially hinder evolution? >> This is spot on. I cannot imagine how one could realistically manage >> multiple control infrastructures for the same set of measurement devices. >> Speaking for Atlas only: if there was a potential second (third, ...) source >> of measurement tasks, we would lose our ability to manage measurement >> capacities, bandwidth, scheduling on the measurement nodes. > First, I think (as noted above) that the measurement point -> collector protocol is out of scope; there are already protocols for doing this, each meeting the requirements of particular measurements, and there's no need either to reinvent the wheel or to put a lot of effort into writing transcoders for data that will never leave the probe->collector pipe. MB> see above about the envelope protocol. Besides, you also point that there are some cases where another protocol is needed, so i am kind of confused by your summary here. My understanding is that we could either define one specific protocol for each type of measurement we are going to support (i understand this is what OWAMP and TWAMP are), but we probably support more tests. I believe this envelope protocol would provide an extensible framework to define then the specific tests. > > I also don't think the right approach is to build multiple control infrastructures; MB> as i mentioned to my reply to Juergen, i think there is much more value in standardizing the interfaces other than supporting multiple control infrastrucutres. For example, the possibility that of the shelf equipment already supports the measurements and can then be integrated into a measurment platform without requiring additional code (e.g. suppose the home routers already support LMAP, they could then be integrated into a platform without additional deployment burden) Regards, marcelo From nweaver@icsi.berkeley.edu Tue Oct 16 10:46:33 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3AE21F8A07 for ; Tue, 16 Oct 2012 10:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tUYgqfSI3s3 for ; Tue, 16 Oct 2012 10:46:33 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 522A821F89E0 for ; Tue, 16 Oct 2012 10:46:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E57BD2C4017 for ; Tue, 16 Oct 2012 10:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2R98whR8BrYQ; Tue, 16 Oct 2012 10:46:32 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id AE7C22C4002; Tue, 16 Oct 2012 10:46:32 -0700 (PDT) From: Nicholas Weaver Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Oct 2012 10:46:32 -0700 Message-Id: <33FFDE6E-42A4-4594-80DE-614C066D8C64@icsi.berkeley.edu> To: lmap@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: Nicholas Weaver Subject: [lmap] Introduction X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2012 17:46:33 -0000 Jason Livinggood and others made me aware of this working group, so I've = joined the list. For background and those who don't know me, I'm one of the primary = developers of Netalyzr. Any questions, feel free to ask. Amongst other = things, we now have a command line client and a JSON API for test = results. From trammell@tik.ee.ethz.ch Wed Oct 17 06:54:48 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660C821F8799 for ; Wed, 17 Oct 2012 06:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWrBoDqhiAdD for ; Wed, 17 Oct 2012 06:54:47 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 10D1721F8795 for ; Wed, 17 Oct 2012 06:54:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id AA882D9310; Wed, 17 Oct 2012 15:54:44 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xJAU8rp8g8bA; Wed, 17 Oct 2012 15:54:44 +0200 (MEST) Received: from [192.168.3.95] (mx.ftw.at [213.235.244.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 17ABAD930C; Wed, 17 Oct 2012 15:54:44 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <507D520F.4010605@it.uc3m.es> Date: Wed, 17 Oct 2012 15:54:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <507CF747.7040302@it.uc3m.es> <20121016063204.GB77090@elstar.local> <507D0EF5.1000403@ripe.net> <65CA05F0-306D-41F1-B46B-A06E11DF0C79@tik.ee.ethz.ch> <507D520F.4010605@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1278) Cc: =?iso-8859-1?Q?Mirja_K=FChlewind?= , Robert Kisteleki , Juergen Schoenwaelder , lmap@ietf.org Subject: Re: [lmap] starting work description discussion X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:54:48 -0000 hi, Marcelo, all, inline per tradition... On Oct 16, 2012, at 2:24 PM, marcelo bagnulo braun wrote: > below.... >=20 > El 16/10/12 11:00, Brian Trammell escribi=F3: >> Hi, all, >>=20 >> catching up on the backlog, so I'm following a couple of threads at = once here, inline. first from last week: >>=20 >> On Oct 10, 2012, at 6:05 PM, Mirja K=FChlewind wrote: >>=20 >>> 3. There might also be some kind of hierarchy between data = collectors. If I >>> use more than one data collector for load balancing reasons. I guess = those >>> single collectors could do some kind of preprocessing but then I = still need >>> one entity to correlate all data to get a view on my whole network. = Thus >>> maybe a protocol to query the data should be regarded as well. Btw. = there can >>> already be some kind of preprocessing at the measurements endpoint >>> (client/server) as well. >> Yep. I presume you'll probably end up with mediators in most large = scale deployments, either to handle load from widely distributed = measurements at collectors, or to consolidate interdomain data exchange = (i.e. each operator has a first-tier collector, which then sends results = to a central collector after applying any data = inspection/aggregation/etc necessary.) >=20 > MB> that makes sense. It is not obvious to me whether the protocol = needs to be different for the measurement clietns and the mediators = though. Probably at this point we should leave it open and make sure = that the work description allows for both. >=20 >> One question in this case would then be one of scope: would the = interactions behind the mediator then be subject to control by LMAP, or = does LMAP's responsibility stop with the first tier collector? Is it a = protocol for controlling simple measurements, or for producing answers = by controlling a hierarchy of devices end to end? >=20 > MB> see above. I mean, i guess this should be left for discussion for = the actual work. It is not obvious to me how significantly different = should these two protocol be. Agreed on both these points... actually, if we think in terms of = measurement specifications, the distinction of the position of a = particular entity within a measurement infrastructure -- whether it's a = mediator, or a final collector, or a measurement point, or whatever -- = goes away; there are just sources and sinks of data... But yes, this should be decided as a question of scope after the work = description... >>> -> All over we might only need two protocols. One to request or = initiate >>> measurements and one to request or exchange measurement data. >> +1. >>=20 >> I'd go further and say it probably makes sense to try and handle = measurement data exchange (from measurement point to collector) using = existing protocols, when they exist -- if I'm doing passive measurement = based on flows, for example, and I have an LMAP-enabled flow meter that = speaks IPFIX and a collector that speaks IPFIX, it makes sense to just = have them talk to each other using the protocol they already know, as = opposed to doing transcoding on both ends. Same goes for OWAMP/TWAMP, = though they do control and data export over the same protocol, so that = might need to be split somehow to fit LMAP as specified. >>=20 >> In cases for supporting measurement for which there's no existing = export protocol, it's not clear what to do, though. >=20 > MB> So, my understanding is that current platforms support an = extensive set of active measruements that go beyond OWAMP/TWAMP. So, i = think more than these two protocols will be needed if we want to support = this. I'm thinking as well specifically about passive measurement tools, and = all the information that might be available over IPFIX or SNMP. > I guess the question at this point is how generic a protocol for = exchanging measurement results can be when it is not tied to a specfic = measurement. > I mean, we could define a protocol (or reuse a protocol) that is a = general envelope to exchange results from the measurement agent to the = data collector, that is generic irrespectively to the actual test being = reported. Then for each specific tests, we should add the specific data = fields that the report should contain. > the generic envelope would carry information about the measurement = agent identification, time stamp, and additional security data. I am = uncertain whether this has value, but i guess it may. > the test specific part shoudl be defined for each test whose results = is being reported and it should contain specific fields for the specific = test. > I agree that we should reuse existing protocols. Do you know an = exisitng protocol that could serve as envelope protocol? IPFIX might be a good fit for this envelope, if the data about the = measurements is relatively uniform in structure, if it acceptable for = the measurement-point-to-collector communication to be (1) = unidirectional and (2) initiated by the measurement point. It's = self-describing without being inefficient, it has a rich set of = information elements for representing timestamps and information about = measurement points, and has bindings to TLS and DTLS. New information = elements for specific metrics and metric parameters can be easily added. As defined, it's not a particularly good fit for architectures where the = information is pulled in chunks, although you could place results in an = IPFIX File and transport that over any of the various protocols we've = defined for moving files around. It's also not a good fit for = applications where each record has a wildly different structure. >=20 >>> The first one can be used between the controller and measurement = endpoint, as >>> well as between measurement endpoints and between controllers in a >>> hierarchical structure. >> Not to do design before we know all the requirements... :) but it = seems to me like this protocol would just be a way to pass "measurement = specifications" around, with all the parameters required: what to = measure, how to measure it, and who to send the results to, with a . = Controllers could split these up and send them down to subordinate = controllers as they see fit. >=20 > MB> I think this is one place where the IETF could add value. We = should define a registry for measurements that can be perfoemed by the = clients and for each of them to have a code identifying the tests, and = the set of parameters that are needed as input and the oputput that is = needs to be reported. > then this protocol should convey to the measurement agent the code for = the measurement as defined in the registry as well as the input = parameters. Absolutely. > (I have seen that the IPPM metrcis registry, that probably looks a bit = like this has been deprecated, I wonder if there is something to learn = from that experience...) =46rom what I understand, this was due to the combinatoric nature of = metric definitions in IPPM, which led to a lack of use. (I'm just a = long-time-lurker in IPPM, though, so if I've got this wrong, IPPM people = please correct me.) I would presume that an IPPM measurement registry = would register classes of measurements, where the specific parameters of = the measurement would not be captured within the type information of the = metric definition, and would rather be captured in the configuration = parameters in a measurement specification / control protocol = interaction. > ... >> On Oct 16, 2012, at 9:38 AM, Robert Kisteleki wrote: >>> Hi, >>>=20 >>> On 2012.10.16. 8:32, Juergen Schoenwaelder wrote: >>>> Taking RIPE Atlas and Sam Knows as examples, I wonder whether we >>>> really see the need for a standard allowing RIPE probes to = interwork >>>> with Sam Knows and vice versa. Is this a realisitic target? How = many >>>> such large measurement platforms do we expect to be implemented, do = we >>>> expect an ecosystem of probe suppliers that provide hardware for >>>> different large scale measurement platforms? And will an attempt to >>>> standardize the protocol between the probes and the >>>> controller/collector not potentially hinder evolution? >>> This is spot on. I cannot imagine how one could realistically manage >>> multiple control infrastructures for the same set of measurement = devices. >>> Speaking for Atlas only: if there was a potential second (third, = ...) source >>> of measurement tasks, we would lose our ability to manage = measurement >>> capacities, bandwidth, scheduling on the measurement nodes. >> First, I think (as noted above) that the measurement point -> = collector protocol is out of scope; there are already protocols for = doing this, each meeting the requirements of particular measurements, = and there's no need either to reinvent the wheel or to put a lot of = effort into writing transcoders for data that will never leave the = probe->collector pipe. >=20 > MB> see above about the envelope protocol. Besides, you also point = that there are some cases where another protocol is needed, so i am kind = of confused by your summary here. Sorry, I didn't express that very well... What I mean is that where we = have an existing data export protocol, we should probably use it; where = we do not, it probably doesn't make much sense to define a new data = export protocol for every new measurement use case, but it might also be = difficult to define a one-size-fits-all protocol. > My understanding is that we could either define one specific protocol = for each type of measurement we are going to support (i understand this = is what OWAMP and TWAMP are), but we probably support more tests. > I believe this envelope protocol would provide an extensible framework = to define then the specific tests. >=20 >=20 >=20 >>=20 >> I also don't think the right approach is to build multiple control = infrastructures; >=20 > MB> as i mentioned to my reply to Juergen, i think there is much more = value in standardizing the interfaces other than supporting multiple = control infrastrucutres. For example, the possibility that of the shelf = equipment already supports the measurements and can then be integrated = into a measurment platform without requiring additional code (e.g. = suppose the home routers already support LMAP, they could then be = integrated into a platform without additional deployment burden) +n for very large n.=20 I wasn't trying to contradict this point; instead, I meant that = standardized interfaces could be supported _inline_ with existing = control for existing measurement infrastructures through translation, as = opposed to a completely alternate source of control. Maybe this is a too = fine a distinction... It is indeed the off-the-shelf-equipment argument that makes LMAP so = interesting for me; it's not about existing infrastructures, but = existing tools from which new infrastructures can be built. Cheers, Brian From marcelo@it.uc3m.es Wed Oct 17 10:34:00 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED93A21F85D5 for ; Wed, 17 Oct 2012 10:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.537 X-Spam-Level: X-Spam-Status: No, score=-105.537 tagged_above=-999 required=5 tests=[AWL=-0.797, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6FgSTEzWyuk for ; Wed, 17 Oct 2012 10:34:00 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 4352821F85C7 for ; Wed, 17 Oct 2012 10:33:59 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [163.117.203.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 7F190CADFA3 for ; Wed, 17 Oct 2012 19:33:58 +0200 (CEST) Message-ID: <507EEC05.8000608@it.uc3m.es> Date: Wed, 17 Oct 2012 19:33:57 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: lmap@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Wed, 17 Oct 2012 19:33:58 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19282.000 X-TM-AS-Result: No--0.824-7.0-31-1 X-imss-scan-details: No--0.824-7.0-31-1 Subject: [lmap] Bar BOF X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 17:34:01 -0000 Hi, Any news about the Bar BOF? Now that the IETF agenda is fixed, do we have a date and time for the Bar BOF? Shouldnt we start discussing the agenda for the meeting? Regards, marcelo From hannes.tschofenig@gmx.net Wed Oct 17 10:56:08 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E798F21F8513 for ; Wed, 17 Oct 2012 10:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT+GpaTNfUCb for ; Wed, 17 Oct 2012 10:56:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1D31B21F850B for ; Wed, 17 Oct 2012 10:56:06 -0700 (PDT) Received: (qmail invoked by alias); 17 Oct 2012 17:56:05 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.216.191] by mail.gmx.net (mp001) with SMTP; 17 Oct 2012 19:56:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/IQJp4WJ7IENYwATRsfTtCVhp+NbLBlhgoL9iDmF vfOd7mLvzy99Tb Message-ID: <507EF132.6060404@gmx.net> Date: Wed, 17 Oct 2012 20:56:02 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: marcelo bagnulo braun References: <507EEC05.8000608@it.uc3m.es> In-Reply-To: <507EEC05.8000608@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: hannes.tschofenig@gmx.net, lmap@ietf.org Subject: Re: [lmap] Bar BOF X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 17:56:09 -0000 Henning created a Doddle poll: http://www.doodle.com/78t3r4m3mfrea5yp (as you know; your name is on it) The Thursday looks pretty promising (from the current person count). I don't think we need a rich agenda. Henning should say a few introductory words and then we discuss the topic. I can check whether the IAB meeting room is available. On 10/17/2012 08:33 PM, marcelo bagnulo braun wrote: > Hi, > > Any news about the Bar BOF? > Now that the IETF agenda is fixed, do we have a date and time for the > Bar BOF? > > Shouldnt we start discussing the agenda for the meeting? > > Regards, marcelo > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From jason.weil@twcable.com Wed Oct 17 10:57:25 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D679F21F8522 for ; Wed, 17 Oct 2012 10:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEEhFiNp9eBJ for ; Wed, 17 Oct 2012 10:57:24 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5236B21F8673 for ; Wed, 17 Oct 2012 10:57:24 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,602,1344225600"; d="scan'208";a="455178306" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 17 Oct 2012 13:56:00 -0400 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.44]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Wed, 17 Oct 2012 13:56:21 -0400 From: "Weil, Jason" To: marcelo bagnulo braun , "lmap@ietf.org" Date: Wed, 17 Oct 2012 13:56:24 -0400 Thread-Topic: [lmap] Bar BOF Thread-Index: Ac2skLdi08n3bVfaTA+8coZpP8g7IQ== Message-ID: In-Reply-To: <507EEC05.8000608@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Walter Johnston , "James.Miller@fcc.gov" , Henning Schulzrinne Subject: Re: [lmap] Bar BOF X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 17:57:26 -0000 All, I requested a meeting room for this discussion under the TSV area late last week based on a discussion with the authors and a number of potential participants at a meeting on 10.10.2012. I just received word that it was approved this morning and the information has been forwarded to the IETF Secretariat for scheduling. I originally scheduled the room for 19:30-20:30 on 10.7.2012, but this time was pushed back 30 mins to 20:00-21:00 as the Plenary technically is scheduled to end at 19:45. Here is the information from the meeting request: Meeting Name: Broadband Performance Measurement Desired Meeting Date: 11/07/2012 Alternate Meeting Date: 11/08/2013 Number of Days: 1 Meeting Area/Type: TSV Expected Attendance: 50 Desired Start Time: 19:30:00 **Moved to 20:00:00** Desired End Time: 20:30:00 Room Configuration: Conference Speakerphone: No LCD Projector: Yes Thanks, Jason Weil On 10/17/12 1:33 PM, "marcelo bagnulo braun" wrote: >Hi, > >Any news about the Bar BOF? >Now that the IETF agenda is fixed, do we have a date and time for the >Bar BOF? > >Shouldnt we start discussing the agenda for the meeting? > >Regards, marcelo > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From marcelo@it.uc3m.es Wed Oct 17 11:17:26 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A516121F854E for ; Wed, 17 Oct 2012 11:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SzWXJqG-1aC for ; Wed, 17 Oct 2012 11:17:25 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id AEC5321F8551 for ; Wed, 17 Oct 2012 11:17:25 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (222.38.218.87.dynamic.jazztel.es [87.218.38.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id C503788BC5F; Wed, 17 Oct 2012 20:17:20 +0200 (CEST) Message-ID: <507EF62F.7080506@it.uc3m.es> Date: Wed, 17 Oct 2012 20:17:19 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Weil, Jason" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTHACL 134 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Wed, 17 Oct 2012 20:17:21 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19282.000 X-TM-AS-Result: No--19.689-7.0-31-1 X-imss-scan-details: No--19.689-7.0-31-1 Cc: Walter Johnston , Henning Schulzrinne , "James.Miller@fcc.gov" , "lmap@ietf.org" Subject: Re: [lmap] Bar BOF X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 18:17:26 -0000 Great, thanks. Dont you think we could need a bigger room? I mean at that time, it shouldnt be hard to get a big room and it is very hard to predict the number of people in these things. El 17/10/12 19:56, Weil, Jason escribió: > All, > > I requested a meeting room for this discussion under the TSV area late > last week based on a discussion with the authors and a number of potential > participants at a meeting on 10.10.2012. I just received word that it was > approved this morning and the information has been forwarded to the IETF > Secretariat for scheduling. I originally scheduled the room for > 19:30-20:30 on 10.7.2012, but this time was pushed back 30 mins to > 20:00-21:00 as the Plenary technically is scheduled to end at 19:45. > > Here is the information from the meeting request: > > Meeting Name: Broadband Performance Measurement > > Desired Meeting Date: 11/07/2012 > Alternate Meeting Date: 11/08/2013 > Number of Days: 1 > Meeting Area/Type: TSV > Expected Attendance: 50 > Desired Start Time: 19:30:00 **Moved to 20:00:00** > Desired End Time: 20:30:00 > Room Configuration: Conference > Speakerphone: No > LCD Projector: Yes > > > > > Thanks, > > Jason Weil > > > > > On 10/17/12 1:33 PM, "marcelo bagnulo braun" wrote: > >> Hi, >> >> Any news about the Bar BOF? >> Now that the IETF agenda is fixed, do we have a date and time for the >> Bar BOF? >> >> Shouldnt we start discussing the agenda for the meeting? >> >> Regards, marcelo >> >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > From acmorton@att.com Thu Oct 18 16:54:19 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E05421F8232 for ; Thu, 18 Oct 2012 16:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.656 X-Spam-Level: X-Spam-Status: No, score=-105.656 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFvW5aAaleLz for ; Thu, 18 Oct 2012 16:54:19 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id A33C221F8512 for ; Thu, 18 Oct 2012 16:54:18 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 9a690805.0.1726948.00-381.4808824.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 18 Oct 2012 23:54:18 +0000 (UTC) X-MXL-Hash: 508096aa424315c4-9bc02312df2093aea7f0af2a55c567c9f57c3828 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9INsHCK008033 for ; Thu, 18 Oct 2012 16:54:17 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9INs7Cl007854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Oct 2012 16:54:11 -0700 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint04.pst.cso.att.com (RSA Interceptor) for ; Thu, 18 Oct 2012 16:53:37 -0700 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9INrbZ4026976 for ; Thu, 18 Oct 2012 19:53:37 -0400 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9INrMXc026654 for ; Thu, 18 Oct 2012 19:53:33 -0400 Received: from lt-hp1044652.att.com (vpn-130-10-175-56.vpn.mwst.att.com[130.10.175.56](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121018235217gw100r2c7he>; Thu, 18 Oct 2012 23:52:18 +0000 X-Originating-IP: [130.10.175.56] Message-Id: <7.0.1.0.0.20121018190628.04cea4c0@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 18 Oct 2012 19:52:44 -0400 To: marcelo bagnulo braun , lmap@ietf.org From: Al Morton In-Reply-To: <507D03B1.6020209@it.uc3m.es> References: <507CF747.7040302@it.uc3m.es> <20121016063204.GB77090@elstar.local> <507D03B1.6020209@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=YMQoP26x c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=g1ckIXtETOkA:10 a=gQaidB2Pm-4A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=rJQOW6L4] X-AnalysisOut: [ja4A:10 a=48vgC7mUAAAA:8 a=0q9XERcwC5o4gSQ3CZ0A:9 a=wPNLvf] X-AnalysisOut: [GTeEIA:10 a=ygIlGakRYjMA:10 a=Y9TcPokFJGMA:10 a=XF1L-ljFkQ] X-AnalysisOut: [Z6jh-9:21 a=_Rm19Onn9ePTIL74:21] Subject: Re: [lmap] starting work description discussion X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 23:54:19 -0000 Marcelo, Juergen, and Robert, please see below: At 02:50 AM 10/16/2012, marcelo bagnulo braun wrote: >El 16/10/12 08:32, Juergen Schoenwaelder escribi=F3: >>Marcelo, >> >>let me play devil's advocate a bit here... >>...Marcelo wrote: >>>- One or more protocol documents (Standard track) that specify at >>>least the following interactions: (i) The protocol between the >>>measurement agent and the controller, where the controller can >>>specify the measurement to be executed by the agent and their >>>schedule. (ii) the protocol between the measurement agent and the >>>data collector through which the agent can report the results of the >>>measurements performed and provide additional data (agent >>>identification, time stamp). The protocols used to actually perform >>>the measurements are out of the scope of this effort and can be done >>>in the IPPM WG (this should disappear if this becomes part of the >>>IPPM WG) Juergen wrote: >>Taking RIPE Atlas and Sam Knows as examples, I wonder whether we >>really see the need for a standard allowing RIPE probes to interwork >>with Sam Knows and vice versa. Is this a realisitic target? How many >>such large measurement platforms do we expect to be implemented, do we >>expect an ecosystem of probe suppliers that provide hardware for >>different large scale measurement platforms? And will an attempt to >>standardize the protocol between the probes and the >>controller/collector not potentially hinder evolution? >Marcelo wrote: >My view on this is the following: I would expect=20 >that the user agents are either embedded in the=20 >CPE (home router) from the vendor, or it can be=20 >dowloaded to the end user device (e.ge standard linux app or whatever). > >Suppose that home router have this measurement=20 >agent already built in. then deployment of very=20 >large platforms would be much easier, you should=20 >simply rely on this existent capability. > >So, I do believe there is value on standardizing=20 >this and i do believe this would make easier to deploy these platforms. I agree with Marcelo, the LMAP requirements indicate that the desired architecture for "...scales drawing on thousands or millions of nodes." will benefit from standards for interaction between all components. The greatest gains from standardization come from reduction in "complexity" at the network edge, where the scale is the largest. At the same time, (addressing Robert's point to some extent) deployed architectures need not adopt standards at all the way down to the measurement agents as long as they join the standard architecture at a reasonable interface, and perform the measurements to collect the standard metrics in a compliant fashion. This is probably a good time to point-out the rest of (what might be) IPPM's work related to the LMAP initiative: - "defining any additional performance metrics as needed." [LMAP-req-00] (this is in-progress, see http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-00 ) - Narrowing down the parameters for existing metrics, and refine metrics as needed for the "wired or wireless networks" scope of [LMAP-req-00] - Providing network characterization and study guidance - Repeat all the above for *passive* and hybrid passive/active metrics - Other related work proposed on IPPM list and LMAP list http://www.ietf.org/mail-archive/web/ippm/current/msg02945.html http://www.ietf.org/mail-archive/web/lmap/current/msg00042.html regards, Al =20 From acmorton@att.com Thu Oct 18 17:10:50 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9400121F8491 for ; Thu, 18 Oct 2012 17:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.971 X-Spam-Level: X-Spam-Status: No, score=-105.971 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY8rDQJdHsrT for ; Thu, 18 Oct 2012 17:10:48 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7FA21F8488 for ; Thu, 18 Oct 2012 17:10:47 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 58a90805.0.1708748.00-340.4783964.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 19 Oct 2012 00:10:48 +0000 (UTC) X-MXL-Hash: 50809a88339f97f9-409376bd3d427d6b4183d9de473ea0566a52c04a Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9J0Ajgt013421 for ; Thu, 18 Oct 2012 20:10:45 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9J0AbC4013357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Oct 2012 20:10:39 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Thu, 18 Oct 2012 20:10:22 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9J0AL3O006138 for ; Thu, 18 Oct 2012 20:10:21 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9J0AFVN005745 for ; Thu, 18 Oct 2012 20:10:18 -0400 Received: from lt-hp1044652.att.com (vpn-130-10-175-56.vpn.mwst.att.com[130.10.175.56](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121019000907gw100r2c7ie>; Fri, 19 Oct 2012 00:09:11 +0000 X-Originating-IP: [130.10.175.56] Message-Id: <7.0.1.0.0.20121018195732.04cea608@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 18 Oct 2012 20:09:34 -0400 To: marcelo bagnulo braun , Brian Trammell From: Al Morton In-Reply-To: <507D520F.4010605@it.uc3m.es> References: <507CF747.7040302@it.uc3m.es> <20121016063204.GB77090@elstar.local> <507D0EF5.1000403@ripe.net> <65CA05F0-306D-41F1-B46B-A06E11DF0C79@tik.ee.ethz.ch> <507D520F.4010605@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=EY5/toaC c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=g1ckIXtETOkA:10 a=gQaidB2Pm-4A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=rJQOW6L4] X-AnalysisOut: [ja4A:10 a=48vgC7mUAAAA:8 a=mnovWnDB9ZFxd3XsBhwA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: Mirja =?iso-8859-1?Q?K=FChlewind?= , Robert Kisteleki , Juergen Schoenwaelder , lmap@ietf.org Subject: Re: [lmap] starting work description discussion X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 19 Oct 2012 00:10:51 -0000 At 08:24 AM 10/16/2012, marcelo bagnulo braun wrote: >MB> I think this is one place where the IETF could add value. We >should define a registry for measurements that can be perfoemed by >the clients and for each of them to have a code identifying the >tests, and the set of parameters that are needed as input and the >oputput that is needs to be reported. >then this protocol should convey to the measurement agent the code >for the measurement as defined in the registry as well as the input parameters. >(I have seen that the IPPM metrcis registry, that probably looks a >bit like this has been deprecated, I wonder if there is something to >learn from that experience...) Hi Marcelo, (As Axe-man for the deprecation of the IPPM Registry,) I can summarize that we (all IPPM authors) were wasting time assigning codes to metrics because the registry itself had insufficient detail: it had no way to indicate the settings of critical parameters of the metrics, so the metric codes were meaningless. The morbidly curious can read the whole indictment here: http://tools.ietf.org/html/rfc6248 and there are definitely lessons learned, plus some around who still remember them. We *can* get this right the second time. regards, Al From acmorton@att.com Thu Oct 18 17:13:55 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8190C21F84A2 for ; Thu, 18 Oct 2012 17:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.096 X-Spam-Level: X-Spam-Status: No, score=-106.096 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hbbc29dFmja for ; Thu, 18 Oct 2012 17:13:54 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 6F80221F84A1 for ; Thu, 18 Oct 2012 17:13:54 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 24b90805.0.252066.00-498.715156.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 19 Oct 2012 00:13:54 +0000 (UTC) X-MXL-Hash: 50809b4274d0b959-8467ab9bc16ae6842fd5baafbb325c0b9fe33ce7 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9J0Drq5014452 for ; Thu, 18 Oct 2012 20:13:53 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9J0Dqsn014449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Oct 2012 20:13:52 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Thu, 18 Oct 2012 20:13:31 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9J0DVNf014107 for ; Thu, 18 Oct 2012 20:13:31 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9J0DPCb013917 for ; Thu, 18 Oct 2012 20:13:25 -0400 Received: from lt-hp1044652.att.com (vpn-130-10-175-56.vpn.mwst.att.com[130.10.175.56](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121019001220gw100r2c7je>; Fri, 19 Oct 2012 00:12:21 +0000 X-Originating-IP: [130.10.175.56] Message-Id: <7.0.1.0.0.20121018201123.04cea750@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 18 Oct 2012 20:12:48 -0400 To: Brian Trammell , marcelo bagnulo braun From: Al Morton In-Reply-To: References: <507CF747.7040302@it.uc3m.es> <20121016063204.GB77090@elstar.local> <507D0EF5.1000403@ripe.net> <65CA05F0-306D-41F1-B46B-A06E11DF0C79@tik.ee.ethz.ch> <507D520F.4010605@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=XqxNzy59 c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=g1ckIXtETOkA:10 a=gQaidB2Pm-4A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=rJQOW6L4] X-AnalysisOut: [ja4A:10 a=Z52ppw6MemWnjqv7JG0A:9 a=CjuIK1q_8ugA:10] Cc: Juergen Schoenwaelder , Robert Kisteleki , Mirja =?iso-8859-1?Q?K=FChlewind?= , lmap@ietf.org Subject: Re: [lmap] starting work description discussion X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 19 Oct 2012 00:13:55 -0000 And Brian's summary is also correct, somehow this escaped my previous scan... At 09:54 AM 10/17/2012, Brian Trammell wrote: > From what I understand, this was due to the combinatoric nature of > metric definitions in IPPM, which led to a lack of use. (I'm just a > long-time-lurker in IPPM, though, so if I've got this wrong, IPPM > people please correct me.) I would presume that an IPPM measurement > registry would register classes of measurements, where the specific > parameters of the measurement would not be captured within the type > information of the metric definition, and would rather be captured > in the configuration parameters in a measurement specification / > control protocol interaction. From marcelo@it.uc3m.es Thu Oct 18 22:51:10 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA4821F85B4 for ; Thu, 18 Oct 2012 22:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.367 X-Spam-Level: X-Spam-Status: No, score=-106.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89o-wRHQdFnr for ; Thu, 18 Oct 2012 22:51:10 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id E4DB421F8200 for ; Thu, 18 Oct 2012 22:51:07 -0700 (PDT) Received: from dummyhost11.it.uc3m.es (dummyhost12.it.uc3m.es [163.117.139.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id BC465767FD0; Fri, 19 Oct 2012 07:51:03 +0200 (CEST) Message-ID: <5080EA47.5000201@it.uc3m.es> Date: Fri, 19 Oct 2012 07:51:03 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Al Morton References: <507CF747.7040302@it.uc3m.es> <20121016063204.GB77090@elstar.local> <507D03B1.6020209@it.uc3m.es> <7.0.1.0.0.20121018190628.04cea4c0@att.com> In-Reply-To: <7.0.1.0.0.20121018190628.04cea4c0@att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Fri, 19 Oct 2012 07:51:03 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19288.000 X-TM-AS-Result: No--7.993-7.0-31-1 X-imss-scan-details: No--7.993-7.0-31-1 Cc: lmap@ietf.org Subject: Re: [lmap] starting work description discussion X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 19 Oct 2012 05:51:11 -0000 Hi Al, Just to complete this list, i think an important contribution from IPPM for this work, is to create a new meaningfull registry for metrics, so that LMAP can refer to them. I guess you had this in mind, but to make it explicit. Regards, marcelo El 19/10/12 01:52, Al Morton escribió: > > > This is probably a good time to point-out the rest of (what might > be) IPPM's work related to the LMAP initiative: > > - "defining any additional performance metrics as needed." [LMAP-req-00] > (this is in-progress, see > http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-00 ) > > - Narrowing down the parameters for existing metrics, and refine metrics > as needed for the "wired or wireless networks" scope of [LMAP-req-00] > > - Providing network characterization and study guidance > > - Repeat all the above for *passive* and hybrid passive/active metrics > > - Other related work proposed on IPPM list and LMAP list > http://www.ietf.org/mail-archive/web/ippm/current/msg02945.html > http://www.ietf.org/mail-archive/web/lmap/current/msg00042.html > > regards, > Al > > > From feamster@cc.gatech.edu Tue Oct 16 10:51:16 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458D921F87AA for ; Tue, 16 Oct 2012 10:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUfBOo7MuqSm for ; Tue, 16 Oct 2012 10:51:15 -0700 (PDT) Received: from deliverator4.gatech.edu (deliverator4.gatech.edu [130.207.160.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8417521F8787 for ; Tue, 16 Oct 2012 10:51:15 -0700 (PDT) Received: from deliverator4.gatech.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 79228995D3F; Tue, 16 Oct 2012 13:51:14 -0400 (EDT) Received: from mail8.gatech.edu (mail8.gatech.edu [130.207.185.168]) by deliverator4.gatech.edu (Postfix) with ESMTP id 289A79959EF; Tue, 16 Oct 2012 13:51:13 -0400 (EDT) Received: from [10.109.164.240] (129-2-129-153.wireless.umd.edu [129.2.129.153]) (Authenticated sender: nf21@mail.gatech.edu) by mail8.gatech.edu (Postfix) with ESMTPSA id 07E0D27587A; Tue, 16 Oct 2012 13:51:12 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Nick Feamster In-Reply-To: <33FFDE6E-42A4-4594-80DE-614C066D8C64@icsi.berkeley.edu> Date: Tue, 16 Oct 2012 13:51:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <33FFDE6E-42A4-4594-80DE-614C066D8C64@icsi.berkeley.edu> To: Nicholas Weaver X-Mailer: Apple Mail (2.1485) X-GT-AVAS-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.16.174109 X-GT-Spam-Details: Internal Mail X-GT-Spam-Rating: (0%) X-GT-True-Rating: (8%) X-Mailman-Approved-At: Fri, 19 Oct 2012 08:08:58 -0700 Cc: lmap@ietf.org Subject: Re: [lmap] Introduction X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2012 17:51:16 -0000 While we're on the topic of announcements/introductions, I'll also = introduce myself as the main PI of the BISmark project, a SamKnows-like = effort to perform various types of measurements from OpenWrt-based home = gateways. Our work (which we did with Sam Crawford of SamKnows) will be featured = in the IRTF open meeting (Srikanth Sundaresan is speaking). More generally, we're using BISmark as a way to understand a variety of = factors relating to end-to-end performance from the home, including but = not limited to studying the characteristics of home wireless networks. = Someone on the list had asked "how many of these measurement platforms = can we expect to have?" beyond SamKnows, etc. BISmark is another = platform that folks may or may not be aware of, but I thought I'd = mention it: http://projectbismark.net/ There are currently a few hundred routers deployed in 20+ countries, and = we'll be happy to send one your way if you'd like to play with one (or = work with us to develop new tests for it). Cheers, -Nick On Oct 16, 2012, at 1:46 PM, Nicholas Weaver = wrote: > Jason Livinggood and others made me aware of this working group, so = I've joined the list. >=20 > For background and those who don't know me, I'm one of the primary = developers of Netalyzr. Any questions, feel free to ask. Amongst other = things, we now have a command line client and a JSON API for test = results. >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From qql@bupt.edu.cn Wed Oct 24 05:50:39 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0ED621F884F for ; Wed, 24 Oct 2012 05:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.502 X-Spam-Level: *** X-Spam-Status: No, score=3.502 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QelRUvK1YTh0 for ; Wed, 24 Oct 2012 05:50:39 -0700 (PDT) Received: from mail.bupt.edu.cn (mail.bupt.edu.cn [211.68.71.7]) by ietfa.amsl.com (Postfix) with ESMTP id E461721F8847 for ; Wed, 24 Oct 2012 05:50:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx3.bupt.edu.cn (Postfix) with SMTP id EB5CA1BC2F for ; Wed, 24 Oct 2012 20:50:36 +0800 (CST) X-AnySpam-Host: mx3.bupt.edu.cn X-AnySpam-Flag: No X-AnySpam-Hits: 3.00/5.00 X-AnySpam-Rules: LocalUSER_Send Received: from bnrcPC (unknown [59.64.157.74]) by mx3.bupt.edu.cn (Postfix) with ESMTP id B86F31BC2A for ; Wed, 24 Oct 2012 20:50:36 +0800 (CST) X-SenderID: Sendmail Sender-ID Filter v0.2.14 mx3.bupt.edu.cn B86F31BC2A Authentication-Results: mx3.bupt.edu.cn from=qql@bupt.edu.cn; sender-id=pass; spf=pass From: =?gb2312?B?x+zA2g==?= To: Date: Wed, 24 Oct 2012 20:50:27 +0800 Message-ID: <000001cdb1e6$24415bf0$6cc413d0$@bupt.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CDB229.32655F40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2x5VyO3ZbY2Em1R2GuFIISYI/bkw== Content-Language: zh-cn Subject: [lmap] what parameters provide the network parameter server? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 12:50:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01CDB229.32655F40 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi, all I have read the draft and comment about the network parameter servers. But I still have a question. What parameters provide the network parameter server? After all, the name of the network parameter server lead me to believe that it can and should provide some parameter. Regards, Qinglei Qi ------=_NextPart_000_0001_01CDB229.32655F40 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, = all

 

I have read the draft = and comment about the network parameter servers. But I still have a = question. What parameters provide the network parameter server? After = all, the name of the network parameter server lead me to believe that it = can and should provide some parameter.

 

Regards, Qinglei Qi =

------=_NextPart_000_0001_01CDB229.32655F40-- From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Oct 24 10:33:59 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C471021F86DB for ; Wed, 24 Oct 2012 10:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aadeA+eKunH9 for ; Wed, 24 Oct 2012 10:33:59 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id D230021F86A2 for ; Wed, 24 Oct 2012 10:33:58 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id F12CB633B1 for ; Wed, 24 Oct 2012 19:33:56 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id D34C859A8A for ; Wed, 24 Oct 2012 19:33:56 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: lmap@ietf.org Date: Wed, 24 Oct 2012 19:33:55 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201210241933.55614.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: [lmap] Fwd: Results of IETF-conflict review for draft-cisco-sla-protocol-03 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 17:33:59 -0000 Hi everybody, is the group aware of the 'Cisco Service Level Assurance Protocol' which al= so=20 seems to provide some kind of measurement framework? See below. Mirja =2D--------- Forwarded Message ---------- Subject: Results of IETF-conflict review for draft-cisco-sla-protocol-03 Date: Friday 12 October 2012, 17:05:52 =46rom: The IESG To: "Nevil Brownlee" ,=20 draft-cisco-sla-protocol@tools.ietf.org, rfc-ise@rfc-editor.org CC: iana@iana.org, The IESG , ietf-announce@ietf.org The IESG has completed a review of draft-cisco-sla-protocol-03 consistent with RFC5742. The IESG has no problem with the publication of 'Cisco Service Level Assurance Protocol' as an Informational RFC. The IESG has concluded that this work is related to IETF work done in WG IP Performance Metrics (IPPM), but this relationship does not prevent publishing The IESG would also like the RFC-Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: http://datatracker.ietf.org/doc/conflict-review-cisco-sla-protocol/ A URL of the reviewed Internet Draft is: http://datatracker.ietf.org/doc/draft-cisco-sla-protocol/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary =2D------------------------------------------------------ =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From acmorton@att.com Wed Oct 24 10:58:43 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BFD21F8755 for ; Wed, 24 Oct 2012 10:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.015 X-Spam-Level: X-Spam-Status: No, score=-106.015 tagged_above=-999 required=5 tests=[AWL=0.584, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCYyWMPRQZnk for ; Wed, 24 Oct 2012 10:58:42 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0603021F870D for ; Wed, 24 Oct 2012 10:58:35 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id b4c28805.0.1181116.00-313.3270319.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 24 Oct 2012 17:58:36 +0000 (UTC) X-MXL-Hash: 50882c4c6dc41833-dfc47828292de098d771566447c6dd2b9c677120 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9OHwZPK032137 for ; Wed, 24 Oct 2012 13:58:35 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9OHwQDD032036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Oct 2012 13:58:28 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Wed, 24 Oct 2012 13:58:07 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9OHw75Y005177 for ; Wed, 24 Oct 2012 13:58:07 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9OHvvYT004391 for ; Wed, 24 Oct 2012 13:58:03 -0400 Received: from lt-hp1044652.att.com (vpn-135-70-209-216.vpn.east.att.com[135.70.209.216](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121024175638gw100r2cdse>; Wed, 24 Oct 2012 17:56:47 +0000 X-Originating-IP: [135.70.209.216] Message-Id: <7.0.1.0.0.20121024135351.04be81f8@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 24 Oct 2012 13:56:41 -0400 To: Mirja Kuehlewind , lmap@ietf.org From: Al Morton In-Reply-To: <201210241933.55614.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <201210241933.55614.mirja.kuehlewind@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=Q/1lFfKa c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=irFiO__MsToA:10 a=knf-nXLuUtcA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=uiBAM78J] X-AnalysisOut: [HOQA:10 a=bQZXuMk_QA5UK84acXkA:9 a=CjuIK1q_8ugA:10] Subject: Re: [lmap] Fwd: Results of IETF-conflict review for draft-cisco-sla-protocol-03 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 17:58:43 -0000 At 01:33 PM 10/24/2012, Mirja Kuehlewind wrote: >is the group aware of the 'Cisco Service Level Assurance Protocol' which also >seems to provide some kind of measurement framework? See below. Folks who crossed-over from IPPM-list certainly are, it was proposed in IPPM as Informational, but ended-up in RFC Editor's queue. You're right that it provides a similar capability to TWAMP, active measurements with a low-complexity responder. Al From trammell@tik.ee.ethz.ch Thu Oct 25 07:54:57 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9B021F8979 for ; Thu, 25 Oct 2012 07:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.712 X-Spam-Level: X-Spam-Status: No, score=-6.712 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+X67IPsa+7d for ; Thu, 25 Oct 2012 07:54:55 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5724921F89DA for ; Thu, 25 Oct 2012 07:54:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 92C4AD9315; Thu, 25 Oct 2012 16:54:49 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id khu4wLSwC+Pb; Thu, 25 Oct 2012 16:54:49 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 4C049D9314; Thu, 25 Oct 2012 16:54:49 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <7.0.1.0.0.20121024135351.04be81f8@att.com> Date: Thu, 25 Oct 2012 16:54:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210241933.55614.mirja.kuehlewind@ikr.uni-stuttgart.de> <7.0.1.0.0.20121024135351.04be81f8@att.com> To: Al Morton X-Mailer: Apple Mail (2.1283) Cc: Mirja Kuehlewind , lmap@ietf.org Subject: Re: [lmap] Fwd: Results of IETF-conflict review for draft-cisco-sla-protocol-03 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:54:57 -0000 hi Al, Mirja, all, I missed CSLAP[*] when it came briefly through IPPM, but having had a = look at it since then, I'd presume that it would be another potential = active measurement technology to think about controlling through LMAP, = like OWAMP and TWAMP. In any case, what's defined there just provide the measurement client = and server and the protocol between them, in LMAP draft terminology. = Missing from the specification are the control of the CSLAP sender by = the measurement controller, and the reporting of results from the CSLAP = sender (the measurement client to measurement controller).=20 For the control protocol I suppose the configuration parameters would = have some mapping to the fields of the defined UDP measurement control = message, so if supporting CSLAP turns out to be an LMAP requirement then = the control message specification would be a starting point to defining = them.=20 However, for the result reporting protocol, the specification is = completely silent on the subject of both the calculated metrics and the = format of reported results, so without more information it would be hard = to say where to start. Best regards, Brian * I have no idea whether this is an accepted acronym for this protocol, = but calling it just SLA would be a trivial terminology collision, so no. On Oct 24, 2012, at 7:56 PM, Al Morton wrote: > At 01:33 PM 10/24/2012, Mirja Kuehlewind wrote: >> is the group aware of the 'Cisco Service Level Assurance Protocol' = which also >> seems to provide some kind of measurement framework? See below. >=20 > Folks who crossed-over from IPPM-list certainly are, > it was proposed in IPPM as Informational, but ended-up > in RFC Editor's queue. >=20 > You're right that it provides a similar capability to TWAMP, > active measurements with a low-complexity responder. >=20 > Al >=20 >=20 >=20 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From acmorton@att.com Thu Oct 25 11:20:36 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE53221F8661 for ; Thu, 25 Oct 2012 11:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.083 X-Spam-Level: X-Spam-Status: No, score=-106.083 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB43naf7JEyW for ; Thu, 25 Oct 2012 11:20:36 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id EBB6E21F85E7 for ; Thu, 25 Oct 2012 11:20:35 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 3f289805.0.1599220.00-386.4429304.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 25 Oct 2012 18:20:35 +0000 (UTC) X-MXL-Hash: 508982f36836bde8-8437140b841ba60dba5106f33067781104c009df Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9PIKZWX030277 for ; Thu, 25 Oct 2012 14:20:35 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9PIKGgv030104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Oct 2012 14:20:16 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Thu, 25 Oct 2012 14:20:12 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9PIK7K4004695 for ; Thu, 25 Oct 2012 14:20:12 -0400 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9PIK1Sr004123 for ; Thu, 25 Oct 2012 14:20:01 -0400 Received: from lt-hp1044652.att.com (vpn-135-70-189-77.vpn.mwst.att.com[135.70.189.77](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121025181849gw100r2cffe>; Thu, 25 Oct 2012 18:18:50 +0000 X-Originating-IP: [135.70.189.77] Message-Id: <7.0.1.0.0.20121025135551.082f6910@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 25 Oct 2012 14:18:49 -0400 To: Brian Trammell From: Al Morton In-Reply-To: References: <201210241933.55614.mirja.kuehlewind@ikr.uni-stuttgart.de> <7.0.1.0.0.20121024135351.04be81f8@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=Q/1lFfKa c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=fZ0pT5-qH6gA:10 a=h4s7HHq8jT0A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=br-kHWFy] X-AnalysisOut: [87sA:10 a=48vgC7mUAAAA:8 a=SqnO2w_RPz9Ez3FLgu8A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=-tzrXOUq0akA:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVv] X-AnalysisOut: [QA:10 a=EjhJJV2Hnh4YqMiW:21 a=Lck6JbJGPSKKOQsH:21] Cc: Mirja Kuehlewind , lmap@ietf.org Subject: Re: [lmap] Fwd: Results of IETF-conflict review for draft-cisco-sla-protocol-03 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 18:20:37 -0000 Hi Brian, You gave a good account of the current protocol* capabilities, especially where you identify the missing pieces. These are partly covered by the list of items I suggested IPPM might work next, to address the LMAP initiative: http://www.ietf.org/mail-archive/web/lmap/current/msg00055.html Marcelo noted the need for a new registry explicitly on that list, and there's also a need to develop details on measurement methodology beyond the parameter settings for metrics, now that I've thought about it some more. There is real/new work needed on the measurement front, to address passive as well as active techniques, wireless as well as wired, and what we're now calling "reactive networks" (and attempting to define in a useful way in IPPM right now). regards, Al * (I've referred to the protocol as IPSLAv2, but authors should name it) At 10:54 AM 10/25/2012, Brian Trammell wrote: >hi Al, Mirja, all, > >I missed CSLAP[*] when it came briefly through IPPM, but having had >a look at it since then, I'd presume that it would be another >potential active measurement technology to think about controlling >through LMAP, like OWAMP and TWAMP. > >In any case, what's defined there just provide the measurement >client and server and the protocol between them, in LMAP draft >terminology. Missing from the specification are the control of the >CSLAP sender by the measurement controller, and the reporting of >results from the CSLAP sender (the measurement client to measurement >controller). > >For the control protocol I suppose the configuration parameters >would have some mapping to the fields of the defined UDP measurement >control message, so if supporting CSLAP turns out to be an LMAP >requirement then the control message specification would be a >starting point to defining them. > >However, for the result reporting protocol, the specification is >completely silent on the subject of both the calculated metrics and >the format of reported results, so without more information it would >be hard to say where to start. > >Best regards, > >Brian > >* I have no idea whether this is an accepted acronym for this >protocol, but calling it just SLA would be a trivial terminology >collision, so no. > >On Oct 24, 2012, at 7:56 PM, Al Morton wrote: > > > At 01:33 PM 10/24/2012, Mirja Kuehlewind wrote: > >> is the group aware of the 'Cisco Service Level Assurance > Protocol' which also > >> seems to provide some kind of measurement framework? See below. > > > > Folks who crossed-over from IPPM-list certainly are, > > it was proposed in IPPM as Informational, but ended-up > > in RFC Editor's queue. > > > > You're right that it provides a similar capability to TWAMP, > > active measurements with a low-complexity responder. > > > > Al > > > > > > > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap From Michael.K.Bugenhagen@centurylink.com Tue Oct 30 13:50:34 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D920A21F8652 for ; Tue, 30 Oct 2012 13:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyQsZOKoPEH3 for ; Tue, 30 Oct 2012 13:50:31 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 7545721F864D for ; Tue, 30 Oct 2012 13:50:31 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id q9UKnh2t005972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2012 14:49:44 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id BDAF41E0032; Tue, 30 Oct 2012 15:49:38 -0500 (CDT) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id A0CAB1E005D; Tue, 30 Oct 2012 15:49:38 -0500 (CDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id q9UKncC6007779; Tue, 30 Oct 2012 15:49:38 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id q9UKnbXK007776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Oct 2012 15:49:38 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([2002:9775:ce1b::9775:ce1b]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 15:49:38 -0500 From: "Bugenhagen, Michael K" To: "lmap@ietf.org" Thread-Topic: Bar BOF - I can provide an overview of the BBF activity if desired Thread-Index: Ac224BMywYHUafhzTLqsWRr4otW6rw== Date: Tue, 30 Oct 2012 20:49:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: multipart/alternative; boundary="_000_A68F3CAC468B2E48BB775ACE2DD99B5E045D7D26podcwmbxex505ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'wes@mti-systems.com'" , 'Al Morton' , Henning Schulzrinne Subject: [lmap] Bar BOF - I can provide an overview of the BBF activity if desired X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2012 20:50:34 -0000 --_000_A68F3CAC468B2E48BB775ACE2DD99B5E045D7D26podcwmbxex505ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a FYI -- I had hoped the BBF framework was ready to shoot over to the group but ti= ming wise it won't work out due to the BBF is meeting the first week of Dec= ember. Therefore the bulk of the work they have been doing framework wise, for Fix= ed wireline testing won't be available until the group reaches fully body c= onsensus at that meeting, at which point the plan is to send it over to the= IETF, and others SDO's. In the mean time, at the meeting next week I can give a general heading ove= rview on that framework piece parts that will likely draw to a consensus vi= ew at the next meeting. That is if the groups are interested in such a thing.. If so, I'll be at the meeting, and try to answer any questions about it. = I plan on attending IPPM, and the other meetings on the subject. Either way I'll see everyone at the meeting next week - safe travels Mike --_000_A68F3CAC468B2E48BB775ACE2DD99B5E045D7D26podcwmbxex505ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Just a FYI --
 
  I had hoped the BBF framework was ready to shoot over to the gr= oup but timing wise it won’t work out due to the BBF is meeting the f= irst week of December.
Therefore the bulk of the work they have been doing framework wise, fo= r Fixed wireline testing won’t be available until the group reaches f= ully body consensus at that meeting, at which point the plan is to send it = over to the IETF, and others SDO’s.
&nbs= p;
In the mean time, at the meeting next week I can give a general headin= g overview on that framework piece parts that will likely draw to a consens= us view at the next meeting. 
That is if the groups are interested in such a thing..  &nbs= p;
&nbs= p;
If so, I’ll be at the meeting, and try to answer any questions a= bout it.   I plan on attending IPPM, and the other meetings on th= e subject.
&nbs= p;
Either way  I’ll see everyone at the meeting next week = ; - safe travels
&nbs= p;
Mike
&nbs= p;
&nbs= p;
&nbs= p;
 --_000_A68F3CAC468B2E48BB775ACE2DD99B5E045D7D26podcwmbxex505ct_-- From Henning.Schulzrinne@fcc.gov Tue Oct 30 20:00:36 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DBB21F86A1 for ; Tue, 30 Oct 2012 20:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5C3gN+q5oja for ; Tue, 30 Oct 2012 20:00:35 -0700 (PDT) Received: from dmz-mail2.fcc.gov (dmz-mail2.fcc.gov [192.104.54.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7637521F8669 for ; Tue, 30 Oct 2012 20:00:34 -0700 (PDT) Received: from P2PXMB13.fccnet.win.fcc.gov ([fe80::6593:6526:65f8:66b7]) by p2pxcas02.fccnet.win.fcc.gov ([fe80::2d69:114:8552:212f%13]) with mapi id 14.01.0421.002; Tue, 30 Oct 2012 23:00:33 -0400 From: Henning Schulzrinne To: "Bugenhagen, Michael K" , "lmap@ietf.org" Thread-Topic: Bar BOF - I can provide an overview of the BBF activity if desired Thread-Index: Ac224BMywYHUafhzTLqsWRr4otW6rwAMv+TB Date: Wed, 31 Oct 2012 03:00:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.64] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'wes@mti-systems.com'" , 'Al Morton' Subject: Re: [lmap] Bar BOF - I can provide an overview of the BBF activity if desired X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 31 Oct 2012 03:00:36 -0000 Mike, I think it would be great to have a BBF overview and discussion at the Bar = BOF. Henning ________________________________ From: Bugenhagen, Michael K [Michael.K.Bugenhagen@centurylink.com] Sent: Tuesday, October 30, 2012 4:49 PM To: lmap@ietf.org Cc: 'Al Morton'; Henning Schulzrinne; 'wes@mti-systems.com' Subject: Bar BOF - I can provide an overview of the BBF activity if desired Just a FYI -- I had hoped the BBF framework was ready to shoot over to the group but ti= ming wise it won=92t work out due to the BBF is meeting the first week of D= ecember. Therefore the bulk of the work they have been doing framework wise, for Fix= ed wireline testing won=92t be available until the group reaches fully body= consensus at that meeting, at which point the plan is to send it over to t= he IETF, and others SDO=92s. In the mean time, at the meeting next week I can give a general heading ove= rview on that framework piece parts that will likely draw to a consensus vi= ew at the next meeting. That is if the groups are interested in such a thing.. If so, I=92ll be at the meeting, and try to answer any questions about it. = I plan on attending IPPM, and the other meetings on the subject. Either way I=92ll see everyone at the meeting next week - safe travels Mike From ford@isoc.org Wed Oct 31 02:28:10 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466FE21F872A for ; Wed, 31 Oct 2012 02:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud0aOBarTbvc for ; Wed, 31 Oct 2012 02:28:09 -0700 (PDT) Received: from smtp200.iad.emailsrvr.com (smtp200.iad.emailsrvr.com [207.97.245.200]) by ietfa.amsl.com (Postfix) with ESMTP id D0A0021F8727 for ; Wed, 31 Oct 2012 02:28:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp50.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 1C1A3370D94; Wed, 31 Oct 2012 05:28:09 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp50.relay.iad1a.emailsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id 05F47370774; Wed, 31 Oct 2012 05:28:07 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Matthew Ford In-Reply-To: Date: Wed, 31 Oct 2012 09:27:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Henning Schulzrinne X-Mailer: Apple Mail (2.1499) Cc: "'wes@mti-systems.com'" , 'Al Morton' , "Bugenhagen, Michael K" , "lmap@ietf.org" Subject: Re: [lmap] Bar BOF - I can provide an overview of the BBF activity if desired X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 31 Oct 2012 09:28:10 -0000 On 31 Oct 2012, at 03:00, Henning Schulzrinne = wrote: > I think it would be great to have a BBF overview and discussion at the = Bar BOF. +1= From lars@netapp.com Wed Oct 31 03:35:44 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CFF21F8785 for ; Wed, 31 Oct 2012 03:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.333 X-Spam-Level: X-Spam-Status: No, score=-10.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWn8t1mKf1t6 for ; Wed, 31 Oct 2012 03:35:44 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3E12D21F8775 for ; Wed, 31 Oct 2012 03:35:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="p7s'?scan'208";a="705628053" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 31 Oct 2012 03:35:43 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q9VAZhQP002893; Wed, 31 Oct 2012 03:35:43 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.216]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 03:35:42 -0700 From: "Eggert, Lars" To: Matthew Ford Thread-Topic: [lmap] Bar BOF - when & where? Thread-Index: AQHNt1N52ryVAIRZaU2JYCOD4dOjRQ== Date: Wed, 31 Oct 2012 10:35:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_79552A43-44D5-4AD5-BFCF-8E62F7672D56"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "wes@mti-systems.com" , "lmap@ietf.org" , Al Morton , "Bugenhagen, Michael K" , Henning Schulzrinne Subject: Re: [lmap] Bar BOF - when & where? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 31 Oct 2012 10:35:44 -0000 --Apple-Mail=_79552A43-44D5-4AD5-BFCF-8E62F7672D56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, when & where is the bar BOF? Has anyone asked for a room? (I have not = seen an IRTF-related request, but maybe someone went and asked an AD?) Lars= --Apple-Mail=_79552A43-44D5-4AD5-BFCF-8E62F7672D56 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAzMTEwMzUzOFowIwYJKoZIhvcNAQkEMRYEFC7d /ZOwibIVXkGtkTRuCSorofRbMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBABKFIDBb /nFc+R0u9Th8twjx1ym9EH0bkUu3+pKaQ3nst/raQgOZc1u7C6cx6cthB5FkYYYxl2v3Al3iayfQ 6+57pO9WxBAD0yMwPcN2VHhqTf+DRAOxxYJ7b1DqBDg16SfZK+UoLGH1fif1XlR8wCDJS4u6VIgi mY8hwVEnIZ1ZDyNja5cvbcf2h3GkLrrgHCLGHEiQyEpmSOSw90hIsOMRW0Ag9xLmyv+aDLrvM+/B u0ym6xsIQXHdKy1x1+ZQBELKVIU4xJwmUYJ9n3/JqyvyHe+B7OfYlwvtBN/2aavYrVAnzZQjXgjv z9jzHks2MLz3Ohn4+eX8yTyzHOcraCsAAAAAAAA= --Apple-Mail=_79552A43-44D5-4AD5-BFCF-8E62F7672D56-- From lars@netapp.com Wed Oct 31 03:40:56 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3179821F84C7 for ; Wed, 31 Oct 2012 03:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CfZF-NZiIk5 for ; Wed, 31 Oct 2012 03:40:55 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id B5BD121F84ED for ; Wed, 31 Oct 2012 03:40:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="p7s'?scan'208";a="705629061" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 31 Oct 2012 03:40:54 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q9VAespC008615; Wed, 31 Oct 2012 03:40:54 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.216]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 03:40:54 -0700 From: "Eggert, Lars" To: Matthew Ford Thread-Topic: [lmap] Bar BOF - when & where? Thread-Index: AQHNt1N52ryVAIRZaU2JYCOD4dOjRZfTrxOA Date: Wed, 31 Oct 2012 10:40:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_ACA31A37-B9B6-4C05-B45C-0E3F967839A5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "wes@mti-systems.com" , Henning Schulzrinne , Al Morton , "Bugenhagen, Michael K" , "lmap@ietf.org" Subject: Re: [lmap] Bar BOF - when & where? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 31 Oct 2012 10:40:56 -0000 --Apple-Mail=_ACA31A37-B9B6-4C05-B45C-0E3F967839A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 31, 2012, at 11:35, "Eggert, Lars" wrote: > when & where is the bar BOF? Has anyone asked for a room? (I have not = seen an IRTF-related request, but maybe someone went and asked an AD?) ah, found it: > Meeting Name: Broadband Performance Measurement >=20 > Desired Meeting Date: 11/07/2012 > Alternate Meeting Date: 11/08/2013 > Number of Days: 1 > Meeting Area/Type: TSV > Expected Attendance: 50 > Desired Start Time: 19:30:00 **Moved to 20:00:00** > Desired End Time: 20:30:00 > Room Configuration: Conference > Speakerphone: No > LCD Projector: Yes That time is in conflict with the IRSG dinner, so IRTF chairs won't be = able to make it. If there are pieces of LMAP that are intended for the = IRTF, someone please clue us in after the meeting. Thanks, Lars= --Apple-Mail=_ACA31A37-B9B6-4C05-B45C-0E3F967839A5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAzMTEwNDA0OVowIwYJKoZIhvcNAQkEMRYEFLRZ cCJA0KlJeJrNCF7oNv0+jsy0MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAJxplr94 5h3ZZfLxxZapzZRElnaYlJB56GcR3LI91bzaysbjDLiGgoq9d6l2TDsF4DqA02j8ccEMwbrypKj7 Qhn89rWsLUJuxR5mK2uIUb70ZVU8gEp2SUhHJfxjA0D1SyxV9aPKU1/rjtWk0kE2DoGGdz34okXF LFb9ICKvljHWIbRnA38FZMQVIO/Klk2ACJ91p5TEfkMrxCDMfUOQANXB62srCFz9AfWeAXngnZTh uEu1pBGIk3pyzvJJVrI3o5kzPiMsgSgr/HecPlQfI9wGHu/DD1hw03C/3+x7sGM2dwlScCx4U8UV 4pVHwv1STpDs8vN4hPYTusxNcRgdMIoAAAAAAAA= --Apple-Mail=_ACA31A37-B9B6-4C05-B45C-0E3F967839A5-- From mlinsner@cisco.com Wed Oct 31 05:35:12 2012 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACDF21F868A for ; Wed, 31 Oct 2012 05:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXDQQfgsIWRN for ; Wed, 31 Oct 2012 05:35:12 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 00AED21F8602 for ; Wed, 31 Oct 2012 05:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1894; q=dns/txt; s=iport; t=1351686912; x=1352896512; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=tP5R3dkKOtXog1pkMAW4g56gFTJaRlpsP4HD5+SYeTU=; b=avzhThfxVzzUvazPMcA3XUVUl8xtXhn6JmLmzZA1cjMCSv++SjkkB4Fo F1eOvnPUcFxGuPRU0ElHXRf1QJ1wX1+nS/nkL58ujrMBFhN2b32mYklJG UW24v94ku3ZsArt4tObNTMQHCpsC4KF86egCM9tkOZPyBJYEBa7io95wM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABQakVCtJV2a/2dsb2JhbABEw22BCIIeAQEBBAEBAQ8BKQExFwcIEQMBAQFWKAgGEx8Dh2QLmkOBLKAGBIt4CoYxA4gljVGFaYhugWuDCw X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="137308291" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 31 Oct 2012 12:35:03 +0000 Received: from [10.116.195.123] (rtp-mlinsner-87110.cisco.com [10.116.195.123]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9VCZ0Sb019137 for ; Wed, 31 Oct 2012 12:35:01 GMT User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Wed, 31 Oct 2012 08:35:00 -0400 From: Marc Linsner To: "lmap@ietf.org" Message-ID: Thread-Topic: [lmap] Bar BOF - I can provide an overview of the BBF activity if desired In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [lmap] Bar BOF - I can provide an overview of the BBF activity if desired X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 31 Oct 2012 12:35:13 -0000 +1 -----Original Message----- From: Henning Schulzrinne Date: Tuesday, October 30, 2012 11:00 PM To: "Bugenhagen, Michael K" , "lmap@ietf.org" Cc: "'wes@mti-systems.com'" , 'Al Morton' Subject: Re: [lmap] Bar BOF - I can provide an overview of the BBF activity if desired >Mike, > >I think it would be great to have a BBF overview and discussion at the >Bar BOF. > >Henning > >________________________________ >From: Bugenhagen, Michael K [Michael.K.Bugenhagen@centurylink.com] >Sent: Tuesday, October 30, 2012 4:49 PM >To: lmap@ietf.org >Cc: 'Al Morton'; Henning Schulzrinne; 'wes@mti-systems.com' >Subject: Bar BOF - I can provide an overview of the BBF activity if >desired > >Just a FYI -- > > I had hoped the BBF framework was ready to shoot over to the group but >timing wise it won=B9t work out due to the BBF is meeting the first week of >December. >Therefore the bulk of the work they have been doing framework wise, for >Fixed wireline testing won=B9t be available until the group reaches fully >body consensus at that meeting, at which point the plan is to send it >over to the IETF, and others SDO=B9s. > >In the mean time, at the meeting next week I can give a general heading >overview on that framework piece parts that will likely draw to a >consensus view at the next meeting. >That is if the groups are interested in such a thing.. > >If so, I=B9ll be at the meeting, and try to answer any questions about it. > I plan on attending IPPM, and the other meetings on the subject. > >Either way I=B9ll see everyone at the meeting next week - safe travels > >Mike > > > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap