From ietf-secretariat-reply@ietf.org Wed May 29 08:30:47 2013 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 2655321F9509 for ; Wed, 29 May 2013 08:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHXTGEySXk+3 for ; Wed, 29 May 2013 08:30:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD5721F9555 for ; Wed, 29 May 2013 08:30:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: lmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130529153026.2239.49208.idtracker@ietfa.amsl.com> Date: Wed, 29 May 2013 08:30:26 -0700 From: IETF Secretariat X-Mailman-Approved-At: Sat, 01 Jun 2013 08:07:03 -0700 Subject: [lmap] Milestones changed for lmap WG 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, 29 May 2013 15:30:47 -0000 Added milestone "Initial WG I-D for the LMAP Framework including terminology", due September 2013. Added milestone "Initial WG I-D for the LMAP Use cases", due September 2013. Added milestone "Submit the LMAP Framework I-D to the IESG for consideration as Informational RFC", due December 2013. Added milestone "Submit I-D on the LMAP Use cases to the IESG for consideration as Informational RFC", due December 2013. Added milestone "Initial WG I-D for LMAP Information models", due January 2014. Added milestone "Initial WG I-D for the Control protocol", due April 2014. Added milestone "Initial WG I-D for the Report protocol", due April 2014. Added milestone "Initial WG I-D for a Data model for LMAP control information", due April 2014. Added milestone "Initial WG I-D for a Data model for LMAP report information", due April 2014. Added milestone "Submit the LMAP Information models I-D to the IESG for consideration as Standards track RFC", due July 2014. Added milestone "Submit the Control protocol I-D to the IESG for consideration as Standards track RFC", due December 2014. Added milestone "Submit the Report protocol I-D to the IESG for consideration as Standards track RFC", due December 2014. Added milestone "Submit the Data model for LMAP control I-D to the IESG for consideration as Standards track RFC", due December 2014. URL: http://datatracker.ietf.org/wg/lmap/charter/ From ietf-secretariat-reply@ietf.org Wed May 29 08:32:04 2013 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 C466E21F92CB for ; Wed, 29 May 2013 08:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiAqDPJ9rnXH for ; Wed, 29 May 2013 08:32:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D2121F9347 for ; Wed, 29 May 2013 08:32:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: lmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130529153202.23802.31973.idtracker@ietfa.amsl.com> Date: Wed, 29 May 2013 08:32:02 -0700 From: IETF Secretariat X-Mailman-Approved-At: Sat, 01 Jun 2013 08:07:03 -0700 Subject: [lmap] Milestones changed for lmap WG 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, 29 May 2013 15:32:05 -0000 Added milestone "Submit the Data model for LMAP report I-D to the IESG for consideration as Standards track RFC", due December 2014. URL: http://datatracker.ietf.org/wg/lmap/charter/ From Michael.K.Bugenhagen@centurylink.com Mon Jun 3 08:13:04 2013 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 3794521E809A for ; Mon, 3 Jun 2013 08:13:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tae0gIi4Lr5f for ; Mon, 3 Jun 2013 08:12:58 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 88DB521E8090 for ; Mon, 3 Jun 2013 08:12:58 -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 r53FCtdi021631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jun 2013 09:12:55 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 38E7A1E005B; Mon, 3 Jun 2013 10:12:50 -0500 (CDT) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 0F71B1E004F; Mon, 3 Jun 2013 10:12:50 -0500 (CDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r53FCnD4019436; Mon, 3 Jun 2013 10:12:49 -0500 (CDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.qintra.com [151.117.206.28]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r53FCnmw019411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 10:12:49 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.02.0318.001; Mon, 3 Jun 2013 10:12:49 -0500 From: "Bugenhagen, Michael K" To: "'Shane Amante'" , "STARK, BARBARA H" Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5dQQpmrX+eILrVQJu06CxfDKZpagAT40sAAAL2LAAAJfx/AAAC6Q8AAAWjBwAAAXA1gAABvFuAAAJpgYAAAUtngAB9vNPw Date: Mon, 3 Jun 2013 15:12:48 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CC0DA@GAALPA1MSGUSR9L.ITServices.sbc.com> <6BCFDF35-14BC-43A9-A795-DF077AFA4A60@castlepoint.net> In-Reply-To: <6BCFDF35-14BC-43A9-A795-DF077AFA4A60@castlepoint.net> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 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, 03 Jun 2013 15:13:04 -0000 Dan, Shane, Barbara -=20 I have been out of the office so I apologize for my input being a bit la= te.. A few key points I think we need to consider for the charter involve EMS sy= stems, and what Interoperability protocols we need. - 1) Protocols / Interfaces - My conclusion - In order to ensure adoption we have to recognize that MA'= s on ISP devices will very likely be managed by their existing management p= rotocols (DOCSIS, GPON and DSL existing management protocols MUST be accept= able). If we choose to ignore this when we may be guilty of driving added= cost into Internet services, which seems foolish to me. To me this means = we have a standard information model, and messaging, and choose a nice way = making that portable and implementable, and possibly identifying the better= IETF protocols and frameworks that require little extra tweaking to make t= hem work. 2) Inter-operability (protocols) Considering #1 and observing the existence of ISP EMS systems, it seems th= e inter-operation space should be restricted to MA to MA, and MA controller= to MA controller like communication protocols. If we have a like informa= tion model, one can split the management protocol, and the test protocols, = the management protocol (EMS to MA need not inter-operate), however control= ler to MA, and MA to MA Must.... Plus I did spec. in an older email that some sort of customer to MA / ISP p= rotocol needs to be standardized for interop as well. Thanks, Mike -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Sha= ne Amante Sent: Friday, May 31, 2013 4:46 PM To: STARK, BARBARA H Cc: Romascanu, Dan (Dan); lmap@ietf.org Subject: Re: [lmap] lmap charter - draft 2 Hi Barbara, On May 31, 2013, at 3:08 PM, "STARK, BARBARA H" wrote: >> Amongst the potential _IETF_ protocols that could fulfill the needs=20 >> of one or the other functions, the IETF should (attempt to) pick one=20 >> of its protocols & data-models for each. I would not want to see the=20 >> LMAP WG select multiple, overlapping _IETF_ protocols to perform a=20 >> single function, (e.g.: we should think long & hard and try to select=20 >> either SNMP -or- NETCONF/YANG for the "Control Protocol"). The main=20 >> benefit with the above approach is for those who desire, like me, to=20 >> have a complete "LMAP solution", with all of the necessary protocols=20 >> and data-models, _available_ for them to deploy the IETF LMAP WG will ha= ve produced such. >=20 > So you are opposed to LMAP being an agent of providing a useful SNMP MIB = for all of the existing network elements (and perhaps cable modems) managed= via SNMP?=20 No. Please re-read my message, above, carefully. I recommended the IETF _= should_, (I did not say: must), try to pick a single IETF protocol for a pa= rticular function. IMO, it is much, much too early -- the LMAP WG has not = even been chartered! -- to declare a single, specific IETF protocol or data= -model as a de-facto winner. This is why I agree with the present charter = when it states, for Control & Reporting transport protocols: "to be selecte= d, perhaps REST-style HTTP(s) or IPFIX". The charter is not mandating a ch= oice right now, but it is /eventually/, at least the way that I'm interpret= ing it. Yes, it has made some suggestions, (e.g.: "perhaps"), but I interp= ret that explanatory and not declarative. -shane > Here's my thought process relative to that... > cost of replacing existing network elements whose main purpose is=20 > network connectivity just so it can also do some specific metrics; and ha= ve corporate IT organization add a whole new system to the management netwo= rk (including developing interfaces from other OSs) vs. > cost of having vendors develop software upgrades for existing network=20 > elements with new, additional management interface with different, unfami= liar protocol to a brand new system that corporate IT would have to add to = the management network (including developing OS interfaces) vs. > cost of upgrading existing network element's SNMP management interface=20 > and existing management systems > To me the math is pretty clear. I know what I would recommend to my emplo= yer. > But if LMAP doesn't want to deliver something useful for the embedded bas= e of network elements and devices, and only wants to consider greenfield de= ployments, I don't think that would stop the SNMP MIB from being created so= mewhere else. > So if that's where the consensus lies, then I guess if we could get the I= nformation Model done first, I would be ok. I'll bother the group no furthe= r after that. Y'all can deliver anything you want, targeted only to those w= ho desire a complete greenfield "LMAP solution", that has no consideration = for re-use/upgrade of anybody's embedded base of devices, network elements,= and systems. > Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From bs7652@att.com Mon Jun 3 08:46:13 2013 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 5B0B521F8FBE for ; Mon, 3 Jun 2013 08:46:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ER4WGSChQ1a for ; Mon, 3 Jun 2013 08:46:01 -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 9D22E11E80BA for ; Mon, 3 Jun 2013 08:46:00 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 83abca15.2aaae7431940.206866.00-574.583310.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 03 Jun 2013 15:46:00 +0000 (UTC) X-MXL-Hash: 51acba38607ca591-7641f03ce388da86b70101b939237febb1c0dc1b Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 63abca15.0.206847.00-255.583249.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 03 Jun 2013 15:46:00 +0000 (UTC) X-MXL-Hash: 51acba384647822d-879b3b589425c99a4655f72f43ca899a406e6c65 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 r53Fjwtf004614; Mon, 3 Jun 2013 11:45:58 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r53FjsmJ004546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jun 2013 11:45:55 -0400 Received: from GAALPA1MSGHUB9B.ITServices.sbc.com (gaalpa1msghub9b.itservices.sbc.com [130.8.36.88]) by alpi132.aldc.att.com (RSA Interceptor); Mon, 3 Jun 2013 15:45:42 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9B.ITServices.sbc.com ([130.8.36.88]) with mapi id 14.02.0342.003; Mon, 3 Jun 2013 11:45:45 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5dQQpm0fx/0vc4R0KsDuJUx0bAUAARytoAAAYmBDAAIsynAAAHK2WAAAFgsQAAB8IRMP//3RAA//vUyRA= Date: Mon, 3 Jun 2013 15:45:45 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302CCE74@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130531200542.GE65929@elstar.local> In-Reply-To: <20130531200542.GE65929@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.45.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-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=YJgoP26x c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=ehFY2oMyEo0A:10 a=dpDthlLKJOUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=r-i3oeFjtK8A:10 a=LRJmhiZd3fMDVcCvF4kA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: Shane Amante , "lmap@ietf.org" , "Romascanu, Dan \(Dan\)" Subject: Re: [lmap] lmap charter - draft 2 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, 03 Jun 2013 15:46:13 -0000 > Hi, >=20 > I am against these proposed changes. >=20 > /js Why? Barbara From j.schoenwaelder@jacobs-university.de Mon Jun 3 09:41:39 2013 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 D209621F8FBE for ; Mon, 3 Jun 2013 09:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-Jlcvgj3QW2 for ; Mon, 3 Jun 2013 09:41:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4794821F8F4A for ; Mon, 3 Jun 2013 09:41:34 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2409420D88; Mon, 3 Jun 2013 18:41:33 +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 J9fERsp8MFpL; Mon, 3 Jun 2013 18:41:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C0C620D69; Mon, 3 Jun 2013 18:41:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4C90F26A8263; Mon, 3 Jun 2013 18:41:29 +0200 (CEST) Date: Mon, 3 Jun 2013 18:41:28 +0200 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20130603164128.GA76619@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , Shane Amante , "lmap@ietf.org" , "Romascanu, Dan (Dan)" References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130531200542.GE65929@elstar.local> <2D09D61DDFA73D4C884805CC7865E611302CCE74@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CCE74@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Shane Amante , "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 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: Mon, 03 Jun 2013 16:41:40 -0000 On Mon, Jun 03, 2013 at 03:45:45PM +0000, STARK, BARBARA H wrote: > > Hi, > > > > I am against these proposed changes. > > > > /js > > Why? I think I already stated my reasoning on the mailing list and I prefer to not go into circles on the reasoning. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From philip.eardley@bt.com Mon Jun 3 09:49:49 2013 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 2499221F9651 for ; Mon, 3 Jun 2013 09:49:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riLV7kiCmWN5 for ; Mon, 3 Jun 2013 09:49:45 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id DBBB221F918F for ; Mon, 3 Jun 2013 09:49:44 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 3 Jun 2013 17:49:37 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.105]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Mon, 3 Jun 2013 17:49:36 +0100 From: To: , Date: Mon, 3 Jun 2013 17:49:35 +0100 Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5eOkFYUA5BMTlDTjak03OIocUNwQCP9eTw Message-ID: <9510D26531EF184D9017DF24659BB87F34B5F411DC@EMV65-UKRD.domain1.systemhost.net> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130531200542.GE65929@elstar.local> In-Reply-To: <20130531200542.GE65929@elstar.local> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: shane@castlepoint.net, dromasca@avaya.com, lmap@ietf.org Subject: Re: [lmap] lmap charter - draft 2 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, 03 Jun 2013 16:49:49 -0000 Juergen=20 Can you clarify whether you're against all the proposed changes? The first set (which Shane was ok with), I think are alright with me The last set (adding and deleting deliverables), I don't like.=20 Thanks phil > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: 31 May 2013 21:06 > To: STARK, BARBARA H > Cc: Shane Amante; lmap@ietf.org; Romascanu, Dan (Dan) > Subject: Re: [lmap] lmap charter - draft 2 >=20 > Hi, >=20 > I am against these proposed changes. >=20 > /js >=20 > On Fri, May 31, 2013 at 07:09:47PM +0000, STARK, BARBARA H wrote: > > Hi Shane, > > It sounds like we're very close. > > Would you agree to the following deliverables? > > > > > > - The LMAP Framework - provides common terminology and justifies the > simplifying constraints > > - The LMAP Use Cases - provides the motivating use cases as a basis > for the work > > - Information Model, the abstract definition of the information > carried from the Controller to the MA and the information carried from > the MA to the Collector. It includes > > > > > > - the metric(s) that can be measured and > > values for its parameters such as the Peer MA participating in the > > measurement and the desired environmental conditions (for example, > only > > conduct the measurement when there is no user traffic observed) > > > > > > - the schedule: information elements for defining when the > measurement should be run and how > > the results should be reported (when and to which Collector) > > - the report: information elements for identifying the metric(s) > measured and when, the actual > > result, and supporting metadata such as location. Result reports > may > > be organized in batches or may be reported immediately, such as for > an > > on-demand measurement. > > > > > > - SNMP MIB: Data Model consistent with the Information Model, for > control and reporting using SNMP. > > - NETCONF data model: Data Model consistent with the Information > Model, for control and reporting using NETCONF. > > > > And maybe (if people want)... > > - IPFIX data model: Data Model consistent with the Information Model, > for reporting using IPFIX. > > - REST-style HTTP(s) data model: Data Model consistent with the > Information Model, for reporting using REST-style HTTP(s). > > >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From philip.eardley@bt.com Mon Jun 3 09:55:41 2013 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 441DE21F8F2C for ; Mon, 3 Jun 2013 09:55:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPdo7Ix3Yvch for ; Mon, 3 Jun 2013 09:55:37 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id AEE0221F8F0C for ; Mon, 3 Jun 2013 09:55:36 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Jun 2013 17:55:35 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.105]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Mon, 3 Jun 2013 17:55:34 +0100 From: To: , , Date: Mon, 3 Jun 2013 17:55:33 +0100 Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5dQQpmrX+eILrVQJu06CxfDKZpagAT40sAAAL2LAAAJfx/AAAC6Q8AAAWjBwAAAXA1gAABvFuAAAJpgYAAAUtngAB9vNPwAARdEtA= Message-ID: <9510D26531EF184D9017DF24659BB87F34B5F411E3@EMV65-UKRD.domain1.systemhost.net> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CC0DA@GAALPA1MSGUSR9L.ITServices.sbc.com> <6BCFDF35-14BC-43A9-A795-DF077AFA4A60@castlepoint.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dromasca@avaya.com, lmap@ietf.org Subject: Re: [lmap] lmap charter - draft 2 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, 03 Jun 2013 16:55:41 -0000 I'm keen for there to be a common (generic) information model Personally I don't want to standardise extensions to a host of protocols. I= 'd like to try and pick one. If this proves impossible, then maybe we do mo= re than one, or at least others done elsewhere still have the same informat= ion model. Controller to Controller has not been suggested as in scope (in the charter= , BoF, etc). I think the work should focus on the MA's interactions with th= e Controller and Collector. MA to MA is in scope of IPPM, don't think we sh= ould touch it in lmap. Best wishes phil > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Bugenhagen, Michael K > Sent: 03 June 2013 16:13 > To: 'Shane Amante'; STARK, BARBARA H > Cc: Romascanu, Dan (Dan); lmap@ietf.org > Subject: Re: [lmap] lmap charter - draft 2 >=20 > Dan, Shane, Barbara - >=20 > I have been out of the office so I apologize for my input being a > bit late.. >=20 > A few key points I think we need to consider for the charter involve > EMS systems, and what Interoperability protocols we need. - >=20 > 1) Protocols / Interfaces - >=20 > My conclusion - In order to ensure adoption we have to recognize that > MA's on ISP devices will very likely be managed by their existing > management protocols (DOCSIS, GPON and DSL existing management > protocols MUST be acceptable). If we choose to ignore this when we > may be guilty of driving added cost into Internet services, which seems > foolish to me. To me this means we have a standard information model, > and messaging, and choose a nice way making that portable and > implementable, and possibly identifying the better IETF protocols and > frameworks that require little extra tweaking to make them work. >=20 >=20 > 2) Inter-operability (protocols) >=20 > Considering #1 and observing the existence of ISP EMS systems, it > seems the inter-operation space should be restricted to MA to MA, and > MA controller to MA controller like communication protocols. If we > have a like information model, one can split the management protocol, > and the test protocols, the management protocol (EMS to MA need not > inter-operate), however controller to MA, and MA to MA Must.... > Plus I did spec. in an older email that some sort of customer to MA / > ISP protocol needs to be standardized for interop as well. >=20 >=20 >=20 > Thanks, > Mike >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Shane Amante > Sent: Friday, May 31, 2013 4:46 PM > To: STARK, BARBARA H > Cc: Romascanu, Dan (Dan); lmap@ietf.org > Subject: Re: [lmap] lmap charter - draft 2 >=20 > Hi Barbara, >=20 > On May 31, 2013, at 3:08 PM, "STARK, BARBARA H" wrote: > >> Amongst the potential _IETF_ protocols that could fulfill the needs > >> of one or the other functions, the IETF should (attempt to) pick one > >> of its protocols & data-models for each. I would not want to see > the > >> LMAP WG select multiple, overlapping _IETF_ protocols to perform a > >> single function, (e.g.: we should think long & hard and try to > select > >> either SNMP -or- NETCONF/YANG for the "Control Protocol"). The main > >> benefit with the above approach is for those who desire, like me, to > >> have a complete "LMAP solution", with all of the necessary protocols > >> and data-models, _available_ for them to deploy the IETF LMAP WG > will have produced such. > > > > So you are opposed to LMAP being an agent of providing a useful SNMP > MIB for all of the existing network elements (and perhaps cable modems) > managed via SNMP? >=20 > No. Please re-read my message, above, carefully. I recommended the > IETF _should_, (I did not say: must), try to pick a single IETF > protocol for a particular function. IMO, it is much, much too early -- > the LMAP WG has not even been chartered! -- to declare a single, > specific IETF protocol or data-model as a de-facto winner. This is why > I agree with the present charter when it states, for Control & > Reporting transport protocols: "to be selected, perhaps REST-style > HTTP(s) or IPFIX". The charter is not mandating a choice right now, > but it is /eventually/, at least the way that I'm interpreting it. > Yes, it has made some suggestions, (e.g.: "perhaps"), but I interpret > that explanatory and not declarative. >=20 > -shane >=20 >=20 > > Here's my thought process relative to that... > > cost of replacing existing network elements whose main purpose is > > network connectivity just so it can also do some specific metrics; > and have corporate IT organization add a whole new system to the > management network (including developing interfaces from other OSs) vs. > > cost of having vendors develop software upgrades for existing network > > elements with new, additional management interface with different, > unfamiliar protocol to a brand new system that corporate IT would have > to add to the management network (including developing OS interfaces) > vs. > > cost of upgrading existing network element's SNMP management > interface > > and existing management systems >=20 > > To me the math is pretty clear. I know what I would recommend to my > employer. > > But if LMAP doesn't want to deliver something useful for the embedded > base of network elements and devices, and only wants to consider > greenfield deployments, I don't think that would stop the SNMP MIB from > being created somewhere else. >=20 > > So if that's where the consensus lies, then I guess if we could get > the Information Model done first, I would be ok. I'll bother the group > no further after that. Y'all can deliver anything you want, targeted > only to those who desire a complete greenfield "LMAP solution", that > has no consideration for re-use/upgrade of anybody's embedded base of > devices, network elements, and systems. > > Barbara >=20 >=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 Michael.K.Bugenhagen@centurylink.com Mon Jun 3 10:13:20 2013 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 9CB3821F96FF for ; Mon, 3 Jun 2013 10:13:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku9fIEiq9t5z for ; Mon, 3 Jun 2013 10:13:05 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC3D21F859D for ; Mon, 3 Jun 2013 10:13:05 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r53HCxTb018143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jun 2013 12:12:59 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id E3DE21E0035; Mon, 3 Jun 2013 11:12:53 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id A39D41E006B; Mon, 3 Jun 2013 11:12:53 -0600 (MDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r53HCrSM017456; Mon, 3 Jun 2013 12:12:53 -0500 (CDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.qintra.com [151.117.206.28]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r53HCqvI017436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 12:12:52 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.02.0318.001; Mon, 3 Jun 2013 12:12:53 -0500 From: "Bugenhagen, Michael K" To: "'philip.eardley@bt.com'" , "j.schoenwaelder@jacobs-university.de" , "bs7652@att.com" Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5eOkFYrX+eILrVQJu06CxfDKZpagCP9eTwAABd+hA= Date: Mon, 3 Jun 2013 17:12:52 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130531200542.GE65929@elstar.local> <9510D26531EF184D9017DF24659BB87F34B5F411DC@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F34B5F411DC@EMV65-UKRD.domain1.systemhost.net> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "shane@castlepoint.net" , "lmap@ietf.org" , "dromasca@avaya.com" Subject: Re: [lmap] lmap charter - draft 2 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, 03 Jun 2013 17:13:20 -0000 Juergen, Barbara, and Phil, I am ok with Barbara's proposal. And am wondering if the SNMP is the issue ? REST "appropriated" the same 4 commands functions from SNMP so I'm hoping t= hat's not the same issue - creation of a model that could be used by both w= ould be awesome. Best regards, Mike -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of phi= lip.eardley@bt.com Sent: Monday, June 03, 2013 11:50 AM To: j.schoenwaelder@jacobs-university.de; bs7652@att.com Cc: shane@castlepoint.net; dromasca@avaya.com; lmap@ietf.org Subject: Re: [lmap] lmap charter - draft 2 Juergen Can you clarify whether you're against all the proposed changes? The first set (which Shane was ok with), I think are alright with me The la= st set (adding and deleting deliverables), I don't like.=20 Thanks phil > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf=20 > Of Juergen Schoenwaelder > Sent: 31 May 2013 21:06 > To: STARK, BARBARA H > Cc: Shane Amante; lmap@ietf.org; Romascanu, Dan (Dan) > Subject: Re: [lmap] lmap charter - draft 2 >=20 > Hi, >=20 > I am against these proposed changes. >=20 > /js >=20 > On Fri, May 31, 2013 at 07:09:47PM +0000, STARK, BARBARA H wrote: > > Hi Shane, > > It sounds like we're very close. > > Would you agree to the following deliverables? > > > > > > - The LMAP Framework - provides common terminology and justifies the > simplifying constraints > > - The LMAP Use Cases - provides the motivating use cases as a basis > for the work > > - Information Model, the abstract definition of the information > carried from the Controller to the MA and the information carried from=20 > the MA to the Collector. It includes > > > > > > - the metric(s) that can be measured and > > values for its parameters such as the Peer MA participating in the > > measurement and the desired environmental conditions (for example, > only > > conduct the measurement when there is no user traffic observed) > > > > > > - the schedule: information elements for defining when the > measurement should be run and how > > the results should be reported (when and to which Collector) > > - the report: information elements for identifying the metric(s) > measured and when, the actual > > result, and supporting metadata such as location. Result reports > may > > be organized in batches or may be reported immediately, such as=20 > > for > an > > on-demand measurement. > > > > > > - SNMP MIB: Data Model consistent with the Information Model, for > control and reporting using SNMP. > > - NETCONF data model: Data Model consistent with the Information > Model, for control and reporting using NETCONF. > > > > And maybe (if people want)... > > - IPFIX data model: Data Model consistent with the Information=20 > > Model, > for reporting using IPFIX. > > - REST-style HTTP(s) data model: Data Model consistent with the > Information Model, for reporting using REST-style HTTP(s). > > >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From trammell@tik.ee.ethz.ch Mon Jun 3 13:07:15 2013 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 DB31821E80C6 for ; Mon, 3 Jun 2013 13:07:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+32CHLgXkWY for ; Mon, 3 Jun 2013 13:07:01 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B82CA21F92FC for ; Mon, 3 Jun 2013 12:57:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C4FDFD930A; Mon, 3 Jun 2013 21:57:06 +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 z1jAbS2nfTur; Mon, 3 Jun 2013 21:57:06 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (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 4C207D9307; Mon, 3 Jun 2013 21:57:06 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <9510D26531EF184D9017DF24659BB87F34B5F411E3@EMV65-UKRD.domain1.systemhost.net> Date: Mon, 3 Jun 2013 21:57:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CC0DA@GAALPA1MSGUSR9L.ITServices.sbc.com> <6BCFDF35-14BC-43A9-A795-DF077AFA4A60@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34B5F411E3@EMV65-UKRD.domain1.systemhost.net> To: philip.eardley@bt.com X-Mailer: Apple Mail (2.1503) Cc: shane@castlepoint.net, dromasca@avaya.com, Michael.K.Bugenhagen@centurylink.com, lmap@ietf.org, bs7652@att.com Subject: Re: [lmap] lmap charter - draft 2 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, 03 Jun 2013 20:07:16 -0000 Hi, Phil, all, Trying to catch up on the thread, but wanted to make this point = quickly... On Jun 3, 2013, at 6:55 PM, philip.eardley@bt.com wrote: > I'm keen for there to be a common (generic) information model > Personally I don't want to standardise extensions to a host of = protocols. I'd like to try and pick one. If this proves impossible, then = maybe we do more than one, or at least others done elsewhere still have = the same information model. Seconding this. Without a common information model (and a reference = architecture, so you have a point of common terminology for talking = about the components of the measurement system within that information = model), it's hard to see what benefit this effort would have for = measurement interoperability. I think the actual protocols used to do control are less important = thereto, and where these protocols touch existing management = infrastructure and/or must deal with the specifics of a given access = technology, it makes sense that these should be based on existing = management protocols from the appropriate forum. You really only need a = control protocol that is access technology agnostic when you want to run = measurements across different access technologies. As a researcher with = access mainly to end systems, I find this a cool feature (and am indeed = working on a platform at the moment that has this as a requirement), but = I don't think it's necessary for the access measurement use cases we're = focused on here. However, I do think it necessary for the WG to produce at least one = instance of a control protocol and report protocol, which could (1) be = used in a "pure IP" situation (i.e., where the entity running the = measurement does not have privileged access to the underlying access = technology and no requirement to integrate tightly with it) and (2) = provide a point of reference for other (possibly access technology and = management infrastructure specific) protocols sharing the information = model. I'm skeptical that just focusing on an information model without = having control/report protocols on which to gain implementation = experience will provide a generally useful result. > Controller to Controller has not been suggested as in scope (in the = charter, BoF, etc). I think the work should focus on the MA's = interactions with the Controller and Collector. MA to MA is in scope of = IPPM, don't think we should touch it in lmap. Agree on all of these points. Cheers, Brian >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf = Of >> Bugenhagen, Michael K >> Sent: 03 June 2013 16:13 >> To: 'Shane Amante'; STARK, BARBARA H >> Cc: Romascanu, Dan (Dan); lmap@ietf.org >> Subject: Re: [lmap] lmap charter - draft 2 >>=20 >> Dan, Shane, Barbara - >>=20 >> I have been out of the office so I apologize for my input being a >> bit late.. >>=20 >> A few key points I think we need to consider for the charter involve >> EMS systems, and what Interoperability protocols we need. - >>=20 >> 1) Protocols / Interfaces - >>=20 >> My conclusion - In order to ensure adoption we have to recognize = that >> MA's on ISP devices will very likely be managed by their existing >> management protocols (DOCSIS, GPON and DSL existing management >> protocols MUST be acceptable). If we choose to ignore this when we >> may be guilty of driving added cost into Internet services, which = seems >> foolish to me. To me this means we have a standard information = model, >> and messaging, and choose a nice way making that portable and >> implementable, and possibly identifying the better IETF protocols and >> frameworks that require little extra tweaking to make them work. >>=20 >>=20 >> 2) Inter-operability (protocols) >>=20 >> Considering #1 and observing the existence of ISP EMS systems, = it >> seems the inter-operation space should be restricted to MA to MA, and >> MA controller to MA controller like communication protocols. If we >> have a like information model, one can split the management protocol, >> and the test protocols, the management protocol (EMS to MA need not >> inter-operate), however controller to MA, and MA to MA Must.... >> Plus I did spec. in an older email that some sort of customer to MA / >> ISP protocol needs to be standardized for interop as well. >>=20 >>=20 >>=20 >> Thanks, >> Mike >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf = Of >> Shane Amante >> Sent: Friday, May 31, 2013 4:46 PM >> To: STARK, BARBARA H >> Cc: Romascanu, Dan (Dan); lmap@ietf.org >> Subject: Re: [lmap] lmap charter - draft 2 >>=20 >> Hi Barbara, >>=20 >> On May 31, 2013, at 3:08 PM, "STARK, BARBARA H" = wrote: >>>> Amongst the potential _IETF_ protocols that could fulfill the needs >>>> of one or the other functions, the IETF should (attempt to) pick = one >>>> of its protocols & data-models for each. I would not want to see >> the >>>> LMAP WG select multiple, overlapping _IETF_ protocols to perform a >>>> single function, (e.g.: we should think long & hard and try to >> select >>>> either SNMP -or- NETCONF/YANG for the "Control Protocol"). The = main >>>> benefit with the above approach is for those who desire, like me, = to >>>> have a complete "LMAP solution", with all of the necessary = protocols >>>> and data-models, _available_ for them to deploy the IETF LMAP WG >> will have produced such. >>>=20 >>> So you are opposed to LMAP being an agent of providing a useful SNMP >> MIB for all of the existing network elements (and perhaps cable = modems) >> managed via SNMP? >>=20 >> No. Please re-read my message, above, carefully. I recommended the >> IETF _should_, (I did not say: must), try to pick a single IETF >> protocol for a particular function. IMO, it is much, much too early = -- >> the LMAP WG has not even been chartered! -- to declare a single, >> specific IETF protocol or data-model as a de-facto winner. This is = why >> I agree with the present charter when it states, for Control & >> Reporting transport protocols: "to be selected, perhaps REST-style >> HTTP(s) or IPFIX". The charter is not mandating a choice right now, >> but it is /eventually/, at least the way that I'm interpreting it. >> Yes, it has made some suggestions, (e.g.: "perhaps"), but I interpret >> that explanatory and not declarative. >>=20 >> -shane >>=20 >>=20 >>> Here's my thought process relative to that... >>> cost of replacing existing network elements whose main purpose is >>> network connectivity just so it can also do some specific metrics; >> and have corporate IT organization add a whole new system to the >> management network (including developing interfaces from other OSs) = vs. >>> cost of having vendors develop software upgrades for existing = network >>> elements with new, additional management interface with different, >> unfamiliar protocol to a brand new system that corporate IT would = have >> to add to the management network (including developing OS interfaces) >> vs. >>> cost of upgrading existing network element's SNMP management >> interface >>> and existing management systems >>=20 >>> To me the math is pretty clear. I know what I would recommend to my >> employer. >>> But if LMAP doesn't want to deliver something useful for the = embedded >> base of network elements and devices, and only wants to consider >> greenfield deployments, I don't think that would stop the SNMP MIB = from >> being created somewhere else. >>=20 >>> So if that's where the consensus lies, then I guess if we could get >> the Information Model done first, I would be ok. I'll bother the = group >> no further after that. Y'all can deliver anything you want, targeted >> only to those who desire a complete greenfield "LMAP solution", that >> has no consideration for re-use/upgrade of anybody's embedded base of >> devices, network elements, and systems. >>> Barbara >>=20 >>=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 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From bs7652@att.com Mon Jun 3 14:13:34 2013 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 C412121F8FE5 for ; Mon, 3 Jun 2013 14:13:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWJ810NB7XpP for ; Mon, 3 Jun 2013 14:13:17 -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 368AE21F84B6 for ; Mon, 3 Jun 2013 14:07:51 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 7a50da15.2aaaf5a48940.34438.00-558.96754.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 03 Jun 2013 21:07:51 +0000 (UTC) X-MXL-Hash: 51ad05a729e0cfe4-669bb0d7885444edf414395c5251912499a71c4b Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 5a50da15.0.34428.00-483.96723.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 03 Jun 2013 21:07:50 +0000 (UTC) X-MXL-Hash: 51ad05a60eca24f5-6fc2d4fc0d0a7ecd386271482e24d7dafbe1034b 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 r53L7mQL020938; Mon, 3 Jun 2013 17:07:49 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r53L7cOW020873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jun 2013 17:07:41 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by alpi131.aldc.att.com (RSA Interceptor); Mon, 3 Jun 2013 21:07:20 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0342.003; Mon, 3 Jun 2013 17:07:24 -0400 From: "STARK, BARBARA H" To: Brian Trammell , "philip.eardley@bt.com" Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5dQQpm0fx/0vc4R0KsDuJUx0bAUAARytoAAAYmBDAAIsynAAAHK2WAAAFgsQAAB8IRMP//21OAgAA638D//+LJgIAEST4AgAActYCAADK4gIAAPpYw Date: Mon, 3 Jun 2013 21:07:22 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302CD0AE@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CC0DA@GAALPA1MSGUSR9L.ITServices.sbc.com> <6BCFDF35-14BC-43A9-A795-DF077AFA4A60@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34B5F411E3@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.255.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-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=ZMRgbwHb c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=qM0YGmjmNJYA:10 a=dpDthlLKJOUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=r-i3oeFjtK8A:10 a=9BC9RRVcoQwZq1TRnS8A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "shane@castlepoint.net" , "lmap@ietf.org" , "Michael.K.Bugenhagen@centurylink.com" , "dromasca@avaya.com" Subject: Re: [lmap] lmap charter - draft 2 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, 03 Jun 2013 21:13:34 -0000 > However, I do think it necessary for the WG to produce at least one insta= nce > of a control protocol and report protocol, which could (1) be used in a "= pure > IP" situation (i.e., where the entity running the measurement does not ha= ve > privileged access to the underlying access technology and no requirement = to > integrate tightly with it) and (2) provide a point of reference for other > (possibly access technology and management infrastructure specific) > protocols sharing the information model.=20 FYI. TR-069 is a "pure IP" protocol that has no underlying assumptions rega= rding or integration with any access technology. It is used by DSL, PON, an= d DOCSIS operators worldwide to manage modems, routers, gateways, set-top b= oxes, VoIP analog terminal adaptors, etc., as well as by wireless operators= to manage small cell (femtocell) access points attached to a home network = (where broadband IP access is not affiliated with the wireless service and = is supplied by whomever the end user subscribes to). I'm not providing this= information to suggest that LMAP consider TR-069, but merely to make sure = that there are no misconceptions about what it is (and isn't). It runs over= HTTP(s), using a handful of very generic RPCs to manage parameters defined= by an xml data model.=20 With that said, I see that I cannot sway the leadership from their desire t= o try to select an IETF protocol as an LMAP Control Protocol and an LMAP Re= port Protocol. I can only hope that these will be described as "an" instanc= e of such protocols, and not "the" instance of such protocols. Barbara From Henning.Schulzrinne@fcc.gov Mon Jun 3 14:43:47 2013 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 77C3C11E8109 for ; Mon, 3 Jun 2013 14:43:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JNoy2E6R5jU for ; Mon, 3 Jun 2013 14:43:30 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 683E011E80BA for ; Mon, 3 Jun 2013 14:40:56 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'STARK, BARBARA H'" , "'Romascanu, Dan (Dan)'" , "lmap@ietf.org" Thread-Topic: lmap charter - draft 2 Thread-Index: Ac5caOfRrX+eILrVQJu06CxfDKZpagAKmuQQAASHtDAANI0f0AAiBHJgAKiwThA= Date: Mon, 3 Jun 2013 21:40:51 +0000 References: <9904FB1B0159DA42B0B887B7FA8119CA17AAF4@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E611302CAA0A@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA17B060@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E611302CBCF2@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CBCF2@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] lmap charter - draft 2 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, 03 Jun 2013 21:43:47 -0000 Currently, both sets of devices (or, rather, the measurement devices ["whit= e boxes"] directly attached to them) use the exact same (proprietary) proto= col, so there's existence proof that this works in practice. We're talking = IP-level measurements, not PHY, so I'm not sure why the nature of the wirel= ine service would make a major difference. It would be helpful if you could= state the technical reason why this should matter, not just in the abstrac= t. All the IPPM measurements, as well as the MBA measurements, are IP-and-a= bove (ICMP, UDP, TCP, etc.), and the measurement end point is typically not= on the same infrastructure. -----Original Message----- From: STARK, BARBARA H [mailto:bs7652@att.com]=20 Sent: Friday, May 31, 2013 9:16 AM To: Henning Schulzrinne; 'Romascanu, Dan (Dan)'; lmap@ietf.org Subject: RE: lmap charter - draft 2 > A good example are DOCSIS cable modems - consumers can and do buy=20 > those at retail, and they are portable across ISPs. The same is true=20 > for DSL modems in Europe, which are routinely bought from third=20 > parties (FritzBox being one example). And is the same set of protocols the right answer for both of these? I suggested to Shane that an "architecture profile" or "device profile" (as= done in v6ops) might be appropriate, that identified the set of protocols = for a particular environment, rather than suggesting that the same protocol= was "right" for all situations. Personally, I would also think that a DOCSIS modem device profile would be = better defined by CableLabs, who has a critical mass of people who understa= nd cable environments, and who could also really and truly ensure interoper= ability through their testing program. Similarly, I think a European DSL mo= dem device profile would be better defined by HGI, who has a critical mass = of experts understanding their environment, and who has a certification pro= gram that can truly ensure interoperability. If the providers who operate i= n these environments want IETF to define device profiles for them, I have n= o objection to that. But if they want to do their profiles in CableLabs or = HGI, I don't think IETF needs to insist on inserting itself into that proce= ss.=20 Barbara From Henning.Schulzrinne@fcc.gov Mon Jun 3 14:45:50 2013 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 1CD9511E80BA for ; Mon, 3 Jun 2013 14:45:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvbMRQrWSS1y for ; Mon, 3 Jun 2013 14:45:36 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4AA11E80A5 for ; Mon, 3 Jun 2013 14:43:30 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'STARK, BARBARA H'" , "philip.eardley@bt.com" , "shane@castlepoint.net" Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5dQQpmrX+eILrVQJu06CxfDKZpagARytoAAAL2KwAAGxvrgAAILqgAAKB4pPA= Date: Mon, 3 Jun 2013 21:43:28 +0000 References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <9510D26531EF184D9017DF24659BB87F34B5414E3E@EMV65-UKRD.domain1.systemhost.net> <2D09D61DDFA73D4C884805CC7865E611302CBCCE@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CBCCE@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dromasca@avaya.com" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 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, 03 Jun 2013 21:45:50 -0000 You could make very similar arguments about TCP, routing protocols, VoIP - = you name it, more or less just by changing your message slightly. I'm not s= ure that this is very helpful in the IETF context. -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STA= RK, BARBARA H Sent: Friday, May 31, 2013 9:07 AM To: philip.eardley@bt.com; shane@castlepoint.net Cc: dromasca@avaya.com; lmap@ietf.org Subject: Re: [lmap] lmap charter - draft 2 Hi Phil, > I work for BT and believe we also would like protocol-level interoperabil= ity. And do you believe that the only way to achieve protocol-level interoperabi= lity is for the IETF to "ensure" it by creating a standards-track RFC with = mandatory-to-implement protocols listed? Or might there be other ways to ac= hieve this? > The case we're particularly interested in is where MAs are embedded in=20 > home gateways. They're dual sourced and the selection of vendors=20 > changes from one cycle to another. The MAs would interact with the=20 > BT-run Controller and Collector, which may be from another vendor that=20 > specialises in network management. >From your description, it sounds like BT is in a position to tell its vendo= rs what protocols to use. Would it not be possible for BT to specify the pr= otocols that BT wants in an RFP, or get together with other European telcos= in HGI or BBF to create a home gateway profile that identifies the mandato= ry-to-implement protocols for BT or for all European telcos? Do you think t= hat the protocols BT or European telcos will want to have implemented are t= he same as what Level3 would want/need, and the same as US cable operators = or US telcos, and that we can all agree on the IETF providing a single stan= dards-track RFC that mandates a single set of protocols for all of us? Beca= use that's *exactly* what's in the charter. A deliverable that defines a ma= ndatory-to-implement "one size fits all" set of protocols.=20 =20 I've suggested an alternate approach of: 1. Define the LMAP data models for all IETF protocols that people agree are= likely to be used for LMAP, 2. For populations who want it, LMAP may defin= e an "architectural profile" or "device profile" that is a targeted informa= tional or BCP recommendation of the profiles that are to be used for that s= pecific population. So if the European telcos wanted IETF to identify the p= rotocols for their devices, they could. And if Level3 wants IETF help to fi= gure out what's right for a Level3-type network, that could also be done. A= nd the set of protocols don't have to be the same. Or the Europeans could d= o this in HGI or BBF or in their own RFPs. >From your email, I was unclear whether you were in support of the current c= harter proposal of deliverables that identify mandatory-to-implement "one s= ize fits all" control and report protocols. Could you clarify that? The cha= rter currently only has deliverables for data models for these mandatory-to= -implement protocols. I would prefer if there were data model deliverables = for all IETF protocols that people agree are likely to be used for lmap pur= poses (personally, I think SNMP and netconf are both likely as control prot= ocols). Do you disagree with this and want only the data models for the IET= F mandatory-to-implement protocols defined? For example, since that single = control protocol probably wouldn't be SNMP, I guess no SNMP MIB would get d= efined. A protocol comparison guide might be useful. That is, which protocols might= be useful in various networks or devices, depending on characteristics of = those networks or devices. This wouldn't be a top priority for me, but I do= think it could be useful. But this wouldn't be a mandatory-to-implement st= andards-track RFC, either. > I don't take the current language to mean it's mandatory to implement=20 > for all ISPs, regulators etc. I'm happy for Dan, Al and Benoit to=20 > decide about re- phrasings. I disagree. The current language is very clear about deliverables that iden= tify "the" control protocol and "the" report protocol, and trying to make t= hese standards track. The language also only has data model deliverables fo= r these 2 protocols, and no others. This isn't just about "re-phrasing". Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From j.schoenwaelder@jacobs-university.de Mon Jun 3 21:55:25 2013 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 024ED21F9AD4 for ; Mon, 3 Jun 2013 21:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN6bc2Znh1hI for ; Mon, 3 Jun 2013 21:55:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0988421F84F2 for ; Mon, 3 Jun 2013 21:01:00 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D183820D52; Tue, 4 Jun 2013 06:00:56 +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 ZEQV1Yb3vk2f; Tue, 4 Jun 2013 06:00:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4DDF20D45; Tue, 4 Jun 2013 06:00:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 458C526A8B28; Tue, 4 Jun 2013 06:00:54 +0200 (CEST) Date: Tue, 4 Jun 2013 06:00:53 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20130604040053.GA77960@elstar.local> Mail-Followup-To: philip.eardley@bt.com, bs7652@att.com, shane@castlepoint.net, lmap@ietf.org, dromasca@avaya.com References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130531200542.GE65929@elstar.local> <9510D26531EF184D9017DF24659BB87F34B5F411DC@EMV65-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F34B5F411DC@EMV65-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: shane@castlepoint.net, dromasca@avaya.com, bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] lmap charter - draft 2 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, 04 Jun 2013 04:55:25 -0000 On Mon, Jun 03, 2013 at 05:49:35PM +0100, philip.eardley@bt.com wrote: > Juergen > Can you clarify whether you're against all the proposed changes? > > The first set (which Shane was ok with), I think are alright with me > The last set (adding and deleting deliverables), I don't like. The change "the metric(s) to be measured" to "the metric(s) that can be measured" is OK. The "information element" change I am bit less excited about since IPFIX uses the term "information element" in a rather different way and IMHO the change is not needed since all these items are scoped by "It includes" where "It" refers to the Information Model. The proposed change of deliverables I do not agree with. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Tue Jun 4 03:12:08 2013 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 07BBB21F9BFC for ; Tue, 4 Jun 2013 03:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.184 X-Spam-Level: X-Spam-Status: No, score=-10.184 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RO0EyQyCknY for ; Tue, 4 Jun 2013 03:11:53 -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 DE4DE21F9C06 for ; Tue, 4 Jun 2013 02:08:08 -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 r54984jv017668 for ; Tue, 4 Jun 2013 11:08:04 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5497l6k022415 for ; Tue, 4 Jun 2013 11:07:58 +0200 (CEST) Message-ID: <51ADAE63.6060209@cisco.com> Date: Tue, 04 Jun 2013 11:07:47 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "lmap@ietf.org" Content-Type: multipart/alternative; boundary="------------040607080609060203010800" Subject: [lmap] LMAP charter - What's next? 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, 04 Jun 2013 10:12:08 -0000 This is a multi-part message in MIME format. --------------040607080609060203010800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, From the LMAP BoF, I understood that the multiple domains situation was the initial goal. The charter mentions: A key assumption constraining the initial work is that the measurement system is under the control of a single organization (for example, an Internet Service Provider or a regulator). This assumption was taken into account so that the WG would not deal with the security and the inter-provider SLA aspects related to multiple domains. So basically a simplifying assumption, at least for now! Now, the discussion right now is that LMAP should not specify the protocol to be used (and as a consequence the associated data model(s)). While this builds on the simplifying assumption, it contradicts the initial goal. Yes, I understand that ISPs have developed proprietary protocols, to fulfill a LMAP type of framework. Yes, I understand that the regulators could receive the required information from these ISPs, who could aggregate the information from their own framework It's a fact that there are different device types and use cases, but not shooting for THE recommendation would be a missed opportunity. We should have a consistent MA implementation, including control and reporting. Across ISPs, across vendors, ideally across use cases. A good example, already mentioned on the list, is DOCSIS for cable modem: a typical device that you can buy at the local store, and it just works. We should shoot for something similar in LMAP. Let's not forget that the end goal is not only for a branch office/managed service type of device, but also for devices bought directly from BestBuy by the average man in the street. We all agree that the information model is key here. We should really strive to have an industry wide consensus on this. This is where the liaisons will play a big role. From the current charter proposal at https://datatracker.ietf.org/wg/lmap/charter/ OLD: The LMAP working group will coordinate with other standards bodies working in this area (e.g., BBF, IEEE 802.16, ETSI), and other IETF working groups in the areas of data models, protocols, multiple interface management, and measurement of performance metrics. NEW: The LMAP working group will coordinate with other standards bodies working in this area (e.g., BBF, IEEE 802.16, ETSI) regarding the information model, and other IETF working groups in the areas of data models, protocols, multiple interface management, and measurement of performance metrics. It's a small change, but it emphasis two points. 1. information model is key. Btw, an information model specific deliverable is a good thing. 2. The IETF can't impose any protocol/data model(s) to other SDOs. However, having information model consistency is a step in the right direction for the industry. What would be a WG failure IMHO is if this WG comes up with a complex matrix of architecture profiles such as: if the MA runs on a device that has a [DSL|DOCSIS|WIRELESS[MOBILE|HOMENET|PC|you-name-it] function, then the right [control|reporting] protocol is the combination of [SNMP|NETCONF|HTTPS|IPFIX|IPDR|TR69|IPDIR|you-name-it] with the combination of [MIB module, YANG modules, IPFIX IE, you-name-it] data models, mapping to the version X of the information model. Something to keep in mind is the cost associated with the proxies: protocol proxies and data models proxies. And not only the development costs, but also the maintenance costs (this is where the version comes into play in my previous sentence. Now, let's be realistic: even if the IETF "imposes" a pair of MUST use protocol/data model in a specification, the market will decide at the end. We have seen that multiple times at the IETF. So what are the next steps for LMAP? 1. I updated the proposed charter text. See https://datatracker.ietf.org/wg/lmap/charter/ I tried to include all editorial comments from the list. If I miss one on which there is apparent consensus, let me know. 2. the charter will go for IESG internal review on the next IESG telechat on June 13th. A ballot will be created asking the IESG and IAB whether the charter is ready for external review. 3. After the IESG telechat on June 13th, assuming that it's approved for external review, the Secretariat will change the state to "External Review" and announce it on iesg-announce and new-work. They'll also schedule it for the next telechat, two weeks later. 4. When the external review period is over (normally the Monday before the telechat), and a second ballot will be created that allows the IESG to ballot final approval. The milestones are in place to have the WG created before the IETF in Berlin... if all goes well. I would like to thank all participants for the fruitful discussions regarding the charter. Time to work on your drafts ;-) Regards, Benoit (OPS AD) --------------040607080609060203010800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

From the LMAP BoF, I understood that the multiple domains situation was the initial goal.
The charter mentions:
    A key assumption constraining the initial work is that the measurement system is
    under the control of a single organization (for example, an Internet Service Provider or
    a regulator).
This assumption was taken into account so that the WG would not deal with the security and the inter-provider SLA aspects related to multiple domains. So basically a simplifying assumption, at least for now!
Now, the discussion right now is that LMAP should not specify the protocol to be used (and as a consequence the associated data model(s)). While this builds on the simplifying assumption, it contradicts the initial goal.

Yes, I understand that ISPs have developed proprietary protocols, to fulfill a LMAP type of framework.
Yes, I understand that the regulators could receive the required information from these ISPs, who could aggregate the information from their own framework

It's a fact that there are different device types and use cases, but not shooting for THE recommendation would be a missed opportunity.  We should have a consistent MA implementation, including control and reporting. Across ISPs, across vendors, ideally across use cases. A good example, already mentioned on the list, is DOCSIS for cable modem: a typical device that you can buy at the local store, and it just works. We should shoot for something similar in LMAP. Let's not forget that the end goal is not only for a branch office/managed service type of device, but also for devices bought directly from BestBuy by the average man in the street.

We all agree that the information model is key here. We should really strive to have an industry wide consensus on this. This is where the liaisons will play a big role.
From the current charter proposal at https://datatracker.ietf.org/wg/lmap/charter/
OLD:
The LMAP working group will coordinate with other standards bodies working in this area (e.g., BBF, IEEE 802.16, ETSI), and other IETF working groups in the areas of data models, protocols, multiple interface management, and measurement of performance metrics.
NEW:
The LMAP working group will coordinate with other standards bodies working in this area (e.g., BBF, IEEE 802.16, ETSI) regarding the information model, and other IETF working groups in the areas of data models, protocols, multiple interface management, and measurement of performance metrics.
It's a small change, but it emphasis two points.
1. information model is key.  Btw, an information model specific deliverable is a good thing.
2. The IETF can't impose any protocol/data model(s) to other SDOs. However, having information model consistency is a step in the right direction for the industry.

What would be a WG failure IMHO is if this WG comes up with a complex matrix of architecture profiles such as: if the MA runs on a device that has a [DSL|DOCSIS|WIRELESS[MOBILE|HOMENET|PC|you-name-it] function, then the right [control|reporting] protocol is the combination of [SNMP|NETCONF|HTTPS|IPFIX|IPDR|TR69|IPDIR|you-name-it] with the combination of [MIB module, YANG modules, IPFIX IE, you-name-it] data models, mapping to the version X of the information model.
Something to keep in mind is the cost associated with the proxies: protocol proxies and data models proxies.
And not only the development costs, but also the maintenance costs (this is where the version comes into play in my previous sentence.

Now, let's be realistic: even if the IETF "imposes" a pair of MUST use protocol/data model in a specification, the market will decide at the end. We have seen that multiple times at the IETF.

So what are the next steps for LMAP?
1. I updated the proposed charter text. See https://datatracker.ietf.org/wg/lmap/charter/
I tried to include all editorial comments from the list. If I miss one on which there is apparent consensus, let me know.
2. the charter will go for IESG internal review on the next IESG telechat on June 13th. A  ballot will be created asking the IESG and IAB whether the charter is ready for external review.
3.  After the IESG telechat on June 13th, assuming that it's approved for external review, the Secretariat will change the state to "External Review" and announce it on iesg-announce and new-work. They'll also schedule it for the next telechat, two weeks later.
4.  When the external review period is over (normally the Monday before the telechat), and a second ballot will be created that allows the IESG to ballot final approval.

The milestones are in place to have the WG created before the IETF in Berlin... if all goes well.

I would like to thank all participants for the fruitful discussions regarding the charter.
Time to work on your drafts ;-)

Regards, Benoit (OPS AD)


--------------040607080609060203010800-- From alessandro.capello@telecomitalia.it Tue Jun 4 03:17:49 2013 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 527D821F9C60 for ; Tue, 4 Jun 2013 03:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOXZceyak-Kw for ; Tue, 4 Jun 2013 03:17:31 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 756A421F9B10 for ; Tue, 4 Jun 2013 02:12:11 -0700 (PDT) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 4 Jun 2013 11:12:06 +0200 Received: from GRFMBX702BA020.griffon.local ([10.188.101.11]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Tue, 4 Jun 2013 11:12:06 +0200 From: Capello Alessandro To: "lmap@ietf.org" Date: Tue, 4 Jun 2013 11:12:05 +0200 Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5g372qZ90MVf41RbWDBZlC+3XeewAIb72Q Message-ID: <36A93B31228D3B49B691AD31652BCAE9A5B07CE48A@GRFMBX702BA020.griffon.local> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130531200542.GE65929@elstar.local> <9510D26531EF184D9017DF24659BB87F34B5F411DC@EMV65-UKRD.domain1.systemhost.net> <20130604040053.GA77960@elstar.local> In-Reply-To: <20130604040053.GA77960@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] lmap charter - draft 2 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, 04 Jun 2013 10:17:49 -0000 Hi all, the scenario that we are considering in Telecom Italia includes MA on CPEs = but also other MAs (both active and passive) in the aggregation/core portio= n of the network. The ambition is to have a common measurement infrastructu= re (one controller) to assist troubleshooting. I agree that the information model is key, but especially for the latter ki= nd of probes, partially based on internal developments, we would also like = to see the IETF converging on a single protocol (a couple, considering cont= roller-to-MA and MA-to-collector communications). Regarding the re-use of existing management protocols for access technologi= es (e.g. TR-069, etc.), I think that on one hand they could speed up the de= ployment of a measurement infrastructure extended to access device, but on = the other hand I would like to highlight the complexity of integrating the = LMAP infrastructure (especially controller and collector) with multiple man= agement systems (DSL, mobile, etc.). It would probably bring to a multi-con= troller scenario (each access technology would have its own controller), wi= th inter-controllers communication being explicitly out of scope for LMAP. Regards, Alessandro Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From arturo.servin@gmail.com Tue Jun 4 07:33:17 2013 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 AC82C21F9A00 for ; Tue, 4 Jun 2013 07:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrt3fZUv1ttk for ; Tue, 4 Jun 2013 07:33:08 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id D06D121F994D for ; Tue, 4 Jun 2013 05:49:36 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id i13so348845qae.10 for ; Tue, 04 Jun 2013 05:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WAU7Sx9NUeVSf1LDzCrYo8AfaNufDcQZfsyTU6wRtj8=; b=nKPyRr3xXSip8mVWpwm3rWe7/Z7qZZ0VRnEY52Oa3SVIrJZp1D87uPMZw73aPGaQb8 UJ0u/1l5ed0Nkkifeoz57kRUOUD/OlES5CiAD5qGNLPNQ8OU/pVwMsJ9SuPyc9WCwNta JyZphHw8sumONJbKiuGd94bvjP9+77z3wuMtu1JyQhWMefjoXP5GsyXQpTjQ2NcHurdY Yvd5y08ydglwdMitIpne1lrJwJsdNVnpd0J+bngHS9bu7izC/zoJD/UTeu6QRHrvD865 QejylD6QLj8XH0pWXLJM58WrfISA/Bs9aWsvWkhWj4iekGG3FZdKfBSrlPZh34x+p+xZ y37Q== X-Received: by 10.229.142.202 with SMTP id r10mr508515qcu.81.1370350176331; Tue, 04 Jun 2013 05:49:36 -0700 (PDT) Received: from Arturos-MacBook-Pro.local ([2001:13c7:7001:7000:d072:fde:8811:179b]) by mx.google.com with ESMTPSA id j10sm64847904qeh.0.2013.06.04.05.49.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 05:49:35 -0700 (PDT) Message-ID: <51ADE261.7060806@gmail.com> Date: Tue, 04 Jun 2013 09:49:37 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Trammell References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CC0DA@GAALPA1MSGUSR9L.ITServices.sbc.com> <6BCFDF35-14BC-43A9-A795-DF077AFA4A60@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34B5F411E3@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bs7652@att.com, Michael.K.Bugenhagen@centurylink.com, lmap@ietf.org Subject: Re: [lmap] lmap charter - draft 2 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, 04 Jun 2013 14:33:17 -0000 On 6/3/13 4:57 PM, Brian Trammell wrote: > I'm skeptical that just focusing on an information model without having control/report protocols on which to gain implementation experience will provide a generally useful result. Same to me. If we want to accomplish Benoit goal's "Let's not forget that the end goal is not only for a branch office/managed service type of device, but also for devices bought directly from BestBuy by the average man in the street." I doubt that just a data model would do. Regards, as From bs7652@att.com Tue Jun 4 08:38:35 2013 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 291FA21F9BD1 for ; Tue, 4 Jun 2013 08:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KccJREGIWrbB for ; Tue, 4 Jun 2013 08:38:19 -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 EF40021F9DF9 for ; Tue, 4 Jun 2013 06:42:08 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 0beeda15.709ad940.155669.00-554.405237.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 04 Jun 2013 13:42:08 +0000 (UTC) X-MXL-Hash: 51adeeb001cdf9a8-987bc1b009cc3bfe1b37a91b156b8762137c57f9 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 26eeda15.0.154932.00-429.403099.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 04 Jun 2013 13:40:51 +0000 (UTC) X-MXL-Hash: 51adee63542fb071-d970cd776edfb6bb99b14a2b731f9c471a0d78d6 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 r54DemcN025920; Tue, 4 Jun 2013 09:40:49 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r54DeWMm025646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jun 2013 09:40:37 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 4 Jun 2013 13:40:12 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0342.003; Tue, 4 Jun 2013 09:40:16 -0400 From: "STARK, BARBARA H" To: Henning Schulzrinne , "'Romascanu, Dan (Dan)'" , "lmap@ietf.org" Thread-Topic: lmap charter - draft 2 Thread-Index: Ac5caOfRrX+eILrVQJu06CxfDKZpagAKmuQQAASHtDAANI0f0AAiBHJgAKiwThAAAFyNwA== Date: Tue, 4 Jun 2013 13:40:15 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302CDD1E@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <9904FB1B0159DA42B0B887B7FA8119CA17AAF4@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E611302CAA0A@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA17B060@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E611302CBCF2@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.238.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-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=C8deP3z+ c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=hNlBpdRzGEsA:10 a=NuZxi4Up2mcA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=jwgqLBMEQXgA:10 a=a_iFvyPHK17d88voFxIA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Subject: Re: [lmap] lmap charter - draft 2 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, 04 Jun 2013 15:38:35 -0000 > Currently, both sets of devices (or, rather, the measurement devices ["wh= ite > boxes"] directly attached to them) use the exact same (proprietary) > protocol, so there's existence proof that this works in practice. We're t= alking > IP-level measurements, not PHY, so I'm not sure why the nature of the > wireline service would make a major difference. It would be helpful if yo= u > could state the technical reason why this should matter, not just in the > abstract. All the IPPM measurements, as well as the MBA measurements, > are IP-and-above (ICMP, UDP, TCP, etc.), and the measurement end point is > typically not on the same infrastructure. It's not the nature of the underlying PHY service that makes a difference. = It's the nature of the entity who intends to deploy measurement capabilitie= s: what protocols are they familiar and comfortable and experienced with, w= hat protocols are currently well-proven and used in their embedded base of = equipment, what protocols are used by systems already integrated into their= operations network, what protocols do they currently have certification la= bs built for, what protocols have many vendors offering systems and solutio= ns to those entities, what protocols are offered by vendors that the entiti= es are comfortable with (because of the quality of work, level of support),= in what SIGs are those entities' needs and requirements actively listened,= in what SIGs does a critical mass of expertise exist in that understands t= he operational environments of such entities, etc.=20 The point that a proprietary protocol was successfully used is indeed exist= ence proof that it does not matter what protocol an entity or SIG chooses f= or devices deployed or managed by members of that SIG (as long as the proto= col is able to do the job).=20 And the point that many (certainly not all) existing devices and other equi= pment may be upgradable to support lmap measurements, using their existing = management interfaces and systems, should not be discounted as "undesirable= ", since this is potentially a very cost-effective way to support lmap meas= urements. Even where re-using existing devices is not possible, it may stil= l be possible to re-use existing OA&M systems that have already been integr= ated into an entity's OA&M network, which would be more cost-effective than= deploying new systems that require new interfaces be built to other O&AM s= ystems of the entity. Many operators already have systems designed for coll= ecting measured data from massive quantities of end devices.=20 Demanding that these operators go to enormous expense to deploy and integra= te new systems, when existing systems may be able to do the job, doesn't si= t well with me as a consumer. As a consumer, I don't want my broadband bill= going up just because someone dictated that measurements had to be reporte= d using IPFIX instead of IPDR. Since it's already not possible to use a DOC= SIS modem on a European operator's DSL network, the fact that DOCSIS modems= bought at a US electronics store and DSL modems bought in Europe may use d= ifferent protocols for control and reporting of measurement data is not som= ething that needs to be prevented. The organizations that already specify a= nd certify these devices (CableLabs and HGI, respectively) need to continue= to do so. Barbara From bclaise@cisco.com Tue Jun 4 10:43:09 2013 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 4A1C921F9922 for ; Tue, 4 Jun 2013 10:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.226 X-Spam-Level: X-Spam-Status: No, score=-10.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdjLpVmjiUTv for ; Tue, 4 Jun 2013 10:43:05 -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 8118121F998A for ; Tue, 4 Jun 2013 09:34:37 -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 r54GYUrL006793; Tue, 4 Jun 2013 18:34:30 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r54GXfJB019326; Tue, 4 Jun 2013 18:33:52 +0200 (CEST) Message-ID: <51AE16E4.5060804@cisco.com> Date: Tue, 04 Jun 2013 18:33:40 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Arturo Servin References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CC0DA@GAALPA1MSGUSR9L.ITServices.sbc.com> <6BCFDF35-14BC-43A9-A795-DF077AFA4A60@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34B5F411E3@EMV65-UKRD.domain1.systemhost.net> <51ADE261.7060806@gmail.com> In-Reply-To: <51ADE261.7060806@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lmap@ietf.org, bs7652@att.com, Michael.K.Bugenhagen@centurylink.com, Brian Trammell Subject: Re: [lmap] lmap charter - draft 2 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, 04 Jun 2013 17:43:09 -0000 Arturo, > > On 6/3/13 4:57 PM, Brian Trammell wrote: >> I'm skeptical that just focusing on an information model without having control/report protocols on which to gain implementation experience will provide a generally useful result. > Same to me. > > If we want to accomplish Benoit goal's "Let's not forget that the end > goal is not only for a branch office/managed service type of device, but > also for devices bought directly from BestBuy by the average man in the > street." I doubt that just a data model would do. I guess you meant: I doubt that just an information model would do See RFC 3444. Regards, Benoit > > > Regards, > as > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > From philip.eardley@bt.com Wed Jun 5 04:12:23 2013 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 50D0521F9A73 for ; Wed, 5 Jun 2013 04:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT0gtIYTzXym for ; Wed, 5 Jun 2013 04:12:19 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 97B6521F9A46 for ; Wed, 5 Jun 2013 04:12:05 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 5 Jun 2013 12:12:04 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.105]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Wed, 5 Jun 2013 12:12:04 +0100 From: To: , , Date: Wed, 5 Jun 2013 12:09:55 +0100 Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5eOkFYrX+eILrVQJu06CxfDKZpagCP9eTwAABd+hAAWGkipw== Message-ID: <9510D26531EF184D9017DF24659BB87F34B61FBEC8@EMV65-UKRD.domain1.systemhost.net> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130531200542.GE65929@elstar.local> <9510D26531EF184D9017DF24659BB87F34B5F411DC@EMV65-UKRD.domain1.systemhost.net>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: shane@castlepoint.net, lmap@ietf.org, dromasca@avaya.com Subject: Re: [lmap] lmap charter - draft 2 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, 05 Jun 2013 11:12:23 -0000 it seems that a data model is protocol-specific. but maybe some protocols a= re similar enough that the data model can be the same? i guess this might come out of the detailed work, or be considered as part = of it ________________________________________ From: Bugenhagen, Michael K [Michael.K.Bugenhagen@centurylink.com] Sent: 03 June 2013 18:12 To: Eardley,PL,Philip,TUB8 R; j.schoenwaelder@jacobs-university.de; bs7652@= att.com Cc: shane@castlepoint.net; dromasca@avaya.com; lmap@ietf.org Subject: RE: [lmap] lmap charter - draft 2 Juergen, Barbara, and Phil, I am ok with Barbara's proposal. And am wondering if the SNMP is the issue ? REST "appropriated" the same 4 commands functions from SNMP so I'm hoping t= hat's not the same issue - creation of a model that could be used by both w= ould be awesome. Best regards, Mike -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of phi= lip.eardley@bt.com Sent: Monday, June 03, 2013 11:50 AM To: j.schoenwaelder@jacobs-university.de; bs7652@att.com Cc: shane@castlepoint.net; dromasca@avaya.com; lmap@ietf.org Subject: Re: [lmap] lmap charter - draft 2 Juergen Can you clarify whether you're against all the proposed changes? The first set (which Shane was ok with), I think are alright with me The la= st set (adding and deleting deliverables), I don't like. Thanks phil > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf > Of Juergen Schoenwaelder > Sent: 31 May 2013 21:06 > To: STARK, BARBARA H > Cc: Shane Amante; lmap@ietf.org; Romascanu, Dan (Dan) > Subject: Re: [lmap] lmap charter - draft 2 > > Hi, > > I am against these proposed changes. > > /js > > On Fri, May 31, 2013 at 07:09:47PM +0000, STARK, BARBARA H wrote: > > Hi Shane, > > It sounds like we're very close. > > Would you agree to the following deliverables? > > > > > > - The LMAP Framework - provides common terminology and justifies the > simplifying constraints > > - The LMAP Use Cases - provides the motivating use cases as a basis > for the work > > - Information Model, the abstract definition of the information > carried from the Controller to the MA and the information carried from > the MA to the Collector. It includes > > > > > > - the metric(s) that can be measured and > > values for its parameters such as the Peer MA participating in the > > measurement and the desired environmental conditions (for example, > only > > conduct the measurement when there is no user traffic observed) > > > > > > - the schedule: information elements for defining when the > measurement should be run and how > > the results should be reported (when and to which Collector) > > - the report: information elements for identifying the metric(s) > measured and when, the actual > > result, and supporting metadata such as location. Result reports > may > > be organized in batches or may be reported immediately, such as > > for > an > > on-demand measurement. > > > > > > - SNMP MIB: Data Model consistent with the Information Model, for > control and reporting using SNMP. > > - NETCONF data model: Data Model consistent with the Information > Model, for control and reporting using NETCONF. > > > > And maybe (if people want)... > > - IPFIX data model: Data Model consistent with the Information > > Model, > for reporting using IPFIX. > > - REST-style HTTP(s) data model: Data Model consistent with the > Information Model, for reporting using REST-style HTTP(s). > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap= From j.schoenwaelder@jacobs-university.de Wed Jun 5 04:29:40 2013 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 3986521F997B for ; Wed, 5 Jun 2013 04:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RovYAL6OMbTZ for ; Wed, 5 Jun 2013 04:29:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0B921F88D8 for ; Wed, 5 Jun 2013 04:29:35 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26C4020C34; Wed, 5 Jun 2013 13:29:34 +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 xw1Ma39nM2A2; Wed, 5 Jun 2013 13:29:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD75620A1F; Wed, 5 Jun 2013 13:29:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DFFA326B613C; Wed, 5 Jun 2013 13:29:30 +0200 (CEST) Date: Wed, 5 Jun 2013 13:29:30 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20130605112929.GA28175@elstar.local> Mail-Followup-To: philip.eardley@bt.com, Michael.K.Bugenhagen@centurylink.com, bs7652@att.com, shane@castlepoint.net, dromasca@avaya.com, lmap@ietf.org References: <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130531200542.GE65929@elstar.local> <9510D26531EF184D9017DF24659BB87F34B5F411DC@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F34B61FBEC8@EMV65-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F34B61FBEC8@EMV65-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: shane@castlepoint.net, dromasca@avaya.com, Michael.K.Bugenhagen@centurylink.com, lmap@ietf.org, bs7652@att.com Subject: Re: [lmap] lmap charter - draft 2 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: Wed, 05 Jun 2013 11:29:40 -0000 On Wed, Jun 05, 2013 at 12:09:55PM +0100, philip.eardley@bt.com wrote: > it seems that a data model is protocol-specific. but maybe some > protocols are similar enough that the data model can be the same? While this is in principle possible, the experience tells us it is rather unlikely since the devil is in the details (differences in the atomicity of transactions, the error handling, the constraints on data and supported encodings, ...). Since SNMP was mentioned in the context of this statement and SNMP has lots of protocol specific restrictions, the likelihood to be able to use a data model written for another protocol with SNMP is very close to 0%. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jamesmilleresquire@gmail.com Wed Jun 5 09:50:25 2013 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 EE35A21F91B1 for ; Wed, 5 Jun 2013 09:50:24 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNGQZ2NfPRlG for ; Wed, 5 Jun 2013 09:50:24 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9591021F99A0 for ; Wed, 5 Jun 2013 09:50:23 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so1522291wev.28 for ; Wed, 05 Jun 2013 09:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RnjTCjFk1fp2V6U5Ac6Z1u9R6lNvzSr7BhzALA/vVys=; b=bfLOfcfnZpuoQdcyQp2BjUwk33F21hXtVqV1GJUmiQZyjDfxT0VMsqAVjRXCaJyJcN zmNuJRQLeePhykU00lg4scO68zwF/GwVVFpWQWHjB2mqWVusYvBKJKANYNCWVQZ/kqwO ZxOQj86WtIQvItcUJEexmbBb4zobdxR1pJgHweWYpnjP3SpOLpeWrR9AMsXueP6ez9po 5nvQBaFmluSrqG409ZWLo17/ElzYPym4ZwLFYDHviqywuW9fYx7KvJon3eTYPOW28uCn PPGLCgd6p+IxaAetNzQytR6ENbrFbrB1IGjy3hovChjah9b8FGHnoC3L2BMqYhOpesho qROQ== X-Received: by 10.181.13.169 with SMTP id ez9mr162287wid.8.1370451022277; Wed, 05 Jun 2013 09:50:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.160.130 with HTTP; Wed, 5 Jun 2013 09:49:42 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CD0AE@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CC0DA@GAALPA1MSGUSR9L.ITServices.sbc.com> <6BCFDF35-14BC-43A9-A795-DF077AFA4A60@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34B5F411E3@EMV65-UKRD.domain1.systemhost.net> <2D09D61DDFA73D4C884805CC7865E611302CD0AE@GAALPA1MSGUSR9L.ITServices.sbc.com> From: James Miller Date: Wed, 5 Jun 2013 12:49:42 -0400 Message-ID: To: "STARK, BARBARA H" Content-Type: multipart/alternative; boundary=f46d0438eb9f5d74bf04de6afe0d Cc: "lmap@ietf.org" , "philip.eardley@bt.com" , "dromasca@avaya.com" , "Michael.K.Bugenhagen@centurylink.com" , "shane@castlepoint.net" , Brian Trammell Subject: Re: [lmap] lmap charter - draft 2 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, 05 Jun 2013 16:50:25 -0000 --f46d0438eb9f5d74bf04de6afe0d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In the original I-D, I think we excluded elements that did not relate to the scope of the execution of a predefined schedule of tests for an already developed sample of measurement devices. The problem of automating the identification and exchange of the speed tier, carrier and other information about the measurement device's provisioned service is a very important piece that I think Mike and others have explained is included in ongoing work at BBForum and elsewhere. We referenced in the use cases, the importance of developing a statistically-valid sample of a set of users as an important task for many entities undertaking a large-scale measurement program. In practice, the FCC's Measuring Broadband America program includes in the sample creation an exchange with the provisioning carriers to confirm the speed tier of the provisioned broadband connect. The benefits we gain are a rock solid baseline for the provisioned (advertised) rate that supports our sample refinements, data processing and reporting. This "validation" process can be cumbersome and we identify it as one area of concern for scaling the FCC approach. It's important to note though that this information is important for setting up a trial and analyzing data but would be strictly necessary for the execution Active test measurements with a trial that was already setup. For example, we are using largely the same network/transport layer testing techniques in our Mobile program, but with very different approaches for developing the sample of measurement devices, interaction of the tests with devices and privacy approaches, and approaches to reporting. So while the PHY/MAC layer information is part of the ecosystem, I would NOT see it as strictly necessary to the protocols for communication between the measurement servers, devices and other collection elements. I would see TR69, MIB definitions and other elements incorporated at different layers of a LMAP solution. -- JamesMillerEsquire@Gmail.com "Wovon man nicht sprechen kann, dar=FCber mu=DF man schweigen." (What we cannot speak about we must pass over in silence. ) Ludwig Josef Johann Wittgenstein On Mon, Jun 3, 2013 at 5:07 PM, STARK, BARBARA H wrote: > > However, I do think it necessary for the WG to produce at least one > instance > > of a control protocol and report protocol, which could (1) be used in a > "pure > > IP" situation (i.e., where the entity running the measurement does not > have > > privileged access to the underlying access technology and no requiremen= t > to > > integrate tightly with it) and (2) provide a point of reference for oth= er > > (possibly access technology and management infrastructure specific) > > protocols sharing the information model. > > FYI. TR-069 is a "pure IP" protocol that has no underlying assumptions > regarding or integration with any access technology. It is used by DSL, > PON, and DOCSIS operators worldwide to manage modems, routers, gateways, > set-top boxes, VoIP analog terminal adaptors, etc., as well as by wireles= s > operators to manage small cell (femtocell) access points attached to a ho= me > network (where broadband IP access is not affiliated with the wireless > service and is supplied by whomever the end user subscribes to). I'm not > providing this information to suggest that LMAP consider TR-069, but mere= ly > to make sure that there are no misconceptions about what it is (and isn't= ). > It runs over HTTP(s), using a handful of very generic RPCs to manage > parameters defined by an xml data model. > > With that said, I see that I cannot sway the leadership from their desire > to try to select an IETF protocol as an LMAP Control Protocol and an LMAP > Report Protocol. I can only hope that these will be described as "an" > instance of such protocols, and not "the" instance of such protocols. > Barbara > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > --f46d0438eb9f5d74bf04de6afe0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In the original I-D, I think we excluded elements that did= not relate to the scope of the=A0execution=A0of a predefined schedule of t= ests for an already developed sample of measurement devices. =A0The problem= of automating the identification and exchange of the speed tier, carrier a= nd other information about the measurement device's provisioned service= is a very important piece that =A0I think Mike and others have explained i= s included in ongoing work at BBForum and elsewhere. =A0We =A0referenced in= the use cases, the importance of developing a statistically-valid sample o= f a set of users as an important task for many entities undertaking a large= -scale measurement program.=A0

In practice, the FCC's Measuring Broadband America progr= am includes in the sample creation an exchange with the provisioning carrie= rs to confirm the speed tier of the provisioned broadband connect. =A0The b= enefits we gain are a rock solid baseline for the provisioned (advertised) = rate that supports our sample refinements, data processing and reporting. = =A0This "validation" process can be cumbersome and we identify it= as one area of concern for scaling the FCC approach. =A0

It's important to note though that this infor= mation is important for setting up a trial and analyzing data but would be = strictly necessary for the execution Active test measurements with a trial = that was already setup. =A0For example, we are using largely the same netwo= rk/transport layer testing techniques in our Mobile program, but with very = different approaches for developing the sample of measurement devices, inte= raction of the tests with devices and privacy approaches, and approaches to= reporting.

So while the PHY/MAC layer information is p= art of the ecosystem, I would NOT see it as strictly necessary to the proto= cols for communication between the measurement servers, devices and other c= ollection elements. =A0I would see TR69, MIB definitions and other elements= incorporated at different layers of a LMAP solution.


--
JamesMillerEsquire@Gmail.com

"Wovon man nicht sprechen kann, dar=FCber mu=DF man sc= hweigen."
(What we cannot speak about we must pass over in silence. =A0)
Ludwig Josef Johann Wittgenstein


On Mon, Jun 3, 2013 at 5:07 PM, STARK, B= ARBARA H <bs7652@att.com> wrote:
> However, I do think it necessary for the WG to produ= ce at least one instance
> of a control protocol and report protocol, which could (1) be used in = a "pure
> IP" situation (i.e., where the entity running the measurement doe= s not have
> privileged access to the underlying access technology and no requireme= nt to
> integrate tightly with it) and (2) provide a point of reference for ot= her
> (possibly access technology and management infrastructure specific) > protocols sharing the information model.

FYI. TR-069 is a "pure IP" protocol that has no underlying = assumptions regarding or integration with any access technology. It is used= by DSL, PON, and DOCSIS operators worldwide to manage modems, routers, gat= eways, set-top boxes, VoIP analog terminal adaptors, etc., as well as by wi= reless operators to manage small cell (femtocell) access points attached to= a home network (where broadband IP access is not affiliated with the wirel= ess service and is supplied by whomever the end user subscribes to). I'= m not providing this information to suggest that LMAP consider TR-069, but = merely to make sure that there are no misconceptions about what it is (and = isn't). It runs over HTTP(s), using a handful of very generic RPCs to m= anage parameters defined by an xml data model.

With that said, I see that I cannot sway the leadership from their desire t= o try to select an IETF protocol as an LMAP Control Protocol and an LMAP Re= port Protocol. I can only hope that these will be described as "an&quo= t; instance of such protocols, and not "the" instance of such pro= tocols.
Barbara

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

--f46d0438eb9f5d74bf04de6afe0d-- From bclaise@cisco.com Wed Jun 12 08:23:15 2013 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 9926621E8055 for ; Wed, 12 Jun 2013 08:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.534 X-Spam-Level: X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBsrRoEdh3sd for ; Wed, 12 Jun 2013 08:23:10 -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 C031B21E8054 for ; Wed, 12 Jun 2013 08:23:09 -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 r5CFN62V028707 for ; Wed, 12 Jun 2013 17:23:06 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5CFMZNb013312 for ; Wed, 12 Jun 2013 17:23:00 +0200 (CEST) Message-ID: <51B89237.90304@cisco.com> Date: Wed, 12 Jun 2013 17:22:31 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "lmap@ietf.org" References: <51B891F8.5020009@cisco.com> In-Reply-To: <51B891F8.5020009@cisco.com> X-Forwarded-Message-Id: <51B891F8.5020009@cisco.com> Content-Type: multipart/alternative; boundary="------------020800080507060905080300" Subject: [lmap] Fwd: Re: Martin Stiemerling's Block on charter-ietf-lmap-00-08: (with BLOCK) 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, 12 Jun 2013 15:23:15 -0000 This is a multi-part message in MIME format. --------------020800080507060905080300 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI. The discussion continues with the IESG. Regards, Benoit -------- Original Message -------- Subject: Re: Martin Stiemerling's Block on charter-ietf-lmap-00-08: (with BLOCK) Date: Wed, 12 Jun 2013 17:21:28 +0200 From: Benoit Claise To: Martin Stiemerling CC: The IESG Hi Martin, Thanks for your feedback. I improved the charter at https://datatracker.ietf.org/doc/charter-ietf-lmap/ See also in line. > Martin Stiemerling has entered the following ballot position for > charter-ietf-lmap-00-08: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > I'm in general support of the LMAP WG, but I share Stewart's concerns > about the length of the charter proposal and the difficulty to get to the > point of it while reading the text. > > I would like to see an updated charter proposal that incorporates > Stewart's text change proposals. > > Here are my comments on top of Stewart's comments: > - The term 'mechanisms' is used a lot in the charter text and in some > places it is ok, but in other places it worries me. For instance, right > in the first paragraph where LMAP is introduced: > "The Large-Scale Measurement of Broadband Performance (LMAP) working > group > is chartered to standardize the mechanisms for performance measurements > of > broadband devices such as home and enterprise edge routers, personal > computers, > mobile devices and other networking devices, whether wired or wireless." > > Another instance where 'mechanisms' is used as an arbitrary place > holder: > 3rd paragraph: "Many measurement systems that exist today use > proprietary, custom-designed > mechanisms to coordinate their Measurement Agents (MAs)" > This is basically all about protocols and data specifications, right? > > > It is better to specify what those mechanisms are, right in this place in > order to avoid any misunderstandings on what LMAP is supposed to work. > E.g. communication protocols between LMAP entities, information models, > ... Understood. > - Also in the first paragraph: > 'other networking devices': What is that? Anything outside of the > broadband network? replaced by "etc..." > - 2nd paragraph: What is a 'characterization plan'? removed. > - Paragraph starting with "It is assumed that different organization's". > I assume this paragraph tries to clearly say considerations for > overlapping LMAP domains is out of scope, isn't it? However, the text is > very, very soft about this, i.e., not clear enough to say it. That's actually the reverse: It is assumed that different organization's LMAP measurement domains can overlap > - "Inter-organization communication of results is not addressed in the > LMAP system > and is deferred to bi-lateral agreements." > This should better read > "Inter-organization communication of results is out of scope of LMAP." > We should not suggest anything about how this is handled in deployments > IMHO. Done. I've also tried to group first what's in scope, then list what it's out of scope. > - I would like to see a stronger statement that LMAP is developing any > performance metrics at all: > "LMAP will, where possible, adopt the performance metrics of the IPPM WG, > and > work with IPPM to develop any required new performance metrics. " > New text suggestion: > "LMAP will, where possible, adopt the performance metrics of the IPPM WG, > and > bring any required new performance metrics to the IPPM WG for > standardization." Fine. Hopefully IPPM will accept all new metrics under their current charter... > - Paragraph "The case where an end user can independently perform network > diagnostic > measurements (beyond their private network) is not directly in scope," > What is 'not directly in scope'? It is in scope or out of scope? The_use_case where an end user can independently perform network diagnostic measurements (beyond their private network) is not directly in scope, > - There are two 'however' paragraphs: > - starting with "Another area that is out of scope is the management" > - starting with "Protection against the intentional or malicious > insertion" > This is an attempt to extend the scope of the WG beyond of what it is > supposed to do the first place, isn't it? Not really. For the first one, we said "no discovery", but "if it's available, use it" For the second one, it was initially written: preventing againg gaming the system is technical impossible... but if there is something very simple that could help, why not... > I would like to see a clear > statement that this has been noted but in order to focus the group it is > better to let out of scope by now. > > > > > > --------------020800080507060905080300 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI.
The discussion continues with the IESG.

Regards, Benoit

-------- Original Message --------
Subject: Re: Martin Stiemerling's Block on charter-ietf-lmap-00-08: (with BLOCK)
Date: Wed, 12 Jun 2013 17:21:28 +0200
From: Benoit Claise <bclaise@cisco.com>
To: Martin Stiemerling <martin.stiemerling@neclab.eu>
CC: The IESG <iesg@ietf.org>


Hi Martin,

Thanks for your feedback.
I improved the charter at https://datatracker.ietf.org/doc/charter-ietf-lmap/
See also in line.
Martin Stiemerling has entered the following ballot position for
charter-ietf-lmap-00-08: Block

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





----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I'm in general support of the LMAP WG, but I share Stewart's concerns
about the length of the charter proposal and the difficulty to get to the
point of it while reading the text. 

I would like to see an updated charter proposal that incorporates
Stewart's text change proposals.

Here are my comments on top of Stewart's comments:
- The term 'mechanisms' is used a lot in the charter text and in some
places it is ok, but in other places it worries me. For instance, right
in the first paragraph where LMAP is introduced:
"The Large-Scale Measurement of Broadband Performance (LMAP) working
group
is chartered to standardize the mechanisms for performance measurements
of
broadband devices such as home and enterprise edge routers, personal
computers,
mobile devices and other networking devices, whether wired or wireless."

Another instance where 'mechanisms' is used as an arbitrary place
holder:
3rd paragraph: "Many measurement systems that exist today use
proprietary, custom-designed 
mechanisms to coordinate their Measurement Agents (MAs)"
This is basically all about protocols and data specifications, right?


It is better to specify what those mechanisms are, right in this place in
order to avoid any misunderstandings on what LMAP is supposed to work.
E.g. communication protocols between LMAP entities, information models,
...
Understood. 
- Also in the first paragraph:
'other networking devices': What is that? Anything outside of the
broadband network?
replaced by "etc..."
- 2nd paragraph: What is a 'characterization plan'?
removed.
- Paragraph starting with "It is assumed that different organization's".
I assume this paragraph tries to clearly say considerations for
overlapping LMAP domains is out of scope, isn't it? However, the text is
very, very soft about this, i.e., not clear enough to say it.
That's actually the reverse:

It is assumed that different organization's LMAP measurement domains can

overlap


 
- "Inter-organization communication of results is not addressed in the
LMAP system
and is deferred to bi-lateral agreements."
This should better read 
"Inter-organization communication of results is out of scope of LMAP." 
We  should not suggest anything about how this is handled in deployments
IMHO.
Done.

I've also tried to group first what's in scope, then list what it's out of scope.
- I would like to see a stronger statement that LMAP is developing any
performance metrics at all: 
"LMAP will, where possible, adopt the performance metrics of the IPPM WG,
and
work with IPPM to develop any required new performance metrics. "
New text suggestion:
"LMAP will, where possible, adopt the performance metrics of the IPPM WG,
and
bring any required new performance metrics to the IPPM WG for
standardization."
Fine. Hopefully IPPM will accept all new metrics under their current charter...
- Paragraph "The case where an end user can independently perform network
diagnostic
measurements (beyond their private network) is not directly in scope,"
What is 'not directly in scope'? It is in scope or out of scope?

The use case where an end user can independently perform network
diagnostic
measurements (beyond their private network) is not directly in scope,
- There are two 'however' paragraphs:
- starting with "Another area that is out of scope is the management"
- starting with "Protection against the intentional or malicious
insertion"
This is an attempt to extend the scope of the WG beyond of what it is
supposed to do the first place, isn't it?
Not really.
For the first one, we said "no discovery", but "if it's available, use it"
For the second one, it was initially written: preventing againg gaming the system is technical impossible... but if there is something very simple that could help, why not...
I would like to see a clear
statement that this has been noted but in order to focus the group it is
better to let out of scope by now.



--------------020800080507060905080300-- From bclaise@cisco.com Thu Jun 13 13:00:48 2013 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 BF9CA21F9957 for ; Thu, 13 Jun 2013 13:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyJOrvIwPsm9 for ; Thu, 13 Jun 2013 13:00:44 -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 4F37521F8FB6 for ; Thu, 13 Jun 2013 13:00:44 -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 r5DK0g51014394 for ; Thu, 13 Jun 2013 22:00:42 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5DK0QCh004224 for ; Thu, 13 Jun 2013 22:00:36 +0200 (CEST) Message-ID: <51BA24DA.1080903@cisco.com> Date: Thu, 13 Jun 2013 22:00:26 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "lmap@ietf.org" Content-Type: multipart/alternative; boundary="------------020205000505060608060502" Subject: [lmap] LMAP status after the IESG call today 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, 13 Jun 2013 20:00:48 -0000 This is a multi-part message in MIME format. --------------020205000505060608060502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Good news. The LMAP charter has been approved by the IESG for external review. The external review message will be sent tomorrow, for a period of 10 days. Some changes in the charter text: - added the notion of privacy The LMAP WG will consider privacy as a core requirement and will ensure that by default measurement and collection mechanisms and protocols standardised operate in a privacy-sensitive manner, for example, ensuring that measurements are not personally identifying except where permission for such has been granted by identified subjects. Note that this does not mean that all uses of LMAP need to turn on all privacy features but it does mean that privacy features do need to be at least well-defined. - many clarifications. Too many to list them all - a lot of simplification: the charter was deemed too long The latest charter is now at https://datatracker.ietf.org/doc/charter-ietf-lmap/ Regards, Benoit --------------020205000505060608060502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Good news. The LMAP charter has been approved by the IESG for external review.
The external review message will be sent tomorrow, for a period of 10 days.

Some changes in the charter text:
- added the notion of privacy
The LMAP WG will consider privacy as a core requirement and will ensure that by
default measurement and collection mechanisms and protocols standardised
operate in a privacy-sensitive manner, for example, ensuring that measurements
are not personally identifying except where permission for such has been
granted by identified subjects. Note that this does not mean that all uses of
LMAP need to turn on all privacy features but it does mean that privacy
features do need to be at least well-defined.
- many clarifications. Too many to list them all
- a lot of simplification: the charter was deemed too long

The latest charter is now at https://datatracker.ietf.org/doc/charter-ietf-lmap/

Regards, Benoit


--------------020205000505060608060502-- From bclaise@cisco.com Fri Jun 14 02:56:41 2013 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 58CAC21F9BA9; Fri, 14 Jun 2013 02:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.872 X-Spam-Level: X-Spam-Status: No, score=-9.872 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTVUapI3+T3T; Fri, 14 Jun 2013 02:56:37 -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 D04E021F9B9D; Fri, 14 Jun 2013 02:56:36 -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 r5E9uYFj005902; Fri, 14 Jun 2013 11:56:34 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5E9uD7X022568; Fri, 14 Jun 2013 11:56:23 +0200 (CEST) Message-ID: <51BAE8BD.70802@cisco.com> Date: Fri, 14 Jun 2013 11:56:13 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080107010101060802070700" X-Mailman-Approved-At: Fri, 14 Jun 2013 03:23:10 -0700 Cc: "ops-ads@tools.ietf.org" Subject: [lmap] OPS/LMAP chair positions 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, 14 Jun 2013 09:56:41 -0000 This is a multi-part message in MIME format. --------------080107010101060802070700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, [bcc'ed a couple mailing lists. You might be receiving duplicates] Joel and I are looking for potential WG chair candidates. 1. Specifically for Large-Scale Measurement of Broadband Performance (LMAP ). At this stage, LMAP is still a proposed WG, but it goes through the process, and might become a WG before the IETF in Berlin. 2. This is also a good opportunity to create a pool of candidates interested in chairing OPS WGs in the future. We might even consider training this group if there is some interest. RFC 2418 might help as background information. Alternatively, if you have questions/comments, don't hesitate to reach out to Joel and I at "ops-ads@tools.ietf.org" Regards, Joel and Benoit --------------080107010101060802070700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

[bcc'ed a couple mailing lists. You might be receiving duplicates]

Joel and I are looking for potential WG chair candidates.
1. Specifically for Large-Scale Measurement of Broadband Performance (LMAP).
At this stage, LMAP is still a proposed WG, but it goes through the process, and might become a WG before the IETF in Berlin.
2. This is also a good opportunity to create a pool of candidates interested in chairing OPS WGs in the future.
We might even consider training this group if there is some interest.

RFC 2418 might help as background information.
Alternatively, if you have questions/comments, don't hesitate to reach out to Joel and I at "ops-ads@tools.ietf.org" <ops-ads@tools.ietf.org>

Regards, Joel and Benoit
--------------080107010101060802070700-- From iesg-secretary@ietf.org Fri Jun 14 08:41:57 2013 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 DFC5D21F9C92; Fri, 14 Jun 2013 08:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qm351qvnAZ4L; Fri, 14 Jun 2013 08:41:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA22F21F9C73; Fri, 14 Jun 2013 08:41:55 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130614154155.24228.49697.idtracker@ietfa.amsl.com> Date: Fri, 14 Jun 2013 08:41:55 -0700 Cc: lmap WG Subject: [lmap] WG Review: Large-Scale Measurement of Broadband Performance (lmap) 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, 14 Jun 2013 15:41:57 -0000 A new IETF working group has been proposed in the Operations and Management Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-06-24. Large-Scale Measurement of Broadband Performance (lmap) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Benoit Claise Mailing list Address: lmap@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/lmap Archive: http://www.ietf.org/mail-archive/web/lmap Charter: The Large-Scale Measurement of Broadband Performance (LMAP) working group standardizes the LMAP measurement system for performance measurements of broadband access devices such as home and enterprise edge routers, personal computers, mobile devices, set top box, whether wired or wireless. Measuring portions of the Internet on a large scale is essential for accurate characterizations of performance over time and geography, for network diagnostic investigations by providers and their users, and for collecting information to support public policy development. The goal is to have the measurements (made using the same metrics and mechanisms) for a large number of points on the Internet, and to have the results collected and stored in the same form. The LMAP working group is chartered to specify an information model, the associated data models, and select/extend one or more protocols for the secure communication: 1. A Control Protocol, from a Controller to instruct Measurement Agents what performance metrics to measure, when to measure them, how/when to report the measurement results to a Collector, 2. A Report Protocol, for a Measurement Agent to report the results to the Collector. The data models should be extensible for new and additional measurements. LMAP will consider re-use of existing data models languages. A key assumption constraining the initial work is that the measurement system is under the control of a single organization (for example, an Internet Service Provider or a regulator). However, the components of an LMAP measurement system can be deployed in administrative domains that are not owned by the measuring organization. Thus, the system of functions deployed by a single organization constitutes a single LMAP domain which may span ownership or other administrative boundaries. The LMAP architecture will allow for measurements that utilize either IPv4 or IPv6, or possibly both. Devices containing Measurement Agents may have several interfaces using different link technologies. Multiple address families and interfaces must be considered in the Control and Report protocols. It is assumed that different organization's LMAP measurement domains can overlap, and that active measurement packets appear along with normal user traffic when crossing another organization's network. There is no requirement to specify a mechanism for coordination between the LMAP measurements in overlapping domains (for instance a home network with MAs on the home gateway, set top box and laptop). In principle, there are no restrictions on the type of device in which the MA function resides. Both active and passive measurements are in scope, although there may be differences in their applicability to specific use cases, or in the security measures needed according to the threats specific to each measurement category. LMAP will not standardize performance metrics. The LMAP WG will consider privacy as a core requirement and will ensure that by default measurement and collection mechanisms and protocols standardized operate in a privacy-sensitive manner, for example, ensuring that measurements are not personally identifying except where permission for such has been granted by identified subjects. Note that this does not mean that all uses of LMAP need to turn on all privacy features but it does mean that privacy features do need to be at least well-defined. Standardizing control of end users Measurement Agents is out of scope. However, end users can obtain an MA to run measurement tasks if desired and report their results to whomever they want, most likely the supplier of the MA. This provides for user-initiated on-demand measurement, which is an important component of the ISP use case. Inter-organization communication of results is out of scope of the LMAP charter. The management protocol to bootstrap the MAs in measurement devices is out of scope of the LMAP charter. Service parameters, such as product category, can be useful to decide which measurements to run and how to interpret the results. These parameters are already gathered and stored by existing operations systems. Discovering the service parameters on the MAs or sharing the service parameters between MAs are out of the scope. However, if the service parameters are available to the MAs, they could be reported with the measurement results in the Report Protocol. Deciding the set of measurements to run is a business decision and is out of scope of the LMAP charter. Protection against the intentional or malicious insertion of inaccuracies into the overall system or measurement process (sometimes known as "gaming the system") is outside the scope of work. The LMAP working group will coordinate with other standards bodies working in this area (e.g., BBF, IEEE 802.16, ETSI) regarding the information model, and with other IETF working groups in the areas of data models, protocols, multiple interface management, and measurement of performance metrics. The LMAP WG will produce the following work items: 1. The LMAP Framework - provides common terminology, basic architecture elements, and justifies the simplifying constraints 2. The LMAP Use Cases - provides the motivating use cases as a basis for the work 3. Information Model, the abstract definition of the information carried from the Controller to the MA and the information carried from the MA to the Collector. It includes * The metric(s) that can be measured and values for its parameters such as the Peer MA participating in the measurement and the desired environmental conditions (for example, only conduct the measurement when there is no user traffic observed) * The schedule: when the measurement should be run and how the results should be reported (when and to which Collector) * The report: the metric(s) measured and when, the actual result, and supporting metadata such as location. Result reports may be organized in batches or may be reported immediately, such as for an on-demand measurement. 4. The Control protocol and the associated data model: The definition of how instructions are delivered from a Controller to a MA; this includes a Data Model consistent with the Information Model plus a transport protocol. This may be a simple instruction - response protocol, and LMAP will specify how it operates over an existing protocol (to be selected, perhaps REST-style HTTP(s) or NETCONF). 5. The Report protocol and the associated data model: The definition of how the Report is delivered from a MA to a Collector; this includes a Data Model consistent with the Information Model plus a transport protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). Milestones: Sep 2013 Initial WG I-D for the LMAP Framework including terminology Sep 2013 Initial WG I-D for the LMAP Use cases Dec 2013 Submit the LMAP Framework I-D to the IESG for consideration as Informational RFC Dec 2013 Submit I-D on the LMAP Use cases to the IESG for consideration as Informational RFC Jan 2014 Initial WG I-D for LMAP Information models Apr 2014 Initial WG I-D for the Control protocol Apr 2014 Initial WG I-D for the Report protocol Apr 2014 Initial WG I-D for a Data model for LMAP control information Apr 2014 Initial WG I-D for a Data model for LMAP report information Jul 2014 Submit the LMAP Information models I-D to the IESG for consideration as Standards track RFC Dec 2014 Submit the Control protocol I-D to the IESG for consideration as Standards track RFC Dec 2014 Submit the Report protocol I-D to the IESG for consideration as Standards track RFC Dec 2014 Submit the Data model for LMAP control I-D to the IESG for consideration as Standards track RFC Dec 2014 Submit the Data model for LMAP report I-D to the IESG for consideration as Standards track RFC From Henning.Schulzrinne@fcc.gov Mon Jun 17 07:39:17 2013 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 E1F3E21F9982 for ; Mon, 17 Jun 2013 07:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5HV0AjlQgMX for ; Mon, 17 Jun 2013 07:39:13 -0700 (PDT) Received: from GB-IP-1.fcc.gov (mail3.fcc.gov [208.31.254.166]) by ietfa.amsl.com (Postfix) with ESMTP id 8158521F964C for ; Mon, 17 Jun 2013 07:39:03 -0700 (PDT) From: Henning Schulzrinne To: "lmap@ietf.org" Thread-Topic: "New ITU-T work to give end-users the tools to test Internet access speed" Thread-Index: Ac5raGeZiEamF+85QYCYS30r340RJQ== Date: Mon, 17 Jun 2013 14:39:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D01FB55D8CGBPXMB13Vfccnet_" MIME-Version: 1.0 Subject: [lmap] "New ITU-T work to give end-users the tools to test Internet access speed" 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, 17 Jun 2013 14:39:18 -0000 --_000_E6A16181E5FD2F46B962315BB05962D01FB55D8CGBPXMB13Vfccnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.itu.int/ITU-T/newslog/New+ITUT+Work+To+Give+Endusers+The+Tools+T= o+Test+Internet+Access+Speed.aspx#.Ub8fTvnVCSo --_000_E6A16181E5FD2F46B962315BB05962D01FB55D8CGBPXMB13Vfccnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.itu.int/I= TU-T/newslog/New+ITUT+Work+To+Give+Endusers+The+= ;Tools+To+Test+Internet+Access+Speed.aspx#.Ub8fTvnVCSo<= /a>

--_000_E6A16181E5FD2F46B962315BB05962D01FB55D8CGBPXMB13Vfccnet_-- From jbustos@niclabs.cl Fri Jun 21 05:38:21 2013 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 B2C3721E810C for ; Fri, 21 Jun 2013 05:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oR-zpwXgnO6F for ; Fri, 21 Jun 2013 05:38:19 -0700 (PDT) Received: from mail-ye0-x231.google.com (mail-ye0-x231.google.com [IPv6:2607:f8b0:4002:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 940BF21E810A for ; Fri, 21 Jun 2013 05:38:19 -0700 (PDT) Received: by mail-ye0-f177.google.com with SMTP id q11so12386yen.8 for ; Fri, 21 Jun 2013 05:38:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer:x-gm-message-state; bh=NumC5qFLgwNLSm87r3yYmWPgbuC2r8j3MaPi6iUksW4=; b=HHHxPiBA8eabY7sCCPeQYbePu4a7+3aj7PRoKarhD2G/+opFQ4YaATbeqs8A/wSvTn yG06dgSCe+G/5F25/zI1r9pRlz4iKj+jqiTbXIk3IHyfSGzDFKQCAxnBz4M/SwPoZZhy NQCayh+T0wSz85AIajV4AA1Z3X1h4jKqrN4zWGrkUCt8aduuT322hmuIKkKeK075JRDU 4T6ptgZWlQJGXHoqGnPUz1485t/Axh8cU5718HZiuS/SKW2/vsNI62AasXL+JfZ7wHnP 432jfr1pSM7w4N2P5C1o3gZhbS0kr7oXBz0Yal0rjLld6m5Sw1p1vFiFOqRCsGwJ1GJa OhnA== X-Received: by 10.236.168.105 with SMTP id j69mr7288853yhl.28.1371818298975; Fri, 21 Jun 2013 05:38:18 -0700 (PDT) Received: from [172.30.65.239] ([200.7.6.129]) by mx.google.com with ESMTPSA id y70sm7990595yhe.15.2013.06.21.05.38.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 05:38:18 -0700 (PDT) From: =?iso-8859-1?Q?Javier_Bustos_Jim=E9nez?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <39AB2F75-0A65-4024-922E-E10CD27B64F9@niclabs.cl> Date: Fri, 21 Jun 2013 08:38:14 -0400 To: lmap@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQkjRKDIrnFleJf3hVHmxcw98jonaFaTB4MyN+OEmWb0dRwsKTxylT5OL/v7PLPkayIf8Tmt Subject: [lmap] Projects in Broadband Performance 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, 21 Jun 2013 12:38:22 -0000 Hello all I'm just registering on this mailist and I would like to collaborate. Here in Chile we are conducting research on this area to fullfil our = neutrality law. In AINA 2013 we presented the article Adkintun: SLA Monitoring of ISP = Broadband offerings (project finished in December 2013), which is = focused on "wired" internet as you can see in http://www.adkintun.cl ; = and in NetGCoop we presented the main ideas of such system oriented to = mobile internet = http://ieeexplore.ieee.org/xpl/login.jsp?tp=3D&arnumber=3D6486123 more = info in http://www.adkintunmobile.cl Hope it helps Javier= From acmorton@att.com Fri Jun 21 08:29:03 2013 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 76E2721F9C51 for ; Fri, 21 Jun 2013 08:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKfJKMG7zrHM for ; Fri, 21 Jun 2013 08:28:57 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 2481F21F9B4A for ; Fri, 21 Jun 2013 08:28:57 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 4C4E1120555 for ; Fri, 21 Jun 2013 11:28:56 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id D5B5FE0187 for ; Fri, 21 Jun 2013 11:27:47 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Fri, 21 Jun 2013 11:28:56 -0400 From: "MORTON JR., ALFRED C (AL)" To: lmap WG Date: Fri, 21 Jun 2013 11:28:54 -0400 Thread-Topic: Call for contributions and Agenda time in Berlin Thread-Index: Ac5ukbwsnWWTUZX3TBq4VwGNgR/klA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] Call for contributions and Agenda time in Berlin 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, 21 Jun 2013 15:29:03 -0000 LMAP, Last week, the draft LMAP charter went forward for external review. LMAP has been approved for a placeholder session at IETF-87, either as a Working Group if approved in time, or as a BoF if not. If charter-related issues remain to be resolved, they will be discussed during the session with highest priority. However, ... If you have new/revised contributions covered under the current draft of the LMAP charter, please reply to the list identifying the topic, the filename(if applicable) and the related issues you would like to discus= s at=20 a face-to-face session, and try to do this by June 28, 2013. thanks and regards, Dan and Al > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: Friday, June 14, 2013 11:42 AM > To: IETF-Announce > Cc: lmap WG > Subject: WG Review: Large-Scale Measurement of Broadband Performance > (lmap) >=20 > A new IETF working group has been proposed in the Operations and > Management Area. The IESG has not made any determination yet. The > following draft charter was submitted, and is provided for informational > purposes only. Please send your comments to the IESG mailing list (iesg > at ietf.org) by 2013-06-24. >=20 > Large-Scale Measurement of Broadband Performance (lmap) > ------------------------------------------------ > Current Status: Proposed WG >=20 > Assigned Area Director: > Benoit Claise >... From dromasca@avaya.com Sun Jun 23 04:15:02 2013 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 D9C3021F9C74 for ; Sun, 23 Jun 2013 04:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.447 X-Spam-Level: X-Spam-Status: No, score=-103.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqGY4LHuWRLY for ; Sun, 23 Jun 2013 04:15:02 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id B3D3921F9C67 for ; Sun, 23 Jun 2013 04:15:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAM3XxlHGmAcF/2dsb2JhbABagmgheoMFvDENbhZtB4IjAQEBAQMSERFRBgEGAg0EBAEBAwIGHQMCBDAUAQYBAQUFBBMIGodsAYxWjEOEQoo6hg2KJReBJoxngRE+gkkzYQOeB4sAgxCBagcXBho X-IronPort-AV: E=Sophos;i="4.87,922,1363147200"; d="scan'208";a="17346734" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 Jun 2013 07:15:00 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jun 2013 07:12:48 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Sun, 23 Jun 2013 07:14:59 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: NOMCOM 2013 - UPDATE of validated volunteers list so far Thread-Index: AQHObdME6Rq94fdvak6H2HdtpQQDoZlDKUtg Date: Sun, 23 Jun 2013 11:14:59 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1AB620@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [lmap] FW: NOMCOM 2013 - UPDATE of validated volunteers list so far 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, 23 Jun 2013 11:15:03 -0000 UGxlYXNlIGNvbnNpZGVyIHZvbHVudGVlcmluZyBmb3IgTk9NQ09NIGlmIHlvdSBhcmUgZWxpZ2li bGUgYW5kIHlvdSBkaWQgbm90IGRvIGl0IGJ5IG5vdy4gDQoNClRoYW5rcyBhbmQgUmVnYXJkcywN Cg0KRGFuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWV0Zi1hbm5v dW5jZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgTm9tQ29tIENoYWlyIDIwMTMNClNlbnQ6IFRodXJzZGF5LCBKdW5l IDIwLCAyMDEzIDE6MTQgQU0NClRvOiBJRVRGIEFubm91bmNlbWVudCBMaXN0DQpDYzogaWV0ZkBp ZXRmLm9yZw0KU3ViamVjdDogTk9NQ09NIDIwMTMgLSBVUERBVEUgb2YgdmFsaWRhdGVkIHZvbHVu dGVlcnMgbGlzdCBzbyBmYXINCg0KQmVsb3cgaXMgdGhlIGN1cnJlbnQgdmFsaWRhdGVkIGxpc3Qg b2Ygdm9sdW50ZWVycyBmb3IgTm9tY29tIDIwMTMuICBJZiB5b3VyIG5hbWUgaGFzIGEgKiwgSSdt IHdhaXRpbmcgZm9yIGEgbWVzc2FnZSBiYWNrIGZyb20geW91Lg0KDQpCaWcgdGhhbmtzIHRvIGV2 ZXJ5b25lIHdobyBoYXMgdm9sdW50ZWVyZWQhDQoNCk5vdyB3aGF0IGFyZSB0aGUgcmVzdCBvZiB5 b3Ugd2FpdGluZyBmb3I/DQoNCldlIHN0aWxsIG5lZWQgcXVpdGUgYSBmZXcgdG8gZ2V0IHVwIHRv IDIwMCB2b2x1bnRlZXJzLg0KUGxlYXNlIHJlcGx5IGFuZCB2b2x1bnRlZXIgLSBpbmNsdWRlIGlu IHRoZSBlbWFpbDogeW91ciBGaXJzdCBOYW1lLCBMYXN0IE5hbWUsIGVtYWlsIGFkZHJlc3NlcyB5 b3UndmUgdXNlZCBpbiB0aGUgbGFzdCBmZXcgeWVhcnMgaW4gcmVnaXN0ZXJpbmcgZm9yIElFVEYg bWVldGluZ3MsIHByZWZlcnJlZCBlbWFpbCBhZGRyZXNzLCBwcmltYXJ5IGFmZmlsaWF0aW9uLCBh bmQgYSBjb250YWN0IHBob25lIG51bWJlciBmb3IgdXNlIGlmIHlvdSdyZSBzZWxlY3RlZC4NCg0K VGhhbmtzLCANCg0KQWxsaXNvbiBNYW5raW4NCk5vbWNvbSAyMDEzIENoYWlyDQoNCg0KMSBKb2hu IFNjdWRkZXINCjIgU3RlcGhlbiBIYW5uYQ0KMyBXYXNzaW0gSGFkZGFkDQo0IFJ1c3MgV2hpdGUN CjUgU3RlcGhhbiBXZW5nZXINCjYgWkhBTyBZaQ0KNyBFcmljIEdyYXkNCjggU3RldmUgS2VudA0K OSBUb2VybGVzcyBFY2tlcnQNCjEwIEFsaWEgQXRsYXMNCjExIFZpY3RvciBLdWFyc2luZ2gNCjEy IFlpemhvdSBMSQ0KMTMgR29uemFsbyBTYWxndWVpcm8NCjE0IEdhbmcgQ0hFTg0KMTUgTmluZyBL T05HDQoxNiBNYXJjZWxvIEJhZ251bG8NCjE3IFNIRU4gU2h1byDmsojng4EgKFNlYW4pDQoxOCBG ZXJuYW5kbyBHb250DQoxOSBHbGVuIFpvcm4NCjIwIFJlaW5hbGRvIFBlbm5vDQoyMSBLbGFhcyBX aWVyZW5nYQ0KMjIgUGFzY2FsIFRodWJlcnQNCjIzIE1laG1ldCBFcnN1ZQ0KMjQgT2xlIFRyb2Fu DQoyNSBKb3VuaSBLb3Job25lbg0KMjYgR2lsZXMgSGVyb24NCjI3IEd1bnRlciBWYW4gZGUgVmVs ZGUNCjI4IEFydHVybyBTZXJ2aW4NCjI5IEVyaWMgVnluY2tlDQozMCBDdWxsZW4gSmVubmluZ3MN CjMxIFRpbmEgVHNvdQ0KMzIgRGhydXYgRGhvZHkNCjMzIEhvbmd5dSBMSSAoSnVsaW8pDQozNCBT Y290dCBNYW5zZmllbGQNCjM1IEpvaG4gRHJha2UNCjM2IEFuZHJldyBNY0xhY2hsYW4NCjM3IERl cmVrIEF0a2lucw0KMzggU3VoYXMgTmFuZGFrdW1hcg0KMzkgRXJpYyBSZXNjb3JsYQ0KNDAgS2Fy ZW4gU2VvDQo0MSBTdGlnIFZlbmFhcw0KNDIgU3RhbiBSYXRsaWZmDQo0MyBJZ25hcyBCYWdkb25h cw0KNDQgUGV0ZXIgWWVlDQo0NSBEb25hbGQgRWFzdGxha2UNCjQ2IFpIT1UgUWlhbiAoQ2F0aHkp DQo0NyBTYW0gSGFydG1hbg0KNDggTGl4aWEgWmhhbmcNCjQ5IFRlZW11IFNhdm9sYWluZW4NCjUw IEFsdmFybyBSZXRhbmENCjUxIFRlcnJ5IE1hbmRlcnNvbg0KNTIgQmlsbCBWZXJTdGVlZw0KNTMg TWVsaW5kYSBTaG9yZQ0KNTQgSUpzYnJhbmQgV2lqbmFuZHMNCjU1IEthcmVuIE8nRG9ub2dodWUN CjU2IEJlbnNvbiBTY2hsaWVzc2VyDQo1NyBBcmkgS2Vyw6RuZW4NCjU4IEZhbmd3ZWkgSFUNCjU5 IE1hY2ggQ0hFTg0KNjAgSHVpIERlbmcNCjYxIExJVSBEYXBlbmcNCjYyIEphYXAgQWtrZXJodWlz DQo2MyBNYWdudXMgV2VzdGVybHVuZA0KNjQgWmVobiBDQU8NCjY1IFphaGVkdXp6YW1hbiBTYXJr ZXINCjY2IEJodW1pcCBLaGFzbmFiaXNoDQo2NyBBbmRyZXcgQ2hpDQo2OCBUaG9tYXMgTmFkZWF1 DQo2OSBTdGV2ZW4gQyAoQ3JhaWcpIFdoaWx0ZQ0KNzAgT3JpdCBMZXZpbg0KNzEgU2FtIEFsZHJp bg0KNzIgUGF1bCBFYmVyc21hbg0KNzMgQ2hyaXN0b3BoZXIgTGlsamVuc3RvbHBlDQo3NCBVbWEg Q2h1bmR1cmkNCjc1IFN1cmVzaCBLcmlzaG5hbg0KNzYgVmFydW4gU2luZ2gNCjc3IFJvbiBCb25p Y2ENCjc4IEJpbGwgKFdpbGxpYW0pIE1hbm5pbmcNCjc5IFJhZGlhIFBlcmxtYW4NCjgwIERhbmll bGUgQ2VjY2FyZWxsaQ0KODEgRGVib3JhaCBCcnVuZ2FyZA0KODIgS29zdGFzIFBlbnRpa291c2lz DQo4MyBHcmVnb3J5IE1pcnNreQ0KODQgRGF2ZSBTaW5pY3JvcGUNCjg1IFRob21hcyBXYWxzaA0K ODYgWmhhb2h1aSAoSmVmZnJleSkgWkhBTkcNCjg3IFhpYW4gWkhBTkcNCjg4IE1hcmsgVG93bnNs ZXkNCjg5IEhhbm5lcyBHcmVkbGVyDQo5MCBCcmlhbiBUcmFtbWVsbA0KOTEgQ2FybG9zIE1hcnRp bmV6DQo5MiBQZXRlciBLb2NoDQo5MyBEYW5pZWwgTWlnYXVsdA0KOTQgWWkgKEFhcm9uKSBEaW5n DQo5NSBNaWNoYWVsIFJpY2hhcmRzb24NCjk2IFNvaGVsIEtoYW4NCjk3IEpvaG4gQnJhZGxleQ0K OTggSHVhaW1vIENoZW4NCjk5IE1hdHRoZXcgQ2FtcGFnbmENCjEwMCBLZWl0aCBEcmFnZQ0KMTAx IENocmlzIEJvd2Vycw0KMTAyIEpha29iIEhlaXR6DQoxMDMgVG9tb2Z1bWkgT2t1Ym8NCjEwNCBF bWlsIEl2b3YNCjEwNSBUaW1vdGh5IEIuIFRlcnJpYmVycnkNCjEwNiBKSUFORyBZdWFubG9uZw0K MTA3IEx1aWdpIElhbm5vbmUNCjEwOCBEYW1pZW4gU2F1Y2V6DQoxMDkgTG91IEJlcmdlcg0KMTEw IFlhbmEgU3RhbWNoZXZhDQoxMTEgT25kxZllaiBTdXLDvQ0KMTEyIE1hcmNpbiBQaWxhcnNraQ0K MTEzIE1pY2hhZWwgU3RKb2hucw0KMTE0IFdlcyBHZW9yZ2UNCjExNSBDaHJpc3RpYW4gTydGbGFo ZXJ0eQ0KMTE2IFV3ZSBSYXVzY2hlbmJhY2gNCjExNyBPbGFmdXIgR3VkbXVuZHNzb24NCjExOCBT aHdldGhhIFN1YnJheSBCaGFuZGFyaSoNCjExOSBUb2JpYXMgR29uZHJvbQ0KMTIwIENocmlzdGVy IEhvbG1iZXJnDQoxMjEgU3VzYW4gSGFyZXMNCjEyMiBLaXJhbiBLdW1hciBDaGl0dGltYW5lbmkN CjEyMyBEb25hbGQgRmVkeWsNCjEyNCBTdGVwaGVuIEJvdHprbyoNCjEyNSBMaSBYdWUqDQoxMjYg Sm9obiBTYXVlcioNCg== From philip.eardley@bt.com Mon Jun 24 07:49:51 2013 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 6DD4421E8178 for ; Mon, 24 Jun 2013 07:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaprZxSxU7OC for ; Mon, 24 Jun 2013 07:49:47 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id B54E121E8170 for ; Mon, 24 Jun 2013 07:49:34 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 24 Jun 2013 15:49:32 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.53]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Mon, 24 Jun 2013 15:49:32 +0100 From: To: , Date: Mon, 24 Jun 2013 15:49:30 +0100 Thread-Topic: Call for contributions and Agenda time in Berlin Thread-Index: Ac5ukbwsnWWTUZX3TBq4VwGNgR/klACUEsiA Message-ID: <9510D26531EF184D9017DF24659BB87F34C53CC7CF@EMV65-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] Call for contributions and Agenda time in Berlin 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, 24 Jun 2013 14:49:51 -0000 These drafts would probably be worth presenting, as it would be the first W= G meeting http://tools.ietf.org/html/draft-eardley-lmap-terminology there are 3 terms listed as "Other potentially useful terminology" (S3.1), = but I don't think we have to resolve whether to include them or not.=20 http://tools.ietf.org/html/draft-eardley-lmap-framework The main thing is that it tries to set the scene for more detailed technica= l contributions.=20 there are a couple of open issues listed in the draft, although I don't thi= nk it's critical to resolve them yet.=20 Best wishes phil > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > MORTON JR., ALFRED C (AL) > Sent: 21 June 2013 16:29 > To: lmap WG > Subject: [lmap] Call for contributions and Agenda time in Berlin >=20 > LMAP, >=20 > Last week, the draft LMAP charter went forward for external review. > LMAP has been approved for a placeholder session at IETF-87, either as > a Working Group if approved in time, or as a BoF if not. > If charter-related issues remain to be resolved, they will be discussed > during the session with highest priority. >=20 > However, ... >=20 > If you have new/revised contributions covered under the current draft > of the LMAP charter, please reply to the list identifying the topic, > the filename(if applicable) and the related issues you would like to > discuss at a face-to-face session, and try to do this by June 28, 2013. >=20 > thanks and regards, > Dan and Al >=20 >=20 >=20 > > -----Original Message----- > > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > > bounces@ietf.org] On Behalf Of The IESG > > Sent: Friday, June 14, 2013 11:42 AM > > To: IETF-Announce > > Cc: lmap WG > > Subject: WG Review: Large-Scale Measurement of Broadband Performance > > (lmap) > > > > A new IETF working group has been proposed in the Operations and > > Management Area. The IESG has not made any determination yet. The > > following draft charter was submitted, and is provided for > > informational purposes only. Please send your comments to the IESG > > mailing list (iesg at ietf.org) by 2013-06-24. > > > > Large-Scale Measurement of Broadband Performance (lmap) > > ------------------------------------------------ > > Current Status: Proposed WG > > > > Assigned Area Director: > > Benoit Claise > >... > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From rachel.huang@huawei.com Fri Jun 28 03:14:18 2013 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 468A221F9C7B for ; Fri, 28 Jun 2013 03:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c6EO8q4DlkH for ; Fri, 28 Jun 2013 03:14:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9A26921F9CAB for ; Fri, 28 Jun 2013 03:13:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUM26307; Fri, 28 Jun 2013 10:13:26 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 28 Jun 2013 11:12:16 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 28 Jun 2013 11:13:03 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Fri, 28 Jun 2013 18:12:57 +0800 From: "Huangyihong (Rachel)" To: "MORTON JR., ALFRED C (AL)" , lmap WG Thread-Topic: Call for contributions and Agenda time in Berlin Thread-Index: Ac5ukbwsnWWTUZX3TBq4VwGNgR/klAFH7G2g Date: Fri, 28 Jun 2013 10:12:55 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB45836126@nkgeml501-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [lmap] Call for contributions and Agenda time in Berlin 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, 28 Jun 2013 10:14:18 -0000 Hi all, I'm new on this list. I have a contribution to discuss a new usage of LMAP= =20 http://tools.ietf.org/html/draft-huang-lmap-data-collection-use-case-00 If anyone is interested in this, I'm happy to present this in the meeting. Best regards, Rachel -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of MOR= TON JR., ALFRED C (AL) Sent: Friday, June 21, 2013 11:29 PM To: lmap WG Subject: [lmap] Call for contributions and Agenda time in Berlin LMAP, Last week, the draft LMAP charter went forward for external review. LMAP has been approved for a placeholder session at IETF-87, either as a Working Group if approved in time, or as a BoF if not. If charter-related issues remain to be resolved, they will be discussed during the session with highest priority. However, ... If you have new/revised contributions covered under the current draft of the LMAP charter, please reply to the list identifying the topic, the filename(if applicable) and the related issues you would like to discus= s at=20 a face-to-face session, and try to do this by June 28, 2013. thanks and regards, Dan and Al > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: Friday, June 14, 2013 11:42 AM > To: IETF-Announce > Cc: lmap WG > Subject: WG Review: Large-Scale Measurement of Broadband Performance > (lmap) >=20 > A new IETF working group has been proposed in the Operations and > Management Area. The IESG has not made any determination yet. The > following draft charter was submitted, and is provided for informational > purposes only. Please send your comments to the IESG mailing list (iesg > at ietf.org) by 2013-06-24. >=20 > Large-Scale Measurement of Broadband Performance (lmap) > ------------------------------------------------ > Current Status: Proposed WG >=20 > Assigned Area Director: > Benoit Claise >... _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From mlinsner@cisco.com Fri Jun 28 05:47:30 2013 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 532E121F9F50 for ; Fri, 28 Jun 2013 05:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuIGhbyOeM3P for ; Fri, 28 Jun 2013 05:47:20 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6589B21F8ADC for ; Fri, 28 Jun 2013 05:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2017; q=dns/txt; s=iport; t=1372423396; x=1373632996; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=xBAcAUKPwikrIJNZUH1+ve2VtmUEWJQv/WQ9pF0Z3tU=; b=MiEoEeETQk9dJUU5fWoAQ1wcgG1midnWDf46K+ryoUQrymwug9b+xDqV iiJghepDLSXSH5x07tRrZCdvPjHUBcQ5/x4cgbU1tpYJ+BAaHrlrFpC2v A/gNewDT8uhYK0uV0JJrK435cBhLZNR1n4Mqayh/KNW1BzEtm6VTlSFwG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFADOEzVGtJV2a/2dsb2JhbABbgmAxSb8KgQaBCYIjAQEBBAEBARodNBcGAQgRAwEBAQsUCS4LFAkIAQEEARIIiAYMszgEjyQGMgaCfGMDqQqDEYIo X-IronPort-AV: E=Sophos;i="4.87,958,1363132800"; d="scan'208";a="228664641" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 28 Jun 2013 12:43:15 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5SChFDL016690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 12:43:15 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.35]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 07:43:15 -0500 From: "Marc Linsner (mlinsner)" To: "MORTON JR., ALFRED C (AL)" , lmap WG Thread-Topic: [lmap] Call for contributions and Agenda time in Berlin Thread-Index: Ac5ukbwsnWWTUZX3TBq4VwGNgR/klAFc7MOA Date: Fri, 28 Jun 2013 12:43:14 +0000 Message-ID: <581E085DEB6A444093CDAEA4C4EE481813575B2D@xmb-rcd-x08.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.195.118] Content-Type: text/plain; charset="us-ascii" Content-ID: <73977536027C634395805F311153B192@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] Call for contributions and Agenda time in Berlin 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, 28 Jun 2013 12:47:30 -0000 Al, I'd like a (short) timeslot for the Use Case draft (update currently in progress). -Marc- -----Original Message----- From: "", "ALFRED C (AL)" Date: Friday, June 21, 2013 11:28 AM To: lmap WG Subject: [lmap] Call for contributions and Agenda time in Berlin >LMAP, > >Last week, the draft LMAP charter went forward for external review. >LMAP has been approved for a placeholder session at IETF-87, >either as a Working Group if approved in time, or as a BoF if not. >If charter-related issues remain to be resolved, they will be >discussed during the session with highest priority. > >However, ... > >If you have new/revised contributions covered under the current >draft of the LMAP charter, please reply to the list identifying the topic, >the filename(if applicable) and the related issues you would like to >discuss at=20 >a face-to-face session, and try to do this by June 28, 2013. > >thanks and regards, >Dan and Al > > > >> -----Original Message----- >> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- >> bounces@ietf.org] On Behalf Of The IESG >> Sent: Friday, June 14, 2013 11:42 AM >> To: IETF-Announce >> Cc: lmap WG >> Subject: WG Review: Large-Scale Measurement of Broadband Performance >> (lmap) >>=20 >> A new IETF working group has been proposed in the Operations and >> Management Area. The IESG has not made any determination yet. The >> following draft charter was submitted, and is provided for informational >> purposes only. Please send your comments to the IESG mailing list (iesg >> at ietf.org) by 2013-06-24. >>=20 >> Large-Scale Measurement of Broadband Performance (lmap) >> ------------------------------------------------ >> Current Status: Proposed WG >>=20 >> Assigned Area Director: >> Benoit Claise >>... >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From Jan.Seedorf@neclab.eu Fri Jun 28 08:09:57 2013 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 D59E221F9A50 for ; Fri, 28 Jun 2013 08:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XM5BC++WPef1 for ; Fri, 28 Jun 2013 08:09:53 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id F401121F8FE5 for ; Fri, 28 Jun 2013 08:08:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id EDDF41047F2; Fri, 28 Jun 2013 17:08:13 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV-LujD9MxdG; Fri, 28 Jun 2013 17:08:13 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id CBADC1047EF; Fri, 28 Jun 2013 17:07:53 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.234]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 28 Jun 2013 17:06:18 +0200 From: Jan Seedorf To: "MORTON JR., ALFRED C (AL)" , lmap WG Thread-Topic: Call for contributions and Agenda time in Berlin Thread-Index: Ac5ukbwsnWWTUZX3TBq4VwGNgR/klAFfNoPA Date: Fri, 28 Jun 2013 15:06:18 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55562C18@DAPHNIS.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.5.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Enrico Marocco , "Vijay K. Gurbani \(vkg@bell-labs.com\)" Subject: Re: [lmap] Call for contributions and Agenda time in Berlin 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, 28 Jun 2013 15:09:58 -0000 Dear Al and Dan, We are currently updating our draft on "using ALTO for Querying LMAP Result= s" (draft-seedorf-lmap-alto). We are adding use cases, and will post the -0= 1 version soon. As discussed in Orlando and at the last BoF, this draft is = not about the core LMAP report protocol from MA to collector, but about how= to make LMAP results available to interested parties at the collector. If = possible, we would be happy to present our ideas again in Berlin to get fee= dback if this is something folks regard as useful or not. Thanks, Jan > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > MORTON JR., ALFRED C (AL) > Sent: Friday, June 21, 2013 5:29 PM > To: lmap WG > Subject: [lmap] Call for contributions and Agenda time in Berlin >=20 > LMAP, >=20 > Last week, the draft LMAP charter went forward for external review. > LMAP has been approved for a placeholder session at IETF-87, > either as a Working Group if approved in time, or as a BoF if not. > If charter-related issues remain to be resolved, they will be > discussed during the session with highest priority. >=20 > However, ... >=20 > If you have new/revised contributions covered under the current > draft of the LMAP charter, please reply to the list identifying the topic= , > the filename(if applicable) and the related issues you would like to disc= uss at > a face-to-face session, and try to do this by June 28, 2013. >=20 > thanks and regards, > Dan and Al >=20 >=20 >=20 > > -----Original Message----- > > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > > bounces@ietf.org] On Behalf Of The IESG > > Sent: Friday, June 14, 2013 11:42 AM > > To: IETF-Announce > > Cc: lmap WG > > Subject: WG Review: Large-Scale Measurement of Broadband > Performance > > (lmap) > > > > A new IETF working group has been proposed in the Operations and > > Management Area. The IESG has not made any determination yet. The > > following draft charter was submitted, and is provided for informationa= l > > purposes only. Please send your comments to the IESG mailing list (iesg > > at ietf.org) by 2013-06-24. > > > > Large-Scale Measurement of Broadband Performance (lmap) > > ------------------------------------------------ > > Current Status: Proposed WG > > > > Assigned Area Director: > > Benoit Claise > >... > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From iesg-secretary@ietf.org Fri Jun 28 09:49:29 2013 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 20FCE21F8584; Fri, 28 Jun 2013 09:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.045 X-Spam-Level: X-Spam-Status: No, score=-102.045 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QRnTkcvWw-V; Fri, 28 Jun 2013 09:49:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DEB21F9A70; Fri, 28 Jun 2013 09:49:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130628164927.29882.71687.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2013 09:49:27 -0700 Cc: lmap WG Subject: [lmap] WG Action: Formed Large-Scale Measurement of Broadband Performance (lmap) 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, 28 Jun 2013 16:49:29 -0000 A new IETF working group has been formed in the Operations and Management Area. For additional information please contact the Area Directors or the WG Chair. Large-Scale Measurement of Broadband Performance (lmap) ------------------------------------------------ Current Status: Proposed WG Chair: Dan Romascanu Assigned Area Director: Benoit Claise Mailing list Address: lmap@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/lmap Archive: http://www.ietf.org/mail-archive/web/lmap Charter: The Large-Scale Measurement of Broadband Performance (LMAP) working group standardizes the LMAP measurement system for performance measurements of broadband access devices such as home and enterprise edge routers, personal computers, mobile devices, set top box, whether wired or wireless. Measuring portions of the Internet on a large scale is essential for accurate characterizations of performance over time and geography, for network diagnostic investigations by providers and their users, and for collecting information to support public policy development. The goal is to have the measurements (made using the same metrics and mechanisms) for a large number of points on the Internet, and to have the results collected and stored in the same form. The LMAP working group is chartered to specify an information model, the associated data models, and select/extend one or more protocols for the secure communication: 1. A Control Protocol, from a Controller to instruct Measurement Agents what performance metrics to measure, when to measure them, how/when to report the measurement results to a Collector, 2. A Report Protocol, for a Measurement Agent to report the results to the Collector. The data models should be extensible for new and additional measurements. LMAP will consider re-use of existing data models languages. A key assumption constraining the initial work is that the measurement system is under the control of a single organization (for example, an Internet Service Provider or a regulator). However, the components of an LMAP measurement system can be deployed in administrative domains that are not owned by the measuring organization. Thus, the system of functions deployed by a single organization constitutes a single LMAP domain which may span ownership or other administrative boundaries. The LMAP architecture will allow for measurements that utilize either IPv4 or IPv6, or possibly both. Devices containing Measurement Agents may have several interfaces using different link technologies. Multiple address families and interfaces must be considered in the Control and Report protocols. It is assumed that different organization's LMAP measurement domains can overlap, and that active measurement packets appear along with normal user traffic when crossing another organization's network. There is no requirement to specify a mechanism for coordination between the LMAP measurements in overlapping domains (for instance a home network with MAs on the home gateway, set top box and laptop). In principle, there are no restrictions on the type of device in which the MA function resides. Both active and passive measurements are in scope, although there may be differences in their applicability to specific use cases, or in the security measures needed according to the threats specific to each measurement category. LMAP will not standardize performance metrics. The LMAP WG will consider privacy as a core requirement and will ensure that by default measurement and collection mechanisms and protocols standardized operate in a privacy-sensitive manner, for example, ensuring that measurements are not personally identifying except where permission for such has been granted by identified subjects. Note that this does not mean that all uses of LMAP need to turn on all privacy features but it does mean that privacy features do need to be at least well-defined. Standardizing control of end users Measurement Agents is out of scope. However, end users can obtain an MA to run measurement tasks if desired and report their results to whomever they want, most likely the supplier of the MA. This provides for user-initiated on-demand measurement, which is an important component of the ISP use case. Inter-organization communication of results is out of scope of the LMAP charter. The management protocol to bootstrap the MAs in measurement devices is out of scope of the LMAP charter. Service parameters, such as product category, can be useful to decide which measurements to run and how to interpret the results. These parameters are already gathered and stored by existing operations systems. Discovering the service parameters on the MAs or sharing the service parameters between MAs are out of the scope. However, if the service parameters are available to the MAs, they could be reported with the measurement results in the Report Protocol. Deciding the set of measurements to run is a business decision and is out of scope of the LMAP charter. Protection against the intentional or malicious insertion of inaccuracies into the overall system or measurement process (sometimes known as "gaming the system") is outside the scope of work. The LMAP working group will coordinate with other standards bodies working in this area (e.g., BBF, IEEE 802.16, ETSI) regarding the information model, and with other IETF working groups in the areas of data models, protocols, multiple interface management, and measurement of performance metrics. The LMAP WG will produce the following work items: 1. The LMAP Framework - provides common terminology, basic architecture elements, and justifies the simplifying constraints 2. The LMAP Use Cases - provides the motivating use cases as a basis for the work 3. Information Model, the abstract definition of the information carried from the Controller to the MA and the information carried from the MA to the Collector. It includes * The metric(s) that can be measured and values for its parameters such as the Peer MA participating in the measurement and the desired environmental conditions (for example, only conduct the measurement when there is no user traffic observed) * The schedule: when the measurement should be run and how the results should be reported (when and to which Collector) * The report: the metric(s) measured and when, the actual result, and supporting metadata such as location. Result reports may be organized in batches or may be reported immediately, such as for an on-demand measurement. 4. The Control protocol and the associated data model: The definition of how instructions are delivered from a Controller to a MA; this includes a Data Model consistent with the Information Model plus a transport protocol. This may be a simple instruction - response protocol, and LMAP will specify how it operates over an existing protocol (to be selected, perhaps REST-style HTTP(s) or NETCONF). 5. The Report protocol and the associated data model: The definition of how the Report is delivered from a MA to a Collector; this includes a Data Model consistent with the Information Model plus a transport protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). Milestones: Sep 2013 - Initial WG I-D for the LMAP Framework including terminology Sep 2013 - Initial WG I-D for the LMAP Use cases Dec 2013 - Submit the LMAP Framework I-D to the IESG for consideration as Informational RFC Dec 2013 - Submit I-D on the LMAP Use cases to the IESG for consideration as Informational RFC Jan 2014 - Initial WG I-D for LMAP Information models Apr 2014 - Initial WG I-D for the Control protocol Apr 2014 - Initial WG I-D for the Report protocol Apr 2014 - Initial WG I-D for a Data model for LMAP control information Apr 2014 - Initial WG I-D for a Data model for LMAP report information Jul 2014 - Submit the LMAP Information models I-D to the IESG for consideration as Standards track RFC Dec 2014 - Submit the Control protocol I-D to the IESG for consideration as Standards track RFC Dec 2014 - Submit the Report protocol I-D to the IESG for consideration as Standards track RFC Dec 2014 - Submit the Data model for LMAP control I-D to the IESG for consideration as Standards track RFC Dec 2014 - Submit the Data model for LMAP report I-D to the IESG for consideration as Standards track RFC From trevor.burbridge@bt.com Fri Jun 28 10:06:44 2013 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 CB60321F9BF4 for ; Fri, 28 Jun 2013 10:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDebAHvXyIxu for ; Fri, 28 Jun 2013 10:06:40 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8C821F9C05 for ; Fri, 28 Jun 2013 10:06:37 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 28 Jun 2013 18:06:25 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.85]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Fri, 28 Jun 2013 18:06:25 +0100 From: To: , Date: Fri, 28 Jun 2013 18:06:24 +0100 Thread-Topic: Call for contributions and Agenda time in Berlin Thread-Index: Ac5ukbwsnWWTUZX3TBq4VwGNgR/klAFjyyww Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] Call for contributions and Agenda time in Berlin 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, 28 Jun 2013 17:06:44 -0000 We will be submitting a draft next week on the Information Model for LMAP (= draft-burbridge-lmap-information-model-00 forthcoming). It would be good to have a slot to present this and discuss the information= that is necessary to pass to/from the Measurement Agents. This will enable= us to make good progress on revisions on the list for this early deliverab= le and frame discussions on any protocols/commands/interfaces. Thanks, Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000=20 >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >MORTON JR., ALFRED C (AL) >Sent: 21 June 2013 16:29 >To: lmap WG >Subject: [lmap] Call for contributions and Agenda time in Berlin > >LMAP, > >Last week, the draft LMAP charter went forward for external review. >LMAP has been approved for a placeholder session at IETF-87, >either as a Working Group if approved in time, or as a BoF if not. >If charter-related issues remain to be resolved, they will be >discussed during the session with highest priority. > >However, ... > >If you have new/revised contributions covered under the current >draft of the LMAP charter, please reply to the list identifying the topic, >the filename(if applicable) and the related issues you would like to discu= ss at >a face-to-face session, and try to do this by June 28, 2013. > >thanks and regards, >Dan and Al > > > >> -----Original Message----- >> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- >> bounces@ietf.org] On Behalf Of The IESG >> Sent: Friday, June 14, 2013 11:42 AM >> To: IETF-Announce >> Cc: lmap WG >> Subject: WG Review: Large-Scale Measurement of Broadband Performance >> (lmap) >> >> A new IETF working group has been proposed in the Operations and >> Management Area. The IESG has not made any determination yet. The >> following draft charter was submitted, and is provided for informational >> purposes only. Please send your comments to the IESG mailing list (iesg >> at ietf.org) by 2013-06-24. >> >> Large-Scale Measurement of Broadband Performance (lmap) >> ------------------------------------------------ >> Current Status: Proposed WG >> >> Assigned Area Director: >> Benoit Claise >>... >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From bclaise@cisco.com Fri Jun 28 12:05:25 2013 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 C38F221F9C7B for ; Fri, 28 Jun 2013 12:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.95 X-Spam-Level: X-Spam-Status: No, score=-7.95 tagged_above=-999 required=5 tests=[AWL=2.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pbfe+cdkjuCv for ; Fri, 28 Jun 2013 12:05:21 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFFA21F9C69 for ; Fri, 28 Jun 2013 12:05:21 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5SJ5K92013448 for ; Fri, 28 Jun 2013 15:05:20 -0400 (EDT) Received: from [10.21.82.30] (sjc-vpn4-542.cisco.com [10.21.82.30]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r5SJ5IH9019709 for ; Fri, 28 Jun 2013 12:05:18 -0700 (PDT) Message-ID: <51CDDE6E.7050309@cisco.com> Date: Fri, 28 Jun 2013 12:05:18 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: lmap WG References: <20130628164927.29882.71687.idtracker@ietfa.amsl.com> In-Reply-To: <20130628164927.29882.71687.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lmap] WG Action: Formed Large-Scale Measurement of Broadband Performance (lmap) 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, 28 Jun 2013 19:05:25 -0000 Dear all, This WG is now approved. Let the fun (and the work) begin. Many thanks to a couple of people. First of all, to Henning (and others) for the introduction of this important work to the IETF. Then, to Al Morton and Dan Romascanu for running an excellent BoF. As recognized by some IESG and IAB members: kudos on the BoF preparation, the BoF session management, and helping in the WG creation Finally, thanks again to Dan, who accepted to become a LMAP chair. Note: Joel and I are currently working on the second chair selection. Regards, Benoit > A new IETF working group has been formed in the Operations and Management > Area. For additional information please contact the Area Directors or the > WG Chair. > > Large-Scale Measurement of Broadband Performance (lmap) > ------------------------------------------------ > Current Status: Proposed WG > > Chair: > Dan Romascanu > > Assigned Area Director: > Benoit Claise > > Mailing list > Address: lmap@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/lmap > Archive: http://www.ietf.org/mail-archive/web/lmap > > Charter: > > The Large-Scale Measurement of Broadband Performance (LMAP) working group > standardizes the LMAP measurement system for performance measurements of > broadband access devices such as home and enterprise edge routers, > personal computers, mobile devices, set top box, whether wired or > wireless. > > Measuring portions of the Internet on a large scale is essential for > accurate characterizations of performance over time and geography, for > network diagnostic investigations by providers and their users, and for > collecting information to support public policy development. The goal is > to have the measurements (made using the same metrics and mechanisms) > for a large number of points on the Internet, and to have the results > collected and stored in the same form. > > The LMAP working group is chartered to specify an information model, the > associated data models, and select/extend one or more protocols for the > secure communication: > 1. A Control Protocol, from a Controller to instruct Measurement Agents > what performance metrics to measure, when to measure them, how/when to > report the measurement results to a Collector, > 2. A Report Protocol, for a Measurement Agent to report the results to > the Collector. > The data models should be extensible for new and additional measurements. > LMAP will consider re-use of existing data models languages. > > A key assumption constraining the initial work is that the measurement > system is under the control of a single organization (for example, an > Internet Service Provider or a regulator). However, the components of an > LMAP measurement system can be deployed in administrative domains that > are not owned by the measuring organization. Thus, the system of > functions deployed by a single organization constitutes a single LMAP > domain which may span ownership or other administrative boundaries. > > The LMAP architecture will allow for measurements that utilize either > IPv4 or IPv6, or possibly both. Devices containing Measurement Agents may > have several interfaces using different link technologies. Multiple > address families and interfaces must be considered in the Control and > Report protocols. > > It is assumed that different organization's LMAP measurement domains can > overlap, and that active measurement packets appear along with normal > user traffic when crossing another organization's network. There is no > requirement to specify a mechanism for coordination between the LMAP > measurements in overlapping domains (for instance a home network with MAs > on the home gateway, set top box and laptop). In principle, there are no > restrictions on the type of device in which the MA function resides. > > Both active and passive measurements are in scope, although there may be > differences in their applicability to specific use cases, or in the > security measures needed according to the threats specific to each > measurement category. LMAP will not standardize performance metrics. > > The LMAP WG will consider privacy as a core requirement and will ensure > that by default measurement and collection mechanisms and protocols > standardized operate in a privacy-sensitive manner, for example, > ensuring that measurements are not personally identifying except where > permission for such has been granted by identified subjects. Note that > this does not mean that all uses of LMAP need to turn on all privacy > features but it does mean that privacy features do need to be at least > well-defined. > > Standardizing control of end users Measurement Agents is out of scope. > However, end users can obtain an MA to run measurement tasks if desired > and report their results to whomever they want, most likely the supplier > of the MA. This provides for user-initiated on-demand measurement, which > is an important component of the ISP use case. > > Inter-organization communication of results is out of scope of the LMAP > charter. > > The management protocol to bootstrap the MAs in measurement devices is > out of scope of the LMAP charter. > > Service parameters, such as product category, can be useful to decide > which measurements to run and how to interpret the results. These > parameters are already gathered and stored by existing operations > systems. > Discovering the service parameters on the MAs or sharing the service > parameters between MAs are out of the scope. However, if the service > parameters are available to the MAs, they could be reported with the > measurement results in the Report Protocol. > > Deciding the set of measurements to run is a business decision and is out > of scope of the LMAP charter. > > Protection against the intentional or malicious insertion of inaccuracies > into the overall system or measurement process (sometimes known as > "gaming the system") is outside the scope of work. > > The LMAP working group will coordinate with other standards bodies > working in this area (e.g., BBF, IEEE 802.16, ETSI) regarding the > information model, and with other IETF working groups in the areas of > data models, protocols, multiple interface management, and measurement of > performance metrics. > > The LMAP WG will produce the following work items: > > 1. The LMAP Framework - provides common terminology, basic architecture > elements, and justifies the simplifying constraints > 2. The LMAP Use Cases - provides the motivating use cases as a basis for > the work > 3. Information Model, the abstract definition of the information carried > from the Controller to the MA and the information carried from the MA to > the Collector. It includes > * The metric(s) that can be measured and values for its parameters > such as the Peer MA participating in the measurement and the desired > environmental conditions (for example, only conduct the measurement when > there is no user traffic observed) > * The schedule: when the measurement should be run and how the results > should be reported (when and to which Collector) > * The report: the metric(s) measured and when, the actual result, and > supporting metadata such as location. Result reports may be organized in > batches or may be reported immediately, such as for an on-demand > measurement. > 4. The Control protocol and the associated data model: The definition of > how instructions are delivered from a Controller to a MA; this includes a > Data Model consistent with the Information Model plus a transport > protocol. This may be a simple instruction - response protocol, and LMAP > will specify how it operates over an existing protocol (to be selected, > perhaps REST-style HTTP(s) or NETCONF). > 5. The Report protocol and the associated data model: The definition of > how the Report is delivered from a MA to a Collector; this includes a > Data Model consistent with the Information Model plus a transport > protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). > > > Milestones: > Sep 2013 - Initial WG I-D for the LMAP Framework including terminology > Sep 2013 - Initial WG I-D for the LMAP Use cases > Dec 2013 - Submit the LMAP Framework I-D to the IESG for consideration > as Informational RFC > Dec 2013 - Submit I-D on the LMAP Use cases to the IESG for > consideration as Informational RFC > Jan 2014 - Initial WG I-D for LMAP Information models > Apr 2014 - Initial WG I-D for the Control protocol > Apr 2014 - Initial WG I-D for the Report protocol > Apr 2014 - Initial WG I-D for a Data model for LMAP control information > Apr 2014 - Initial WG I-D for a Data model for LMAP report information > Jul 2014 - Submit the LMAP Information models I-D to the IESG for > consideration as Standards track RFC > Dec 2014 - Submit the Control protocol I-D to the IESG for > consideration as Standards track RFC > Dec 2014 - Submit the Report protocol I-D to the IESG for consideration > as Standards track RFC > Dec 2014 - Submit the Data model for LMAP control I-D to the IESG for > consideration as Standards track RFC > Dec 2014 - Submit the Data model for LMAP report I-D to the IESG for > consideration as Standards track RFC > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > >