From nobody Wed Apr 1 03:19:48 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746FA1A1B60 for ; Wed, 1 Apr 2015 03:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T3ct6jta7-O for ; Wed, 1 Apr 2015 03:19:45 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4881A1A59 for ; Wed, 1 Apr 2015 03:19:42 -0700 (PDT) Received: from EVMHT02-UKBR.domain1.systemhost.net (193.113.108.43) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Apr 2015 11:19:36 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EVMHT02-UKBR.domain1.systemhost.net (193.113.108.43) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 1 Apr 2015 11:19:39 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 1 Apr 2015 11:19:38 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Wed, 1 Apr 2015 11:19:38 +0100 From: To: Thread-Topic: [lmap] Reporting of service parameters Thread-Index: AdBrsDSzqH/iw2m1Sz2op8ywjfqKsQAECBwAACk7xDA= Date: Wed, 1 Apr 2015 10:19:37 +0000 Message-ID: <8cdcabfce01b49d29432fc57626f4acb@rew09926dag03b.domain1.systemhost.net> References: <20150331153820.GA71628@elstar.local> In-Reply-To: <20150331153820.GA71628@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] Reporting of service parameters X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 10:19:47 -0000 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: 31 March 2015 16:38 > To: Eardley,PL,Philip,TUB8 R > Cc: lmap@ietf.org > Subject: Re: [lmap] Reporting of service parameters >=20 > On Tue, Mar 31, 2015 at 12:49:34PM +0000, philip.eardley@bt.com wrote: > > There was some discussion during the LMAP meeting about the reporting > of service parameters by the MA. > > This is indeed covered by the framework > > http://tools.ietf.org/html/draft-ietf-lmap-framework-12#section-5.4.1 > > > > this sub-section is called "Reporting of Subscriber's service > parameters". > > "The Subscriber's service parameters are information about his/her > broadband contract, line rate and so on." > > > > I think from the discussion that this is slightly narrow - we > mentioned things other than Subscriber's service parameters. So I > suggest we add a sentence on the lines: > > > > Similarly the MA could report service parameters about the device > with the MA, such as its access interface or location. > > > > Assuming people are OK (please say if not), we can add this at the > same time as handling the IESG comments > > >=20 > Where do you want to add this sentence? I was thinking, at the end of Section 5.4.1.=20 >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Apr 1 03:32:33 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AAA1A8A65 for ; Wed, 1 Apr 2015 03:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c11Skcc-9l5n for ; Wed, 1 Apr 2015 03:32:30 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B831A1B44 for ; Wed, 1 Apr 2015 03:32:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F22B011DE; Wed, 1 Apr 2015 12:32:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id CxacLWZ8TQdA; Wed, 1 Apr 2015 12:32:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Apr 2015 12:32:27 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E591A2002B; Wed, 1 Apr 2015 12:32:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id oHSzK_l7-6S9; Wed, 1 Apr 2015 12:32:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E62A20013; Wed, 1 Apr 2015 12:32:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 33A50329C0DB; Wed, 1 Apr 2015 12:32:22 +0200 (CEST) Date: Wed, 1 Apr 2015 12:32:21 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20150401103219.GA74042@elstar.local> Mail-Followup-To: philip.eardley@bt.com, lmap@ietf.org References: <20150331153820.GA71628@elstar.local> <8cdcabfce01b49d29432fc57626f4acb@rew09926dag03b.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cdcabfce01b49d29432fc57626f4acb@rew09926dag03b.domain1.systemhost.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] Reporting of service parameters X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 10:32:32 -0000 Sorry, I did not even understand that this is a proposed update of the framework document. Anyway, the proposal seems to be to add Similarly the MA could report service parameters about the device with the MA, such as its access interface or location. at the end of 5.4.1. Now, it is not clear to me which proplem is solved with this. Section 5.4.1 starts with: The Subscriber's service parameters are information about his/her broadband contract, line rate and so on. So are we going to make a distinction between 'subscriber's service parameters' and 'device service parameters'? Or is the issue that the definition of subscriber's service parameters should be more detailed? In that case, would changing the first sentence not do better? The Subscriber's service parameters are information about his/her broadband contract, line rate, access interface, location and so on. I am actually not sure a change is needed in the framework based on the WG meeting discussions. /js On Wed, Apr 01, 2015 at 10:19:37AM +0000, philip.eardley@bt.com wrote: > > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: 31 March 2015 16:38 > > To: Eardley,PL,Philip,TUB8 R > > Cc: lmap@ietf.org > > Subject: Re: [lmap] Reporting of service parameters > > > > On Tue, Mar 31, 2015 at 12:49:34PM +0000, philip.eardley@bt.com wrote: > > > There was some discussion during the LMAP meeting about the reporting > > of service parameters by the MA. > > > This is indeed covered by the framework > > > http://tools.ietf.org/html/draft-ietf-lmap-framework-12#section-5.4.1 > > > > > > this sub-section is called "Reporting of Subscriber's service > > parameters". > > > "The Subscriber's service parameters are information about his/her > > broadband contract, line rate and so on." > > > > > > I think from the discussion that this is slightly narrow - we > > mentioned things other than Subscriber's service parameters. So I > > suggest we add a sentence on the lines: > > > > > > Similarly the MA could report service parameters about the device > > with the MA, such as its access interface or location. > > > > > > Assuming people are OK (please say if not), we can add this at the > > same time as handling the IESG comments > > > > > > > Where do you want to add this sentence? > > I was thinking, at the end of Section 5.4.1. > > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Apr 2 05:29:33 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0971A89FF for ; Thu, 2 Apr 2015 05:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2SuxC4_5m4Z for ; Thu, 2 Apr 2015 05:29:30 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E58D1A1B05 for ; Thu, 2 Apr 2015 05:29:29 -0700 (PDT) Received: from EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 2 Apr 2015 13:29:17 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 2 Apr 2015 13:29:21 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 2 Apr 2015 13:29:20 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Thu, 2 Apr 2015 13:29:20 +0100 From: To: Thread-Topic: [lmap] Reporting of service parameters Thread-Index: AdBrsDSzqH/iw2m1Sz2op8ywjfqKsQAECBwAACk7xDD///L5gP/+PGEQ Date: Thu, 2 Apr 2015 12:29:19 +0000 Message-ID: <9f37fcd0217f4977afa40d16bc6d1798@rew09926dag03b.domain1.systemhost.net> References: <20150331153820.GA71628@elstar.local> <8cdcabfce01b49d29432fc57626f4acb@rew09926dag03b.domain1.systemhost.net> <20150401103219.GA74042@elstar.local> In-Reply-To: <20150401103219.GA74042@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] Reporting of service parameters X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 12:29:32 -0000 > I am actually not sure a change is needed in the framework based on the > WG meeting discussions. Ok, I won't change it.=20 phil >=20 > /js >=20 > On Wed, Apr 01, 2015 at 10:19:37AM +0000, philip.eardley@bt.com wrote: > > > > > > > -----Original Message----- > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: 31 March 2015 16:38 > > > To: Eardley,PL,Philip,TUB8 R > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] Reporting of service parameters > > > > > > On Tue, Mar 31, 2015 at 12:49:34PM +0000, philip.eardley@bt.com > wrote: > > > > There was some discussion during the LMAP meeting about the > > > > reporting > > > of service parameters by the MA. > > > > This is indeed covered by the framework > > > > http://tools.ietf.org/html/draft-ietf-lmap-framework-12#section- > 5. > > > > 4.1 > > > > > > > > this sub-section is called "Reporting of Subscriber's service > > > parameters". > > > > "The Subscriber's service parameters are information about > his/her > > > broadband contract, line rate and so on." > > > > > > > > I think from the discussion that this is slightly narrow - we > > > mentioned things other than Subscriber's service parameters. So I > > > suggest we add a sentence on the lines: > > > > > > > > Similarly the MA could report service parameters about the device > > > with the MA, such as its access interface or location. > > > > > > > > Assuming people are OK (please say if not), we can add this at > the > > > same time as handling the IESG comments > > > > > > > > > > Where do you want to add this sentence? > > > > I was thinking, at the end of Section 5.4.1. > > > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Apr 2 06:42:40 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32831A8F3C for ; Thu, 2 Apr 2015 06:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5xD3YSLH0Zg for ; Thu, 2 Apr 2015 06:42:27 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA4D1A0161 for ; Thu, 2 Apr 2015 06:42:27 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 3474d155.2b53c4e5a940.616344.00-2415.1740258.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 02 Apr 2015 13:42:27 +0000 (UTC) X-MXL-Hash: 551d47435e26b5c6-98e2e035413ca8f7b05918f3c654c305951bfe97 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id f374d155.0.616310.00-2389.1740152.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 02 Apr 2015 13:42:25 +0000 (UTC) X-MXL-Hash: 551d474174393501-bb0abca203781eb5aedf060e1c4260efb13f04e4 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t32DgNnR012243; Thu, 2 Apr 2015 09:42:23 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t32DgFAw012125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Apr 2015 09:42:16 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 2 Apr 2015 13:42:02 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.35]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0224.002; Thu, 2 Apr 2015 09:42:01 -0400 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [lmap] Reporting of service parameters Thread-Index: AdBrsDSzqH/iw2m1Sz2op8ywjfqKsQAOglEAACcpDoAAAHHYgAA2YF6AAAY3m4A= Date: Thu, 2 Apr 2015 13:42:00 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130F9AC28@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20150331153820.GA71628@elstar.local> <8cdcabfce01b49d29432fc57626f4acb@rew09926dag03b.domain1.systemhost.net> <20150401103219.GA74042@elstar.local> <9f37fcd0217f4977afa40d16bc6d1798@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <9f37fcd0217f4977afa40d16bc6d1798@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.192.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Kq36LxqN c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=eEI6JNMSksQA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=e9J7MTPGsLIA:10 a=kkEB9DNyJ] X-AnalysisOut: [tr9wI88SoMA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Reporting of service parameters X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 13:42:37 -0000 > > I am actually not sure a change is needed in the framework based on > > the WG meeting discussions. >=20 > Ok, I won't change it. I think that's fine. After the F2F meeting, I thought some more about this,= and think that probably what we really need are some simple holistic examp= les that get documented somewhere (but not framework). For some measurement= method, create example registry entries (including for the "environmental = / service attribute parameter" "measurement method" -- which would likely n= ot be included in the IANA registry), tasks (including tasks for collecting= environmental parameters), and schedules. I think until such an example ex= ists it's going to continue to be hard to explain to people who keep asking= about these environmental parameters. A sentence added to framework or inf= ormation-model just isn't going to help. Barbara From nobody Tue Apr 7 02:41:16 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727251B33AD for ; Tue, 7 Apr 2015 02:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dpZF191f-AO for ; Tue, 7 Apr 2015 02:41:13 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874261B33BB for ; Tue, 7 Apr 2015 02:41:13 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 59F22F7D for ; Tue, 7 Apr 2015 11:41:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4n8NMXlswjAu for ; Tue, 7 Apr 2015 11:41:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 7 Apr 2015 11:41:11 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 681482002C for ; Tue, 7 Apr 2015 11:41:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DdmLseAbuZay for ; Tue, 7 Apr 2015 11:41:10 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas04.jacobs.jacobs-university.de [10.70.0.154]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 0EC9820013 for ; Tue, 7 Apr 2015 11:41:10 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS04.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0224.002; Tue, 7 Apr 2015 11:41:09 +0200 From: "Bajpai, Vaibhav" To: "" Thread-Topic: survey on large-scale measurement platforms and related standards Thread-Index: AQHQcRb5C7lxPcsRuEmOigXO7Tx9Ww== Date: Tue, 7 Apr 2015 09:41:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.50.203.30] Content-Type: multipart/signed; boundary="Apple-Mail=_63BB8168-BE2E-41C7-AD96-DCD2315F5898"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: "Bajpai, Vaibhav" Subject: [lmap] survey on large-scale measurement platforms and related standards X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 09:41:15 -0000 --Apple-Mail=_63BB8168-BE2E-41C7-AD96-DCD2315F5898 X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear LMAP WG, I would like to share something with you today. As you know, early discussions within the IETF LMAP working group often = lead to folks asking for feature sets and possibilities of each contemporary performance measurement platform. So I started digging literature work = in this space and found that although there were surveys on topology-based measurement platforms (such CAIDA Ark et al.); literature work on = performance measurement platforms (such as SamKnows, RIPE Atlas et al.) was missing. Therefore, I started writing such a survey in 2013 to plug this gap and also complement this with a summary of IETF standardization efforts = happening within the LMAP and IPPM working groups. This work got published and came online this week. I thought I would share this with you: = ----------------8<-----------------8<-----------------8<-----------------8= < A Survey on Internet Performance Measurement Platforms and Related = Standardization Efforts Vaibhav Bajpai, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder IEEE Communications Surveys & Tutorials April, 2015 A number of Internet measurement platforms have emerged in the last few = years. These platforms have deployed thousands of probes at strategic locations within access and backbone networks and behind residential gateways. In = this paper we provide a taxonomy of these measurement platforms on the basis = of their deployment use-case. We describe these platforms in detail by = exploring their coverage, scale, lifetime, deployed metrics and measurement tools, architecture and overall research impact. We conclude the survey by = describing current standardization efforts to make large-scale performance = measurement platforms interoperable. DOI: http://dx.doi.org/10.1109/COMST.2015.2418435 Author Copy: = http://vaibhavbajpai.com/documents/papers/proceedings/lsmp-comst-2015.pdf = ----------------8<-----------------8<-----------------8<-----------------8= < Thanks! Best, Vaibhav =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Vaibhav Bajpai Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --Apple-Mail=_63BB8168-BE2E-41C7-AD96-DCD2315F5898 X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVI6Y0AAoJEHR3XKwTWKOZR4MH/3s1UPaoox2JLGy6Df7LT7pY 9USfoeYd6kPfDmQAgsaBJrYtr9bL48IK6c1XT/9bFmTX1UUftovjtjCTIXr1xZow +kq1DMiOngW9sGq9q6DAjxr8sBznBy0KJOIAcP0eM5fWSzhLNgcToWtVdvNvuAu6 YfSHV0RIVObRJCCGVCSdihm9D7lpFdwShHU+7Z04CJ9QDcYer0Tc/6TrdddMLbTN xwBHR1uV/BTSwdKXzeTNUflNxqBtlpgjM5HSfPYqm4TeiRDA3rrSXthuqLoW/IsM FITPuOrFryeWPE9TG3zyWFdni7n4bgXzlNGvoyulRshPiEI2V5w3tkTApCW+4Tw= =1ACq -----END PGP SIGNATURE----- --Apple-Mail=_63BB8168-BE2E-41C7-AD96-DCD2315F5898-- From nobody Tue Apr 7 08:11:26 2015 Return-Path: X-Original-To: expand-draft-ietf-lmap-framework.all@virtual.ietf.org Delivered-To: lmap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 648EA1B3258; Tue, 7 Apr 2015 00:10:29 -0700 (PDT) X-Original-To: xfilter-draft-ietf-lmap-framework.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lmap-framework.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420751B3250 for ; Tue, 7 Apr 2015 00:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlCGPBA7sauL for ; Tue, 7 Apr 2015 00:10:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCB21B3256 for ; Tue, 7 Apr 2015 00:10:28 -0700 (PDT) Received: from atlas3.jacobs-university.de ([212.201.44.18]:43409) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfNeU-0001Uk-Sm for draft-ietf-lmap-framework.all@tools.ietf.org; Tue, 07 Apr 2015 00:10:28 -0700 Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 766AD764; Tue, 7 Apr 2015 09:10:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zBi30FvCO0Ye; Tue, 7 Apr 2015 09:10:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 7 Apr 2015 09:10:21 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9649B2002B; Tue, 7 Apr 2015 09:10:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JE9WkdJQDA03; Tue, 7 Apr 2015 09:10:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 60DA120013; Tue, 7 Apr 2015 09:10:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EF63B32B5DDB; Tue, 7 Apr 2015 09:10:18 +0200 (CEST) Date: Tue, 7 Apr 2015 09:10:18 +0200 From: Juergen Schoenwaelder To: Sarah Banks Message-ID: <20150407071018.GA7019@elstar.local> Mail-Followup-To: Sarah Banks , draft-ietf-lmap-framework.all@tools.ietf.org, "" References: <9B2DF3E2-7215-43EE-9702-AE7B501497B6@encrypted.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B2DF3E2-7215-43EE-9702-AE7B501497B6@encrypted.net> User-Agent: Mutt/1.4.2.3i X-SA-Exim-Connect-IP: 212.201.44.18 X-SA-Exim-Rcpt-To: draft-ietf-lmap-framework.all@tools.ietf.org X-SA-Exim-Mail-From: j.schoenwaelder@jacobs-university.de X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-lmap-framework.all@ietf.org Resent-Message-Id: <20150407071028.5BCB21B3256@ietfa.amsl.com> Resent-Date: Tue, 7 Apr 2015 00:10:28 -0700 (PDT) Resent-From: j.schoenwaelder@jacobs-university.de Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 08:11:24 -0700 Cc: draft-ietf-lmap-framework.all@tools.ietf.org, "" Subject: Re: [lmap] [OPS-DIR] Review of draft-ietf-lmap-framework-12 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 07:10:29 -0000 On Mon, Apr 06, 2015 at 01:43:01PM -0700, Sarah Banks wrote: > > I did, however, find the lack of normative language distracting, particularly in the face of the considerable security/privacy considerations conversation. If security and privacy are a base requirement, why is there no normative language to that end? As written, it seems completely wide open to the implementation - and maybe this is true even if there is normative language), and I think the document would be well served to consider modification to include normative language. > This is a framework document and as such there is nothing normative to be implemented. Other documents will follow that provide concrete protocol definitions to be implemented. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 7 08:11:45 2015 Return-Path: X-Original-To: expand-draft-ietf-lmap-framework.all@virtual.ietf.org Delivered-To: lmap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0C9AF1A916A; Mon, 6 Apr 2015 13:43:28 -0700 (PDT) X-Original-To: xfilter-draft-ietf-lmap-framework.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lmap-framework.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E189D1A9164 for ; Mon, 6 Apr 2015 13:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_iqbIABv6CP for ; Mon, 6 Apr 2015 13:43:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392761A9166 for ; Mon, 6 Apr 2015 13:43:27 -0700 (PDT) Received: from firefly.encrypted.net ([72.13.81.186]:35928 ident=postfix) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfDri-0007AX-5Z for draft-ietf-lmap-framework.all@tools.ietf.org; Mon, 06 Apr 2015 13:43:27 -0700 Received: from firefly.encrypted.net (localhost [127.0.0.1]) by firefly.encrypted.net (Postfix) with ESMTP id C47434AD88; Mon, 6 Apr 2015 13:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at encrypted.net Received: from firefly.encrypted.net ([127.0.0.1]) by firefly.encrypted.net (firefly.encrypted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygXd9s7x1ZGT; Mon, 6 Apr 2015 13:42:56 -0700 (PDT) Received: from divinaair.global.tektronix.net (66-7-254-66.static-ip.telepacific.net [66.7.254.66]) by firefly.encrypted.net (Postfix) with ESMTPSA id 313DD4AD6E; Mon, 6 Apr 2015 13:42:56 -0700 (PDT) From: Sarah Banks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9B2DF3E2-7215-43EE-9702-AE7B501497B6@encrypted.net> Date: Mon, 6 Apr 2015 13:43:01 -0700 To: draft-ietf-lmap-framework.all@tools.ietf.org, "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-SA-Exim-Connect-IP: 72.13.81.186 X-SA-Exim-Rcpt-To: draft-ietf-lmap-framework.all@tools.ietf.org X-SA-Exim-Mail-From: sbanks@encrypted.net X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-lmap-framework.all@ietf.org Resent-Message-Id: <20150406204327.392761A9166@ietfa.amsl.com> Resent-Date: Mon, 6 Apr 2015 13:43:27 -0700 (PDT) Resent-From: sbanks@encrypted.net Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 08:11:45 -0700 Subject: [lmap] Review of draft-ietf-lmap-framework-12 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 20:43:28 -0000 Hello, =09 I have reviewed this document as part of the Operational = directorate's ongoing effort to review all IETF documents being = processed by the IESG. These comments were written with the intent of = improving the operational aspects of the IETF drafts. Comments that are = not addressed in last call may be included in AD reviews during the IESG = review. Document editors and WG chairs should treat these comments just = like any other last call comments. First, a big thanks to the authors for a decently-sized Security = and Privacy Considerations section. I certainly found myself wanting to = ask a lot of questions as I read through this, and these two = aforementioned sections did a decent job of running through the = considerations. =09 I did, however, find the lack of normative language distracting, = particularly in the face of the considerable security/privacy = considerations conversation. If security and privacy are a base = requirement, why is there no normative language to that end? As written, = it seems completely wide open to the implementation - and maybe this is = true even if there is normative language), and I think the document = would be well served to consider modification to include normative = language. Regards, Sarah From nobody Wed Apr 8 19:17:56 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A891ACE7E; Wed, 8 Apr 2015 19:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUrd5mMVF6Gy; Wed, 8 Apr 2015 19:17:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 050D11ACE59; Wed, 8 Apr 2015 19:17:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409021752.2465.57916.idtracker@ietfa.amsl.com> Date: Wed, 08 Apr 2015 19:17:52 -0700 Archived-At: Cc: dromasca@avaya.com, lmap-chairs@ietf.org, lmap@ietf.org Subject: [lmap] Kathleen Moriarty's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 02:17:53 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-lmap-framework-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for your very careful and detailed attention to security and privacy, with options suggested to protect privacy in practice through group ids instead of ones that identify an individual. I just have one question. The security considerations section has a lower case 'must' for providing session encryption, but then the privacy section warns that monitoring can be possible when sessions are not encrypted. When I saw the privacy considerations, I went back to the security section to make sure active attacks against session traffic that was not encrypted was addressed as I didn't see this same 'must' and by that time needed to go back to make sure something as in place. I'm wondering why these weren't just addressed together since more security things could happen too if sessions were not encrypted (in other words, there could be less text, unless I am missing something and we need more on the security side). Thanks! From nobody Thu Apr 9 06:58:51 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA10D1A1B1E; Thu, 9 Apr 2015 06:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNc-uB55pPeg; Thu, 9 Apr 2015 06:58:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A70A91A1B07; Thu, 9 Apr 2015 06:58:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409135845.13211.89354.idtracker@ietfa.amsl.com> Date: Thu, 09 Apr 2015 06:58:45 -0700 Archived-At: Cc: dromasca@avaya.com, lmap-chairs@ietf.org, lmap@ietf.org Subject: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 13:58:47 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-lmap-framework-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - general: Thanks for the significant consideration of privacy, the draft has a quite good analysis. I want to check though that the plan is that other lmap drafts, esp protocol drafts, will in fact describe (and maybe mandate) ways to meet privacy goals, and will not simply refer to section 8 of this and tell developers to go figure it out. If that latter was the plan/expectation, then we'd be better off discussing that now, rather than as a late surprise for the WG. I assume though that the plan is rather to try make the lmap protocol something that can really be used in a privacy sensitive manner and that defaults to that where possible, in which case we'll not have that problem. - One way in which it might be possible to provide evidence that a system respects user privacy would be to have some kind of auditor entity as part of the framework. For example, an MA could be setup to send some selection of reports/instructions to (or encrypted for) the auditor as well as to the normal destination. Did the WG consider such an entity? (This is not a DISCUSS as I can see pros and cons in the auditor-approach, so I'm not sure if it'd be a good idea in the end.) - Thanks for section 8, one suggestion - I'd argue that "privacy respecting/friendly" ought be a bullet at the end of section 1, as if the system is not, then it'll eventually be turned off, one way or another. If you agree, I'd be happy. If not, I'll not get in the way. - 5.4 (and elsewhere) I'm not sure a Group-ID by itself is sufficient to hide identity (timing and soure addressing may expose it anyway). That should be noted, and that lmap protocols should be analysed to see what turns out to be the case. I'm not sure talking about "anonymising" is really correct as anonymity is a very very hard thing to achieve. - section 8: I'm not that keen on considering the privacy of organisations at the same level as that of people. I can see why you might do it but that is also often done as a way to minimise the privacy of people. - section 8: I didn't spot considerations related to re-identification, which can be significant. E.g. if I can see other traffic that identifies a person and the re-identify that person based on LMAP trafic later on (or elsewhere). Did the WG consider that? - section 8: I'm not sure that the "user consent" thing is really of that much benefit here (and it's ubiquitously abused on the Internet today). It would have been welcome had the WG come up with something better, but then since I don't have a solution to hand, I can't insist that you do;-) From nobody Thu Apr 9 10:56:12 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBF41B32FE; Wed, 8 Apr 2015 09:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DFsBTV1P_v8; Wed, 8 Apr 2015 09:04:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC7A1B32E7; Wed, 8 Apr 2015 09:03:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150408160353.15564.41103.idtracker@ietfa.amsl.com> Date: Wed, 08 Apr 2015 09:03:53 -0700 Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 10:56:11 -0700 Cc: dromasca@avaya.com, lmap-chairs@ietf.org, lmap@ietf.org Subject: [lmap] Alvaro Retana's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 16:04:44 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-lmap-framework-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document provides a framework, as such it is not defining the specific final pieces. Section 2 reads: Other LMAP specifications will define an information model, the associated data models, and select/extend one or more protocols for the secure communication: . . . I believe there are at least 2 superfluous forward references that the document can live without. 1. Information Model. For example, in Section 5: The protocol model is closely related to the Information Model [I-D.ietf-lmap-information-model], which is the abstract definition of the information carried by the protocol. (If there is any difference between this document and the Information Model, the latter is definitive, since it is on the standards track.) The purpose of both is to provide a protocol and device independent view, which can be implemented via specific protocols. LMAP defines a specific Control Protocol and Report Protocol, but others could be defined by other standards bodies or be proprietary. However it is important that they all implement the same Information Model and protocol model, in order to ease the definition, operation and interoperability of large-scale Measurement Systems. Reference is made to Information Model work in progress that could match this document. Given the disclaimer in the text about potential differences, I think that leaving a reference in the text could cause confusion. IOW, I'm suggesting you take out the reference and the disclaimer, and just let the Information Model draft speak for itself. 2. Registry for Performance Metrics. Section 5.2.2: o the Measurement Task configurations, each of which needs: * the Metric, specified as a URI to a registry entry; it includes the specification of a Measurement Method. The registry could be defined by the IETF [I-D.ietf-ippm-metric-registry], locally by the operator of the Measurement System or perhaps by another standards organisation. The framework is leaving the door open for multiple ways to define a registry, but is making reference to a specific one (still WIP)..it just causes confusion. Neither of these comments are major, not do they take away from the technical value of the document. Mostly suggestions to improve the clarity of what the framework is proposing. From nobody Thu Apr 9 10:56:13 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC98E1ACDA7; Wed, 8 Apr 2015 18:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4R_JklzUI7ts; Wed, 8 Apr 2015 18:28:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4031ACDA0; Wed, 8 Apr 2015 18:28:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409012839.12369.88541.idtracker@ietfa.amsl.com> Date: Wed, 08 Apr 2015 18:28:39 -0700 Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 10:56:11 -0700 Cc: dromasca@avaya.com, lmap-chairs@ietf.org, lmap@ietf.org Subject: [lmap] Ben Campbell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 01:28:42 -0000 Ben Campbell has entered the following ballot position for draft-ietf-lmap-framework-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1, paragraph starting with "Broadly speaking there are two types of Measurement Method. " s / Method / Methods Figures: Several figures that start at the top of the page have the first line out of alignment. Figure numbers might be useful. (For example, had there been numbers I could have referenced the figures with the alignment problem :-) ) From nobody Thu Apr 9 11:11:42 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F03C1B30AA; Thu, 9 Apr 2015 11:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhIC2QRC8uom; Thu, 9 Apr 2015 11:11:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 853041B30A0; Thu, 9 Apr 2015 11:11:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409181138.23462.35132.idtracker@ietfa.amsl.com> Date: Thu, 09 Apr 2015 11:11:38 -0700 From: IETF Secretariat Archived-At: Subject: [lmap] ID Tracker State Update Notice: X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:11:40 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ From nobody Fri Apr 10 09:11:15 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95B91A8700; Fri, 10 Apr 2015 09:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A10Ej5vvizZE; Fri, 10 Apr 2015 09:11:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B700D1A8034; Fri, 10 Apr 2015 09:11:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410161107.23135.15758.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 09:11:07 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 16:11:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance Working Group of the IETF. Title : Information Model for Large-Scale Measurement Platforms (LMAP) Authors : Trevor Burbridge Philip Eardley Marcelo Bagnulo Juergen Schoenwaelder Filename : draft-ietf-lmap-information-model-05.txt Pages : 38 Date : 2015-04-10 Abstract: This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the MA or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the MA that can be implemented via one or more Control and Report protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-information-model-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 10 09:11:19 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B895F1A8034; Fri, 10 Apr 2015 09:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nji5R-aUKPTN; Fri, 10 Apr 2015 09:11:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DD91A871E; Fri, 10 Apr 2015 09:11:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410161107.23135.78497.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 09:11:07 -0700 Archived-At: Subject: [lmap] New Version Notification - draft-ietf-lmap-information-model-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 16:11:14 -0000 A new version (-05) has been submitted for draft-ietf-lmap-information-model: http://www.ietf.org/internet-drafts/draft-ietf-lmap-information-model-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Apr 10 10:23:04 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510741A87E9; Fri, 10 Apr 2015 10:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKmf_r9tTAI1; Fri, 10 Apr 2015 10:23:00 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC7C1A8820; Fri, 10 Apr 2015 10:23:00 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 935507F8; Fri, 10 Apr 2015 19:22:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id KslAuGqPEXzL; Fri, 10 Apr 2015 19:22:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 10 Apr 2015 19:22:57 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B50722002C; Fri, 10 Apr 2015 19:22:57 +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 WH5Dq_ZdUc5A; Fri, 10 Apr 2015 19:22:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D366B20013; Fri, 10 Apr 2015 19:22:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5860F32BE441; Fri, 10 Apr 2015 19:22:54 +0200 (CEST) Date: Fri, 10 Apr 2015 19:22:54 +0200 From: Juergen Schoenwaelder To: internet-drafts@ietf.org Message-ID: <20150410172254.GA5391@elstar.local> Mail-Followup-To: internet-drafts@ietf.org, lmap@ietf.org References: <20150410161107.23135.78497.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150410161107.23135.78497.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] New Version Notification - draft-ietf-lmap-information-model-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 17:23:02 -0000 On Fri, Apr 10, 2015 at 09:11:07AM -0700, internet-drafts@ietf.org wrote: > > A new version (-05) has been submitted for draft-ietf-lmap-information-model: > http://www.ietf.org/internet-drafts/draft-ietf-lmap-information-model-05.txt > This version has no substantial changes but lots of edits since I added descriptions for all information model elements. I think this makes the definitions way more concise. There are also a number of minor changes (clarification of types, alignment of names, etc.) in order to align the information model and the data model. We also posted a new version of the data model as WG I-D, which is pending approval. I removed the JSON serialization from the appendix. It is a manual task to keep it consistent with the information model and it is already time consuming to keep the information model and the data model in sync manually. We do have XML and JSON serializations of the data model in the data model draft (and the good news here is that tools can check that the serializations are valid against the data model). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Apr 12 14:49:49 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43851B2C7C; Sun, 12 Apr 2015 14:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vYx5NIi6eWm; Sun, 12 Apr 2015 14:49:46 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 648891B2C7A; Sun, 12 Apr 2015 14:49:46 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id B6CED120942; Sun, 12 Apr 2015 18:07:53 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-blue.research.att.com (Postfix) with ESMTP id DBFC76834B; Sun, 12 Apr 2015 17:49:44 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Sun, 12 Apr 2015 17:49:36 -0400 From: "MORTON, ALFRED C (AL)" To: Kathleen Moriarty , The IESG Date: Sun, 12 Apr 2015 17:49:35 -0400 Thread-Topic: [lmap] Kathleen Moriarty's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) Thread-Index: AdBya2tNqN4IBzpAQN20hquvpjkiMwC++Qcg Message-ID: <4AF73AA205019A4C8A1DDD32C034631D01608849F4@NJFPSRVEXG0.research.att.com> References: <20150409021752.2465.57916.idtracker@ietfa.amsl.com> In-Reply-To: <20150409021752.2465.57916.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dromasca@avaya.com" , "lmap-chairs@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] Kathleen Moriarty's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 21:49:49 -0000 Hi Kathleen, > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Kathleen Moriarty ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for your very careful and detailed attention to security and > privacy, with options suggested to protect privacy in practice through > group ids instead of ones that identify an individual. >=20 > I just have one question. The security considerations section has a > lower case 'must' for providing session encryption, but then the privacy > section warns that monitoring can be possible when sessions are not > encrypted. =20 lc must is as demanding as we get in this memo, there are no 2119 terms as = agreed. You may be referring to this sentence at the end of the privacy section, 8.= 4.4 and the figure in that section: If the Measurement Traffic is unencrypted, as found in many systems today,= =20 then both timing and limited results are open to on-path observers. The measurement traffic is distinctly different from the=20 LMAP Control and Reporting protocols. We have ability/scope to specify requirements on the LMAP Control and Reporting protocols, and have required encryption. The measurement traffic itself is out of scope for LMAP. It may be unencrypted user traffic which we observe passively, or it may be an un-encrypted (active) stream dedicated to measurement (which is in the clear to avoid encryption processing with its impact on performance - the objective is to assess the network). But even this active measurement traffic would likely be encrypted when e2e encryption becomes the norm. > When I saw the privacy considerations, I went back to the > security section to make sure active attacks against session traffic > that was not encrypted was addressed as I didn't see this same 'must' > and by that time needed to go back to make sure something as in place. > I'm wondering why these weren't just addressed together since more > security things could happen too if sessions were not encrypted (in > other words, there could be less text, unless I am missing something and > we need more on the security side). Thanks! >=20 Attacks on measurement traffic and their supporting protocols are covered in the relevant WG literature (e.g., IPPM and IPFIX). hope this helps, Al From nobody Sun Apr 12 15:47:44 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1C21B393C; Sun, 12 Apr 2015 15:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WftQPHX_Vix6; Sun, 12 Apr 2015 15:47:41 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4965A1B393B; Sun, 12 Apr 2015 15:47:41 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id AE216120A7F; Sun, 12 Apr 2015 19:05:49 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-blue.research.att.com (Postfix) with ESMTP id BBA7FF6436; Sun, 12 Apr 2015 18:47:40 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Sun, 12 Apr 2015 18:47:40 -0400 From: "MORTON, ALFRED C (AL)" To: Stephen Farrell , The IESG Date: Sun, 12 Apr 2015 18:47:38 -0400 Thread-Topic: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) Thread-Index: AdByzVdjy2Fn+kUtRGSXspOXoQvr9gCnU91A Message-ID: <4AF73AA205019A4C8A1DDD32C034631D01608849F7@NJFPSRVEXG0.research.att.com> References: <20150409135845.13211.89354.idtracker@ietfa.amsl.com> In-Reply-To: <20150409135845.13211.89354.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dromasca@avaya.com" , "lmap-chairs@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 22:47:43 -0000 Hi Stephen,=20 many replies below (since most is on section 8), other authors should chime in too. Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Stephen Farrell ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - general: Thanks for the significant consideration of privacy, the > draft has a quite good analysis. I want to check though that the plan is > that other lmap drafts, esp protocol drafts, will in fact describe (and > maybe mandate) ways to meet privacy goals, and will not simply refer to > section 8 of this and tell developers to go figure it out. If that > latter was the plan/expectation, then we'd be better off discussing that > now, rather than as a late surprise for the WG. I assume though that the > plan is rather to try make the lmap protocol something that can really > be used in a privacy sensitive manner and that defaults to that where > possible, in which case we'll not have that problem. I think it's expected that the protocol design(s) will embrace the=20 relevant mitigations described in section 8, just as they should take-on all relevant specifications of the framework. So, the answer is yes, IMO. >=20 > - One way in which it might be possible to provide evidence that a > system respects user privacy would be to have some kind of auditor > entity as part of the framework. For example, an MA could be setup to > send some selection of reports/instructions to (or encrypted for) the > auditor as well as to the normal destination. Did the WG consider such > an entity? > (This is not a DISCUSS as I can see pros and cons in the auditor- > approach, so I'm not sure if it'd be a good idea in the end.) An independent auditor is an interesting possibility, but it didn't come-up in discussions. That's likely due to the scope of initial LMAP work, which limits us to design for LMAP systems under the control of a=20 single organization. I'm assuming the auditor needs to be somehow independe= nt to be effective. >=20 > - Thanks for section 8, one suggestion - I'd argue that "privacy > respecting/friendly" ought be a bullet at the end of section 1, as if > the system is not, then it'll eventually be turned off, one way or > another. If you agree, I'd be happy. If not, I'll not get in the way. I agree, something like: o Privacy Conserving - the protocols and procedures should respect the sensitive information of all those involved in measurements. >=20 > - 5.4 (and elsewhere) I'm not sure a Group-ID by itself is sufficient to > hide identity (timing and soure addressing may expose it anyway). That > should be noted, and that lmap protocols should be analysed to see what > turns out to be the case. I'm not sure talking about "anonymising" is > really correct as anonymity is a very very hard thing to achieve. That's a fair point, we could add this limitation in section 5.1, the second bullet seems to be where Group-ID is first discussed in=20 some detail. (It's never claimed that Group-ID fixes cures all ills.) >=20 > - section 8: I'm not that keen on considering the privacy of > organisations at the same level as that of people. I can see why you > might do it but that is also often done as a way to minimise the privacy > of people. In this case, the specific organization is an ISP, who has responsibilities to protect the sensitive customer info they possess and to protect=20 the private information about their network which they are entitled to conc= eal. >=20 > - section 8: I didn't spot considerations related to re-identification, > which can be significant. E.g. if I can see other traffic that > identifies a person and the re-identify that person based on LMAP trafic > later on (or elsewhere). Did the WG consider that? The short answer is that if RFC 6973 had considered re-identification, we w= ould have. The closest topic we covered is Correlation, combining various separate pie= ces of info to obtain identity. The point is that an LMAP system could unwittingly complete an information chain if it exposes any sensitive info, so don't. If a user's access with another system already gave away sensitive info,=20 correlation is clearly easier and can result in re-identification,=20 even when an LMAP conserves sensitive information to great extent. We could add this point in 8.5.3. >=20 > - section 8: I'm not sure that the "user consent" > thing is really of that much benefit here (and it's ubiquitously abused > on the Internet today). It would have been welcome had the WG come up > with something better, but then since I don't have a solution to hand, I > can't insist that you do;-) Right now, user consent and temporary/per-instance user consent are helpful if the protocols communicate the permission status, or stop transactions when they don't get indication of permission. We have difficulty limiting w= hat=20 consenting adults do. From nobody Sun Apr 12 17:10:44 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4C61ACE2C; Sun, 12 Apr 2015 17:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVdCoGxjX33N; Sun, 12 Apr 2015 17:10:38 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4BE1B3A55; Sun, 12 Apr 2015 17:10:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5A91CBF4B; Mon, 13 Apr 2015 01:10:34 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip0MMETTDmxW; Mon, 13 Apr 2015 01:10:32 +0100 (IST) Received: from [10.87.48.73] (unknown [86.41.51.113]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 68CD7BF48; Mon, 13 Apr 2015 01:10:32 +0100 (IST) Message-ID: <552B0978.2060404@cs.tcd.ie> Date: Mon, 13 Apr 2015 01:10:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "MORTON, ALFRED C (AL)" , The IESG References: <20150409135845.13211.89354.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D01608849F7@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D01608849F7@NJFPSRVEXG0.research.att.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "dromasca@avaya.com" , "lmap-chairs@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 00:10:40 -0000 Hi Al, On 12/04/15 23:47, MORTON, ALFRED C (AL) wrote: > Hi Stephen, > many replies below (since most is on section 8), > other authors should chime in too. > Al > >> -----Original Message----- >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Stephen Farrell > ... >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - general: Thanks for the significant consideration of privacy, the >> draft has a quite good analysis. I want to check though that the plan is >> that other lmap drafts, esp protocol drafts, will in fact describe (and >> maybe mandate) ways to meet privacy goals, and will not simply refer to >> section 8 of this and tell developers to go figure it out. If that >> latter was the plan/expectation, then we'd be better off discussing that >> now, rather than as a late surprise for the WG. I assume though that the >> plan is rather to try make the lmap protocol something that can really >> be used in a privacy sensitive manner and that defaults to that where >> possible, in which case we'll not have that problem. > > I think it's expected that the protocol design(s) will embrace the > relevant mitigations described in section 8, just as they should take-on > all relevant specifications of the framework. So, the answer is yes, IMO. Great. > >> >> - One way in which it might be possible to provide evidence that a >> system respects user privacy would be to have some kind of auditor >> entity as part of the framework. For example, an MA could be setup to >> send some selection of reports/instructions to (or encrypted for) the >> auditor as well as to the normal destination. Did the WG consider such >> an entity? >> (This is not a DISCUSS as I can see pros and cons in the auditor- >> approach, so I'm not sure if it'd be a good idea in the end.) > > An independent auditor is an interesting possibility, but it didn't come-up > in discussions. That's likely due to the scope of initial LMAP work, > which limits us to design for LMAP systems under the control of a > single organization. I'm assuming the auditor needs to be somehow independent > to be effective. Well, while I think the idea has pros and cons, I don't think ruling it out on the single-domain ground is really compelling. Enterprises inherently qualify as single-domain but yet all (are required to) do some kind of audit. And in some senses, a comms. regulator could be considered as having audit of ISPs as part of it's remit I guess, esp. where an ISP has (near) local monopoly. So no, I don't think that gets us off the hook, in terms of whether or not we ought consider an audit function. Maybe that's one to raise with the WG and see what folks think? >From my POV, it's fine to leave out of this document though, but I think would be good to consider more fully as the work proceeds. (To be clear: I think an audit approach to privacy isn't an ultra-clear winner at all. In some cases, it'd help, but I can imagine circumstances where an audit function could be abused in highly privacy unfriendly ways.) >> >> - Thanks for section 8, one suggestion - I'd argue that "privacy >> respecting/friendly" ought be a bullet at the end of section 1, as if >> the system is not, then it'll eventually be turned off, one way or >> another. If you agree, I'd be happy. If not, I'll not get in the way. > > I agree, something like: > > o Privacy Conserving - the protocols and procedures should respect the > sensitive information of all those involved in measurements. I like that. > >> >> - 5.4 (and elsewhere) I'm not sure a Group-ID by itself is sufficient to >> hide identity (timing and soure addressing may expose it anyway). That >> should be noted, and that lmap protocols should be analysed to see what >> turns out to be the case. I'm not sure talking about "anonymising" is >> really correct as anonymity is a very very hard thing to achieve. > > That's a fair point, we could add this limitation in section 5.1, > the second bullet seems to be where Group-ID is first discussed in > some detail. (It's never claimed that Group-ID fixes cures all ills.) Ack. > >> >> - section 8: I'm not that keen on considering the privacy of >> organisations at the same level as that of people. I can see why you >> might do it but that is also often done as a way to minimise the privacy >> of people. > > In this case, the specific organization is an ISP, who has responsibilities > to protect the sensitive customer info they possess and to protect > the private information about their network which they are entitled to conceal. Yes, that is something one hears argued. I just think it dilutes the concept of privacy if we extend that to organisations as well as people. And even moreso when the last decade or so tells us that the very organisations to whom this document is granting privacy "rights" are ones who have in ways not honoured the privacy expectations of humans. I'd really encourage you to re-cast discussion of network structure in terms of security and confidentiality for the organisation, but not in terms of privacy. > >> >> - section 8: I didn't spot considerations related to re-identification, >> which can be significant. E.g. if I can see other traffic that >> identifies a person and the re-identify that person based on LMAP trafic >> later on (or elsewhere). Did the WG consider that? > > The short answer is that if RFC 6973 had considered re-identification, we would have. > The closest topic we covered is Correlation, combining various separate pieces of info > to obtain identity. The point is that an LMAP system could unwittingly > complete an information chain if it exposes any sensitive info, so don't. > > If a user's access with another system already gave away sensitive info, > correlation is clearly easier and can result in re-identification, > even when an LMAP conserves sensitive information to great extent. > We could add this point in 8.5.3. That'd be great. I think we've loads to learn about re-identification so just adding an acknowledgement of the issue is probably about right for now. > >> >> - section 8: I'm not sure that the "user consent" >> thing is really of that much benefit here (and it's ubiquitously abused >> on the Internet today). It would have been welcome had the WG come up >> with something better, but then since I don't have a solution to hand, I >> can't insist that you do;-) > > Right now, user consent and temporary/per-instance user consent are helpful > if the protocols communicate the permission status, or stop transactions > when they don't get indication of permission. We have difficulty limiting what > consenting adults do. As to that last, we have difficulty knowing when we're dealing with, or being, consenting adults is the problem. (Do you really consent to everything in every EULA through which you click? No you do not is the reality, no matter the legalese.) But again I've no concrete change that's better to offer, sorry. Cheers & thanks for the full response. S. > > > From nobody Mon Apr 13 06:57:23 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528AE1A1BAC for ; Mon, 13 Apr 2015 06:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSAFgMfxc-w6 for ; Mon, 13 Apr 2015 06:57:20 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112A71A1B6A for ; Mon, 13 Apr 2015 06:57:19 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id t3DDvILF024159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Apr 2015 08:57:18 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id E069C1E0079 for ; Mon, 13 Apr 2015 08:57:12 -0500 (CDT) Received: from lxdnp31k.corp.intranet (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id C3A921E0073 for ; Mon, 13 Apr 2015 08:57:12 -0500 (CDT) Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id t3DDvCJd030016 for ; Mon, 13 Apr 2015 07:57:12 -0600 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id t3DDvC0e030011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 13 Apr 2015 07:57:12 -0600 Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 08:57:12 -0500 From: "Bugenhagen, Michael K" To: "''" Thread-Topic: Internet evolution and lmap Thread-Index: AQHQdfC2LWPsAxhKRE2mY15YmSyzWw== Date: Mon, 13 Apr 2015 13:57:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: [lmap] Internet evolution and lmap X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 13:57:21 -0000 SnVzdCBhIG5vdGUgYWJvdXQgc29tZXRoaW5nIHdlJ3ZlIGNvbWUgYWNyb3NzIGxhdGVseSBmb3Ig dGhlIGxtYXAgZ3JvdXAgdG8gY29uc2lkZXIgLyBjaGV3IG9uIGEgYml0Lg0KTk9UIGZvciB0aGUg Y3VycmVudCBzcGVjLCBidXQgZnV0dXJlICJwaWVjZSBwYXJ0cyIuLi4NCg0KVHdvIHN1YmplY3Rz IGluIGVuc3VyZSB0ZXN0aW5nIHJlc3VsdHMgYXJlIGNvbnRleHR1YWxseSB3ZWxsIGxpbmtlZCB0 byBzb21ldGhpbmcuLg0KICAgICAgICAtIFRlY2hub2xvZ3kgRXZvbHV0aW9uIGFuZCBCdXNpbmVz cyByZWxhdGlvbnNoaXAgZXZvbHV0aW9uIGluc3BpcmVkIGRpbWVuc2lvbnMgdG8gbm90IGhhdmlu ZyBhcHBsZXMgdG8gYXBwbGVzIHRlc3QgcmVzdWx0cyBvdmVyIHRpbWUuLi4uDQogICAgICAgIC0g QmVuY2hpbmcgbWFya2luZyBvbiB0aGUgcGF0aCBwZXJmb3JtYW5jZSwgbm90IGFwcGxpY2F0aW9u IGRldmVsb3BtZW50IGZvciBhbnl0aGluZyB1c2luZyBqaXR0ZXIgYnVmZmVycy4NCg0KDQpQcm9i bGVtKHMpIC0NCg0KYSkgU2VydmVyIGNoYW5nZSBvdXQNCiAgICAgICAgLSAgSSdtIHRlc3Rpbmcg VmlkZW8gYnV0IHRoZSBWaWRlbyBlcXVpcG1lbnQgYW5kIHNvZnR3YXJlIGNoYW5nZXMgZXZlcnkg MSAtIDEuNSB5ZWFycyAoSXQncyBoaWdobHkgbGlrZWx5IHRoZSByZXN1bHRzIGFyZSBvZmYgYSBj b21wbGV0ZWx5IGRpZmZlcmVudCAidmlkZW8gc2VydmVyIGZyb250IGVuZCIgb25lIHllYXIgdG8g dGhlIG5leHQpDQoNCg0KYikgU2VydmVyIExvY2F0aW9uIGNoYW5nZSBvdXQNCiAgICAgICAgVGhl IENETiBsb2NhdGlvbnMgc2VydmluZyB0aGUgY3VzdG9tZXJzIG1vdmVzIGV2ZXJ5IDItMyB5ZWFy cyBiYXNlZCBvbiBDRE4gY29udHJhY3RzLi4uDQogICAgICAgIExvYWQgYmFsYW5jaW5nIGFuZCB1 c2luZyB0aGUgImZpeGVkIGJhbmR3aWR0aCIgY29tcG9uZW50cyBvZiBhIENETiBhbHNvIGNoYW5n ZSB0aGUgc2VydmluZyBsb2NhdGlvbg0KICAgICAgICBCb3RoIHJlc3VsdCBpcyBwYXRoIGNoYW5n ZXMgdGhhdCBjaGFuZ2UgcGVyZm9ybWFuY2UNCg0KDQpjKSBIb3QgcG90YXRvIHJvdXRpbmcgKHRl c3RpbmcgZGlyZWN0aW9uYWxpdHkpDQogICAgICAgIFRoZSBkb3dubG9hZCBwYXRoIGFuZCB0aGUg dXBsb2FkIHBhdGggYXJlbid0IHRoZSBzYW1lIC0gc28gdXNpbmcgYW5kICJ1cGxvYWQiIHRyYWNl cm91dGUgbWF5IG5vdCBjYXB0dXJlIHRoZSBhY3R1YWwgcGF0aCBvZiB0aGUgZG93bmxvYWQgdHJh ZmZpYywgYnV0IHRoZSBkb3dubG9hZCBpcyB3aGVyZSB3ZSBhcmUgbG9va2luZyBmb3IgcGVyZm9y bWFuY2UuDQoNCg0KcG9zc2libGUgc29sdXRpb24gdG8gImEgdGhydSBjIiBpc3N1ZXMgLSBpcyB0 byBwbGFjZSBhIHRlc3Qgc2VydmVyIGF0IHRoZSBDRE4gLyBTZXJ2ZXIgbG9jYXRpb25zIHRoYXQg ZG9lc24ndCBjaGFuZ2Ugb3ZlciB0aW1lLCBhbmQgY2FuIG1lYXN1cmUgdGhlIHBhdGggcGVyZm9y bWFuY2UgZnJvbSBlbmQgdG8gZW5kLiAgIFRoaXMgd291bGQgZW5hYmxlIGEgY29udHJvbCB0byBy ZWZsZWN0IGEgcGF0aCBjaGFuZ2UgdnMuIGEgZnJvbnQgZW5kIGNoYW5nZSwgYW5kIHdvdWxkIGFs c28gZ2l2ZSB0aGUgY29ycmVjdCBwYXRoIGZvciB0aGUgZG93bmxvYWQgcGVyZm9ybWFuY2UgdnMu IHRoZSB1cGxvYWQgcGF0aC4NCg0KDQoNCmQpIEJlbmNobWFya2luZyBvbiAiZXhwZWN0ZWQgcGF0 aCBwZXJmb3JtYW5jZSIgdnMuIHdoYXQgYW55IG9uZSBhcHBsaWNhdGlvbiBpcyBzZXQgdG9vLg0K DQogICAgICAgIEFuYWxvZ291c2x5IC0gc2hvY2sgYWJzb3JiZXJzIGFyZSBkZXNpZ25lZCB0byBj b3JyZWN0IHRoZSBidW1wcyBpbiB0aGUgcm9hZCwgYW5kIGppdHRlciBidWZmZXJzIGFyZSBkZXNp Z25lZCB0byBkbyB0aGUgc2FtZS4NCiAgICAgICAgVG8gZW5zdXJlIGEgImFwcHJvcHJpYXRlIiBq aXR0ZXIgYnVmZmVyICJkZWxheSB0byBYIHNlY29uZHMgb3IgZnJhbWVzIGFuZCB0aGVuIHBsYXki IC0gb25lIG5lZWRzIHRvIHVuZGVyc3RhbmQgaG93IGJ1bXB5IHRoZSByb2FkIGlzIHZzLiBtZWFz dXJpbmcgdGhlIHRyYXZlbCBpbiBhIHNob2NrIGFic29yYmVyIHRvIGlkZW50aWZ5IHdoYXQgdGhl IGJhc2VsaW5lIHNob3VsZCBiZS4NCg0KICAgICAgICBJJ20gZ29pbmcgdG8gcGluZyBzb21lIG9m IHRoZSB1bml2ZXJzaXRpZXMgbG9va2luZyBhdCB0aGUgZHVyYXRpb24gb2YgYSBjb25nZXN0aW9u IGV2ZW50IG9uIFdJRkkgdG8gc2VlIHdoYXQgdGhleSBjYW1lIHVwIHdpdGggaW4gdGVybXMgb2Yg Y29sbGVjdGl2ZSBjb2xsaXNpb24gc2Vjb25kcyBiZWhhdmlvciBvZiBXSUZJIGZvciB0aGlzIG9u ZS4NCiAgICAgICAgQXQgdGhlIGVuZCBvZiB0aGUgZGF5IHdlIHNob3VsZCBpZGVudGlmeSB3aGF0 IHRoZSBub3JtYWwgcGVyaW9kIGZvciBpbnRlcnJ1cHRpb24gaXMgaW4gb3JkZXIgdG8gY3JlYXRl IGEgc3RhbmRhcmQuLi4gdGhpcyBtYXkgY2hhbmdlIHdpdGggdGVjaG5vbG9neSwgdGltZSwgZGlz dGFuY2UsIC4uLiBkb24ndCBrbm93IHlldC4NCiAgICAgICAgU28gZm9yIG5vdyAtIGl0J3MgdGhl IHByaW5jaXBsZSBvZiBjcmVhdGluZyB0aGUgZm91bmRhdGlvbiBmb3IgdGhlIGJlbmNoIG1hcmsg dnMuIGdyYWJiaW5nIHdoYXQncyBjb21tb25seSB1c2VkLg0KVGhpcyBjb21tdW5pY2F0aW9uIGlz IHRoZSBwcm9wZXJ0eSBvZiBDZW50dXJ5TGluayBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIFVuYXV0aG9yaXplZCB1c2Ugb2YgdGhpcyBjb21t dW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2UgaW1t ZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsIGFuZCBkZXN0cm95IGFs bCBjb3BpZXMgb2YgdGhlIGNvbW11bmljYXRpb24gYW5kIGFueSBhdHRhY2htZW50cy4NCg== From nobody Mon Apr 13 12:06:52 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56531B31AB; Mon, 13 Apr 2015 12:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzzwEO5_ETFv; Mon, 13 Apr 2015 12:06:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9EA1B31B9; Mon, 13 Apr 2015 12:06:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150413190633.20657.31591.idtracker@ietfa.amsl.com> Date: Mon, 13 Apr 2015 12:06:33 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-yang-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 19:06:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance Working Group of the IETF. Title : A YANG Data Model for LMAP Measurement Agents Authors : Juergen Schoenwaelder Vaibhav Bajpai Filename : draft-ietf-lmap-yang-00.txt Pages : 40 Date : 2015-04-10 Abstract: This document defines a data model for Large-Scale Measurement Platforms (LMAP). The data model is defined using the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-yang-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 13 12:13:30 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160601B31CE for ; Mon, 13 Apr 2015 12:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.899 X-Spam-Level: X-Spam-Status: No, score=-8.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_REMOTE_IMAGE=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvUrFZnC7q8f for ; Mon, 13 Apr 2015 12:13:27 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3920D1B31C1 for ; Mon, 13 Apr 2015 12:13:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoGAAwVLFXGmAcV/2dsb2JhbABcgkUhJlJcBYMQsCMBAQEBAQeSeQYdAQiGAgIcgSBMAQEBAQEBfoQfAQEBAQMSEQpBGwIBCA0EBAEBCx0DAgICMBQHAQEFAwIEEwgGFIgIAQysWopQlhkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgTWEW4UbgT2DDi0KAYItOxIdgRYFkQyBboEzWIczOoJ9glqJcYNNIoIDHIFQbwEBgUJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,571,1422939600"; d="txt'?scan'208,217";a="98531730" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Apr 2015 15:13:10 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 13 Apr 2015 15:13:10 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 13 Apr 2015 21:13:08 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [lmap] LMAP Virtual Interim Meeting - May 2015 Thread-Index: AQHQatmt9zlu0XeSk0+2726tWmIm1J1LZVcQ Date: Mon, 13 Apr 2015 19:13:08 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9F1048@AZ-FFEXMB04.global.avaya.com> References: <1712410046.874902.1427713625128.POLL_INVITECONTACT_PARTICIPANT_INVITATION.doodle@worker3> In-Reply-To: <1712410046.874902.1427713625128.POLL_INVITECONTACT_PARTICIPANT_INVITATION.doodle@worker3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/mixed; boundary="_004_9904FB1B0159DA42B0B887B7FA8119CA5C9F1048AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] FW: LMAP Virtual Interim Meeting - May 2015 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 19:13:29 -0000 --_004_9904FB1B0159DA42B0B887B7FA8119CA5C9F1048AZFFEXMB04globa_ Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C9F1048AZFFEXMB04globa_" --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9F1048AZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UkVNSU5ERVI6IFdlIG5lZWQgdG8gcmVhY2ggYSBkZWNpc2lvbiBhYm91dCB0aGUgZGF0ZSBvZiB0 aGUgTWF5IGludGVyaW0gbWVldGluZyBpbiB0aGUgbmV4dCBmZXcgZGF5cy4gSWYgeW91IGRpZCBu b3QgZXhwcmVzcyB5b3VyIHByZWZlcmVuY2VzIGZvciB0aGUgZGF0ZSBhbmQgdGltZSBvZiB0aGUg bWVldGluZyBwbGVhc2UgZG8gaXQgYXMgc29vbiBhcyBwb3NzaWJsZS4gV2Ugc2hhbGwgYW5ub3Vu Y2UgdGhlIGRhdGUgb2YgdGhlIG1lZXRpbmcgYnkgdGhlIGVuZCBvZiB0aGlzIHdlZWsuDQoNClRo YW5rcyBhbmQgUmVnYXJkcywNCg0KRGFuDQoNCg0KRnJvbTogbG1hcCBbbWFpbHRvOmxtYXAtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbiBSb21hc2NhbnUgKHZpYSBEb29kbGUpDQpT ZW50OiBNb25kYXksIE1hcmNoIDMwLCAyMDE1IDI6MDcgUE0NClRvOiBsbWFwQGlldGYub3JnDQpT dWJqZWN0OiBbbG1hcF0gTE1BUCBWaXJ0dWFsIEludGVyaW0gTWVldGluZyAtIE1heSAyMDE1DQoN CkRhbiBSb21hc2NhbnUgaW52aXRlcyB5b3UgdG8gcGFydGljaXBhdGUgaW4gdGhlIERvb2RsZSBw b2xsICJMTUFQIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nIC0gTWF5IDIwMTUuIg0KDQoNCg0KW2h0 dHBzOi8vZG9vZGxlLmNvbS9ncmFwaGljcy9tYWlsczAvbG9nby5wbmc/dG1haWw9cG9sbF9pbnZp dGVjb250YWN0X3BhcnRpY2lwYW50X2ludml0YXRpb24mdGxpbms9b3BlbmVkXTxodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2Rvb2RsZS5jb21fLTNG dG1haWwtM0Rwb2xsLTVGaW52aXRlY29udGFjdC01RnBhcnRpY2lwYW50LTVGaW52aXRhdGlvbi0y NnRsaW5rLTNEbG9nbyZkPUF3TUZhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1JNGR6R3hS MzFPY05YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09VlpQREJRLThKMGdtN3JxN2hp dG5iWHV6Q3BXQURRQ0NLMjhWTlNNODBJdyZzPVAzMm1ydmhxb2pObV9iSkF2Mi0xN3Z6OEJpaGpj LWo5QjlNZU5NNVM3OUUmZT0+DQoNCg0KDQpIaSB0aGVyZSwNCg0KDQoNCg0KDQpEYW4gUm9tYXNj YW51IChkcm9tYXNjYUBhdmF5YS5jb208bWFpbHRvOmRyb21hc2NhQGF2YXlhLmNvbT4pIGludml0 ZXMgeW91IHRvIHBhcnRpY2lwYXRlIGluIHRoZSBEb29kbGUgcG9sbCAiTE1BUCBWaXJ0dWFsIElu dGVyaW0gTWVldGluZyAtIE1heSAyMDE1LiINCg0KDQoNClBhcnRpY2lwYXRlIG5vdzxodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2Rvb2RsZS5jb21f Y3ZhYThpNHh3Ym1mNndwcC0zRnRtYWlsLTNEcG9sbC01Rmludml0ZWNvbnRhY3QtNUZwYXJ0aWNp cGFudC01Rmludml0YXRpb24tMjZ0bGluay0zRHBvbGxidG4mZD1Bd01GYVEmYz1CRnBXUXc4YnN1 S3BsMVNnaVpINjRRJnI9STRkekd4UjMxT2NOWENKZlF6dmxzaUxRZnVjQlhSdWNQdmRycGhwQnNG QSZtPVZaUERCUS04SjBnbTdycTdoaXRuYlh1ekNwV0FEUUNDSzI4Vk5TTTgwSXcmcz1LVEJ6YnM5 clBXaU0yV0pOZUlXQlRObzI4VHVkOUlkZ0ZaZDQ3dERmMVNjJmU9Pg0KDQoNCg0KDQpbaHR0cDov L2Rvb2RsZS5jb20vZ3JhcGhpY3MvbWFpbHMwL2luZm8ucG5nXQ0KDQpXaGF0IGlzIERvb2RsZT8g RG9vZGxlIGlzIGEgd2ViIHNlcnZpY2UgdGhhdCBoZWxwcyBEYW4gUm9tYXNjYW51IHRvIGZpbmQg YSBzdWl0YWJsZSBkYXRlIGZvciBtZWV0aW5nIHdpdGggYSBncm91cCBvZiBwZW9wbGUuIExlYXJu IG1vcmUgYWJvdXQgaG93IERvb2RsZSB3b3Jrcy48aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kb29kbGUuY29tX21haW4uaHRtbC0zRnRsaW5rLTNE Y2hlY2tPdXRMaW5rLTI2dG1haWwtM0Rwb2xsLTVGaW52aXRlY29udGFjdC01RnBhcnRpY2lwYW50 LTVGaW52aXRhdGlvbiZkPUF3TUZhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1JNGR6R3hS MzFPY05YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09VlpQREJRLThKMGdtN3JxN2hp dG5iWHV6Q3BXQURRQ0NLMjhWTlNNODBJdyZzPU9FcHl4TkdOSDRnQlRRY0lDNkFLZEZzRVRqdVBr SkJzTzhMeUpVSThtMzgmZT0+DQoNCg0KDQpZb3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBi ZWNhdXNlICJEYW4gUm9tYXNjYW51IiBoYXMgaW52aXRlZCB5b3UgdG8gcGFydGljaXBhdGUgaW4g dGhlIERvb2RsZSBwb2xsICJMTUFQIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nIC0gTWF5IDIwMTUu Ig0KDQoNCg0KRG9vZGxlIEFHLCBXZXJkc3RyYXNzZSAyMSwgODAyMSBaw7xyaWNoDQoNCg0KDQoN Cg== --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9F1048AZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1h aWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SRU1JTkRFUjog V2UgbmVlZCB0byByZWFjaCBhIGRlY2lzaW9uIGFib3V0IHRoZSBkYXRlIG9mIHRoZSBNYXkgaW50 ZXJpbSBtZWV0aW5nIGluIHRoZSBuZXh0IGZldyBkYXlzLiBJZiB5b3UgZGlkIG5vdCBleHByZXNz IHlvdXIgcHJlZmVyZW5jZXMgZm9yIHRoZSBkYXRlIGFuZA0KIHRpbWUgb2YgdGhlIG1lZXRpbmcg cGxlYXNlIGRvIGl0IGFzIHNvb24gYXMgcG9zc2libGUuIFdlIHNoYWxsIGFubm91bmNlIHRoZSBk YXRlIG9mIHRoZSBtZWV0aW5nIGJ5IHRoZSBlbmQgb2YgdGhpcyB3ZWVrLg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGFua3MgYW5kIFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PkRhbiBSb21hc2NhbnUgKHZpYSBEb29kbGUpPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWFy Y2ggMzAsIDIwMTUgMjowNyBQTTxicj4NCjxiPlRvOjwvYj4gbG1hcEBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBbbG1hcF0gTE1BUCBWaXJ0dWFsIEludGVyaW0gTWVldGluZyAtIE1heSAy MDE1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+RGFuIFJvbWFzY2FudSBpbnZpdGVzIHlv dSB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgRG9vZGxlIHBvbGwgJnF1b3Q7TE1BUCBWaXJ0dWFsIElu dGVyaW0gTWVldGluZyAtIE1heSAyMDE1LiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2IGFsaWduPSJjZW50ZXIiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0i d2lkdGg6MTAwLjAlO2JhY2tncm91bmQ6d2hpdGU7aGVpZ2h0OjEwMCUhaW1wb3J0YW50O3dpZHRo OjEwMCUhaW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9 InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxkaXYgYWxpZ249ImNlbnRlciI+DQo8dGFibGUg Y2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFk ZGluZz0iMCIgd2lkdGg9IjQ4MCIgc3R5bGU9IndpZHRoOjM2MC4wcHQ7YmFja2dyb3VuZDp3aGl0 ZSI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoyMS4wcHQiPg0KPHRkIGNvbHNwYW49IjQi IHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MjEuMHB0Ij48L3RkPg0KPC90 cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHRhYmxlIGNs YXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRp bmc9IjAiIHdpZHRoPSI0ODAiIHN0eWxlPSJ3aWR0aDozNjAuMHB0O2JhY2tncm91bmQ6d2hpdGUi IGlkPSJ0ZW1wbGF0ZUhlYWRlciI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoyMS4wcHQi Pg0KPHRkIGNvbHNwYW49IjQiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6 MjEuMHB0Ij48L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjIxLjBwdCI+DQo8dGQgd2lk dGg9IjE1IiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjExLjI1cHQ7cGFkZGluZzowY20g MGNtIDBjbSAwY207aGVpZ2h0OjIxLjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSIxMjYiIHZhbGln bj0iYm90dG9tIiBzdHlsZT0id2lkdGg6OTQuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hl aWdodDoyMS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kb29kbGUuY29tXy0zRnRt YWlsLTNEcG9sbC01Rmludml0ZWNvbnRhY3QtNUZwYXJ0aWNpcGFudC01Rmludml0YXRpb24tMjZ0 bGluay0zRGxvZ28mYW1wO2Q9QXdNRmFRJmFtcDtjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmYW1w O3I9STRkekd4UjMxT2NOWENKZlF6dmxzaUxRZnVjQlhSdWNQdmRycGhwQnNGQSZhbXA7bT1WWlBE QlEtOEowZ203cnE3aGl0bmJYdXpDcFdBRFFDQ0syOFZOU004MEl3JmFtcDtzPVAzMm1ydmhxb2pO bV9iSkF2Mi0xN3Z6OEJpaGpjLWo5QjlNZU5NNVM3OUUmYW1wO2U9Ij48c3BhbiBzdHlsZT0idGV4 dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMTI2IiBoZWlnaHQ9IjI4 IiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vZG9vZGxlLmNvbS9ncmFwaGljcy9tYWls czAvbG9nby5wbmc/dG1haWw9cG9sbF9pbnZpdGVjb250YWN0X3BhcnRpY2lwYW50X2ludml0YXRp b24mYW1wO3RsaW5rPW9wZW5lZCI+PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 dGQgd2lkdGg9IjMyNCIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDoyNDMuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoyMS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTUi IHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6MTEuMjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDBjbTtoZWlnaHQ6MjEuMHB0Ij4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6OS4w cHQiPg0KPHRkIGNvbHNwYW49IjQiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWln aHQ6OS4wcHQiPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzow Y20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNt Ij48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UwRTdGMCAxLjBwdDtiYWNrZ3JvdW5kOiNGNUY5RkQ7cGFkZGlu ZzowY20gMGNtIDBjbSAwY20iPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0i d2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBh ZGRpbmc6MTUuMHB0IDExLjI1cHQgMGNtIDExLjI1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE4Ljc1cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPkhpIHRo ZXJlLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90 YWJsZT4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0K PHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFk ZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9w IiBzdHlsZT0iYmFja2dyb3VuZDojRjVGOUZEO3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNl bGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+ DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAxMS4yNXB0IDBjbSAx MS4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy41cHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiM1NzU3NTciPiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRp bmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt IDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8 L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYmFja2dyb3VuZDojRjVGOUZEO3Bh ZGRpbmc6MGNtIDExLjI1cHQgMTUuMHB0IDExLjI1cHQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRo PSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249 InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxOC43NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTc1NzU3Ij5E YW4gUm9tYXNjYW51ICg8YSBocmVmPSJtYWlsdG86ZHJvbWFzY2FAYXZheWEuY29tIj5kcm9tYXNj YUBhdmF5YS5jb208L2E+KSBpbnZpdGVzIHlvdSB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgRG9vZGxl IHBvbGwNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mcXVvdDtMTUFQIFZpcnR1YWwg SW50ZXJpbSBNZWV0aW5nIC0gTWF5IDIwMTUuJnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1 NzU3NTciPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3Rk Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0i cGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJi YWNrZ3JvdW5kOiNERkVDRkM7cGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHRhYmxlIGNsYXNz PSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9 IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0ciBzdHls ZT0iaGVpZ2h0OjcuNXB0Ij4NCjx0ZCB3aWR0aD0iMTUiIGNvbHNwYW49IjMiIHZhbGlnbj0idG9w IiBzdHlsZT0id2lkdGg6MTEuMjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6Ny41 cHQiPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20g MGNtO2JveC1zaGFkb3c6IDBweCAwcHggMnB4IDAgcmdiKDAsIDAsIDAuMjgpO2JvcmRlci1yYWRp dXM6IDNweCI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxw YWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLXNwYWNpbmc6IDE0cHggMHB4Ij4NCjx0Ym9keT4NCjx0 cj4NCjx0ZCBzdHlsZT0iYmFja2dyb3VuZDojMDA2NkREO3BhZGRpbmc6My4wcHQgNS4yNXB0IDMu MHB0IDUuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OjBjbTttYXJnaW4tcmlnaHQ6Mi4yNXB0O21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0 OjEzLjVwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6MTMuNXB0Ij4NCjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZG9vZGxlLmNvbV9jdmFhOGk0eHdibWY2d3Bw LTNGdG1haWwtM0Rwb2xsLTVGaW52aXRlY29udGFjdC01RnBhcnRpY2lwYW50LTVGaW52aXRhdGlv bi0yNnRsaW5rLTNEcG9sbGJ0biZhbXA7ZD1Bd01GYVEmYW1wO2M9QkZwV1F3OGJzdUtwbDFTZ2la SDY0USZhbXA7cj1JNGR6R3hSMzFPY05YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJmFt cDttPVZaUERCUS04SjBnbTdycTdoaXRuYlh1ekNwV0FEUUNDSzI4Vk5TTTgwSXcmYW1wO3M9S1RC emJzOXJQV2lNMldKTmVJV0JUTm8yOFR1ZDlJZGdGWmQ0N3REZjFTYyZhbXA7ZT0iPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aGl0ZTt0ZXh0LWRlY29yYXRpb246bm9uZSI+UGFydGljaXBhdGUmbmJzcDtu b3c8L3NwYW4+PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt IDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8 L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6Ny41cHQiPg0KPHRkIHdpZHRoPSIxNSIgY29sc3Bhbj0i MyIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMS4yNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g MGNtO2hlaWdodDo3LjVwdCI+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90 ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAw Y20gMGNtIDBjbSI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJi b3JkZXI6c29saWQgI0RGRUNGQyAxLjBwdDtwYWRkaW5nOjExLjI1cHQgMTEuMjVwdCAxMS4yNXB0 IDExLjI1cHQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs c3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAw LjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB3aWR0aD0iMzUiIHZhbGlnbj0idG9wIiBzdHlsZT0i d2lkdGg6MjYuMjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyNiIgc3JjPSJodHRwOi8vZG9vZGxl LmNvbS9ncmFwaGljcy9tYWlsczAvaW5mby5wbmciPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0 ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTYuNXB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+V2hhdCBpcyBEb29kbGU/PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTc1NzU3Ij4gRG9vZGxlIGlzIGEgd2ViIHNlcnZp Y2UgdGhhdCBoZWxwcw0KIERhbiBSb21hc2NhbnUgdG8gZmluZCBhIHN1aXRhYmxlIGRhdGUgZm9y IG1lZXRpbmcgd2l0aCBhIGdyb3VwIG9mIHBlb3BsZS4gPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kb29kbGUuY29tX21haW4uaHRt bC0zRnRsaW5rLTNEY2hlY2tPdXRMaW5rLTI2dG1haWwtM0Rwb2xsLTVGaW52aXRlY29udGFjdC01 RnBhcnRpY2lwYW50LTVGaW52aXRhdGlvbiZhbXA7ZD1Bd01GYVEmYW1wO2M9QkZwV1F3OGJzdUtw bDFTZ2laSDY0USZhbXA7cj1JNGR6R3hSMzFPY05YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBC c0ZBJmFtcDttPVZaUERCUS04SjBnbTdycTdoaXRuYlh1ekNwV0FEUUNDSzI4Vk5TTTgwSXcmYW1w O3M9T0VweXhOR05INGdCVFFjSUM2QUtkRnNFVGp1UGtKQnNPOEx5SlVJOG0zOCZhbXA7ZT0iPg0K TGVhcm4gbW9yZSBhYm91dCBob3cgRG9vZGxlIHdvcmtzLjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRk IHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGlu ZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20g MGNtIj48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0Y1RjlGRCAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBj bSI+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIg Ym9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRy IHN0eWxlPSJoZWlnaHQ6MTguMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw Y207aGVpZ2h0OjE4LjBwdCI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0 eWxlPSJwYWRkaW5nOjBjbSAxMS4yNXB0IDYuNzVwdCAxMS4yNXB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojOTk5OTk5Ij5Zb3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBiZWNhdXNlICZx dW90O0RhbiBSb21hc2NhbnUmcXVvdDsgaGFzIGludml0ZWQgeW91IHRvIHBhcnRpY2lwYXRlIGlu IHRoZSBEb29kbGUgcG9sbCAmcXVvdDtMTUFQIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nDQogLSBN YXkgMjAxNS4mcXVvdDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIg c3R5bGU9ImhlaWdodDo5LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNt O2hlaWdodDo5LjBwdCI+PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvZGl2Pg0K PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBj bSAwY20gMGNtIDBjbSI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNEREREREQgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSAwY20iPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj ZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6 MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6 OS4wcHQgMTEuMjVwdCAxNS4wcHQgMTEuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTIuNzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5 OTk5OTkiPkRvb2RsZSBBRywgV2VyZHN0cmFzc2UgMjEsIDgwMjEgWsO8cmljaA0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPHRkIHN0eWxlPSJwYWRk aW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBj bSAwY20iPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4NCjwvdGQ+DQo8 L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9F1048AZFFEXMB04globa_-- --_004_9904FB1B0159DA42B0B887B7FA8119CA5C9F1048AZFFEXMB04globa_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=348; creation-date="Mon, 30 Mar 2015 11:07:14 GMT"; modification-date="Mon, 30 Mar 2015 11:07:14 GMT" Content-ID: <5D8A212E8AE0A640878066EE2DE3B89E@avaya.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxtYXAgbWFp bGluZyBsaXN0DQpsbWFwQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2xtYXAm ZD1Bd0lDQWcmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9STRkekd4UjMxT2NOWENKZlF6dmxz aUxRZnVjQlhSdWNQdmRycGhwQnNGQSZtPVZaUERCUS04SjBnbTdycTdoaXRuYlh1ekNwV0FEUUND SzI4Vk5TTTgwSXcmcz1CbGtOWElaZkVodFdvMFJLTVpFRzFSRFZYWVJoNHVDV2FKQnFGZFYxUzRn JmU9IA0K --_004_9904FB1B0159DA42B0B887B7FA8119CA5C9F1048AZFFEXMB04globa_-- From nobody Tue Apr 14 01:27:40 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865A41B3547 for ; Tue, 14 Apr 2015 01:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.926 X-Spam-Level: ** X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjWWCivXSoTm for ; Tue, 14 Apr 2015 01:27:37 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id E62511B3546 for ; Tue, 14 Apr 2015 01:27:36 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,575,1422939600"; d="scan'208,217";a="238538618" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 14 Apr 2015 04:13:47 -0400 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.96]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 14 Apr 2015 04:27:34 -0400 From: "Weil, Jason" To: "lmap@ietf.org" Date: Tue, 14 Apr 2015 04:27:33 -0400 Thread-Topic: IETF92 LMAP Notes Posted Thread-Index: AdB2jNsjAE5ynzbWSGKCV/a0Fuj8nw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D15247B53FA90jasonweiltwcablecom_" MIME-Version: 1.0 Archived-At: Subject: [lmap] IETF92 LMAP Notes Posted X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 08:27:38 -0000 --_000_D15247B53FA90jasonweiltwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable LMAP WG, The notes from the LMAP WG meeting at IETF92 in Dallas have been posted. Th= ey can be found at the following link: https://www.ietf.org/proceedings/92/= minutes/minutes-92-lmap Thanks to Barbara and Marius from providing detailed notes of the discussio= ns. Please let me know if any corrections or additional comments are needed= . Jason ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_D15247B53FA90jasonweiltwcablecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
LMAP WG, 

The notes from the LMAP WG meeting at IETF92 in Dallas have been poste= d. They can be found at the following link: https://www.ietf.org/proceedi= ngs/92/minutes/minutes-92-lmap

Thanks to Barbara and Marius from providing detailed notes of the disc= ussions. Please let me know if any corrections or additional comments are n= eeded. 

Jason

This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_D15247B53FA90jasonweiltwcablecom_-- From nobody Tue Apr 14 02:09:58 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8622A1A1A33; Tue, 14 Apr 2015 02:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2RrJ7L8yZkl; Tue, 14 Apr 2015 02:09:51 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2981A1A2E; Tue, 14 Apr 2015 02:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13379; q=dns/txt; s=iport; t=1429002590; x=1430212190; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=PQZk1+KvClwfHjPZWThT7dzc5NxqpMM802KopowJYjw=; b=Z829scchBtlx/UyJV+FRSew3g73YZ2Y6DIPAOEMrGe9xYpkHizZu/wxD AkBcQBq5/D6+i9fiT0O4bAlDx7AhF1tT/yljPaHWR+LltWvZZ0j/N2sEr 2u2/AA+1NM/v3sWwPgoX4FKcobkfk02rHgmw/gJjicxkKEk6x01HwY74O o=; X-IronPort-AV: E=Sophos;i="5.11,575,1422921600"; d="scan'208,217";a="426667038" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 14 Apr 2015 09:09:48 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t3E99mi8012342; Tue, 14 Apr 2015 09:09:48 GMT Message-ID: <552CD98A.9020408@cisco.com> Date: Tue, 14 Apr 2015 11:10:34 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alvaro Retana , The IESG References: <20150408160353.15564.41103.idtracker@ietfa.amsl.com> In-Reply-To: <20150408160353.15564.41103.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010103070402090604040700" Archived-At: Cc: dromasca@avaya.com, lmap-chairs@ietf.org, lmap@ietf.org Subject: Re: [lmap] Alvaro Retana's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 09:09:53 -0000 This is a multi-part message in MIME format. --------------010103070402090604040700 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Alvaro, Thanks for your review. See in-line. > Alvaro Retana has entered the following ballot position for > draft-ietf-lmap-framework-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This document provides a framework, as such it is not defining the > specific final pieces. Section 2 reads: > > Other LMAP specifications will define an information model, the > associated data models, and select/extend one or more protocols for > the secure communication: . . . > > I believe there are at least 2 superfluous forward references that the > document can live without. > > 1. Information Model. For example, in Section 5: > > The protocol model is closely related to the Information Model > [I-D.ietf-lmap-information-model], which is the abstract definition > of the information carried by the protocol. (If there is any > difference between this document and the Information Model, the > latter is definitive, since it is on the standards track.) The > purpose of both is to provide a protocol and device independent view, > which can be implemented via specific protocols. LMAP defines a > specific Control Protocol and Report Protocol, but others could be > defined by other standards bodies or be proprietary. However it is > important that they all implement the same Information Model and > protocol model, in order to ease the definition, operation and > interoperability of large-scale Measurement Systems. > > Reference is made to Information Model work in progress that could match > this document. Given the disclaimer in the text about potential > differences, I think that leaving a reference in the text could cause > confusion. IOW, I'm suggesting you take out the reference and the > disclaimer, and just let the Information Model draft speak for itself. There is actually a correlation between the [I-D.ietf-lmap-information-model] and the high level primitives documented in the framework. Just as one example: +-----------------+ +-------------+ | | | Measurement | | Controller |===================================| Agent | +-----------------+ +-------------+ Instruction: -> [(Measurement Task configuration URI of Metric( [Input Parameter], (Role) (interface), (Cycle-ID) (measurement point)), (Report Channel), (Schedule), (Suppression information)] <- Response(details) The Instruction defines information with the following aims ([I-D.ietf-lmap-information-model] defines the consequent list of information elements): o the Measurement Task configurations, each of which needs: * the Metric, specified as a URI to a registry entry; it includes the specification of a Measurement Method. The registry could ... Considering that we needed some agreement on the information model to document the framework, and considering that the information model is stable, I'm not too concerned about the forward reference to the information model. LMAP could have been submitting the framework and the information model at the same time, but chose to submit first the framework and then the information model AND the YANG data model at the same time. > > 2. Registry for Performance Metrics. Section 5.2.2: > > o the Measurement Task configurations, each of which needs: > > * the Metric, specified as a URI to a registry entry; it includes > the specification of a Measurement Method. The registry could > be defined by the IETF [I-D.ietf-ippm-metric-registry], locally > by the operator of the Measurement System or perhaps by another > standards organisation. > > The framework is leaving the door open for multiple ways to define a > registry, but is making reference to a specific one (still WIP)..it just > causes confusion. I understand where you come from. The fact is that LMAP requires performance metric definitions, so it should be mentioned. Potential new text: o the Measurement Task configurations, each of which needs: * the Metric, specified as a URI to a registry entry; it includes the specification of a Measurement Method. Note that the IETF currently works on such a registry specification [I-D.ietf-ippm-metric-registry]. Regards, Benoit > > > Neither of these comments are major, not do they take away from the > technical value of the document. Mostly suggestions to improve the > clarity of what the framework is proposing. > > > . > --------------010103070402090604040700 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Alvaro,

Thanks for your review.
See in-line.
Alvaro Retana has entered the following ballot position for
draft-ietf-lmap-framework-12: No Objection

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


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


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



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This document provides a framework, as such it is not defining the
specific final pieces.  Section 2 reads:

   Other LMAP specifications will define an information model, the
   associated data models, and select/extend one or more protocols for
   the secure communication: . . .

I believe there are at least 2 superfluous forward references that the
document can live without.

1. Information Model.  For example, in Section 5:

   The protocol model is closely related to the Information Model
   [I-D.ietf-lmap-information-model], which is the abstract definition
   of the information carried by the protocol.  (If there is any
   difference between this document and the Information Model, the
   latter is definitive, since it is on the standards track.)  The
   purpose of both is to provide a protocol and device independent view,
   which can be implemented via specific protocols.  LMAP defines a
   specific Control Protocol and Report Protocol, but others could be
   defined by other standards bodies or be proprietary.  However it is
   important that they all implement the same Information Model and
   protocol model, in order to ease the definition, operation and
   interoperability of large-scale Measurement Systems.

Reference is made to Information Model work in progress that could match
this document.  Given the disclaimer in the text about potential
differences, I think that leaving a reference in the text could cause
confusion.  IOW, I'm suggesting you take out the reference and the
disclaimer, and just let the Information Model draft speak for itself.
There is actually a correlation between the [I-D.ietf-lmap-information-model] and the high level primitives documented in the framework.
Just as one example:
   +-----------------+                                   +-------------+
   |                 |                                   | Measurement |
   |  Controller     |===================================|  Agent      |
   +-----------------+                                   +-------------+

   Instruction:                            ->
   [(Measurement Task configuration
       URI of Metric(
      [Input Parameter],
      (Role)
      (interface),
      (Cycle-ID)
      (measurement point)),
    (Report Channel),
    (Schedule),
    (Suppression information)]
                                            <-        Response(details)


   The Instruction defines information with the following aims
   ([I-D.ietf-lmap-information-model] defines the consequent list of
   information elements):

   o  the Measurement Task configurations, each of which needs:

      *  the Metric, specified as a URI to a registry entry; it includes
         the specification of a Measurement Method.  The registry could
                ...

Considering that we needed some agreement on the information model to document the framework, and considering that the information model is stable, I'm not too concerned about the forward reference to the information model.
LMAP could have been submitting the framework and the information model at the same time, but chose to submit first the framework and then the information model AND the YANG data model at the same time.


2. Registry for Performance Metrics.  Section 5.2.2:

   o  the Measurement Task configurations, each of which needs:

      *  the Metric, specified as a URI to a registry entry; it includes
         the specification of a Measurement Method.  The registry could
         be defined by the IETF [I-D.ietf-ippm-metric-registry], locally
         by the operator of the Measurement System or perhaps by another
         standards organisation.

The framework is leaving the door open for multiple ways to define a
registry, but is making reference to a specific one (still WIP)..it just
causes confusion.
I understand where you come from. The fact is that LMAP requires performance metric definitions, so it should be mentioned.
Potential new text:
  o  the Measurement Task configurations, each of which needs:

      *  the Metric, specified as a URI to a registry entry; it includes
         the specification of a Measurement Method.  Note that the IETF 
	 currently works on such a registry specification 
         [I-D.ietf-ippm-metric-registry].
Regards, Benoit


Neither of these comments are major, not do they take away from the
technical value of the document.  Mostly suggestions to improve the
clarity of what the framework is proposing.


.

--------------010103070402090604040700-- From nobody Tue Apr 14 06:58:52 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C291A00FD; Tue, 14 Apr 2015 06:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dA9oqjdXF5QG; Tue, 14 Apr 2015 06:58:45 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C811A0119; Tue, 14 Apr 2015 06:58:45 -0700 (PDT) Received: from EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 14 Apr 2015 14:58:39 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Apr 2015 14:58:43 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 14 Apr 2015 14:58:42 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Tue, 14 Apr 2015 14:58:42 +0100 From: To: , Thread-Topic: [lmap] Ben Campbell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) Thread-Index: AQHQcu56JbBOfgC/mUCpIw0Umrr32J1MhIug Date: Tue, 14 Apr 2015 13:58:42 +0000 Message-ID: <42e8ed1730104685a0823900d6abba6a@rew09926dag03b.domain1.systemhost.net> References: <20150409012839.12369.88541.idtracker@ietfa.amsl.com> In-Reply-To: <20150409012839.12369.88541.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dromasca@avaya.com, lmap-chairs@ietf.org, lmap@ietf.org Subject: Re: [lmap] Ben Campbell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 13:58:48 -0000 Ben, Thanks for the comments.=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: 09 April 2015 02:29 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Section 1, paragraph starting with "Broadly speaking there are two > types of Measurement Method. " >=20 > s / Method / Methods Can we leave this one for discussion with the RFC Editor?=20 Doing a bit of googling, there's no clear rule. In UK English I think that = 'there are two types of method /dog /apple' would be much more usual than m= ethods/ dogs /apples.=20 >=20 > Figures: >=20 > Several figures that start at the top of the page have the first line > out of alignment. >=20 > Figure numbers might be useful. (For example, had there been numbers I > could have referenced the figures with the alignment problem :-) ) >=20 Figures now aligned. Figure numbering - will leave to RFC editor if they want them.=20 From nobody Tue Apr 14 07:11:12 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6801F1A92AB; Tue, 14 Apr 2015 07:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.745 X-Spam-Level: X-Spam-Status: No, score=-0.745 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LOLITA1=1.865, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6JOtGyEtuhM; Tue, 14 Apr 2015 07:11:01 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3BA1A92BD; Tue, 14 Apr 2015 07:10:40 -0700 (PDT) Received: from E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 14 Apr 2015 15:10:34 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 14 Apr 2015 15:10:38 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 14 Apr 2015 15:10:37 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Tue, 14 Apr 2015 15:10:37 +0100 From: To: , , Thread-Topic: [lmap] Alvaro Retana's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) Thread-Index: AQHQcu565g25/nfd0E6kINqaMrNPVJ1MLxkAgABhXoA= Date: Tue, 14 Apr 2015 14:10:36 +0000 Message-ID: References: <20150408160353.15564.41103.idtracker@ietfa.amsl.com> <552CD98A.9020408@cisco.com> In-Reply-To: <552CD98A.9020408@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: multipart/alternative; boundary="_000_e866f67c840941199922cdc7d54d12b5rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Cc: dromasca@avaya.com, lmap-chairs@ietf.org, lmap@ietf.org Subject: Re: [lmap] Alvaro Retana's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 14:11:04 -0000 --_000_e866f67c840941199922cdc7d54d12b5rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWx2YXJvLCBCZW5vaXQNClRoYW5rcyENCg0KT24gY29tbWVudCAxLCBhYm91dCByZWZlcmVuY2Vz IHRvIHRoZSBJbmZvcm1hdGlvbiBtb2RlbDoNCknigJltIGhhcHB5IHRvIGtlZXAgYXMtaXMsIGFz IEJlbm9pdCBzdWdnZXN0cyAocHJvdmlkaW5nIGl0IGRvZXNu4oCZdCBob2xkIHVwIHRoaXMgZG9j dW1lbnQpDQoNCk9uIGNvbW1lbnQgMiBhbmQgQmVub2l04oCZcyByZXBseQ0KDQpJZiBJIHJlbWVt YmVyIHNvbWUgZWFybGllciBkaXNjdXNzaW9uLCBpdCB3YXNu4oCZdCBvYnZpb3VzIHRvIGV2ZXJ5 b25lIHRoYXQgdGhlcmUgY2FuIGJlIG5vbi1JRVRGIHJlZ2lzdHJpZXMuDQoNCg0KDQpIb3cgYWJv dXQgdGhpczoNCg0KICAgICAgKiAgdGhlIE1ldHJpYywgc3BlY2lmaWVkIGFzIGEgVVJJIHRvIGEg cmVnaXN0cnkgZW50cnk7IGl0IGluY2x1ZGVzDQoNCiAgICAgICAgIHRoZSBzcGVjaWZpY2F0aW9u IG9mIGEgTWVhc3VyZW1lbnQgTWV0aG9kLiBUaGUgcmVnaXN0cnkgY291bGQgYmUgZGVmaW5lZCBi eSBhIHN0YW5kYXJkcyBvcmdhbmlzYXRpb24gb3IgbG9jYWxseSBieSB0aGUgb3BlcmF0b3Igb2Yg dGhlIE1lYXN1cmVtZW50IFN5c3RlbS4gTm90ZSB0aGF0IHRoZSBJRVRGDQoNCiAgICAgICAgICAg ICAgIGN1cnJlbnRseSB3b3JrcyBvbiBzdWNoIGEgcmVnaXN0cnkgc3BlY2lmaWNhdGlvbg0KDQog ICAgICAgICBbSS1ELmlldGYtaXBwbS1tZXRyaWMtcmVnaXN0cnldLg0KDQpwaGlsDQoNCkZyb206 IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZW5vaXQg Q2xhaXNlDQpTZW50OiAxNCBBcHJpbCAyMDE1IDEwOjExDQpUbzogQWx2YXJvIFJldGFuYTsgVGhl IElFU0cNCkNjOiBkcm9tYXNjYUBhdmF5YS5jb207IGxtYXAtY2hhaXJzQGlldGYub3JnOyBsbWFw QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2xtYXBdIEFsdmFybyBSZXRhbmEncyBObyBPYmplY3Rp b24gb24gZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0xMjogKHdpdGggQ09NTUVOVCkNCg0KSGkg QWx2YXJvLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KU2VlIGluLWxpbmUuDQoNCkFsdmFy byBSZXRhbmEgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQoN CmRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMTI6IE5vIE9iamVjdGlvbg0KDQoNCg0KV2hlbiBy ZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkg dG8gYWxsDQoNCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVz LiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQoNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2 ZXIuKQ0KDQoNCg0KDQoNClBsZWFzZSByZWZlciB0byBodHRwOi8vd3d3LmlldGYub3JnL2llc2cv c3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNCg0KDQoNClRoZSBk b2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQg aGVyZToNCg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWxtYXAt ZnJhbWV3b3JrLw0KDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkNPTU1FTlQ6DQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQoNClRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBmcmFtZXdvcmssIGFz IHN1Y2ggaXQgaXMgbm90IGRlZmluaW5nIHRoZQ0KDQpzcGVjaWZpYyBmaW5hbCBwaWVjZXMuICBT ZWN0aW9uIDIgcmVhZHM6DQoNCg0KDQogICBPdGhlciBMTUFQIHNwZWNpZmljYXRpb25zIHdpbGwg ZGVmaW5lIGFuIGluZm9ybWF0aW9uIG1vZGVsLCB0aGUNCg0KICAgYXNzb2NpYXRlZCBkYXRhIG1v ZGVscywgYW5kIHNlbGVjdC9leHRlbmQgb25lIG9yIG1vcmUgcHJvdG9jb2xzIGZvcg0KDQogICB0 aGUgc2VjdXJlIGNvbW11bmljYXRpb246IC4gLiAuDQoNCg0KDQpJIGJlbGlldmUgdGhlcmUgYXJl IGF0IGxlYXN0IDIgc3VwZXJmbHVvdXMgZm9yd2FyZCByZWZlcmVuY2VzIHRoYXQgdGhlDQoNCmRv Y3VtZW50IGNhbiBsaXZlIHdpdGhvdXQuDQoNCg0KDQoxLiBJbmZvcm1hdGlvbiBNb2RlbC4gIEZv ciBleGFtcGxlLCBpbiBTZWN0aW9uIDU6DQoNCg0KDQogICBUaGUgcHJvdG9jb2wgbW9kZWwgaXMg Y2xvc2VseSByZWxhdGVkIHRvIHRoZSBJbmZvcm1hdGlvbiBNb2RlbA0KDQogICBbSS1ELmlldGYt bG1hcC1pbmZvcm1hdGlvbi1tb2RlbF0sIHdoaWNoIGlzIHRoZSBhYnN0cmFjdCBkZWZpbml0aW9u DQoNCiAgIG9mIHRoZSBpbmZvcm1hdGlvbiBjYXJyaWVkIGJ5IHRoZSBwcm90b2NvbC4gIChJZiB0 aGVyZSBpcyBhbnkNCg0KICAgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoaXMgZG9jdW1lbnQgYW5kIHRo ZSBJbmZvcm1hdGlvbiBNb2RlbCwgdGhlDQoNCiAgIGxhdHRlciBpcyBkZWZpbml0aXZlLCBzaW5j ZSBpdCBpcyBvbiB0aGUgc3RhbmRhcmRzIHRyYWNrLikgIFRoZQ0KDQogICBwdXJwb3NlIG9mIGJv dGggaXMgdG8gcHJvdmlkZSBhIHByb3RvY29sIGFuZCBkZXZpY2UgaW5kZXBlbmRlbnQgdmlldywN Cg0KICAgd2hpY2ggY2FuIGJlIGltcGxlbWVudGVkIHZpYSBzcGVjaWZpYyBwcm90b2NvbHMuICBM TUFQIGRlZmluZXMgYQ0KDQogICBzcGVjaWZpYyBDb250cm9sIFByb3RvY29sIGFuZCBSZXBvcnQg UHJvdG9jb2wsIGJ1dCBvdGhlcnMgY291bGQgYmUNCg0KICAgZGVmaW5lZCBieSBvdGhlciBzdGFu ZGFyZHMgYm9kaWVzIG9yIGJlIHByb3ByaWV0YXJ5LiAgSG93ZXZlciBpdCBpcw0KDQogICBpbXBv cnRhbnQgdGhhdCB0aGV5IGFsbCBpbXBsZW1lbnQgdGhlIHNhbWUgSW5mb3JtYXRpb24gTW9kZWwg YW5kDQoNCiAgIHByb3RvY29sIG1vZGVsLCBpbiBvcmRlciB0byBlYXNlIHRoZSBkZWZpbml0aW9u LCBvcGVyYXRpb24gYW5kDQoNCiAgIGludGVyb3BlcmFiaWxpdHkgb2YgbGFyZ2Utc2NhbGUgTWVh c3VyZW1lbnQgU3lzdGVtcy4NCg0KDQoNClJlZmVyZW5jZSBpcyBtYWRlIHRvIEluZm9ybWF0aW9u IE1vZGVsIHdvcmsgaW4gcHJvZ3Jlc3MgdGhhdCBjb3VsZCBtYXRjaA0KDQp0aGlzIGRvY3VtZW50 LiAgR2l2ZW4gdGhlIGRpc2NsYWltZXIgaW4gdGhlIHRleHQgYWJvdXQgcG90ZW50aWFsDQoNCmRp ZmZlcmVuY2VzLCBJIHRoaW5rIHRoYXQgbGVhdmluZyBhIHJlZmVyZW5jZSBpbiB0aGUgdGV4dCBj b3VsZCBjYXVzZQ0KDQpjb25mdXNpb24uICBJT1csIEknbSBzdWdnZXN0aW5nIHlvdSB0YWtlIG91 dCB0aGUgcmVmZXJlbmNlIGFuZCB0aGUNCg0KZGlzY2xhaW1lciwgYW5kIGp1c3QgbGV0IHRoZSBJ bmZvcm1hdGlvbiBNb2RlbCBkcmFmdCBzcGVhayBmb3IgaXRzZWxmLg0KVGhlcmUgaXMgYWN0dWFs bHkgYSBjb3JyZWxhdGlvbiBiZXR3ZWVuIHRoZSBbSS1ELmlldGYtbG1hcC1pbmZvcm1hdGlvbi1t b2RlbF0gYW5kIHRoZSBoaWdoIGxldmVsIHByaW1pdGl2ZXMgZG9jdW1lbnRlZCBpbiB0aGUgZnJh bWV3b3JrLg0KSnVzdCBhcyBvbmUgZXhhbXBsZToNCiAgICstLS0tLS0tLS0tLS0tLS0tLSsgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tKw0KICAgfCAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBNZWFzdXJl bWVudCB8DQogICB8ICBDb250cm9sbGVyICAgICB8PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT18ICBBZ2VudCAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tKw0KDQogICBJbnN0cnVjdGlv bjogICAgICAgICAgICAgICAgICAgICAgICAgICAgLT4NCiAgIFsoTWVhc3VyZW1lbnQgVGFzayBj b25maWd1cmF0aW9uDQogICAgICAgVVJJIG9mIE1ldHJpYygNCiAgICAgIFtJbnB1dCBQYXJhbWV0 ZXJdLA0KICAgICAgKFJvbGUpDQogICAgICAoaW50ZXJmYWNlKSwNCiAgICAgIChDeWNsZS1JRCkN CiAgICAgIChtZWFzdXJlbWVudCBwb2ludCkpLA0KICAgIChSZXBvcnQgQ2hhbm5lbCksDQogICAg KFNjaGVkdWxlKSwNCiAgICAoU3VwcHJlc3Npb24gaW5mb3JtYXRpb24pXQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LSAgICAgICAgUmVzcG9uc2UoZGV0YWls cykNCg0KDQogICBUaGUgSW5zdHJ1Y3Rpb24gZGVmaW5lcyBpbmZvcm1hdGlvbiB3aXRoIHRoZSBm b2xsb3dpbmcgYWltcw0KICAgKFtJLUQuaWV0Zi1sbWFwLWluZm9ybWF0aW9uLW1vZGVsXSBkZWZp bmVzIHRoZSBjb25zZXF1ZW50IGxpc3Qgb2YNCiAgIGluZm9ybWF0aW9uIGVsZW1lbnRzKToNCg0K ICAgbyAgdGhlIE1lYXN1cmVtZW50IFRhc2sgY29uZmlndXJhdGlvbnMsIGVhY2ggb2Ygd2hpY2gg bmVlZHM6DQoNCiAgICAgICogIHRoZSBNZXRyaWMsIHNwZWNpZmllZCBhcyBhIFVSSSB0byBhIHJl Z2lzdHJ5IGVudHJ5OyBpdCBpbmNsdWRlcw0KICAgICAgICAgdGhlIHNwZWNpZmljYXRpb24gb2Yg YSBNZWFzdXJlbWVudCBNZXRob2QuICBUaGUgcmVnaXN0cnkgY291bGQNCiAgICAgICAgICAgICAg ICAuLi4NCkNvbnNpZGVyaW5nIHRoYXQgd2UgbmVlZGVkIHNvbWUgYWdyZWVtZW50IG9uIHRoZSBp bmZvcm1hdGlvbiBtb2RlbCB0byBkb2N1bWVudCB0aGUgZnJhbWV3b3JrLCBhbmQgY29uc2lkZXJp bmcgdGhhdCB0aGUgaW5mb3JtYXRpb24gbW9kZWwgaXMgc3RhYmxlLCBJJ20gbm90IHRvbyBjb25j ZXJuZWQgYWJvdXQgdGhlIGZvcndhcmQgcmVmZXJlbmNlIHRvIHRoZSBpbmZvcm1hdGlvbiBtb2Rl bC4NCkxNQVAgY291bGQgaGF2ZSBiZWVuIHN1Ym1pdHRpbmcgdGhlIGZyYW1ld29yayBhbmQgdGhl IGluZm9ybWF0aW9uIG1vZGVsIGF0IHRoZSBzYW1lIHRpbWUsIGJ1dCBjaG9zZSB0byBzdWJtaXQg Zmlyc3QgdGhlIGZyYW1ld29yayBhbmQgdGhlbiB0aGUgaW5mb3JtYXRpb24gbW9kZWwgQU5EIHRo ZSBZQU5HIGRhdGEgbW9kZWwgYXQgdGhlIHNhbWUgdGltZS4NCg0KDQoNCg0KMi4gUmVnaXN0cnkg Zm9yIFBlcmZvcm1hbmNlIE1ldHJpY3MuICBTZWN0aW9uIDUuMi4yOg0KDQoNCg0KICAgbyAgdGhl IE1lYXN1cmVtZW50IFRhc2sgY29uZmlndXJhdGlvbnMsIGVhY2ggb2Ygd2hpY2ggbmVlZHM6DQoN Cg0KDQogICAgICAqICB0aGUgTWV0cmljLCBzcGVjaWZpZWQgYXMgYSBVUkkgdG8gYSByZWdpc3Ry eSBlbnRyeTsgaXQgaW5jbHVkZXMNCg0KICAgICAgICAgdGhlIHNwZWNpZmljYXRpb24gb2YgYSBN ZWFzdXJlbWVudCBNZXRob2QuICBUaGUgcmVnaXN0cnkgY291bGQNCg0KICAgICAgICAgYmUgZGVm aW5lZCBieSB0aGUgSUVURiBbSS1ELmlldGYtaXBwbS1tZXRyaWMtcmVnaXN0cnldLCBsb2NhbGx5 DQoNCiAgICAgICAgIGJ5IHRoZSBvcGVyYXRvciBvZiB0aGUgTWVhc3VyZW1lbnQgU3lzdGVtIG9y IHBlcmhhcHMgYnkgYW5vdGhlcg0KDQogICAgICAgICBzdGFuZGFyZHMgb3JnYW5pc2F0aW9uLg0K DQoNCg0KVGhlIGZyYW1ld29yayBpcyBsZWF2aW5nIHRoZSBkb29yIG9wZW4gZm9yIG11bHRpcGxl IHdheXMgdG8gZGVmaW5lIGENCg0KcmVnaXN0cnksIGJ1dCBpcyBtYWtpbmcgcmVmZXJlbmNlIHRv IGEgc3BlY2lmaWMgb25lIChzdGlsbCBXSVApLi5pdCBqdXN0DQoNCmNhdXNlcyBjb25mdXNpb24u DQpJIHVuZGVyc3RhbmQgd2hlcmUgeW91IGNvbWUgZnJvbS4gVGhlIGZhY3QgaXMgdGhhdCBMTUFQ IHJlcXVpcmVzIHBlcmZvcm1hbmNlIG1ldHJpYyBkZWZpbml0aW9ucywgc28gaXQgc2hvdWxkIGJl IG1lbnRpb25lZC4NClBvdGVudGlhbCBuZXcgdGV4dDoNCg0KDQogIG8gIHRoZSBNZWFzdXJlbWVu dCBUYXNrIGNvbmZpZ3VyYXRpb25zLCBlYWNoIG9mIHdoaWNoIG5lZWRzOg0KDQoNCg0KICAgICAg KiAgdGhlIE1ldHJpYywgc3BlY2lmaWVkIGFzIGEgVVJJIHRvIGEgcmVnaXN0cnkgZW50cnk7IGl0 IGluY2x1ZGVzDQoNCiAgICAgICAgIHRoZSBzcGVjaWZpY2F0aW9uIG9mIGEgTWVhc3VyZW1lbnQg TWV0aG9kLiAgTm90ZSB0aGF0IHRoZSBJRVRGDQoNCiAgICAgICAgY3VycmVudGx5IHdvcmtzIG9u IHN1Y2ggYSByZWdpc3RyeSBzcGVjaWZpY2F0aW9uDQoNCiAgICAgICAgIFtJLUQuaWV0Zi1pcHBt LW1ldHJpYy1yZWdpc3RyeV0uDQoNCg0KUmVnYXJkcywgQmVub2l0DQoNCg0KDQoNCg0KDQoNCg0K TmVpdGhlciBvZiB0aGVzZSBjb21tZW50cyBhcmUgbWFqb3IsIG5vdCBkbyB0aGV5IHRha2UgYXdh eSBmcm9tIHRoZQ0KDQp0ZWNobmljYWwgdmFsdWUgb2YgdGhlIGRvY3VtZW50LiAgTW9zdGx5IHN1 Z2dlc3Rpb25zIHRvIGltcHJvdmUgdGhlDQoNCmNsYXJpdHkgb2Ygd2hhdCB0aGUgZnJhbWV3b3Jr IGlzIHByb3Bvc2luZy4NCg0KDQoNCg0KDQouDQoNCg0KDQo= --_000_e866f67c840941199922cdc7d54d12b5rew09926dag03bdomain1sy_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 Ymx1ZTsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1k ZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibHVlIj5BbHZhcm8sIEJlbm9pdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlRoYW5rcyENCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs dWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsdWUiPk9uIGNvbW1lbnQgMSwgYWJvdXQgcmVmZXJlbmNlcyB0byB0aGUg SW5mb3JtYXRpb24gbW9kZWw6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SeKAmW0gaGFwcHkgdG8ga2VlcCBhcy1pcywgYXMg QmVub2l0IHN1Z2dlc3RzIChwcm92aWRpbmcgaXQgZG9lc27igJl0IGhvbGQgdXAgdGhpcyBkb2N1 bWVudCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5PbiBjb21tZW50IDIgYW5kIEJlbm9pdOKAmXMg cmVwbHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6Ymx1ZSI+SWYgSSByZW1lbWJlciBzb21lIGVhcmxpZXIgZGlzY3Vzc2lvbiwgaXQg d2FzbuKAmXQgb2J2aW91cyB0byBldmVyeW9uZSB0aGF0IHRoZXJlIGNhbiBiZSBub24tSUVURiBy ZWdpc3RyaWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkhvdyBhYm91dCB0aGlzOjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAqJm5ic3A7IHRoZSBNZXRyaWMsIHNwZWNpZmllZCBhcyBhIFVSSSB0byBhIHJl Z2lzdHJ5IGVudHJ5OyBpdCBpbmNsdWRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsdWUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0 aGUgc3BlY2lmaWNhdGlvbiBvZiBhIE1lYXN1cmVtZW50IE1ldGhvZC4gVGhlIHJlZ2lzdHJ5IGNv dWxkIGJlIGRlZmluZWQgYnkgYSBzdGFuZGFyZHMgb3JnYW5pc2F0aW9uIG9yIGxvY2FsbHkgYnkg dGhlIG9wZXJhdG9yIG9mIHRoZSBNZWFzdXJlbWVudCBTeXN0ZW0uIE5vdGUgdGhhdCB0aGUgSUVU RiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Y3VycmVudGx5IHdvcmtzIG9uIHN1Y2ggYSByZWdpc3RyeSBzcGVjaWZpY2F0 aW9uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO1tJLUQuaWV0Zi1pcHBtLW1ldHJpYy1yZWdpc3RyeV0uPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj5waGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gbG1hcCBbbWFpbHRv OmxtYXAtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVub2l0IENsYWlz ZTxicj4NCjxiPlNlbnQ6PC9iPiAxNCBBcHJpbCAyMDE1IDEwOjExPGJyPg0KPGI+VG86PC9iPiBB bHZhcm8gUmV0YW5hOyBUaGUgSUVTRzxicj4NCjxiPkNjOjwvYj4gZHJvbWFzY2FAYXZheWEuY29t OyBsbWFwLWNoYWlyc0BpZXRmLm9yZzsgbG1hcEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW2xtYXBdIEFsdmFybyBSZXRhbmEncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1s bWFwLWZyYW1ld29yay0xMjogKHdpdGggQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQWx2YXJvLDxicj4NCjxicj4NClRoYW5r cyBmb3IgeW91ciByZXZpZXcuPGJyPg0KU2VlIGluLWxpbmUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHByZT5BbHZhcm8gUmV0YW5hIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90 IHBvc2l0aW9uIGZvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRyYWZ0LWlldGYtbG1hcC1mcmFt ZXdvcmstMTI6IE5vIE9iamVjdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlPldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl Y3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmVt YWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVl IHRvIGN1dCB0aGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+aW50cm9kdWN0b3J5IHBhcmFncmFw aCwgaG93ZXZlci4pPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+UGxlYXNlIHJlZmVyIHRvIDxh IGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJp YS5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVy aWEuaHRtbDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5mb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlPlRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25z LCBjYW4gYmUgZm91bmQgaGVyZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmsvIj5o dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmsv PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DT01NRU5UOjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgZnJhbWV3 b3JrLCBhcyBzdWNoIGl0IGlzIG5vdCBkZWZpbmluZyB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5zcGVjaWZpYyBmaW5hbCBwaWVjZXMuJm5ic3A7IFNlY3Rpb24gMiByZWFkczo8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg T3RoZXIgTE1BUCBzcGVjaWZpY2F0aW9ucyB3aWxsIGRlZmluZSBhbiBpbmZvcm1hdGlvbiBtb2Rl bCwgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGFzc29jaWF0ZWQgZGF0 YSBtb2RlbHMsIGFuZCBzZWxlY3QvZXh0ZW5kIG9uZSBvciBtb3JlIHByb3RvY29scyBmb3I8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdGhlIHNlY3VyZSBjb21tdW5pY2F0aW9u OiAuIC4gLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPkkgYmVsaWV2ZSB0aGVyZSBhcmUgYXQgbGVhc3QgMiBzdXBlcmZsdW91cyBmb3J3YXJkIHJl ZmVyZW5jZXMgdGhhdCB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kb2N1bWVudCBjYW4gbGl2 ZSB3aXRob3V0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPjEuIEluZm9ybWF0aW9uIE1vZGVsLiZuYnNwOyBGb3IgZXhhbXBsZSwgaW4gU2VjdGlv biA1OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBUaGUgcHJvdG9jb2wgbW9kZWwgaXMgY2xvc2VseSByZWxhdGVkIHRvIHRo ZSBJbmZvcm1hdGlvbiBNb2RlbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBb SS1ELmlldGYtbG1hcC1pbmZvcm1hdGlvbi1tb2RlbF0sIHdoaWNoIGlzIHRoZSBhYnN0cmFjdCBk ZWZpbml0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG9mIHRoZSBpbmZv cm1hdGlvbiBjYXJyaWVkIGJ5IHRoZSBwcm90b2NvbC4mbmJzcDsgKElmIHRoZXJlIGlzIGFueTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBkaWZmZXJlbmNlIGJldHdlZW4gdGhp cyBkb2N1bWVudCBhbmQgdGhlIEluZm9ybWF0aW9uIE1vZGVsLCB0aGU8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgbGF0dGVyIGlzIGRlZmluaXRpdmUsIHNpbmNlIGl0IGlzIG9u IHRoZSBzdGFuZGFyZHMgdHJhY2suKSZuYnNwOyBUaGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgcHVycG9zZSBvZiBib3RoIGlzIHRvIHByb3ZpZGUgYSBwcm90b2NvbCBhbmQg ZGV2aWNlIGluZGVwZW5kZW50IHZpZXcsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IHdoaWNoIGNhbiBiZSBpbXBsZW1lbnRlZCB2aWEgc3BlY2lmaWMgcHJvdG9jb2xzLiZuYnNw OyBMTUFQIGRlZmluZXMgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBzcGVj aWZpYyBDb250cm9sIFByb3RvY29sIGFuZCBSZXBvcnQgUHJvdG9jb2wsIGJ1dCBvdGhlcnMgY291 bGQgYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZGVmaW5lZCBieSBvdGhl ciBzdGFuZGFyZHMgYm9kaWVzIG9yIGJlIHByb3ByaWV0YXJ5LiZuYnNwOyBIb3dldmVyIGl0IGlz PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGltcG9ydGFudCB0aGF0IHRoZXkg YWxsIGltcGxlbWVudCB0aGUgc2FtZSBJbmZvcm1hdGlvbiBNb2RlbCBhbmQ8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcHJvdG9jb2wgbW9kZWwsIGluIG9yZGVyIHRvIGVhc2Ug dGhlIGRlZmluaXRpb24sIG9wZXJhdGlvbiBhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgaW50ZXJvcGVyYWJpbGl0eSBvZiBsYXJnZS1zY2FsZSBNZWFzdXJlbWVudCBTeXN0 ZW1zLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PlJlZmVyZW5jZSBpcyBtYWRlIHRvIEluZm9ybWF0aW9uIE1vZGVsIHdvcmsgaW4gcHJvZ3Jlc3Mg dGhhdCBjb3VsZCBtYXRjaDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoaXMgZG9jdW1lbnQuJm5i c3A7IEdpdmVuIHRoZSBkaXNjbGFpbWVyIGluIHRoZSB0ZXh0IGFib3V0IHBvdGVudGlhbDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPmRpZmZlcmVuY2VzLCBJIHRoaW5rIHRoYXQgbGVhdmluZyBhIHJl ZmVyZW5jZSBpbiB0aGUgdGV4dCBjb3VsZCBjYXVzZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNv bmZ1c2lvbi4mbmJzcDsgSU9XLCBJJ20gc3VnZ2VzdGluZyB5b3UgdGFrZSBvdXQgdGhlIHJlZmVy ZW5jZSBhbmQgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+ZGlzY2xhaW1lciwgYW5kIGp1c3Qg bGV0IHRoZSBJbmZvcm1hdGlvbiBNb2RlbCBkcmFmdCBzcGVhayBmb3IgaXRzZWxmLjxvOnA+PC9v OnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBh Y3R1YWxseSBhIGNvcnJlbGF0aW9uIGJldHdlZW4gdGhlIFtJLUQuaWV0Zi1sbWFwLWluZm9ybWF0 aW9uLW1vZGVsXSBhbmQgdGhlIGhpZ2ggbGV2ZWwgcHJpbWl0aXZlcyBkb2N1bWVudGVkIGluIHRo ZSBmcmFtZXdvcmsuPGJyPg0KSnVzdCBhcyBvbmUgZXhhbXBsZTo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHR0PjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0t LS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0t LS0tLSYjNDM7PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwgTWVhc3VyZW1lbnQgfDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNw OyB8Jm5ic3A7IENvbnRyb2xsZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfD09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09fCZuYnNwOyBBZ2VudCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0t LS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0t LS0tLS0mIzQzOzwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBJbnN0cnVjdGlvbjom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSZndDs8L3R0 Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgWyhNZWFzdXJlbWVudCBUYXNrIGNvbmZpZ3VyYXRpb248 L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVVJJIG9m IE1ldHJpYyg8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW0lu cHV0IFBhcmFtZXRlcl0sPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IChSb2xlKTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAo aW50ZXJmYWNlKSw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg KEN5Y2xlLUlEKTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAo bWVhc3VyZW1lbnQgcG9pbnQpKSw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsgKFJl cG9ydCBDaGFubmVsKSw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsgKFNjaGVkdWxl KSw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsgKFN1cHByZXNzaW9uIGluZm9ybWF0 aW9uKV08L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy0m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVzcG9uc2UoZGV0YWls cyk8L3R0Pjxicj4NCjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgVGhlIEluc3RydWN0aW9u IGRlZmluZXMgaW5mb3JtYXRpb24gd2l0aCB0aGUgZm9sbG93aW5nIGFpbXM8L3R0Pjxicj4NCjx0 dD4mbmJzcDsmbmJzcDsgKFtJLUQuaWV0Zi1sbWFwLWluZm9ybWF0aW9uLW1vZGVsXSBkZWZpbmVz IHRoZSBjb25zZXF1ZW50IGxpc3Qgb2Y8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgaW5mb3Jt YXRpb24gZWxlbWVudHMpOjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBvJm5ic3A7 IHRoZSBNZWFzdXJlbWVudCBUYXNrIGNvbmZpZ3VyYXRpb25zLCBlYWNoIG9mIHdoaWNoIG5lZWRz OjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5i c3A7IHRoZSBNZXRyaWMsIHNwZWNpZmllZCBhcyBhIFVSSSB0byBhIHJlZ2lzdHJ5IGVudHJ5OyBp dCBpbmNsdWRlczwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB0aGUgc3BlY2lmaWNhdGlvbiBvZiBhIE1lYXN1cmVtZW50IE1ldGhv ZC4mbmJzcDsgVGhlIHJlZ2lzdHJ5IGNvdWxkPC90dD48L3NwYW4+PGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Q29uc2lkZXJpbmcgdGhhdCB3ZSBuZWVkZWQgc29tZSBhZ3JlZW1lbnQgb24gdGhlIGlu Zm9ybWF0aW9uIG1vZGVsIHRvIGRvY3VtZW50IHRoZSBmcmFtZXdvcmssIGFuZCBjb25zaWRlcmlu ZyB0aGF0IHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBpcyBzdGFibGUsIEknbSBub3QgdG9vIGNvbmNl cm5lZCBhYm91dCB0aGUgZm9yd2FyZCByZWZlcmVuY2UgdG8gdGhlIGluZm9ybWF0aW9uIG1vZGVs Ljxicj4NCkxNQVAgY291bGQgaGF2ZSBiZWVuIHN1Ym1pdHRpbmcgdGhlIGZyYW1ld29yayBhbmQg dGhlIGluZm9ybWF0aW9uIG1vZGVsIGF0IHRoZSBzYW1lIHRpbWUsIGJ1dCBjaG9zZSB0byBzdWJt aXQgZmlyc3QgdGhlIGZyYW1ld29yayBhbmQgdGhlbiB0aGUgaW5mb3JtYXRpb24gbW9kZWwgQU5E IHRoZSBZQU5HIGRhdGEgbW9kZWwgYXQgdGhlIHNhbWUgdGltZS48YnI+DQo8YnI+DQo8c3BhbiBz dHlsZT0iY29sb3I6Ymx1ZSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT4yLiBSZWdpc3RyeSBmb3IgUGVyZm9ybWFuY2UgTWV0cmljcy4m bmJzcDsgU2VjdGlvbiA1LjIuMjo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbyZuYnNwOyB0aGUgTWVhc3VyZW1lbnQgVGFz ayBjb25maWd1cmF0aW9ucywgZWFjaCBvZiB3aGljaCBuZWVkczo8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgKiZuYnNwOyB0aGUgTWV0cmljLCBzcGVjaWZpZWQgYXMgYSBVUkkgdG8gYSByZWdp c3RyeSBlbnRyeTsgaXQgaW5jbHVkZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHNwZWNpZmljYXRpb24g b2YgYSBNZWFzdXJlbWVudCBNZXRob2QuJm5ic3A7IFRoZSByZWdpc3RyeSBjb3VsZDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBiZSBkZWZpbmVkIGJ5IHRoZSBJRVRGIFtJLUQuaWV0Zi1pcHBtLW1ldHJpYy1yZWdp c3RyeV0sIGxvY2FsbHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnkgdGhlIG9wZXJhdG9yIG9mIHRoZSBNZWFz dXJlbWVudCBTeXN0ZW0gb3IgcGVyaGFwcyBieSBhbm90aGVyPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0YW5k YXJkcyBvcmdhbmlzYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+VGhlIGZyYW1ld29yayBpcyBsZWF2aW5nIHRoZSBkb29yIG9wZW4gZm9y IG11bHRpcGxlIHdheXMgdG8gZGVmaW5lIGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZWdpc3Ry eSwgYnV0IGlzIG1ha2luZyByZWZlcmVuY2UgdG8gYSBzcGVjaWZpYyBvbmUgKHN0aWxsIFdJUCku Lml0IGp1c3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jYXVzZXMgY29uZnVzaW9uLjxvOnA+PC9v OnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHVuZGVyc3RhbmQgd2hlcmUgeW91IGNv bWUgZnJvbS4gVGhlIGZhY3QgaXMgdGhhdCBMTUFQIHJlcXVpcmVzIHBlcmZvcm1hbmNlIG1ldHJp YyBkZWZpbml0aW9ucywgc28gaXQgc2hvdWxkIGJlIG1lbnRpb25lZC4NCjxicj4NClBvdGVudGlh bCBuZXcgdGV4dDo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7IG8mbmJz cDsgdGhlIE1lYXN1cmVtZW50IFRhc2sgY29uZmlndXJhdGlvbnMsIGVhY2ggb2Ygd2hpY2ggbmVl ZHM6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsgdGhlIE1ldHJpYywgc3BlY2lm aWVkIGFzIGEgVVJJIHRvIGEgcmVnaXN0cnkgZW50cnk7IGl0IGluY2x1ZGVzPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRoZSBzcGVjaWZpY2F0aW9uIG9mIGEgTWVhc3VyZW1lbnQgTWV0aG9kLiZuYnNwOyBOb3Rl IHRoYXQgdGhlIElFVEYgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO2N1cnJlbnRseSB3b3JrcyBvbiBzdWNoIGEgcmVnaXN0 cnkgc3BlY2lmaWNhdGlvbiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtbSS1ELmlldGYtaXBwbS1tZXRy aWMtcmVnaXN0cnldLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5SZWdhcmRzLCBCZW5vaXQ8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+TmVpdGhlciBvZiB0aGVzZSBj b21tZW50cyBhcmUgbWFqb3IsIG5vdCBkbyB0aGV5IHRha2UgYXdheSBmcm9tIHRoZTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPnRlY2huaWNhbCB2YWx1ZSBvZiB0aGUgZG9jdW1lbnQuJm5ic3A7IE1v c3RseSBzdWdnZXN0aW9ucyB0byBpbXByb3ZlIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNs YXJpdHkgb2Ygd2hhdCB0aGUgZnJhbWV3b3JrIGlzIHByb3Bvc2luZy48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT4uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_e866f67c840941199922cdc7d54d12b5rew09926dag03bdomain1sy_-- From nobody Tue Apr 14 07:26:37 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729431AC3B7 for ; Tue, 14 Apr 2015 07:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXW0HWArShyZ for ; Tue, 14 Apr 2015 07:26:33 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A661A0115 for ; Tue, 14 Apr 2015 07:26:20 -0700 (PDT) Received: from EPDAG01C-UKBR.domain1.systemhost.net (193.113.197.204) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 14 Apr 2015 15:26:15 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EPDAG01C-UKBR.domain1.systemhost.net (193.113.197.204) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 14 Apr 2015 15:26:17 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 14 Apr 2015 15:26:16 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Tue, 14 Apr 2015 15:26:16 +0100 From: To: Thread-Topic: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) Thread-Index: AQHQcs1QFHQfXbYs/EqvK85lRGF6GJ1J7vsAgAKnXlA= Date: Tue, 14 Apr 2015 14:26:15 +0000 Message-ID: References: <20150409135845.13211.89354.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D01608849F7@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D01608849F7@NJFPSRVEXG0.research.att.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lmap] FW: Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 14:26:35 -0000 Hi, Just wanted to highlight the IESG's assumption that LMAP protocols will des= cribe how to meet the privacy goals, ie not just say 'read Section 8 of the= framework'. Just making sure that the protocol people are ok with this! Privacy is mentioned in http://tools.ietf.org/html/draft-starkcarey-lmap-pr= otocol-criteria-01 in the context of security=20 --- Stephen Farrell's IESG comment: > - general: Thanks for the significant consideration of privacy, the=20 > draft has a quite good analysis. I want to check though that the plan=20 > is that other lmap drafts, esp protocol drafts, will in fact describe=20 > (and maybe mandate) ways to meet privacy goals, and will not simply=20 > refer to section 8 of this and tell developers to go figure it out. If=20 > that latter was the plan/expectation, then we'd be better off=20 > discussing that now, rather than as a late surprise for the WG. I=20 > assume though that the plan is rather to try make the lmap protocol=20 > something that can really be used in a privacy sensitive manner and=20 > that defaults to that where possible, in which case we'll not have that p= roblem. Al's reply: I think it's expected that the protocol design(s) will embrace the relevant= mitigations described in section 8, just as they should take-on all releva= nt specifications of the framework. So, the answer is yes, IMO. From nobody Tue Apr 14 07:32:22 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717841A9166; Tue, 14 Apr 2015 07:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daL8405wZix1; Tue, 14 Apr 2015 07:21:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B09C1A92DD; Tue, 14 Apr 2015 07:21:06 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3EEKdTm082750 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2015 09:20:50 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: philip.eardley@bt.com Date: Tue, 14 Apr 2015 09:20:39 -0500 Message-ID: <9F9D9713-D4A8-4DF0-94CD-81642C218168@nostrum.com> In-Reply-To: <42e8ed1730104685a0823900d6abba6a@rew09926dag03b.domain1.systemhost.net> References: <20150409012839.12369.88541.idtracker@ietfa.amsl.com> <42e8ed1730104685a0823900d6abba6a@rew09926dag03b.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: X-Mailman-Approved-At: Tue, 14 Apr 2015 07:32:16 -0700 Cc: dromasca@avaya.com, lmap-chairs@ietf.org, iesg@ietf.org, lmap@ietf.org Subject: Re: [lmap] Ben Campbell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 14:21:07 -0000 On 14 Apr 2015, at 8:58, philip.eardley@bt.com wrote: > Ben, > Thanks for the comments. > >> -----Original Message----- >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Ben Campbell >> Sent: 09 April 2015 02:29 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Section 1, paragraph starting with "Broadly speaking there are two >> types of Measurement Method. " >> >> s / Method / Methods > > Can we leave this one for discussion with the RFC Editor? > Doing a bit of googling, there's no clear rule. In UK English I think > that 'there are two types of method /dog /apple' would be much more > usual than methods/ dogs /apples. You may be right for American English, too :-) (I read "two...method[s]", but you wrote "two types...". My bad.) > >> >> Figures: >> >> Several figures that start at the top of the page have the first line >> out of alignment. >> >> Figure numbers might be useful. (For example, had there been numbers >> I >> could have referenced the figures with the alignment problem :-) ) >> > > Figures now aligned. > Figure numbering - will leave to RFC editor if they want them. Sure I usually suggest them if there's more than a couple of figures, because it makes it easier for people to talk about (and reference) the figures. But to my knowledge they are not required, and the RFC editor will probably not add them. /Ben From nobody Tue Apr 14 07:32:23 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130BB1ABD3A; Tue, 14 Apr 2015 07:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdkTi3uu-v8y; Tue, 14 Apr 2015 07:23:22 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35561ABC75; Tue, 14 Apr 2015 07:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2317; q=dns/txt; s=iport; t=1429021402; x=1430231002; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FVhm1NCkIbTKAAhV3LOwv5vjbCw2rGeFDTQ6jIvPGFk=; b=PfAc1WanCZnSv69egJLf+gFwgt1fJCHpFoatL+r/9avFFcTB/71ZrDt+ jWgi+x6JylD5Hz23K8ELKl6jQydvbHGCzd5G95YvdCYHXJnyqpGXHnnOa Lb7TGuAwFucCMtYANT0royzTKKJ3mcKP4wgcVcL/RQLKNErsS20DP2k4L 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BZBABwIS1V/51dJa1cgkVHgS4FxWAJh08CgUE4FAEBAQEBAQF9hCABAQR5EAIBCAQBOgcyFBECBAENBYgqy0IBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiyuEfAeELQWOdIIaihGUbCKCM4E8b4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,576,1422921600"; d="scan'208,217";a="141008390" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 14 Apr 2015 14:23:21 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t3EENLlf021690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Apr 2015 14:23:21 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.6]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 14 Apr 2015 09:23:21 -0500 From: "Alvaro Retana (aretana)" To: "Benoit Claise (bclaise)" , The IESG Thread-Topic: Alvaro Retana's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) Thread-Index: AQHQchW9QabkthxmsU6MrPf7J7YW2p1MlWAAgAAUO4A= Date: Tue, 14 Apr 2015 14:23:21 +0000 Message-ID: References: <20150408160353.15564.41103.idtracker@ietfa.amsl.com> <552CD98A.9020408@cisco.com> In-Reply-To: <552CD98A.9020408@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_D1529A49A6C39aretanaciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 14 Apr 2015 07:32:12 -0700 Cc: "dromasca@avaya.com" , "lmap-chairs@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] Alvaro Retana's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 14:23:27 -0000 --_000_D1529A49A6C39aretanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 4/14/15, 5:10 AM, "Benoit Claise (bclaise)" > wrote: Considering that we needed some agreement on the information model to docum= ent the framework, and considering that the information model is stable, I'= m not too concerned about the forward reference to the information model. LMAP could have been submitting the framework and the information model at = the same time, but chose to submit first the framework and then the informa= tion model AND the YANG data model at the same time. This provided some of the missing background. Thanks! Alvaro. --_000_D1529A49A6C39aretanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8586537F4B29DA4E863A7420ACEDB20D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 4/14/15, 5:10 AM, "Benoit Claise (bclaise)" <bclaise@cisco.com> wrote:

Considering that we needed some a= greement on the information model to document the framework, and considerin= g that the information model is stable, I'm not too concerned about the for= ward reference to the information model.
LMAP could have been submitting the framework and the information model at = the same time, but chose to submit first the framework and then the informa= tion model AND the YANG data model at the same time.

This provided some of the missing background.

Thanks!

Alvaro.
--_000_D1529A49A6C39aretanaciscocom_-- From nobody Tue Apr 14 07:32:24 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527A41AC3A6; Tue, 14 Apr 2015 07:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-pC6zISXaAY; Tue, 14 Apr 2015 07:25:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D28B1AC39C; Tue, 14 Apr 2015 07:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6864; q=dns/txt; s=iport; t=1429021526; x=1430231126; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZqhYvQIioikaVIfpukvzEqJBrpy7TWMaMc0QBfD8gmA=; b=PosLkw86RKdhIijQ81CULUAXxHb7+fbV2a8kXt4jnwYfxgqYEvG3TseI fS6eJyvxfbPn6+S8hc35g6ocy9Cp1zA5cN3X4Mru23VSIq5Z+Jou6KxAg tYtAtl6Ox9diCH9a/IgaQOfFUqXZhk1lTXYD9i7RgU+qOG2uZkoGXkQ3k M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AXBQBnIi1V/5NdJa1cgkVHgS4FzTgCgUFMAQEBAQEBfoQgAQEEeRACAQg/BzIUEQIEAQ0FiCrLTgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLK4R8B4QtAQSOdIIaihGUbCKCM4E8b4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,576,1422921600"; d="scan'208,217";a="411802036" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP; 14 Apr 2015 14:25:25 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t3EEPPYR027182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Apr 2015 14:25:25 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.6]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Tue, 14 Apr 2015 09:25:25 -0500 From: "Alvaro Retana (aretana)" To: "philip.eardley@bt.com" , "Benoit Claise (bclaise)" , "iesg@ietf.org" Thread-Topic: [lmap] Alvaro Retana's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) Thread-Index: AQHQchW9QabkthxmsU6MrPf7J7YW2p1MlWAAgABT1AD//8D7gA== Date: Tue, 14 Apr 2015 14:25:24 +0000 Message-ID: References: <20150408160353.15564.41103.idtracker@ietfa.amsl.com> <552CD98A.9020408@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.117.15.4] Content-Type: multipart/alternative; boundary="_000_D1529B72A6C51aretanaciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 14 Apr 2015 07:32:13 -0700 Cc: "dromasca@avaya.com" , "lmap-chairs@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] Alvaro Retana's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 14:25:28 -0000 --_000_D1529B72A6C51aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 4/14/15, 10:10 AM, "philip.eardley@bt.com"= > wrote: On comment 2 and Benoit=92s reply If I remember some earlier discussion, it wasn=92t obvious to everyone that= there can be non-IETF registries. How about this: * the Metric, specified as a URI to a registry entry; it includes the specification of a Measurement Method. The registry could be d= efined by a standards organisation or locally by the operator of the Measur= ement System. Note that the IETF currently works on such a registry specification [I-D.ietf-ippm-metric-registry]. Thank works for me. Thanks! Alvaro. --_000_D1529B72A6C51aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1DDCB7904B81B644ABE1581334F717F4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 4/14/15, 10:10 AM, "p= hilip.eardley@bt.com" <philip.eardley@bt.com> wrote:

On comment 2 a= nd Benoit=92s reply

If I remember some earlier discussion, it wasn=92t obvi=
ous to everyone that there can be non-IETF registries.

 


How about this:


      *  the Metri=
c, specified as a URI to a registry entry; it includes

        =
 the specification of a Measurement Method. The registry could be defined b=
y a standards organisation or locally by the operator of the Measurement Sy=
stem. Note that the IETF 


        =
       currently works on such a registry spe=
cification 


         [=
I-D.ietf-ippm-metric-registry].

Thank works for me.

Thanks!

Alvaro.
--_000_D1529B72A6C51aretanaciscocom_-- From nobody Tue Apr 14 07:51:29 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E4D1A8770; Tue, 14 Apr 2015 07:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK76huYDQa55; Tue, 14 Apr 2015 07:51:22 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D5C1ACDB2; Tue, 14 Apr 2015 07:51:02 -0700 (PDT) Received: from EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 14 Apr 2015 15:50:51 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 14 Apr 2015 15:50:54 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 14 Apr 2015 15:50:54 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Tue, 14 Apr 2015 15:50:54 +0100 From: To: , , Thread-Topic: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) Thread-Index: AQHQcs1QFHQfXbYs/EqvK85lRGF6GJ1J7vsAgAKqLRA= Date: Tue, 14 Apr 2015 14:50:54 +0000 Message-ID: <7ec2881f92e94953870e2e1479d6247e@rew09926dag03b.domain1.systemhost.net> References: <20150409135845.13211.89354.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D01608849F7@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D01608849F7@NJFPSRVEXG0.research.att.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dromasca@avaya.com, lmap-chairs@ietf.org, lmap@ietf.org Subject: Re: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 14:51:24 -0000 Stephen, Thanks! =20 > I agree, something like: >=20 > o Privacy Conserving - the protocols and procedures should respect > the > sensitive information of all those involved in measurements. I think 'Privacy respecting' is better than 'Privacy conserving'. >=20 > > > > - 5.4 (and elsewhere) I'm not sure a Group-ID by itself is sufficient > > to hide identity (timing and soure addressing may expose it anyway). > > That should be noted, and that lmap protocols should be analysed to > > see what turns out to be the case. I'm not sure talking about > > "anonymising" is really correct as anonymity is a very very hard > thing to achieve. >=20 > That's a fair point, we could add this limitation in section 5.1, the > second bullet seems to be where Group-ID is first discussed in some > detail. (It's never claimed that Group-ID fixes cures all ills.) >=20 Agree with above. The idea of Group-ID was so that you had to do some work = to discover the end-user's identity - do it deliberately. With the MA-ID yo= u have to do work not to know the MA's identity.=20 In Section 5.4 >> The Report contains: >> o the MA-ID or a Group-ID (to anonymise results) I agree this puts it too strongly. How about something like "to obscure the= MA's identity" I'm not sure whether this sentence in S8.4.1 needs to be similarly toned do= wn: << Assignment of a Group-ID enables anonymisation sets to be formed on the basis of service type/grade/rates. =20 >> Perhaps "obfuscation sets" would be better? Similarly in S8.6.2 << Another anonymisation technique is for the MA to include its Group-ID instead of its MA-ID >> "obfuscation technique"? >=20 > > > > - section 8: I didn't spot considerations related to > > re-identification, which can be significant. E.g. if I can see other > > traffic that identifies a person and the re-identify that person > based > > on LMAP trafic later on (or elsewhere). Did the WG consider that? >=20 > The short answer is that if RFC 6973 had considered re-identification, > we would have. > The closest topic we covered is Correlation, combining various separate > pieces of info to obtain identity. The point is that an LMAP system > could unwittingly complete an information chain if it exposes any > sensitive info, so don't. >=20 > If a user's access with another system already gave away sensitive > info, correlation is clearly easier and can result in re- > identification, even when an LMAP conserves sensitive information to > great extent. > We could add this point in 8.5.3. If I understand your point, it's that the LMAP measurement traffic or contr= ol /reporting messages from a particular end-user may contain a 'signature'= that enables someone to track the end-user (perhaps they're mobile) Interesting point, would be worth adding somewhere.=20 >=20 > > > > - section 8: I'm not sure that the "user consent" > > thing is really of that much benefit here (and it's ubiquitously > > abused on the Internet today). It would have been welcome had the WG > > come up with something better, but then since I don't have a solution > > to hand, I can't insist that you do;-) >=20 > Right now, user consent and temporary/per-instance user consent are > helpful if the protocols communicate the permission status, or stop > transactions when they don't get indication of permission. We have > difficulty limiting what consenting adults do. >=20 User consent and empowerment seem central to Data protection and privacy re= gulations and discussions. I agree with you that the Internet industry hasn= 't worked out how to make this meaningful - beyond today's mostly unread T&= Cs and (in Europe) irritating messages about cookies.=20 From nobody Wed Apr 15 07:45:21 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061E31B35CB; Wed, 15 Apr 2015 07:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99iWK-Zimed2; Wed, 15 Apr 2015 07:45:15 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id E33201B35C4; Wed, 15 Apr 2015 07:45:14 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id 686161213D1; Wed, 15 Apr 2015 11:03:31 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-green.research.att.com (Postfix) with ESMTP id 117CAE348B; Wed, 15 Apr 2015 10:44:48 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Wed, 15 Apr 2015 10:45:14 -0400 From: "MORTON, ALFRED C (AL)" To: Stephen Farrell , The IESG Date: Wed, 15 Apr 2015 10:45:13 -0400 Thread-Topic: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) Thread-Index: AdB1fkrI+rpZe5f/RzS4dPiT/YUPCQCANUXQ Message-ID: <4AF73AA205019A4C8A1DDD32C034631D020F888560@NJFPSRVEXG0.research.att.com> References: <20150409135845.13211.89354.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D01608849F7@NJFPSRVEXG0.research.att.com> <552B0978.2060404@cs.tcd.ie> In-Reply-To: <552B0978.2060404@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dromasca@avaya.com" , "lmap-chairs@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 14:45:17 -0000 SGkgU3RlcGhlbiwgDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkgbGF0ZSBTdW5kYXksDQpJJ20gZm9s bG93aW5nIHVwIG9uIGp1c3QgYSBmZXcgcG9pbnRzLCBzbyBJJ3ZlDQpkZWxldGVkIHRoZSBhZ3Jl ZW1lbnRzIGluIHByZXZpb3VzIG1haWwuDQoNCkFsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNz LnRjZC5pZV0NCj4gU2VudDogU3VuZGF5LCBBcHJpbCAxMiwgMjAxNSA4OjExIFBNDQouLi4NCj4g Pg0KPiA+Pg0KPiA+PiAtIE9uZSB3YXkgaW4gd2hpY2ggaXQgbWlnaHQgYmUgcG9zc2libGUgdG8g cHJvdmlkZSBldmlkZW5jZSB0aGF0IGENCj4gPj4gc3lzdGVtIHJlc3BlY3RzIHVzZXIgcHJpdmFj eSB3b3VsZCBiZSB0byBoYXZlIHNvbWUga2luZCBvZiBhdWRpdG9yDQo+ID4+IGVudGl0eSBhcyBw YXJ0IG9mIHRoZSBmcmFtZXdvcmsuIEZvciBleGFtcGxlLCBhbiBNQSBjb3VsZCBiZSBzZXR1cCB0 bw0KPiA+PiBzZW5kIHNvbWUgc2VsZWN0aW9uIG9mIHJlcG9ydHMvaW5zdHJ1Y3Rpb25zIHRvIChv ciBlbmNyeXB0ZWQgZm9yKSB0aGUNCj4gPj4gYXVkaXRvciBhcyB3ZWxsIGFzIHRvIHRoZSBub3Jt YWwgZGVzdGluYXRpb24uIERpZCB0aGUgV0cgY29uc2lkZXINCj4gPj4gc3VjaCBhbiBlbnRpdHk/ DQo+ID4+IChUaGlzIGlzIG5vdCBhIERJU0NVU1MgYXMgSSBjYW4gc2VlIHByb3MgYW5kIGNvbnMg aW4gdGhlIGF1ZGl0b3ItDQo+ID4+IGFwcHJvYWNoLCBzbyBJJ20gbm90IHN1cmUgaWYgaXQnZCBi ZSBhIGdvb2QgaWRlYSBpbiB0aGUgZW5kLikNCj4gPg0KPiA+IEFuIGluZGVwZW5kZW50IGF1ZGl0 b3IgaXMgYW4gaW50ZXJlc3RpbmcgcG9zc2liaWxpdHksIGJ1dCBpdCBkaWRuJ3QNCj4gPiBjb21l LXVwIGluIGRpc2N1c3Npb25zLiAgVGhhdCdzIGxpa2VseSBkdWUgdG8gdGhlIHNjb3BlIG9mIGlu aXRpYWwNCj4gPiBMTUFQIHdvcmssIHdoaWNoIGxpbWl0cyB1cyB0byBkZXNpZ24gZm9yIExNQVAg c3lzdGVtcyB1bmRlciB0aGUNCj4gPiBjb250cm9sIG9mIGEgc2luZ2xlIG9yZ2FuaXphdGlvbi4g SSdtIGFzc3VtaW5nIHRoZSBhdWRpdG9yIG5lZWRzIHRvIGJlDQo+ID4gc29tZWhvdyBpbmRlcGVu ZGVudCB0byBiZSBlZmZlY3RpdmUuDQo+IA0KPiBXZWxsLCB3aGlsZSBJIHRoaW5rIHRoZSBpZGVh IGhhcyBwcm9zIGFuZCBjb25zLCBJIGRvbid0IHRoaW5rIHJ1bGluZyBpdA0KPiBvdXQgb24gdGhl IHNpbmdsZS1kb21haW4gZ3JvdW5kIGlzIHJlYWxseSBjb21wZWxsaW5nLg0KPiBFbnRlcnByaXNl cyBpbmhlcmVudGx5IHF1YWxpZnkgYXMgc2luZ2xlLWRvbWFpbiBidXQgeWV0IGFsbCAoYXJlDQo+ IHJlcXVpcmVkIHRvKSBkbyBzb21lIGtpbmQgb2YgYXVkaXQuIEFuZCBpbiBzb21lIHNlbnNlcywg YSBjb21tcy4NCj4gcmVndWxhdG9yIGNvdWxkIGJlIGNvbnNpZGVyZWQgYXMgaGF2aW5nIGF1ZGl0 IG9mIElTUHMgYXMgcGFydCBvZiBpdCdzDQo+IHJlbWl0IEkgZ3Vlc3MsIGVzcC4gd2hlcmUgYW4g SVNQIGhhcyAobmVhcikgbG9jYWwgbW9ub3BvbHkuDQo+IFNvIG5vLCBJIGRvbid0IHRoaW5rIHRo YXQgZ2V0cyB1cyBvZmYgdGhlIGhvb2ssIGluIHRlcm1zIG9mIHdoZXRoZXIgb3INCj4gbm90IHdl IG91Z2h0IGNvbnNpZGVyIGFuIGF1ZGl0IGZ1bmN0aW9uLg0KPiANCj4gTWF5YmUgdGhhdCdzIG9u ZSB0byByYWlzZSB3aXRoIHRoZSBXRyBhbmQgc2VlIHdoYXQgZm9sa3MgdGhpbms/DQo+IEZyb20g bXkgUE9WLCBpdCdzIGZpbmUgdG8gbGVhdmUgb3V0IG9mIHRoaXMgZG9jdW1lbnQgdGhvdWdoLCBi dXQgSSB0aGluaw0KPiB3b3VsZCBiZSBnb29kIHRvIGNvbnNpZGVyIG1vcmUgZnVsbHkgYXMgdGhl IHdvcmsgcHJvY2VlZHMuDQo+IA0KPiAoVG8gYmUgY2xlYXI6IEkgdGhpbmsgYW4gYXVkaXQgYXBw cm9hY2ggdG8gcHJpdmFjeSBpc24ndCBhbiB1bHRyYS1jbGVhcg0KPiB3aW5uZXIgYXQgYWxsLiBJ biBzb21lIGNhc2VzLCBpdCdkIGhlbHAsIGJ1dCBJIGNhbiBpbWFnaW5lIGNpcmN1bXN0YW5jZXMN Cj4gd2hlcmUgYW4gYXVkaXQgZnVuY3Rpb24gY291bGQgYmUgYWJ1c2VkIGluIGhpZ2hseSBwcml2 YWN5IHVuZnJpZW5kbHkNCj4gd2F5cy4pDQo+IA0KDQpJJ20gbm90IHJ1bGluZyBpdCBvdXQsIGJ1 dCBzYXlpbmcgdGhhdCB0aGUgaW5pdGlhbCBwaGFzZSBvZiBMTUFQIHdvcmsNCnNpbXBsaWZpZXMg YWxsIHJlbGF0aW9uc2hpcHMgYnkgYXNzdW1pbmcgYSBzaW5nbGUgc3lzdGVtIG9wZXJhdG9yLg0K VGhlcmUgYXJlIG1hbnkgYXNwZWN0cyB0byBjb25zaWRlciB3aGVuIG11bHRpcGxlIG9yZ2FuaXph dGlvbnMgDQpqb2luIHRoZSBzeXN0ZW0uIEFuIGF1ZGl0b3IgaXMgb25lIGV4YW1wbGUgd2hlcmUg dGhlIHRydXN0IGJvdW5kYXJ5DQpoYXMgdG8gYmUgZXh0ZW5kZWQgdG8gaW5jbHVkZSBhbiBpbmRl cGVuZGVudCBlbnRpdHksIGlmIHRoYXQncyBob3cgDQp0aGUgYXVkaXQgaXMgYXJyYW5nZWQuDQoN CkkgdGhpbmsgaXQgd291bGQgYmUgZmFpciB0byBhZGQgYSByZWNvbW1lbmRhdGlvbiBmb3IgZWFj aCBlbnRpdHkgaW4gOC4xLA0KKGluZGl2aWR1YWxzLCBJU1BzLCBSZWd1bGF0b3JzLCBvdGhlcnMp IHRvIGFzc2VzcyB0aGUgcmlza3Mgb2YgTE1BUCANCmRhdGEgY29sbGVjdGlvbiBieSBjb25kdWN0 aW5nIGF1ZGl0cyBvZiBkYXRhIHByb3RlY3Rpb24gbWV0aG9kcyANCihhdCBlbmQgb2YgOC42LjQp Lg0KDQpUaGlzIHdvdWxkIGJlIGFuIGVzc2VudGlhbCB0b3BpYyBpbiBhbnkgZnVydGhlciBwaGFz ZSBvZiBMTUFQLg0KDQoob25lIG9mIG15IGZhdm9yaXRlIHF1b3RlcyBhcHBsaWVzIGhlcmU6DQoJ Ikhvd2V2ZXIgYmVhdXRpZnVsIHRoZSBzdHJhdGVneSwgDQogICAgICB5b3Ugc2hvdWxkIG9jY2Fz aW9uYWxseSBsb29rIGF0IHRoZSByZXN1bHRzLiAgU2lyIFdpbnN0b24gQ2h1cmNoaWxsICApDQoN Cj4gPj4NCi4uLg0KPiA+Pg0KPiA+PiAtIHNlY3Rpb24gODogSSdtIG5vdCB0aGF0IGtlZW4gb24g Y29uc2lkZXJpbmcgdGhlIHByaXZhY3kgb2YNCj4gPj4gb3JnYW5pc2F0aW9ucyBhdCB0aGUgc2Ft ZSBsZXZlbCBhcyB0aGF0IG9mIHBlb3BsZS4gSSBjYW4gc2VlIHdoeSB5b3UNCj4gPj4gbWlnaHQg ZG8gaXQgYnV0IHRoYXQgaXMgYWxzbyBvZnRlbiBkb25lIGFzIGEgd2F5IHRvIG1pbmltaXNlIHRo ZQ0KPiA+PiBwcml2YWN5IG9mIHBlb3BsZS4NCj4gPg0KPiA+IEluIHRoaXMgY2FzZSwgdGhlIHNw ZWNpZmljIG9yZ2FuaXphdGlvbiBpcyBhbiBJU1AsIHdobyBoYXMNCj4gPiByZXNwb25zaWJpbGl0 aWVzIHRvIHByb3RlY3QgdGhlIHNlbnNpdGl2ZSBjdXN0b21lciBpbmZvIHRoZXkgcG9zc2Vzcw0K PiA+IGFuZCB0byBwcm90ZWN0IHRoZSBwcml2YXRlIGluZm9ybWF0aW9uIGFib3V0IHRoZWlyIG5l dHdvcmsgd2hpY2ggdGhleQ0KPiBhcmUgZW50aXRsZWQgdG8gY29uY2VhbC4NCj4gDQo+IFllcywg dGhhdCBpcyBzb21ldGhpbmcgb25lIGhlYXJzIGFyZ3VlZC4gSSBqdXN0IHRoaW5rIGl0IGRpbHV0 ZXMgdGhlDQo+IGNvbmNlcHQgb2YgcHJpdmFjeSBpZiB3ZSBleHRlbmQgdGhhdCB0byBvcmdhbmlz YXRpb25zIGFzIHdlbGwgYXMgcGVvcGxlLg0KPiBBbmQgZXZlbiBtb3Jlc28gd2hlbiB0aGUgbGFz dCBkZWNhZGUgb3Igc28gdGVsbHMgdXMgdGhhdCB0aGUgdmVyeQ0KPiBvcmdhbmlzYXRpb25zIHRv IHdob20gdGhpcyBkb2N1bWVudCBpcyBncmFudGluZyBwcml2YWN5ICJyaWdodHMiIGFyZQ0KPiBv bmVzIHdobyBoYXZlIGluIHdheXMgbm90IGhvbm91cmVkIHRoZSBwcml2YWN5IGV4cGVjdGF0aW9u cyBvZiBodW1hbnMuDQo+IA0KPiBJJ2QgcmVhbGx5IGVuY291cmFnZSB5b3UgdG8gcmUtY2FzdCBk aXNjdXNzaW9uIG9mIG5ldHdvcmsgc3RydWN0dXJlIGluDQo+IHRlcm1zIG9mIHNlY3VyaXR5IGFu ZCBjb25maWRlbnRpYWxpdHkgZm9yIHRoZSBvcmdhbmlzYXRpb24sIGJ1dCBub3QgaW4NCj4gdGVy bXMgb2YgcHJpdmFjeS4NCg0KSSBzb21ldGltZXMgaGF2ZSB0cm91YmxlIGRpc3Rpbmd1aXNoaW5n IGJldHdlZW4gdGhlc2UgdGVybXMsIGVzcGVjaWFsbHkNCndoZW4gdGhleSBvZnRlbiByZXN1bHQg aW4gdGFraW5nIHRoZSBzYW1lIG1lYXN1cmVzIHRvIGVuc3VyZSB0aGVpciBwcmVzZXJ2YXRpb24u DQoNCkluIHRoZSBVUywgY2VydGlmaWVkIGFjY291bnRhbnRzIGFyZSBvZnRlbiB0cnVzdGVkIG1v cmUgdGhhbiBvdGhlcnMuDQpUaGUgQW1lcmljYW4gSW5zdGl0dXRlIG9mIENQQXMgd2Vic2l0ZSBz YXlzOiAgDQoiUHJpdmFjeSAvIERhdGEgUHJvdGVjdGlvbjogUHJpdmFjeSBlbmNvbXBhc3NlcyB0 aGUgcmlnaHRzIGFuZCBvYmxpZ2F0aW9ucyANCm9mIGluZGl2aWR1YWxzIGFuZCBvcmdhbml6YXRp b25zIHdpdGggcmVzcGVjdCB0byB0aGUgY29sbGVjdGlvbiwgdXNlLCANCnJldGVudGlvbiwgZGlz Y2xvc3VyZSwgYW5kIGRpc3Bvc2FsIG9mIHBlcnNvbmFsIGluZm9ybWF0aW9uLiINCg0KSGVyZSdz IHdoYXQgd2Ugc2FpZCBpbiBzZWN0aW9uIDguMToNCiAgIEFsdGhvdWdoIHByaXZhY3kgaXMgYSBw cm90ZWN0aW9uIGV4dGVuZGVkIHRvIGluZGl2aWR1YWxzLCB3ZSBpbmNsdWRlDQogICBkaXNjdXNz aW9uIG9mIElTUHMgYW5kIG90aGVyIExNQVAgc3lzdGVtIG9wZXJhdG9ycyBpbiB0aGlzIHNlY3Rp b24uDQogICBUaGVzZSBvcmdhbmlzYXRpb25zIGhhdmUgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGlu dm9sdmVkIGluIHRoZSBMTUFQDQogICBzeXN0ZW0sIGFuZCBtYW55IG9mIHRoZSBzYW1lIGRhbmdl cnMgYW5kIG1pdGlnYXRpb25zIGFyZSBhcHBsaWNhYmxlLg0KICAgRnVydGhlciwgdGhlIElTUHMg c3RvcmUgaW5mb3JtYXRpb24gb24gdGhlaXIgU3Vic2NyaWJlcnMgYmV5b25kIHRoYXQNCiAgIHVz ZWQgaW4gdGhlIExNQVAgc3lzdGVtIChmb3IgaW5zdGFuY2UgYmlsbGluZyBpbmZvcm1hdGlvbiks IGFuZCB0aGVyZQ0KICAgc2hvdWxkIGJlIGEgYmVuZWZpdCBpbiBjb25zaWRlcmluZyBhbGwgdGhl IG5lZWRzIGFuZCBwb3RlbnRpYWwNCiAgIHNvbHV0aW9ucyBjb2hlcmVudGx5Lg0KDQpXZSBjb3Vs ZCBzYXk6DQogICBBbHRob3VnaCBwcml2YWN5IGlzIGEgcHJvdGVjdGlvbiBleHRlbmRlZCB0byBp bmRpdmlkdWFscywgd2UgZGlzY3VzcyANCiAgIGRhdGEgcHJvdGVjdGlvbiBieSBJU1BzIGFuZCBv dGhlciBMTUFQIHN5c3RlbSBvcGVyYXRvcnMgaW4gdGhpcyBzZWN0aW9uLg0KICAgLi4uDQoNCk15 IG93biB2aWV3IGlzIHRoYXQgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGlzIHNvIG9mdGVuIHNoYXJl ZCBhbW9uZyBzZXRzIA0Kb2YgaW5kaXZpZHVhbHMgLSBpbiBwYXJ0bmVyc2hpcHMsIG1hcnJpYWdl cywgZmFtaWxpZXMgLSB0aGF0IHRoZSBwcml2YWN5DQpib3VuZGFyeSBuZWVkcyB0byBiZSByZS1k cmF3biBmb3IgZWFjaCBwaWVjZSBvZiBpbmZvIGNvbnNpZGVyZWQgYW5kL29yIHNoYXJlZC4gDQoN Cj4gDQo+ID4NCj4gPj4NCj4gPj4gLSBzZWN0aW9uIDg6IEkgZGlkbid0IHNwb3QgY29uc2lkZXJh dGlvbnMgcmVsYXRlZCB0bw0KPiA+PiByZS1pZGVudGlmaWNhdGlvbiwgd2hpY2ggY2FuIGJlIHNp Z25pZmljYW50LiAgRS5nLiBpZiBJIGNhbiBzZWUgb3RoZXINCj4gPj4gdHJhZmZpYyB0aGF0IGlk ZW50aWZpZXMgYSBwZXJzb24gYW5kIHRoZSByZS1pZGVudGlmeSB0aGF0IHBlcnNvbg0KPiA+PiBi YXNlZCBvbiBMTUFQIHRyYWZpYyBsYXRlciBvbiAob3IgZWxzZXdoZXJlKS4gRGlkIHRoZSBXRyBj b25zaWRlcg0KPiB0aGF0Pw0KPiA+DQo+ID4gVGhlIHNob3J0IGFuc3dlciBpcyB0aGF0IGlmIFJG QyA2OTczIGhhZCBjb25zaWRlcmVkIHJlLWlkZW50aWZpY2F0aW9uLA0KPiB3ZSB3b3VsZCBoYXZl Lg0KPiA+IFRoZSBjbG9zZXN0IHRvcGljIHdlIGNvdmVyZWQgaXMgQ29ycmVsYXRpb24sIGNvbWJp bmluZyB2YXJpb3VzDQo+ID4gc2VwYXJhdGUgcGllY2VzIG9mIGluZm8gdG8gb2J0YWluIGlkZW50 aXR5LiBUaGUgcG9pbnQgaXMgdGhhdCBhbiBMTUFQDQo+ID4gc3lzdGVtIGNvdWxkIHVud2l0dGlu Z2x5IGNvbXBsZXRlIGFuIGluZm9ybWF0aW9uIGNoYWluIGlmIGl0IGV4cG9zZXMNCj4gYW55IHNl bnNpdGl2ZSBpbmZvLCBzbyBkb24ndC4NCj4gPg0KPiA+IElmIGEgdXNlcidzIGFjY2VzcyB3aXRo IGFub3RoZXIgc3lzdGVtIGFscmVhZHkgZ2F2ZSBhd2F5IHNlbnNpdGl2ZQ0KPiA+IGluZm8sIGNv cnJlbGF0aW9uIGlzIGNsZWFybHkgZWFzaWVyIGFuZCBjYW4gcmVzdWx0IGluDQo+ID4gcmUtaWRl bnRpZmljYXRpb24sIGV2ZW4gd2hlbiBhbiBMTUFQIGNvbnNlcnZlcyBzZW5zaXRpdmUgaW5mb3Jt YXRpb24NCj4gdG8gZ3JlYXQgZXh0ZW50Lg0KPiA+IFdlIGNvdWxkIGFkZCB0aGlzIHBvaW50IGlu IDguNS4zLg0KPiANCj4gVGhhdCdkIGJlIGdyZWF0LiBJIHRoaW5rIHdlJ3ZlIGxvYWRzIHRvIGxl YXJuIGFib3V0IHJlLWlkZW50aWZpY2F0aW9uIHNvDQo+IGp1c3QgYWRkaW5nIGFuIGFja25vd2xl ZGdlbWVudCBvZiB0aGUgaXNzdWUgaXMgcHJvYmFibHkgYWJvdXQgcmlnaHQgZm9yDQo+IG5vdy4N Cj4gDQoNClBoaWwgbWFkZSBhIGNvbW1lbnQgb24gcmUtaWRlbnRpZmljYXRpb24sIGFuZCBJJ2xs IHJlcGx5IHRvDQppdCBzZXBhcmF0ZWx5IG9uIHRoYXQgdGhyZWFkLg0KDQouLi4NCg0KQWwNCg0K From nobody Wed Apr 15 07:55:07 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E251B3565; Wed, 15 Apr 2015 07:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8BX9Difswiy; Wed, 15 Apr 2015 07:55:04 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id C8AF81AC402; Wed, 15 Apr 2015 07:55:03 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 88D56120E25; Wed, 15 Apr 2015 11:13:20 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-blue.research.att.com (Postfix) with ESMTP id 808B7F0470; Wed, 15 Apr 2015 10:55:00 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Wed, 15 Apr 2015 10:55:00 -0400 From: "MORTON, ALFRED C (AL)" To: "philip.eardley@bt.com" , "stephen.farrell@cs.tcd.ie" , "iesg@ietf.org" Date: Wed, 15 Apr 2015 10:54:59 -0400 Thread-Topic: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) Thread-Index: AQHQcs1QFHQfXbYs/EqvK85lRGF6GJ1J7vsAgAKqLRCAAZcZ8A== Message-ID: <4AF73AA205019A4C8A1DDD32C034631D020F88856A@NJFPSRVEXG0.research.att.com> References: <20150409135845.13211.89354.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D01608849F7@NJFPSRVEXG0.research.att.com> <7ec2881f92e94953870e2e1479d6247e@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <7ec2881f92e94953870e2e1479d6247e@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dromasca@avaya.com" , "lmap-chairs@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 14:55:05 -0000 Hi Phil and Stephen, some replies in-line below. (apologies for limited formatting help to find them) Al > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Tuesday, April 14, 2015 10:51 AM > To: MORTON, ALFRED C (AL); stephen.farrell@cs.tcd.ie; iesg@ietf.org > Cc: dromasca@avaya.com; lmap-chairs@ietf.org; lmap@ietf.org > Subject: RE: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap- > framework-12: (with COMMENT) >=20 > Stephen, > Thanks! >=20 >=20 > > I agree, something like: > > > > o Privacy Conserving - the protocols and procedures should respect > > the > > sensitive information of all those involved in measurements. >=20 > I think 'Privacy respecting' is better than 'Privacy conserving'. >=20 > > > > > > > > - 5.4 (and elsewhere) I'm not sure a Group-ID by itself is > > > sufficient to hide identity (timing and soure addressing may expose > it anyway). > > > That should be noted, and that lmap protocols should be analysed to > > > see what turns out to be the case. I'm not sure talking about > > > "anonymising" is really correct as anonymity is a very very hard > > thing to achieve. > > > > That's a fair point, we could add this limitation in section 5.1, the > > second bullet seems to be where Group-ID is first discussed in some > > detail. (It's never claimed that Group-ID fixes cures all ills.) > > >=20 > Agree with above. The idea of Group-ID was so that you had to do some > work to discover the end-user's identity - do it deliberately. With the > MA-ID you have to do work not to know the MA's identity. >=20 > In Section 5.4 > >> The Report contains: > >> o the MA-ID or a Group-ID (to anonymise results) > I agree this puts it too strongly. How about something like "to obscure > the MA's identity" >=20 > I'm not sure whether this sentence in S8.4.1 needs to be similarly toned > down: > << Assignment of a Group-ID > enables anonymisation sets to be formed on the basis of service > type/grade/rates. > >> > Perhaps "obfuscation sets" would be better? I don't think so, " anonymisation sets" is the RFC 6973 term. We have said that anonymisation is difficult in 8.6.2, changing what we call it doesn't change that fact.=20 >=20 > Similarly in S8.6.2 > << Another anonymisation technique is for the MA to include its Group-ID > instead of its MA-ID > >> > "obfuscation technique"? >=20 > > > > > > > > - section 8: I didn't spot considerations related to > > > re-identification, which can be significant. E.g. if I can see > > > other traffic that identifies a person and the re-identify that > > > person > > based > > > on LMAP trafic later on (or elsewhere). Did the WG consider that? > > > > The short answer is that if RFC 6973 had considered re-identification, > > we would have. > > The closest topic we covered is Correlation, combining various > > separate pieces of info to obtain identity. The point is that an LMAP > > system could unwittingly complete an information chain if it exposes > > any sensitive info, so don't. > > > > If a user's access with another system already gave away sensitive > > info, correlation is clearly easier and can result in re- > > identification, even when an LMAP conserves sensitive information to > > great extent. > > We could add this point in 8.5.3. >=20 > If I understand your point, it's that the LMAP measurement traffic or > control /reporting messages from a particular end-user may contain a > 'signature' that enables someone to track the end-user (perhaps they're > mobile) Interesting point, would be worth adding somewhere. I took this to mean that once a person IS identified, then less info is needed to infer that observed traffic is from the same person. IOW, re-identifying Alice, once I've seen Alice's name and her IP address together, can be accomplished with just the IP address. I added to 8.5.3: If a user's access with another system already gave away sensitive info,=20 correlation is clearly easier and can result in re-identification,=20 even when an LMAP conserves sensitive information to great extent. >=20 > > > > > > > > - section 8: I'm not sure that the "user consent" > > > thing is really of that much benefit here (and it's ubiquitously > > > abused on the Internet today). It would have been welcome had the > > > WG come up with something better, but then since I don't have a > > > solution to hand, I can't insist that you do;-) > > > > Right now, user consent and temporary/per-instance user consent are > > helpful if the protocols communicate the permission status, or stop > > transactions when they don't get indication of permission. We have > > difficulty limiting what consenting adults do. > > >=20 > User consent and empowerment seem central to Data protection and privacy > regulations and discussions. I agree with you that the Internet industry > hasn't worked out how to make this meaningful - beyond today's mostly > unread T&Cs and (in Europe) irritating messages about cookies. From nobody Wed Apr 15 08:29:28 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F161B35CF; Wed, 15 Apr 2015 08:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ti-o-ibj0ORY; Wed, 15 Apr 2015 08:29:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD701B35EF; Wed, 15 Apr 2015 08:29:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1D586BEE9; Wed, 15 Apr 2015 16:29:22 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0wy2MLgxMW3; Wed, 15 Apr 2015 16:29:20 +0100 (IST) Received: from [192.168.1.140] (unknown [31.216.237.100]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1B330BECF; Wed, 15 Apr 2015 16:29:20 +0100 (IST) Message-ID: <552E83CF.3030008@cs.tcd.ie> Date: Wed, 15 Apr 2015 16:29:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "MORTON, ALFRED C (AL)" , The IESG References: <20150409135845.13211.89354.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D01608849F7@NJFPSRVEXG0.research.att.com> <552B0978.2060404@cs.tcd.ie> <4AF73AA205019A4C8A1DDD32C034631D020F888560@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D020F888560@NJFPSRVEXG0.research.att.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "dromasca@avaya.com" , "lmap-chairs@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 15:29:26 -0000 Hi Al, I'm fine with all below and with the separate mail about re-identification. S. On 15/04/15 15:45, MORTON, ALFRED C (AL) wrote: > Hi Stephen, > Thanks for your reply late Sunday, > I'm following up on just a few points, so I've > deleted the agreements in previous mail. > > Al > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Sunday, April 12, 2015 8:11 PM > ... >>> >>>> >>>> - One way in which it might be possible to provide evidence that a >>>> system respects user privacy would be to have some kind of auditor >>>> entity as part of the framework. For example, an MA could be setup to >>>> send some selection of reports/instructions to (or encrypted for) the >>>> auditor as well as to the normal destination. Did the WG consider >>>> such an entity? >>>> (This is not a DISCUSS as I can see pros and cons in the auditor- >>>> approach, so I'm not sure if it'd be a good idea in the end.) >>> >>> An independent auditor is an interesting possibility, but it didn't >>> come-up in discussions. That's likely due to the scope of initial >>> LMAP work, which limits us to design for LMAP systems under the >>> control of a single organization. I'm assuming the auditor needs to be >>> somehow independent to be effective. >> >> Well, while I think the idea has pros and cons, I don't think ruling it >> out on the single-domain ground is really compelling. >> Enterprises inherently qualify as single-domain but yet all (are >> required to) do some kind of audit. And in some senses, a comms. >> regulator could be considered as having audit of ISPs as part of it's >> remit I guess, esp. where an ISP has (near) local monopoly. >> So no, I don't think that gets us off the hook, in terms of whether or >> not we ought consider an audit function. >> >> Maybe that's one to raise with the WG and see what folks think? >> From my POV, it's fine to leave out of this document though, but I think >> would be good to consider more fully as the work proceeds. >> >> (To be clear: I think an audit approach to privacy isn't an ultra-clear >> winner at all. In some cases, it'd help, but I can imagine circumstances >> where an audit function could be abused in highly privacy unfriendly >> ways.) >> > > I'm not ruling it out, but saying that the initial phase of LMAP work > simplifies all relationships by assuming a single system operator. > There are many aspects to consider when multiple organizations > join the system. An auditor is one example where the trust boundary > has to be extended to include an independent entity, if that's how > the audit is arranged. > > I think it would be fair to add a recommendation for each entity in 8.1, > (individuals, ISPs, Regulators, others) to assess the risks of LMAP > data collection by conducting audits of data protection methods > (at end of 8.6.4). > > This would be an essential topic in any further phase of LMAP. > > (one of my favorite quotes applies here: > "However beautiful the strategy, > you should occasionally look at the results. Sir Winston Churchill ) > >>>> > ... >>>> >>>> - section 8: I'm not that keen on considering the privacy of >>>> organisations at the same level as that of people. I can see why you >>>> might do it but that is also often done as a way to minimise the >>>> privacy of people. >>> >>> In this case, the specific organization is an ISP, who has >>> responsibilities to protect the sensitive customer info they possess >>> and to protect the private information about their network which they >> are entitled to conceal. >> >> Yes, that is something one hears argued. I just think it dilutes the >> concept of privacy if we extend that to organisations as well as people. >> And even moreso when the last decade or so tells us that the very >> organisations to whom this document is granting privacy "rights" are >> ones who have in ways not honoured the privacy expectations of humans. >> >> I'd really encourage you to re-cast discussion of network structure in >> terms of security and confidentiality for the organisation, but not in >> terms of privacy. > > I sometimes have trouble distinguishing between these terms, especially > when they often result in taking the same measures to ensure their preservation. > > In the US, certified accountants are often trusted more than others. > The American Institute of CPAs website says: > "Privacy / Data Protection: Privacy encompasses the rights and obligations > of individuals and organizations with respect to the collection, use, > retention, disclosure, and disposal of personal information." > > Here's what we said in section 8.1: > Although privacy is a protection extended to individuals, we include > discussion of ISPs and other LMAP system operators in this section. > These organisations have sensitive information involved in the LMAP > system, and many of the same dangers and mitigations are applicable. > Further, the ISPs store information on their Subscribers beyond that > used in the LMAP system (for instance billing information), and there > should be a benefit in considering all the needs and potential > solutions coherently. > > We could say: > Although privacy is a protection extended to individuals, we discuss > data protection by ISPs and other LMAP system operators in this section. > ... > > My own view is that sensitive information is so often shared among sets > of individuals - in partnerships, marriages, families - that the privacy > boundary needs to be re-drawn for each piece of info considered and/or shared. > >> >>> >>>> >>>> - section 8: I didn't spot considerations related to >>>> re-identification, which can be significant. E.g. if I can see other >>>> traffic that identifies a person and the re-identify that person >>>> based on LMAP trafic later on (or elsewhere). Did the WG consider >> that? >>> >>> The short answer is that if RFC 6973 had considered re-identification, >> we would have. >>> The closest topic we covered is Correlation, combining various >>> separate pieces of info to obtain identity. The point is that an LMAP >>> system could unwittingly complete an information chain if it exposes >> any sensitive info, so don't. >>> >>> If a user's access with another system already gave away sensitive >>> info, correlation is clearly easier and can result in >>> re-identification, even when an LMAP conserves sensitive information >> to great extent. >>> We could add this point in 8.5.3. >> >> That'd be great. I think we've loads to learn about re-identification so >> just adding an acknowledgement of the issue is probably about right for >> now. >> > > Phil made a comment on re-identification, and I'll reply to > it separately on that thread. > > ... > > Al > From nobody Thu Apr 16 12:34:09 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA7F1B353A for ; Thu, 16 Apr 2015 12:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZnHoCgYNFVQ for ; Thu, 16 Apr 2015 12:34:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BF81B3533 for ; Thu, 16 Apr 2015 12:34:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A86C993B for ; Thu, 16 Apr 2015 21:34:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gcCxSrTYH3hK for ; Thu, 16 Apr 2015 21:33:36 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 16 Apr 2015 21:33:58 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E27232002C for ; Thu, 16 Apr 2015 21:33:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uQ_Ovwfy12RV; Thu, 16 Apr 2015 21:33:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5511520013; Thu, 16 Apr 2015 21:33:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 012FB32C3C97; Thu, 16 Apr 2015 21:33:53 +0200 (CEST) Date: Thu, 16 Apr 2015 21:33:53 +0200 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20150416193353.GA6290@elstar.local> Mail-Followup-To: lmap@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [lmap] proposed information model / data model changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 19:34:08 -0000 Hi, we are working on an implementation of the data model and we found a couple of things non-intuitive or more difficult to implement than needed or complex to use for certain use cases. After discussing things for a while internally, we consolidated our thoughts in the following list of proposed changes. Note that some of the listed changes 1)-6) interact. I would be nice if could get feedback quickly so we can get our code do the 'right' thing. 1) Execution model for actions: A schedule has a list of task with parameters (we call them actions). The info model currently says that the tasks are executed sequentially. Or in Unix shell syntax, the actions a_1 to a_n are executed as follows: a_1; a_2; ...; a_n There is no data passed between the actions in the above example (unless you configure specific action destinations options). We believe there are other execution models that should be supported, in particular the piped model where data flows from one task to the next task: a_1 | a_2 | ... | a_n The prime use case is to have a measurement task feeding results directly into a reporting task. This is needed to support simple ad-hoc measurements that report data immediately (the help-desk use case). Right now, it is unclear and/or cumbersome to support this use case (in which two schedule objects are involved). The third possible execution model is that all tasks are started concurrently, in Unix shell syntax: a_1 & a_2 & ... & a_n & This may appear a bit less useful to have but there are situations where this is actually useful (e.g., if you want to start N long running passive monitoring tasks from a schedule bound to a startup timing object; right now you have to create N different schedules (because schedules are executed in parallel). Our proposal is thus to change the information model and the data model to support all three types of invocations. If done properly, it may even be possible to mix things, e.g. a_1 & a_2 | a_3; a_4 (Start a_1 but do not wait for completion, run a_2 and feed the output into a_3, once a_3 is done, run a_4.) To support this, it is necessary to add another element to ma-action-obj indicating whether the action is executed sequentially, concurrently, or as part of a pipe. 2) Remove the notion of multiple task outputs. Compensate that by having a tag in every result row and allow filter tasks. During implementation, we found it complicated to deal with multiple task outputs. It is also unclear how one discovers the outputs supported by a given task. We find the model used by at least one large scale measurement platform way simpler to work with. On that platform, every result row carries a tag that identifies the type of a result row. A measurement task that can measure different metrics simply creates differently tagged result rows. Since we have moved to a generic model where tasks can also act as filters, it seems easier to have only a single output for task and to use filters to filter output that is not needed in a task processing chain. In other words, instead of having an action a_1 in schedule s_1 feedings different output to other actions in other schedules s_1: a_1 -o_2-> s_2.a_2, -o_3-> s_3.a_2 we would do s_1: a_1 -> s_2.a_1, -> s_3.a_1 s_2: a_1 | a_2 s_3: a_1 | a_2 where s_2.a_1 and s_3.a_1 are acting as filters. We found that the proposed model simplifies implementation and at the same time adds flexibility (since filtering can be more flexible than hard wired task outputs). Of course, this requires to have a mechanism in place to pipeline data. 3) Remove the feature to forward task output to a specific action within a schedule; instead output is directed to another schedule. Right now, data is moved from a source task in an action list of a schedule to a receiving task in an action list of another schedule. It is unclear why this is useful; we had trouble finding convincing use cases. It seems that it is sufficient to forward to the first task of a different schedule only. This simplifies the data (and information model). To continue the previous example, we propose to reduce things to this: s_1: a_1 -> s_2, -> s_3 s_2: a_1 | a_2 s_3: a_1 | a_2 The proposed changes 2) and 3) together allow to eliminate ma-action-dest-obj and to replace it with a list of ma-action-dest-schedule-name values in the ma-action-obj. 4) Timing should be generalized to events. There was a comment at the last IETF meetings that IEEE likes to bind the invocation of measurements to events such as reaching a certain location. Other people commented that they like to bind the execution of measurements to the status of certain interfaces (e.g., run the connectivity test when the WAN interface changes into the 'up' state). To accommodate future extension in this direction, we propose to change the information model and the data model such that schedules are a list of actions bound to an event. Timing objects like periodic and calendar or one-off timings simply generate events. The existing startup and immediate timing objects effectively are not timing objects but events. This is mostly an editorial change but it supports future extensibility for other event sources. 5) Separate the reporting of meta-information (possibly verbose since it includes all options) from the reporting of results to make result reports more efficient. Right now, the information model mandates that every report contains the complete task configuration so that results can be interpreted correctly. This, however, introduces significant overhead. Assuming that task configurations change rarely compared to the frequency with which we ship result records, we propose to decouple things. This allows to send meta-information at a low frequency or only when it changes. (This separation has already proven useful in IPFIX where templates are send less frequently than data records.) This change is relatively trivial to implement; simply reorganize the ma-report-obj and ma-report-task-obj. 6) Change timers to use meaningful units rather than milliseconds everywhere. Right now, all timers or timeouts use the same unit (milliseconds). This is, however, not a suitable unit for some of the timers or timeouts (e.g., ma-controller-lost-timeout). We propose to use units that a meaningful for the specific information model element instead of using the highest resolution possible everywhere. This change is relatively trivial to implement. X) The structural changes would be roughly: object { string ma-action-name; string ma-action-task-name; + enumeration ma-action-exec-type; [ma-option-obj ma-action-task-options<0..*>]; - [ma-action-dest-obj ma-action-destinations<0..*>;] + [string ma-action-sendto-schedule<0..*>;] } ma-action-obj; - object { - string ma-action-dest-schedule-name; - string ma-action-dest-action-name; - [int ma-action-dest-action-outputs<0..*>;] - } ma-action-dest-obj; object { datetime ma-report-date; [uuid ma-report-agent-id;] [string ma-report-group-id;] [ma-report-task-obj ma-report-tasks<0..*>]; + [ma-report-row-obj ma-report-data<0..*>]; } ma-report-obj; object { string ma-report-task-name; [uri ma-report-task-registry-entry;] [ma-option-obj ma-report-scheduled-task-options<0..*>]; [string ma-report-task-cycle-id;] string ma-report-task-column-labels<0..*>; - ma-report-row-obj ma-report-task-rows<0..*>; } ma-report-task-obj; object { datetime ma-report-result-start-time; [datetime ma-report-result-end-time;] string ma-report-result-conflicts<0..*>; + string ma-report-result-tag; data ma-report-result-values<0..*>; } ma-report-row-obj; /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 17 00:32:50 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F291ACF04; Fri, 17 Apr 2015 00:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS1aIr7fAWno; Fri, 17 Apr 2015 00:32:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C43751B2A29; Fri, 17 Apr 2015 00:32:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150417073244.23514.76246.idtracker@ietfa.amsl.com> Date: Fri, 17 Apr 2015 00:32:44 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-framework-13.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 07:32:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance Working Group of the IETF. Title : A framework for Large-Scale Measurement of Broadband Performance (LMAP) Authors : Philip Eardley Al Morton Marcelo Bagnulo Trevor Burbridge Paul Aitken Aamer Akhter Filename : draft-ietf-lmap-framework-13.txt Pages : 58 Date : 2015-04-17 Abstract: Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (Large-Scale Measurement of Broadband Performance). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-framework-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 17 02:21:26 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5971E1A90C1 for ; Fri, 17 Apr 2015 02:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ft0GQrbGS61L for ; Fri, 17 Apr 2015 02:21:22 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904091A90A7 for ; Fri, 17 Apr 2015 02:21:21 -0700 (PDT) Received: from EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 17 Apr 2015 10:21:12 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 17 Apr 2015 10:21:10 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 17 Apr 2015 10:21:09 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Fri, 17 Apr 2015 10:21:09 +0100 From: To: Thread-Topic: [lmap] I-D Action: draft-ietf-lmap-framework-13.txt Thread-Index: AQHQeODAuRx8NLYxzU2gDE/wh0kJxZ1Q7aZw Date: Fri, 17 Apr 2015 09:21:09 +0000 Message-ID: References: <20150417073244.23514.76246.idtracker@ietfa.amsl.com> In-Reply-To: <20150417073244.23514.76246.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] I-D Action: draft-ietf-lmap-framework-13.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 09:21:24 -0000 This version handles the IESG review comments - we didn't get any DISCUSS Best wishes, phil > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 17 April 2015 08:33 > To: i-d-announce@ietf.org > Cc: lmap@ietf.org > Subject: [lmap] I-D Action: draft-ietf-lmap-framework-13.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Large-Scale Measurement of Broadband > Performance Working Group of the IETF. >=20 > Title : A framework for Large-Scale Measurement of > Broadband Performance (LMAP) > Authors : Philip Eardley > Al Morton > Marcelo Bagnulo > Trevor Burbridge > Paul Aitken > Aamer Akhter > Filename : draft-ietf-lmap-framework-13.txt > Pages : 58 > Date : 2015-04-17 >=20 > Abstract: > Measuring broadband service on a large scale requires a description > of the logical architecture and standardisation of the key protocols > that coordinate interactions between the components. The document > presents an overall framework for large-scale measurements. It also > defines terminology for LMAP (Large-Scale Measurement of Broadband > Performance). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-lmap-framework-13 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-framework-13 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Sun Apr 19 15:47:57 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B0E1A904F for ; Sun, 19 Apr 2015 15:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFqAXbpi75nU for ; Sun, 19 Apr 2015 15:47:51 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 551551A904C for ; Sun, 19 Apr 2015 15:47:51 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 9442C120BDC; Sun, 19 Apr 2015 19:06:19 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-blue.research.att.com (Postfix) with ESMTP id B1F54F04A0; Sun, 19 Apr 2015 18:47:50 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Sun, 19 Apr 2015 18:47:32 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , "lmap@ietf.org" Date: Sun, 19 Apr 2015 18:44:54 -0400 Thread-Topic: [lmap] proposed information model / data model changes Thread-Index: AdB4fFi6NHyjrEzlT9m3maGfCd+kMgCdhuTj Message-ID: <4AF73AA205019A4C8A1DDD32C034631D020F956C8B@NJFPSRVEXG0.research.att.com> References: <20150416193353.GA6290@elstar.local> In-Reply-To: <20150416193353.GA6290@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] proposed information model / data model changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 22:47:54 -0000 Hi Juergen, you wrote: ... 2) Remove the notion of multiple task outputs. Compensate that by having a tag in every result row and allow filter tasks. During implementation, we found it complicated to deal with multiple task outputs. It is also unclear how one discovers the outputs supported by a given task. We find the model used by at least one large scale measurement platform way simpler to work with. On that platform, every result row carries a tag that identifies the type of a result row. A measurement task that can measure different metrics simply creates differently tagged result rows. Since we have moved to a generic model where tasks can also act as filters, it seems easier to have only a single output for task and to use filters to filter output that is not needed in a task processing chain. In other words, instead of having an action a_1 in schedule s_1 feedings different output to other actions in other schedules s_1: a_1 -o_2-> s_2.a_2, -o_3-> s_3.a_2 we would do s_1: a_1 -> s_2.a_1, -> s_3.a_1 s_2: a_1 | a_2 s_3: a_1 | a_2 where s_2.a_1 and s_3.a_1 are acting as filters. We found that the proposed model simplifies implementation and at the same time adds flexibility (since filtering can be more flexible than hard wired task outputs). Of course, this requires to have a mechanism in place to pipeline data. ... Last week, I started to see a related issue with another part of=20 supporting picture for LMAP. It's in the way we have the=20 performance metrics registry is organized. The info model says, in section 3: 3. Task Configurations. A set of Task Configurations is used to configure the Tasks that are run by the MA. This includes _the_ _registry_entry for the Task and any configuration parameters. I take this to mean that each task can have one registry entry.=20 We have organized the performance metrics registry so that each entry for *active* metrics and methods will describe the packet stream to be sent and a *single* form of output result.=20 We are also likely to have some sets of registry entries that use=20 identical stream characteristics, but produce different results. Results like mean delay, 95th %-time of delay variation, loss ratio, and others could all use the same stream. In fact, we want to avoid having the MA interpret that each task/registry entry with the=20 *same* stream specification would each produce its own stream when all we want is four or five different metrics measured at the same time. So, I see the problem shaping-up differently, if I understood your scenario. Rather than tasks with multiple outputs, I imagined multiple tasks/registry entries that have a single output,=20 but ideally depend on a single measurement resource, the=20 packet stream. In the output, I think we both want: ID Time Stream Result tag Result =20 01 01:00 100pps Loss_Ratio 0.001 01 01:00 100pps Mean_delay 0.015 01 01:00 100pps PDV_95% 0.030 01 ... where "ID" groups these measurements and results. If the task configuration provided a common ID, we would be able to combine measurements on a single stream when desired, or measure on separate streams if two tasks had different IDs. OTOH, if we can somehow combine tasks to share resources already, then there would likely be multiple outputs, and I support your proposal. regards, Al ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder [j.sc= hoenwaelder@jacobs-university.de] Sent: Thursday, April 16, 2015 3:33 PM To: lmap@ietf.org Subject: [lmap] proposed information model / data model changes Hi, we are working on an implementation of the data model and we found a couple of things non-intuitive or more difficult to implement than needed or complex to use for certain use cases. After discussing things for a while internally, we consolidated our thoughts in the following list of proposed changes. Note that some of the listed changes 1)-6) interact. I would be nice if could get feedback quickly so we can get our code do the 'right' thing. 1) Execution model for actions: A schedule has a list of task with parameters (we call them actions). The info model currently says that the tasks are executed sequentially. Or in Unix shell syntax, the actions a_1 to a_n are executed as follows: a_1; a_2; ...; a_n There is no data passed between the actions in the above example (unless you configure specific action destinations options). We believe there are other execution models that should be supported, in particular the piped model where data flows from one task to the next task: a_1 | a_2 | ... | a_n The prime use case is to have a measurement task feeding results directly into a reporting task. This is needed to support simple ad-hoc measurements that report data immediately (the help-desk use case). Right now, it is unclear and/or cumbersome to support this use case (in which two schedule objects are involved). The third possible execution model is that all tasks are started concurrently, in Unix shell syntax: a_1 & a_2 & ... & a_n & This may appear a bit less useful to have but there are situations where this is actually useful (e.g., if you want to start N long running passive monitoring tasks from a schedule bound to a startup timing object; right now you have to create N different schedules (because schedules are executed in parallel). Our proposal is thus to change the information model and the data model to support all three types of invocations. If done properly, it may even be possible to mix things, e.g. a_1 & a_2 | a_3; a_4 (Start a_1 but do not wait for completion, run a_2 and feed the output into a_3, once a_3 is done, run a_4.) To support this, it is necessary to add another element to ma-action-obj indicating whether the action is executed sequentially, concurrently, or as part of a pipe. 2) Remove the notion of multiple task outputs. Compensate that by having a tag in every result row and allow filter tasks. During implementation, we found it complicated to deal with multiple task outputs. It is also unclear how one discovers the outputs supported by a given task. We find the model used by at least one large scale measurement platform way simpler to work with. On that platform, every result row carries a tag that identifies the type of a result row. A measurement task that can measure different metrics simply creates differently tagged result rows. Since we have moved to a generic model where tasks can also act as filters, it seems easier to have only a single output for task and to use filters to filter output that is not needed in a task processing chain. In other words, instead of having an action a_1 in schedule s_1 feedings different output to other actions in other schedules s_1: a_1 -o_2-> s_2.a_2, -o_3-> s_3.a_2 we would do s_1: a_1 -> s_2.a_1, -> s_3.a_1 s_2: a_1 | a_2 s_3: a_1 | a_2 where s_2.a_1 and s_3.a_1 are acting as filters. We found that the proposed model simplifies implementation and at the same time adds flexibility (since filtering can be more flexible than hard wired task outputs). Of course, this requires to have a mechanism in place to pipeline data. 3) Remove the feature to forward task output to a specific action within a schedule; instead output is directed to another schedule. Right now, data is moved from a source task in an action list of a schedule to a receiving task in an action list of another schedule. It is unclear why this is useful; we had trouble finding convincing use cases. It seems that it is sufficient to forward to the first task of a different schedule only. This simplifies the data (and information model). To continue the previous example, we propose to reduce things to this: s_1: a_1 -> s_2, -> s_3 s_2: a_1 | a_2 s_3: a_1 | a_2 The proposed changes 2) and 3) together allow to eliminate ma-action-dest-obj and to replace it with a list of ma-action-dest-schedule-name values in the ma-action-obj. 4) Timing should be generalized to events. There was a comment at the last IETF meetings that IEEE likes to bind the invocation of measurements to events such as reaching a certain location. Other people commented that they like to bind the execution of measurements to the status of certain interfaces (e.g., run the connectivity test when the WAN interface changes into the 'up' state). To accommodate future extension in this direction, we propose to change the information model and the data model such that schedules are a list of actions bound to an event. Timing objects like periodic and calendar or one-off timings simply generate events. The existing startup and immediate timing objects effectively are not timing objects but events. This is mostly an editorial change but it supports future extensibility for other event sources. 5) Separate the reporting of meta-information (possibly verbose since it includes all options) from the reporting of results to make result reports more efficient. Right now, the information model mandates that every report contains the complete task configuration so that results can be interpreted correctly. This, however, introduces significant overhead. Assuming that task configurations change rarely compared to the frequency with which we ship result records, we propose to decouple things. This allows to send meta-information at a low frequency or only when it changes. (This separation has already proven useful in IPFIX where templates are send less frequently than data records.) This change is relatively trivial to implement; simply reorganize the ma-report-obj and ma-report-task-obj. 6) Change timers to use meaningful units rather than milliseconds everywhere. Right now, all timers or timeouts use the same unit (milliseconds). This is, however, not a suitable unit for some of the timers or timeouts (e.g., ma-controller-lost-timeout). We propose to use units that a meaningful for the specific information model element instead of using the highest resolution possible everywhere. This change is relatively trivial to implement. X) The structural changes would be roughly: object { string ma-action-name; string ma-action-task-name; + enumeration ma-action-exec-type; [ma-option-obj ma-action-task-options<0..*>]; - [ma-action-dest-obj ma-action-destinations<0..*>;] + [string ma-action-sendto-schedule<0..*>;] } ma-action-obj; - object { - string ma-action-dest-schedule-name; - string ma-action-dest-action-name; - [int ma-action-dest-action-outputs<0..*>;] - } ma-action-dest-obj; object { datetime ma-report-date; [uuid ma-report-agent-id;] [string ma-report-group-id;] [ma-report-task-obj ma-report-tasks<0..*>]; + [ma-report-row-obj ma-report-data<0..*>]; } ma-report-obj; object { string ma-report-task-name; [uri ma-report-task-registry-entry;] [ma-option-obj ma-report-scheduled-task-options<0..*>]; [string ma-report-task-cycle-id;] string ma-report-task-column-labels<0..*>; - ma-report-row-obj ma-report-task-rows<0..*>; } ma-report-task-obj; object { datetime ma-report-result-start-time; [datetime ma-report-result-end-time;] string ma-report-result-conflicts<0..*>; + string ma-report-result-tag; data ma-report-result-values<0..*>; } ma-report-row-obj; /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Apr 20 03:26:12 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD991B29EF for ; Mon, 20 Apr 2015 03:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJWNoY5OlbB4 for ; Mon, 20 Apr 2015 03:26:10 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2CCD1A1A62 for ; Mon, 20 Apr 2015 03:26:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4GABvTNFXGmAcV/2dsb2JhbABbgkUhJlJhs2cBAQEBAQYFmTMCgTFMAQEBAQEBfoQiAQEDEhteAQwJFVYmAQQbGogJAaUjhQWebQwBH4YWiXSDT4EWBZEri0CDPIJhihiDTiKDc4IzgQABAQE X-IronPort-AV: E=Sophos; i="5.11,609,1422939600"; d="scan'208,217"; a="99355472" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Apr 2015 06:26:07 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 20 Apr 2015 06:26:06 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Mon, 20 Apr 2015 06:26:04 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP WG Virtual Interim Meeting - Monday 5/11 1-3PM EDT Thread-Index: AdB7VGekulgMKCWYTj6M/K1MrDDX6g== Date: Mon, 20 Apr 2015 10:26:04 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9F77C7@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C9F77C7AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP WG Virtual Interim Meeting - Monday 5/11 1-3PM EDT X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 10:26:11 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9F77C7AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Doodle has spoken and the majority of the respondents chose Monday 5/11, 1-= 3PM EDT as the date and time for the next Virtual Interim meeting of the LM= AP WG. Please mark this in your calendars. The Secretariat announcement wit= h the Webex details should follow shortly. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9F77C7AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Doodle has spoken and the majority of the respondent= s chose Monday 5/11, 1-3PM EDT as the date and time for the next Virtual In= terim meeting of the LMAP WG. Please mark this in your calendars. The Secre= tariat announcement with the Webex details should follow shortly.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C9F77C7AZFFEXMB04globa_-- From nobody Mon Apr 20 13:49:59 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224DD1B317C; Mon, 20 Apr 2015 13:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H-LGwCmBm_a; Mon, 20 Apr 2015 13:49:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 071701B317A; Mon, 20 Apr 2015 13:49:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150420204957.30653.60169.idtracker@ietfa.amsl.com> Date: Mon, 20 Apr 2015 13:49:57 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] LMAP WG Virtual Interim Meeting: 11 May 2015 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 20:49:58 -0000 The Large-Scale Measurement of Broadband Performance (lmap) working group will hold a virtual interim meeting as follows: Date: Monday, 11 May 2015 Time: 1300-1500 EDT(1700-1900 UTC) Join WebEx Meeting: https://ietf.webex.com/ietf/j.php?MTID=m6e7cba82289b469dca036280cea9b029 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 642 084 847 From nobody Wed Apr 22 03:11:20 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177BD1A6EE8 for ; Wed, 22 Apr 2015 03:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rA3oPx8YGS5M for ; Wed, 22 Apr 2015 03:11:15 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79581A0338 for ; Wed, 22 Apr 2015 03:11:14 -0700 (PDT) Received: from EVMHT04-UKBR.domain1.systemhost.net (193.113.108.57) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 22 Apr 2015 11:11:11 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVMHT04-UKBR.domain1.systemhost.net (193.113.108.57) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 22 Apr 2015 11:11:12 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 22 Apr 2015 11:11:11 +0100 Received: from rew09926dag03c.domain1.systemhost.net ([fe80::bd0c:3548:7105:cecb]) by rew09926dag03c.domain1.systemhost.net ([fe80::bd0c:3548:7105:cecb%12]) with mapi id 15.00.0995.031; Wed, 22 Apr 2015 11:11:11 +0100 From: To: , Thread-Topic: [lmap] proposed information model / data model changes Thread-Index: AQHQeHxSbh0oFmbCcUSpwpDtNXfHDp1Yzf2g Date: Wed, 22 Apr 2015 10:11:10 +0000 Message-ID: References: <20150416193353.GA6290@elstar.local> In-Reply-To: <20150416193353.GA6290@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] proposed information model / data model changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 10:11:19 -0000 1) Execution model: Sounds like a nice idea if people don't find it too con= fusing and it's easy to implement (in code, not in the information model).= =20 2) Task outputs: I agree multiple task outputs have always been quite diffi= cult. The bit of the picture that is missing is that tasks could have confi= guration parameters to indicate which tags they use/filter. 3) Output to Schedule: Generally I think this can work - e.g. having a post= -processing or reporting task on a delayed schedule. If we really think thi= s makes things easier then OK. Overall I can see that the new suggestions 1-3 can work. I guess I'm unclea= r whether they a) make things easier to understand and b) are actually easy= to implement. 4) Timing as events: OK. I think this is just semantics and it probably doe= s makes more sense to think of things like 'startup' as an event rather tha= n a timing. 5) Reporting of metadata: There is an incorrect assumption that all the tas= k configurations have to be reported. It is explained that this is a choice= of the reporting task and can be configured with an option on more complex= reporting tasks. So a reporting task can already do what you suggest: i.e.= send metadata only when it changes. I'm not sure I want to lose the abilit= y to include the metadata in the same report as the results - this makes it= easy for a Collector to de-normalise settings into the result data if requ= ired rather than having to look up the current applied metadata in order to= be able to perform such enhancement. 6) different timing units: no strong opinion. I don't see it really improve= s things much to have coarse units (e.g. seconds) though. Trevor. -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: 16 April 2015 20:34 To: lmap@ietf.org Subject: [lmap] proposed information model / data model changes Hi, we are working on an implementation of the data model and we found a couple of things non-intuitive or more difficult to implement than needed or complex to use for certain use cases. After discussing things for a while internally, we consolidated our thoughts in the following list of proposed changes. Note that some of the listed changes 1)-6) interact. I would be nice if could get feedback quickly so we can get our code do the 'right' thing. 1) Execution model for actions: A schedule has a list of task with parameters (we call them actions). The info model currently says that the tasks are executed sequentially. Or in Unix shell syntax, the actions a_1 to a_n are executed as follows: a_1; a_2; ...; a_n There is no data passed between the actions in the above example (unless you configure specific action destinations options). We believe there are other execution models that should be supported, in particular the piped model where data flows from one task to the next task: a_1 | a_2 | ... | a_n The prime use case is to have a measurement task feeding results directly into a reporting task. This is needed to support simple ad-hoc measurements that report data immediately (the help-desk use case). Right now, it is unclear and/or cumbersome to support this use case (in which two schedule objects are involved). The third possible execution model is that all tasks are started concurrently, in Unix shell syntax: a_1 & a_2 & ... & a_n & This may appear a bit less useful to have but there are situations where this is actually useful (e.g., if you want to start N long running passive monitoring tasks from a schedule bound to a startup timing object; right now you have to create N different schedules (because schedules are executed in parallel). Our proposal is thus to change the information model and the data model to support all three types of invocations. If done properly, it may even be possible to mix things, e.g. a_1 & a_2 | a_3; a_4 (Start a_1 but do not wait for completion, run a_2 and feed the output into a_3, once a_3 is done, run a_4.) To support this, it is necessary to add another element to ma-action-obj indicating whether the action is executed sequentially, concurrently, or as part of a pipe. 2) Remove the notion of multiple task outputs. Compensate that by having a tag in every result row and allow filter tasks. During implementation, we found it complicated to deal with multiple task outputs. It is also unclear how one discovers the outputs supported by a given task. We find the model used by at least one large scale measurement platform way simpler to work with. On that platform, every result row carries a tag that identifies the type of a result row. A measurement task that can measure different metrics simply creates differently tagged result rows. Since we have moved to a generic model where tasks can also act as filters, it seems easier to have only a single output for task and to use filters to filter output that is not needed in a task processing chain. In other words, instead of having an action a_1 in schedule s_1 feedings different output to other actions in other schedules s_1: a_1 -o_2-> s_2.a_2, -o_3-> s_3.a_2 we would do s_1: a_1 -> s_2.a_1, -> s_3.a_1 s_2: a_1 | a_2 s_3: a_1 | a_2 where s_2.a_1 and s_3.a_1 are acting as filters. We found that the proposed model simplifies implementation and at the same time adds flexibility (since filtering can be more flexible than hard wired task outputs). Of course, this requires to have a mechanism in place to pipeline data. 3) Remove the feature to forward task output to a specific action within a schedule; instead output is directed to another schedule. Right now, data is moved from a source task in an action list of a schedule to a receiving task in an action list of another schedule. It is unclear why this is useful; we had trouble finding convincing use cases. It seems that it is sufficient to forward to the first task of a different schedule only. This simplifies the data (and information model). To continue the previous example, we propose to reduce things to this: s_1: a_1 -> s_2, -> s_3 s_2: a_1 | a_2 s_3: a_1 | a_2 The proposed changes 2) and 3) together allow to eliminate ma-action-dest-obj and to replace it with a list of ma-action-dest-schedule-name values in the ma-action-obj. 4) Timing should be generalized to events. There was a comment at the last IETF meetings that IEEE likes to bind the invocation of measurements to events such as reaching a certain location. Other people commented that they like to bind the execution of measurements to the status of certain interfaces (e.g., run the connectivity test when the WAN interface changes into the 'up' state). To accommodate future extension in this direction, we propose to change the information model and the data model such that schedules are a list of actions bound to an event. Timing objects like periodic and calendar or one-off timings simply generate events. The existing startup and immediate timing objects effectively are not timing objects but events. This is mostly an editorial change but it supports future extensibility for other event sources. 5) Separate the reporting of meta-information (possibly verbose since it includes all options) from the reporting of results to make result reports more efficient. Right now, the information model mandates that every report contains the complete task configuration so that results can be interpreted correctly. This, however, introduces significant overhead. Assuming that task configurations change rarely compared to the frequency with which we ship result records, we propose to decouple things. This allows to send meta-information at a low frequency or only when it changes. (This separation has already proven useful in IPFIX where templates are send less frequently than data records.) This change is relatively trivial to implement; simply reorganize the ma-report-obj and ma-report-task-obj. 6) Change timers to use meaningful units rather than milliseconds everywhere. Right now, all timers or timeouts use the same unit (milliseconds). This is, however, not a suitable unit for some of the timers or timeouts (e.g., ma-controller-lost-timeout). We propose to use units that a meaningful for the specific information model element instead of using the highest resolution possible everywhere. This change is relatively trivial to implement. X) The structural changes would be roughly: object { string ma-action-name; string ma-action-task-name; + enumeration ma-action-exec-type; [ma-option-obj ma-action-task-options<0..*>]; - [ma-action-dest-obj ma-action-destinations<0..*>;]=09 + [string ma-action-sendto-schedule<0..*>;] } ma-action-obj; - object { - string ma-action-dest-schedule-name; - string ma-action-dest-action-name; - [int ma-action-dest-action-outputs<0..*>;] - } ma-action-dest-obj; object { datetime ma-report-date; [uuid ma-report-agent-id;] [string ma-report-group-id;] [ma-report-task-obj ma-report-tasks<0..*>]; + [ma-report-row-obj ma-report-data<0..*>]; } ma-report-obj; object { string ma-report-task-name; [uri ma-report-task-registry-entry;] [ma-option-obj ma-report-scheduled-task-options<0..*>]; [string ma-report-task-cycle-id;] string ma-report-task-column-labels<0..*>; - ma-report-row-obj ma-report-task-rows<0..*>; } ma-report-task-obj; object { datetime ma-report-result-start-time; [datetime ma-report-result-end-time;] string ma-report-result-conflicts<0..*>; + string ma-report-result-tag; data ma-report-result-values<0..*>; } ma-report-row-obj; /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Apr 27 02:08:47 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF841B2F56 for ; Mon, 27 Apr 2015 02:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3cbf4rUMOKf for ; Mon, 27 Apr 2015 02:08:44 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C54E1B2F52 for ; Mon, 27 Apr 2015 02:08:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAFT7PVXGmAcV/2dsb2JhbABcgkUhJlNhtEcFAQaZQQKBMEwBAQEBAQGBC4QiAQEDEhteARUVViYBBBsaiAkBoWeFBp4mDAEfhhaJdoNPgRYFkVWSCI4SI2CDFIIzgQABAQE X-IronPort-AV: E=Sophos;i="5.11,655,1422939600"; d="scan'208,217";a="113829700" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Apr 2015 05:08:43 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 27 Apr 2015 05:08:43 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Mon, 27 Apr 2015 05:08:41 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP WG meeting at IETF 93 Thread-Index: AdCAycENr4vPY0N7QYe7s0TwAcfDWQ== Date: Mon, 27 Apr 2015 09:08:41 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9FFFF3@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C9FFFF3AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP WG meeting at IETF 93 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 09:08:46 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9FFFF3AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It's time to discuss scheduling of the meeting for the LMAP WG at IETF 93. - Should we ask for a similar meeting slot as at the last few IETF= meetings (one 2.5 hours meeting slot)? - Are there any new conflicts that we MUST avoid? Are there any ol= der conflicts that we can take out of the conflicts (or at least critical c= onflicts) list? - Agenda items Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C9FFFF3AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

It’s time to discuss scheduling of the meeting= for the LMAP WG at IETF 93.

 

-     &= nbsp;    Should we ask for a simila= r meeting slot as at the last few IETF meetings (one 2.5 hours meeting slot= )?

-     &= nbsp;    Are there any new conflict= s that we MUST avoid? Are there any older conflicts that we can take out of= the conflicts (or at least critical conflicts) list?

-     &= nbsp;    Agenda items

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C9FFFF3AZFFEXMB04globa_-- From nobody Wed Apr 29 06:22:07 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D42C1A90AD; Wed, 29 Apr 2015 06:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mW0mUcNyjuIl; Wed, 29 Apr 2015 06:22:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9E51A912B; Wed, 29 Apr 2015 06:22:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150429132201.28596.50044.idtracker@ietfa.amsl.com> Date: Wed, 29 Apr 2015 06:22:01 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-framework-14.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 13:22:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance Working Group of the IETF. Title : A framework for Large-Scale Measurement of Broadband Performance (LMAP) Authors : Philip Eardley Al Morton Marcelo Bagnulo Trevor Burbridge Paul Aitken Aamer Akhter Filename : draft-ietf-lmap-framework-14.txt Pages : 58 Date : 2015-04-29 Abstract: Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (Large-Scale Measurement of Broadband Performance). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-framework-14 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 29 06:26:20 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDDC1B2CC0 for ; Wed, 29 Apr 2015 06:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eZJslSiea4u for ; Wed, 29 Apr 2015 06:26:17 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B4C1A913A for ; Wed, 29 Apr 2015 06:26:16 -0700 (PDT) Received: from E07HT02-UKBR.domain1.systemhost.net (193.113.197.160) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 29 Apr 2015 14:26:13 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by E07HT02-UKBR.domain1.systemhost.net (193.113.197.160) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 29 Apr 2015 14:26:14 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 29 Apr 2015 14:26:14 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Wed, 29 Apr 2015 14:26:14 +0100 From: To: Thread-Topic: [lmap] I-D Action: draft-ietf-lmap-framework-14.txt Thread-Index: AQHQgn+MDaIMxGgxM0mk1Tg/qGllLp1j+oCw Date: Wed, 29 Apr 2015 13:26:13 +0000 Message-ID: References: <20150429132201.28596.50044.idtracker@ietfa.amsl.com> In-Reply-To: <20150429132201.28596.50044.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lmap] FW: I-D Action: draft-ietf-lmap-framework-14.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 13:26:19 -0000 This version just fixes an issue that crept into fig 1 in v-13 The new figure keeps the LMAP labels (MA, MP) inside the LMAP scope part of= the picture. Thanks, phil -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: 29 April 2015 14:22 To: i-d-announce@ietf.org Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-framework-14.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Large-Scale Measurement of Broadband Perf= ormance Working Group of the IETF. Title : A framework for Large-Scale Measurement of Broadb= and Performance (LMAP) Authors : Philip Eardley Al Morton Marcelo Bagnulo Trevor Burbridge Paul Aitken Aamer Akhter Filename : draft-ietf-lmap-framework-14.txt Pages : 58 Date : 2015-04-29 Abstract: Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (Large-Scale Measurement of Broadband Performance). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-framework-14 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-framework-14 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Apr 29 09:50:51 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21EC1A8978; Wed, 29 Apr 2015 09:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itwp55Aiw5lN; Wed, 29 Apr 2015 09:50:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 645601AC7E7; Wed, 29 Apr 2015 09:50:42 -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: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150429165042.20636.3567.idtracker@ietfa.amsl.com> Date: Wed, 29 Apr 2015 09:50:42 -0700 Archived-At: Cc: lmap mailing list , lmap chair , RFC Editor Subject: [lmap] Document Action: 'A framework for Large-Scale Measurement of Broadband Performance (LMAP)' to Informational RFC (draft-ietf-lmap-framework-14.txt) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 16:50:49 -0000 The IESG has approved the following document: - 'A framework for Large-Scale Measurement of Broadband Performance (LMAP)' (draft-ietf-lmap-framework-14.txt) as Informational RFC This document is the product of the Large-Scale Measurement of Broadband Performance Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ Technical Summary Measuring broadband service on a large scale requires a description of the logical architecture and standardization of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (large-scale measurement platforms). Working Group Summary The Working Group process was serious and a relative large number of participants participated. Some of the points that required clarification and further editing were related to passive monitoring and to privacy. ll ended in consensus behind the document as it was forwarded for approval and publication. Document Quality The document was very carefully reviewed and discussed by a large number of participants in the WG, because it contains key information concerning the scope, architecture and components of the recommended solutions. Several issues were debated for many months, the resulting document includes a strong consensus of the participants about the goals (and non goals) of LMAP and the path to be taken by the IETF to provide a standard solution. Personnel Dan Romascanu is the document shepherd. Benoit Claise is the responsible Area Director. From nobody Thu Apr 30 02:39:50 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55021ACE77 for ; Thu, 30 Apr 2015 02:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WP1W59fQ_0K3 for ; Thu, 30 Apr 2015 02:39:47 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018A61ACEF0 for ; Thu, 30 Apr 2015 02:39:46 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 671EAFB3; Thu, 30 Apr 2015 11:39:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id QO9ng_Ib0jun; Thu, 30 Apr 2015 11:39:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 30 Apr 2015 11:39:43 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32C682002C; Thu, 30 Apr 2015 11:39:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HRvBcxPUPzF5; Thu, 30 Apr 2015 11:39:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC2512002B; Thu, 30 Apr 2015 11:39:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0BC6632F4807; Thu, 30 Apr 2015 11:39:39 +0200 (CEST) Date: Thu, 30 Apr 2015 11:39:39 +0200 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20150430093939.GA2080@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, lmap@ietf.org References: <20150416193353.GA6290@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] proposed information model / data model changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 09:39:49 -0000 On Wed, Apr 22, 2015 at 10:11:10AM +0000, trevor.burbridge@bt.com wrote: > > 5) Reporting of metadata: There is an incorrect assumption that all the task configurations have to be reported. It is explained that this is a choice of the reporting task and can be configured with an option on more complex reporting tasks. So a reporting task can already do what you suggest: i.e. send metadata only when it changes. I'm not sure I want to lose the ability to include the metadata in the same report as the results - this makes it easy for a Collector to de-normalise settings into the result data if required rather than having to look up the current applied metadata in order to be able to perform such enhancement. Yes, I checked the text again and this was a misunderstanding on our side. That said, it remains unclear how this is configured. The text is simply saying referring to "setting a configurable parameter in the Task Configuration" and I guess our confusion comes from the fact that there is no such parameter defined in the information model. Anyway, looking at the object definitions, it seems that ma-report-obj includes an optional sequence of ma-report-task-obj and ma-report-task-obj in turn includes a mandatory sequence of ma-report-row-obj (but the sequence is allowed to be empty). Would it not make more sense to change ma-report-task-obj as follows object { string ma-report-task-name; [uri ma-report-task-registry-entry;] [ma-option-obj ma-report-scheduled-task-options<0..*>]; [string ma-report-task-cycle-id;] [string ma-report-task-column-labels<0..*>;] [ma-report-row-obj ma-report-task-rows<0..*>;] } ma-report-task-obj; to mark ma-report-task-column-labels and ma-report-task-rows more clearly as optional? > 6) different timing units: no strong opinion. I don't see it really > improves things much to have coarse units (e.g. seconds) though. It likely does not make much sense to configure, for example, ma-controller-lost-timeout in milliseconds granularity but right now you require an implementation to implement a milliseconds granularity (or to cheat by simply rounding things up to something like seconds granularity). In other words, the model allows likely not useful configurations (or even harmful configuration errors) and the model raise the implementation requirements to support somewhat questionable and potentially harmful settings. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Apr 30 05:23:35 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9A21AD289 for ; Thu, 30 Apr 2015 05:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPDKbOb2lX0n for ; Thu, 30 Apr 2015 05:23:32 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBAF1A8830 for ; Thu, 30 Apr 2015 05:23:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIFAIYdQlWHCzIm/2dsb2JhbABcgmYmU1wFs1oBAQEBAQEGk0CGBAKBTUwBAQEBAQGBC4QgAQEBAQMSKDQXBAIBCA0EAQMBAQsUBQQHMhQDBAEBBQMCBBMIEweICQEMqRCeHgEBAQEBBQEBAQEBAQEBAQEBEwSGFoUihFQ4BoMRgRYFkWqECY4TjikjYIFYgTxvgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.11,676,1422939600"; d="scan'208";a="118209926" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 30 Apr 2015 08:23:30 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 30 Apr 2015 08:23:30 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Thu, 30 Apr 2015 14:23:29 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [lmap] Document Action: 'A framework for Large-Scale Measurement of Broadband Performance (LMAP)' to Informational RFC (draft-ietf-lmap-framework-14.txt) Thread-Index: AQHQgpynfmSue5C3/0mqdI6ohZDdkZ1le4WA Date: Thu, 30 Apr 2015 12:23:28 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA1343A@AZ-FFEXMB04.global.avaya.com> References: <20150429165042.20636.3567.idtracker@ietfa.amsl.com> In-Reply-To: <20150429165042.20636.3567.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lmap] FW: Document Action: 'A framework for Large-Scale Measurement of Broadband Performance (LMAP)' to Informational RFC (draft-ietf-lmap-framework-14.txt) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 12:23:34 -0000 Congratulations to the authors and to the whole Working Group! Regards, Dan > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of The IESG > Sent: Wednesday, April 29, 2015 7:51 PM > To: IETF-Announce > Cc: lmap mailing list; lmap chair; RFC Editor > Subject: [lmap] Document Action: 'A framework for Large-Scale > Measurement of Broadband Performance (LMAP)' to Informational RFC > (draft-ietf-lmap-framework-14.txt) >=20 > The IESG has approved the following document: > - 'A framework for Large-Scale Measurement of Broadband Performance > (LMAP)' > (draft-ietf-lmap-framework-14.txt) as Informational RFC >=20 > This document is the product of the Large-Scale Measurement of Broadband > Performance Working Group. >=20 > The IESG contact persons are Benoit Claise and Joel Jaeggli. >=20 > A URL of this Internet Draft is: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dlmap- > 2Dframework_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31Oc > NXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DU2O3ANmOFVmNo1R2lI5KoyfHSFj > T8SBqPQgEYX209ic&s=3D4ElngfQRZmiShxQ74FRRK7r39KWE2ZSJ1sqd5GjUZtM& > e=3D >=20 >=20 >=20 >=20 >=20 > Technical Summary >=20 > Measuring broadband service on a large scale requires a description > of the logical architecture and standardization of the key protocols > that coordinate interactions between the components. The document > presents an overall framework for large-scale measurements. It also > defines terminology for LMAP (large-scale measurement platforms). >=20 > Working Group Summary >=20 > The Working Group process was serious and a relative large number of > participants participated. Some of the points that required clarificati= on > and further editing were related to passive monitoring and to privacy. > ll ended in consensus behind the document as it was forwarded for > approval and publication. >=20 > Document Quality >=20 > The document was very carefully reviewed and discussed by a > large number of participants in the WG, because it contains key > information concerning the scope, architecture and components of > the recommended solutions. Several issues were debated for many > months, the resulting document includes a strong consensus of the > participants about the goals (and non goals) of LMAP and the path > to be taken by the IETF to provide a standard solution. >=20 > Personnel >=20 > Dan Romascanu is the document shepherd. Benoit Claise is the > responsible Area Director. >=20 >=20 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_lmap&d=3DAwICAg&c=3DBFpWQw8bsuKpl > 1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DU2O3A > NmOFVmNo1R2lI5KoyfHSFjT8SBqPQgEYX209ic&s=3DGHlOuSJ_sas6xXznqmJUF > 7Rqrt697Fu0tkezSNVfw8k&e=3D From nobody Thu Apr 30 06:53:45 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63721B2A8F for ; Thu, 30 Apr 2015 06:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EifS5Qjv2al8 for ; Thu, 30 Apr 2015 06:53:43 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143831B2A5F for ; Thu, 30 Apr 2015 06:53:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFANcyQlWHCzIm/2dsb2JhbABcgkUhJlNhs1oBAQEBAQEGBZk/AoFRTAEBAQEBAYELhCIBAQMSCxBeAQwJFVYmAQQbGogJAaRuhQaeGQwBH4YWiXaDT4EWBZFqi2uDS4JmilmDUCNggxSCM4EBAQEB X-IronPort-AV: E=Sophos;i="5.11,677,1422939600"; d="scan'208,217";a="114379286" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 30 Apr 2015 09:53:41 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 30 Apr 2015 09:53:41 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Thu, 30 Apr 2015 09:53:40 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: call for agenda items for the 5/11 LMAP WG interim meeting Thread-Index: AdCDTQ+wySFrYiT2R3iQzIiCn/P/Og== Date: Thu, 30 Apr 2015 13:53:39 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA14B07@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA14B07AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] call for agenda items for the 5/11 LMAP WG interim meeting X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 13:53:44 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA14B07AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The LMAP WG interim is scheduled for Monday 5/11 at 1PM EDT. Please send to Jason and me your requests for agenda items including the to= pic and requested amount of time. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA14B07AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The LMAP WG interim is scheduled for Monday 5/11 at = 1PM EDT.

 

Please send to Jason and me your requests for agenda= items including the topic and requested amount of time.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA14B07AZFFEXMB04globa_--